CN110866833A - 一种基于保险业务的投保方法 - Google Patents

Abstract

本发明提供一种基于保险业务的投保方法，包括：步骤S1、获取客户的投保信息，并根据投保信息创建一初始保险订单；步骤S2、获取初始保险订单的订单信息，并判断订单信息是否是见费支付；若是，则向客户提供一支付页面进行支付，并在支付完成之后转向投保服务；若否，则转向投保服务；步骤S3、接收客户的投保请求，以创建一初始投保记录，并持久化初始投保记录；步骤S4、操作初始投保记录的投保状态查询对应的保险产品，以根据保险产品匹配得到对应的投保服务通道，并进行投保输出投保结果；步骤S5、将投保结果通过投保服务通道发送至订单服务端，订单服务端接收投保结果，并将投保结果反馈至客户。有益效果，采用异步处理方式可以提高投保效率。

Description

一种基于保险业务的投保方法

技术领域

本发明涉及保险金融技术领域，尤其涉及一种基于保险业务的投保方法。

背景技术

随着保险行业业务的快速发展以及市场竞争的加强，保险行业的业务系统包括线下保险业务和线上渠道保险业务。在传统保险业务中，当前单体架构的核心业务系统运行稳定，从性能和功能均能满足传统线下保险业务。

随着线上渠道业务的快速发展，由于不同保险公司之间的业务和经验模式差异性较大，需要通用核心系统具有高度的模块化、参数化已经无法满足不同保险公司的需求，并且也无法保证保险业务系统的可拓展性和稳定性。结合以上问题，目前有必要梳理一套完整的关于核心业务系统的出单流程，以解决传统保险业务中存在的渠道对接的问题。

发明内容

针对现有技术中存在的上述问题，现提供一种基于保险业务的投保方法。

具体技术方案如下：

本发明提供一种基于保险业务的投保方法，其中，提供一订单服务端与一投保服务端，所述订单服务端委托所述投保服务端，采用异步处理的方式受理客户的投保请求；

所述订单服务端包括以下步骤：

步骤S1、获取客户的投保信息，并根据所述投保信息创建一初始保险订单；

步骤S2、获取所述初始保险订单的订单信息，并判断所述订单信息是否是见费支付；

若是，则向所述客户提供一支付页面进行支付，并在支付完成之后转向所述投保服务；

若否，则转向所述投保服务；

所述投保服务端包括以下步骤：

步骤S3、接收所述客户的投保请求，以创建一初始投保记录，并持久化所述初始投保记录；

步骤S4、操作所述初始投保记录的投保状态查询对应的保险产品，以根据所述保险产品匹配得到对应的投保服务通道，并进行投保输出投保结果；

步骤S5、将所述投保结果通过所述投保服务通道发送至所述订单服务端，所述订单服务端接收所述投保结果，并将所述投保结果反馈至所述客户。

优选的，于所述步骤S1包括：

步骤S10、获取客户的投保信息；

步骤S11、判断所述投保信息是否符合保险产品的投保要求；

若是，则创建所述初始保险订单，所述初始保险订单包括记录所述客户信息、购买保险产品信息以及被保险人信息；

若否，则退出。

优选的，于所述步骤S4中，所述投保服务通道调用对应的投保服务接口的过程包括以下步骤：

步骤S40、判断所述投保服务通道是否异常；

若是，则转向步骤S41；

若否，则删除所述投保服务通道的键值；

步骤S41、于一预设有效期内，记录所述投保服务通道的异常次数，每出现一次异常，将异常值的记录加一；

步骤S42、判断所述异常值是否小于一第一预设阈值；

若是，则调用对应述保险产品的投保服务接口；

若否，则将所述投保状态改为未知状态。

优选的，于所述步骤S42中，调用对应述保险产品的投保服务接口的过程中，

若发生异常，则查看所述投保服务通道的键值，并记录所述投保服务通道的键值；

若没有发生异常，则删除所述投保服务通道的键值。

优选的，所述第一预设阈值设置为10。

优选的，所述投保结果包括投保成功、投保失败或拒保、未知状态；

当所述投保结果处于所述未知状态时，还包括以下步骤：

步骤S43、判断所述投保记录的投保执行次数是否是第一次投保；

若是，则向系统负责人以及维护人员发送预警信息，并再发出所述预警信息后转向步骤S44；

若否，则转向步骤S44；

步骤S44、将所述投保记录修改为待投保状态，进行所述初始投保记录的投保重试状态。

优选的，于所述投保重试状态的过程包括以下步骤：

步骤S440、在一预设时间内，通过一查询条件对所述投保记录进行定时查询，并调用所述投保服务端的查询接口查询所述投保结果；

步骤S441、当所述投保重试状态的查询次数达到一第二预设阈值时，将所述投保记录修改为停用，并向发送所述预警信息。

优选的，所述第二预设阈值为5。

优选的，所述预设时间段设置为一分钟。

优选的，所述查询条件包括：

所述投保状态设置为待投保；

所述投保重试状态设置为启用；

所述下次执行时间设置为当前时间。

本发明的技术方案有益效果在于：提供一种基于保险业务的投保方法，订单服务端委托投保服务端采用异步处理的方式受理客户的投保请求，采用异步处理方式可以为每个投保通道分配不同的线程并发调用投保服务接口，不影响其他通道，已满足不同保险公司的需求，并且也能够保证保险业务系统的可拓展性和稳定性。

附图说明

参考所附附图，以更加充分的描述本发明的实施例。然而，所附附图仅用于说明和阐述，并不构成对本发明范围的限制。

图1为本发明的实施例的基于保险业务的投保方法的步骤流程图；

图2为本发明的实施例的基于保险业务的投保方法的步骤S1的步骤流程图；

图3为本发明的实施例的基于保险业务的投保方法的步骤S4的实施例一的步骤流程图；

图4为本发明的实施例的基于保险业务的投保方法的步骤S4的实施例二的步骤流程图；

图5为本发明的实施例的基于保险业务的投保方法的投保重试状态的过程的步骤流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

下面结合附图和具体实施例对本发明作进一步说明，但不作为本发明的限定。

本发明包括一种基于保险业务的投保方法，其中，提供一订单服务端与一投保服务端，订单服务端委托投保服务端，采用异步处理的方式受理客户的投保请求；

订单服务端包括以下步骤：

步骤S1、获取客户的投保信息，并根据投保信息创建一初始保险订单；

步骤S2、获取初始保险订单的订单信息，并判断订单信息是否是见费支付；

若是，则向客户提供一支付页面进行支付，并在支付完成之后转向投保服务；

若否，则转向投保服务；

投保服务端包括以下步骤：

步骤S3、接收客户的投保请求，以创建一初始投保记录，并持久化初始投保记录；

步骤S4、操作初始投保记录的投保状态查询对应的保险产品，以根据保险产品匹配得到对应的投保服务通道，并进行投保输出投保结果；

步骤S5、将投保结果通过投保服务通道发送至订单服务端，订单服务端接收投保结果，并将投保结果反馈至客户。

通过上述基于保险业务的投保方法的技术方案，如图1所示，该投保方法基于一投保管理平台，该投保管理平台提供基于http协议的接口和H5应用两种方式投保。该投保管理平台包括应用层、服务层以及数据层，其中该应用层包含投保API接口、H5应用、管理终端等，即只包含各应用的逻辑，该服务层提供订单、支付、投保等核心服务，该数据层目前只用到mysql、redis。

进一步地，该投保管理平台主要使用应用程序开源框架spring framework和Tomcat，应用层与服务层及服务层之间通过java RPC框架dubbo框架通信，服务层与数据层使用了mybatis plus，是持久层框架mybatis的增强工具，Redis的访问通过springdataredis，它对reids底层开发包(Jedis，JRedis，and RJC)进行了高度封装，RedisTemplate提供了redis各种操作、异常处理及序列化，支持发布订阅，并对spring3.1cache进行实现。

进一步地，该投保管理平台包括订单服务端与投保服务端，在订单服务端收到客户的投保单信息后，首先对投保单数据根据保险产品的约束做校验，在校验通过后创建初始保险订单，主要记录客户、购买保险产品的基本信息以及被保险人等信息，如果出单模式是见费，需要先通过支付服务完成付款，目前，仅个人客户在H5应用投保，需要通过第三方支付平台，例如可以通过微信完成支付保费；如果是非见费模式，直接把订单委托给投保服务端向保险公司进行投保。

进一步地，基于保险业务的投保方法包括两种方式投保，其中一种是投保服务端首先创建投保记录，主要反应订单向保司投保的过程，包含平台订单号、保险产品对应保司的产品信息，投保状态等，其中，不同的保险产品，保司可能会提供基于http协议的投保服务接口和线下投保两种方式。该实施例中的实现主要是线上投保。另一种是如果保司承保，直接进行投保并记录保司保单号和保单信息。

进一步地，投保服务端采用异步处理的方式受理客户的投保请求，采用异步处理方式可以为每个投保通道分配不同的线程并发调用投保服务接口，不影响其他通道，已满足不同保险公司的需求，并且也能够保证保险业务系统的可拓展性和稳定性。

在一种较优的实施例中，当订单满足投保条件后，交给投保服务端完成投保，投保服务端采用异步事件的方式处理，其中在异步事件的处理过程中，该投保管理平台提供的投保控制器作为事件监听者处理投保事件，首先根据产品代码找到对应投保通道及通道配置，然后由投保通道调用投保服务接口投保，当投保控制器通过投保通道得到保司投保结果后，首先通知订单服务端，然后由订单服务端通知客户。

进一步地，投保服务接口可以选用InsuranceDubbo接口，InsuranceDubbo接口是投保服务端基于dubbo的RPC(Remote Procedure Call Protocol，远程过程调用协议)接口，提供投保、查询投保结果等方法，也是投保服务对订单服务的边界。

进一步地，投保服务端的投保方法实现逻辑包括首先委托投保控制器受理投保请求，然后构建并发布投保事件，查询投保结果委托投保服务接口。

进一步地，投保服务端的投保过程的处理对象是投保控制器，投保控制器是主要提供受理投保请求方法和投保方法。受理投保请求方法主要根据订单服务传的参数创建一条初始状态的初始投保记录，并持久化它，初始投保记录初始值包括执行次数为0、重试状态为启用、投保状态为待投保、下次执行时间为5分钟后。投保方法首先修改投保记录状态为投保中，然后根据保险产品代码找到对应投保通道和通道配置。其中，投保通道和保险产品的关系是在投保管理平台维护在数据的，通道配置是接入保险公司的接口时维护在系统的，然后投保通道实现和保司通信投保，在该实施例中采用了代理模式对投保通道加了投保通道调用投保服务接口的方式，最后处理投保通道输出投保结果。

进一步地，投保结果包括投保成功、投保失败或拒保、投保未知等三种状态，前两种状态表示投保完成，即将修改投保记录，并发布投保完成事件。未知状态是中间状态，即此时在投保记录里记录执行次数和下次执行时间，并修改投保状态为待投保，待重试机制触发重试，以进行投保重试状态的过程，若第一次投保，则发送预警信息。

进一步地，投保服务端的投保事件的模式线程数是有限的，避免某个投保通道响应时间太长，阻塞所有线程，导致整个投保服务吞吐量下降。该投保方法为每个投保通道分配不同的线程数调用保司投保接口，实现线程池隔离，从而不会影响其他通道。进一步地，投保通道负责调用保司投保接口。投保服务是投保过程逻辑的封装，确保投保过程逻辑在数据库写入的数据是一致的，且投保事件采用的spring异步事件框架，主要包含事件对象、事件发布者、事件监听者、广播等。

进一步地，在投保的过程中，投保记录的投保状态包括待投保、投保中、投保完成，订单服务端调用投保服务提供的RPC接口InsuranceDubbo投保，InsuranceDubbo接口的实现过程是投保服务的边界也是事件发布者，首先委托投保控制器受理投保请求，然后构建投保事件并发布到spring管理的事件广播器，最后响应订单服务投保受理结果。投保控制器的实现担当了投保事件监听者的角色，该投保控制器监听到投保事件后，调用自身投保方法完成投保逻辑，如果投保完成并发布完成事件，最后投保完成事件的监听者，会创建保单，通知订单服务投保结果。

进一步地，订单服务端委托投保服务端采用异步处理的方式受理客户的投保请求，采用异步处理方式可以为每个投保通道分配不同的线程并发调用投保服务接口，不影响其他通道，进而提高系统吞吐量。

上述技术方案中，作为较优的实施方式，于步骤S1包括：

步骤S10、获取客户的投保信息；

步骤S11、判断投保信息是否符合保险产品的投保要求；

若是，则创建初始保险订单，初始保险订单包括记录客户信息、购买保险产品信息以及被保险人信息；

若否，则退出。

具体地，如图2所示，订单服务端主要包括核保校验，目前核保校验只根据保险产品的约束做校验，其中包含参数校验和业务规则校验，参数校验为字段校验，必要字段非空校验和格式校验，目前采用开源工具Hibernate Validator实现；业务规则校验，主要校验被保人是否符合保险产品投保要求。并且，该投保管理平台的订单校验以及出单模式都是保险产品上线前在该投保管理平台维护好的，订单服务对客户、产品、校验、出单方式的维护关系使用了缓存，进而提高了查询效率。

上述技术方案中，作为较优的实施方式，于步骤S4中，投保服务通道调用对应的投保服务接口的过程包括以下步骤：

步骤S40、判断投保服务通道是否异常；

若是，则转向步骤S41；

若否，则删除投保服务通道的键值；

步骤S41、于一预设有效期内，记录投保服务通道的异常次数，每出现一次异常，将异常值的记录加一；

步骤S42、判断异常值是否小于一第一预设阈值，第一预设阈值设置为10；

若是，则调用对应述保险产品的投保服务接口；

若否，则将投保状态改为未知状态。

进一步地，于步骤S42中，调用对应述保险产品的投保服务接口的过程中，

若发生异常，则查看投保服务通道的键值，并记录投保服务通道的键值；

若没有发生异常，则删除投保服务通道的键值。

具体地，如图3所示，在投保服务端根据订单信息通过投保服务接口完成投保，记录保单信息并通知企业客户，并且在捕获到投保异常，发出报警邮件，投保重试3次，然后每5分钟重试1次，重试5次后转人工处理并邮件通知。

进一步地，投保服务通道调用对应的投保服务接口的过程中，连续多次调用投保服务接口异常，并将在接下时间段不会再调用投保服务接口，直接返回缺省结果。这里的多次、时间段是可配置的，根据实际情况调整。

具体过程包括，Redis可以方便的为键值(key)配置有效期，例如设置一个1分钟有效期的键值(key)记录投保通道的投保方法异常次数(其中，redis数字类型默认值为0)。当投保服务接口出现一次异常记作异常值加1，正常删除键值(key)。

例如，在实现的过程中，在调用目标投保通道对象的投保方法之前先检测异常值是否小于阈值10，若小于10，调用目标投保通道的投保方法，(含键值(key)不存在的情况)；若大于等于10，构建缺省投保结果(未知状态status＝unknown)。

进一步地，如果调用目标投保通道的投保方法出现异常，首先查看redis里面是否有键值(key)，当键值(key)不存在时，设置键值(key)有效期1分钟并异常值+1，例如，INCR(键值(key)，1)；expire(键值(key)，1000)；当键值(key)存在，则异常值加1；如果调用目标投保通道的投保方法没有异常，删除redis里面的键值(key)。进一步地，通过投保服务通道调用对应的投保服务接口，操作简单，提高投保效率。

上述技术方案中，作为较优的实施方式，投保结果包括投保成功、投保失败或拒保、未知状态；

当投保结果处于未知状态时，还包括以下步骤：

步骤S43、判断投保记录的投保执行次数是否是第一次投保；

若是，则向系统负责人以及维护人员发送预警信息，并再发出预警信息后转向步骤S44；

若否，则转向步骤S44；

步骤S44、将投保记录修改为待投保状态，进行初始投保记录的投保重试状态。

进一步地，于投保重试状态的过程包括以下步骤：

步骤S440、在一预设时间内，通过一查询条件对投保记录进行定时查询，并调用投保服务端的查询接口查询投保结果，其中，预设时间段设置为一分钟，查询条件包括：投保状态设置为待投保；投保重试状态设置为启用；下次执行时间设置为当前时间；

步骤S441、当投保重试状态的查询次数达到一第二预设阈值时，将投保记录修改为停用，并向发送预警信息，其中，第二预设阈值为5。

具体地，结合图4、5所示，投保重试状态的过程中，定时任务每分钟触发一次，使重试任务从数据库根据查询条件查询投保记录，其中查询条件包括投保状态为待投保，重试状态为启用，下次执行时间为当前时间，然后委托投保重试，与投保方法不同的是，先通过保司提供的查询接口查询投保结果，如果保司没有提供查询接口或保司没有收到投保请求，会调用原投保方法。

进一步地，在投保重试状态的过程中，如果重试次数超过阈值5次，修改投保记录重试状态为停用，并发送报警邮件。这样定时任务不再查询该投保记录，由人工接管。

可拓展地，修改投保记录的重试状态为启用和下次执行时间，依托上面的定时任务实现自动重试，重投是指为订单产生新的投保记录投保，投保逻辑不变。进一步增加投保重试状态的过程能够提高投保效率。

进一步地，可拓展地，通常为了提高查询效率、减小数据库压力，该投保管理平台对系统配置信息及产品信息都会做缓存以及日志系统，其中系统缓存是基于Redis实现，日志系统用于运维搭建提供的服务。

以上所述仅为本发明较佳的实施例，并非因此限制本发明的实施方式及保护范围，对于本领域技术人员而言，应当能够意识到凡运用本发明说明书及图示内容所作出的等同替换和显而易见的变化所得到的方案，均应当包含在本发明的保护范围内。

Claims (10)

1.一种基于保险业务的投保方法，其特征在于，提供一订单服务端与一投保服务端，所述订单服务端委托所述投保服务端，采用异步处理的方式受理客户的投保请求；

所述订单服务端包括以下步骤：

步骤S1、获取客户的投保信息，并根据所述投保信息创建一初始保险订单；

步骤S2、获取所述初始保险订单的订单信息，并判断所述订单信息是否是见费支付；

若是，则向所述客户提供一支付页面进行支付，并在支付完成之后转向所述投保服务；

若否，则转向所述投保服务；

所述投保服务端包括以下步骤：

步骤S3、接收所述客户的投保请求，以创建一初始投保记录，并持久化所述初始投保记录；

步骤S4、操作所述初始投保记录的投保状态查询对应的保险产品，以根据所述保险产品匹配得到对应的投保服务通道，并进行投保输出投保结果；

步骤S5、将所述投保结果通过所述投保服务通道发送至所述订单服务端，所述订单服务端接收所述投保结果，并将所述投保结果反馈至所述客户。

2.根据权利要求1所述的基于保险业务的投保方法，其特征在于，于所述步骤S1包括：

步骤S10、获取客户的投保信息；

步骤S11、判断所述投保信息是否符合保险产品的投保要求；

若是，则创建所述初始保险订单，所述初始保险订单包括记录所述客户信息、购买保险产品信息以及被保险人信息；

若否，则退出。

3.根据权利要求1所述的基于保险业务的投保方法，其特征在于，于所述步骤S4中，所述投保服务通道调用对应的投保服务接口的过程包括以下步骤：

步骤S40、判断所述投保服务通道是否异常；

若是，则转向步骤S41；

若否，则删除所述投保服务通道的键值；

步骤S41、于一预设有效期内，记录所述投保服务通道的异常次数，每出现一次异常，将异常值的记录加一；

步骤S42、判断所述异常值是否小于一第一预设阈值；

若是，则调用对应述保险产品的投保服务接口；

若否，则将所述投保状态改为未知状态。

4.根据权利要求3所述的基于保险业务的投保方法，其特征在于，于所述步骤S42中，调用对应述保险产品的投保服务接口的过程中，

若发生异常，则查看所述投保服务通道的键值，并记录所述投保服务通道的键值；

若没有发生异常，则删除所述投保服务通道的键值。

5.根据权利要求3所述的基于保险业务的投保方法，其特征在于，所述第一预设阈值设置为10。

6.根据权利要求1所述的基于保险业务的投保方法，其特征在于，所述投保结果包括投保成功、投保失败或拒保、未知状态；

当所述投保结果处于所述未知状态时，还包括以下步骤：

步骤S43、判断所述投保记录的投保执行次数是否是第一次投保；

若是，则向系统负责人以及维护人员发送预警信息，并再发出所述预警信息后转向步骤S44；

若否，则转向步骤S44；

步骤S44、将所述投保记录修改为待投保状态，进行所述初始投保记录的投保重试状态。

7.根据权利要求6所述的基于保险业务的投保方法，其特征在于，于所述投保重试状态的过程包括以下步骤：

步骤S440、在一预设时间内，通过一查询条件对所述投保记录进行定时查询，并调用所述投保服务端的查询接口查询所述投保结果；

步骤S441、当所述投保重试状态的查询次数达到一第二预设阈值时，将所述投保记录修改为停用，并向发送所述预警信息。

8.根据权利要求7所述的基于保险业务的投保方法，其特征在于，所述第二预设阈值为5。

9.根据权利要求7所述的基于保险业务的投保方法，其特征在于，所述预设时间段设置为一分钟。

10.根据权利要求7所述的基于保险业务的投保方法，其特征在于，所述查询条件包括：

所述投保状态设置为待投保；

所述投保重试状态设置为启用；

所述下次执行时间设置为当前时间。

Images