CN106384290A - 保单处理系统、方法及装置 - Google Patents

Abstract

本申请公开一种保单处理系统、方法及装置。该保单处理系统包括：多个客户端、承保系统及保单管理系统；其中，保单管理系统用于投保保单的处理；承保系统用于：接收客户端发送的投保请求消息，投保请求消息中包括：投保保单的信息；存储投保保单的信息；向客户端返回投保成功消息；以及每隔一预定时间，读取存储的投保保单的信息，并将投保保单的信息发送至保单管理系统进行处理。该保单处理系统能够提升保单管理系统的安全性、可靠性及承保效率。

Description

保单处理系统、方法及装置

技术领域

本发明涉及计算机数据处理技术领域，具体而言，涉及一种保单处理系统、方法及装置。

背景技术

美国CSC(Computer Sciences Corporation)公司作为保险核心软件提供商，其提供的保单管理系统可以运行在IBM公司的iSeries服务器上。在使用CSC保单管理系统进行承保时，该系统通过BO(Business Object，业务对象层)接口向外围多个渠道的投保客户端(包括网站、电销、两核系统等)提供保单投保服务。各个渠道的客户端通过消息队列MQ的方式调用CSC保单管理系统的BO接口，将保单信息存储到CSC保单管理系统中，完成保单的承保。

目前，当客户或业务员通过客户端提交投保申请时，客户端会多次与CSC保单管理系统进行服务交互，使得客户端响应缓慢，客户或业务员体验度差，保单承保效率低下。

并且，由于根据不同渠道划分了多个客户端(如MSS客户端、微信客户端、网站客户端、电销系统客户端、银保通客户端、养老客户端等)进行保单投保，而CSC保单管理系统提供的是较细粒度的服务接口，每个客户端进行投保时都要多次与CSC保单管理系统进行消息交互，才能将保单的全部信息保存进CSC保单管理系统中。当CSC保单管理系统中定义的产品或业务场景发生变化需要改动接口服务时，各个客户端均要配合进行改动，牵一发而动全身，导致重复的工作量加大，系统间的交互风险也会提高。

此外，各个客户端可以无休止的直接与CSC保单管理系统进行消息交互，当交互频率达到一定程度时，使得CSC保单管理系统服务器压力过大，从而导致CSC保单管理系统的安全性、可靠性降低，不利于对保单管理系统进行有效把控。

在所述背景技术部分公开的上述信息仅用于加强对本发明的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

有鉴于此，本发明提供一种保单处理系统、方法及装置，能够提升保单管理系统的安全性、可靠性及承保效率。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

根据本发明的一方面，提供一种保单处理系统，包括：多个客户端、承保系统及保单管理系统；其中，保单管理系统用于投保保单的处理；承保系统用于：接收客户端发送的投保请求消息，投保请求消息中包括：投保保单的信息；存储投保保单的信息；向客户端返回投保成功消息；以及每隔一预定时间，读取存储的投保保单的信息，并将投保保单的信息发送至保单管理系统进行处理。

根据本发明的一实施方式，将投保保单的信息发送至保单管理系统进行处理包括：通过JDK API提供的接口将投保保单的信息转换成文件对象；通过JAVA反射机制将文件对象中的数据存储至JAVA虚拟机内存中；以及通过消息队列调用保单管理系统，以将文件对象发送至保单管理系统进行处理。

根据本发明的一实施方式，承保系统采用负载均衡的分布式多服务器架构。

根据本发明的一实施方式，分布式多服务器中的每台服务器设置线程池，采用多线程方式，使每个线程通过消息对了调用保单管理系统。

根据本发明的一实施方式，线程池的大小根据服务器的性能设定。

根据本发明的一实施方式，承保系统包括：数据库服务器；存储投保保单的信息包括：将投保保单的信息存储至数据库服务器中。

根据本发明的一实施方式，数据服务器包括：数据库连接池，数据库连接池的大小根据数据服务器的性能设定。

根据本发明的一实施方式，承保系统向多个客户端提供统一的WEB服务接口，多个客户端通过WEB服务接口向承保系统发送投保请求消息。

根据本发明的一实施方式，在接收客户端发送的投保请求消息之后，承保系统还用于校验投保保单的信息，以确保投保保单的信息的正确性。

根据本发明的一实施方式，承保系统还用于通过一可调节频率读取存储的投保保单的信息，以控制保单管理系统对投保保单的信息的处理量。

根据本发明的一实施方式，在读取存储的投保保单的信息之前，承保系统还用于对存储的投保保单的信息进行排序。

根据本发明的一实施方式，承保系统通过多次发送投保保单的不同信息至保单管理系统，控制投保保单在保单管理系统中的状态。

根据本发明的另一个方面，提供一种保单处理方法，包括：接收客户端发送的投保请求消息，投保请求消息中包括：投保保单的信息；存储投保保单的信息；向客户端返回投保成功消息；以及每隔一预定时间，读取存储的投保保单的信息，并将投保保单的信息发送至保单管理系统进行处理。

根据本发明的一实施方式，将投保保单的信息发送至保单管理系统进行处理包括：通过JDK API提供的接口将投保保单的信息转换成文件对象；通过JAVA反射机制将文件对象中的数据存储至JAVA虚拟机内存中；以及通过消息队列调用保单管理系统，以将文件对象发送至保单管理系统进行处理。

根据本发明的再一个方面，提供一种保单处理装置，包括：消息接收模块，用于接收客户端发送的投保请求消息，投保请求消息中包括：投保保单的信息；信息存储模块，用于存储投保保单的信息；消息返回模块，用于向客户端返回投保成功消息；以及信息传递模块，用于每隔一预定时间，读取存储的投保保单的信息，并将投保保单的信息发送至保单管理系统进行处理。

根据本发明的一实施方式，信息传递模块包括：数据转换子模块，用于通过JDKAPI提供的接口将投保保单的信息转换成文件对象；数据存储子模块，用于通过JAVA反射机制将文件对象中的数据存储至JAVA虚拟机内存中；以及消息调用子模块，用于通过消息队列调用保单管理系统，以将文件对象发送至保单管理系统进行处理。

根据本发明的保单处理系统、方法及装置，在处理客户端发起的投保业务时，可以使得客户端仅需一次交互就将保单信息传递给保单管理系统进行投保处理，系统响应快，使得客户或业务员的在投保时的用户体验度高。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本发明。

附图说明

通过参照附图详细描述其示例实施例，本发明的上述和其它目标、特征及优点将变得更加显而易见。

图1是根据一示例性实施方式示出的保单处理系统的框图。

图2是根据一示例性实施方式示出的一种保单处理方法的流程图。

图3是根据一示例性实施方式示出的一种保单处理装置的框图。

图4是根据一示例性实施方式示出的另一种保单处理装置的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本发明的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本发明的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知结构、方法、装置、实现或者操作以避免喧宾夺主而使得本发明的各方面变得模糊。

图1是根据一示例性实施方式示出的保单处理系统的框图。如图1所示，该保单处理系统1包括：多个客户端11、承保系统12及保单管理系统系统13。

其中客户端11用于为客户和业务人员提供投保服务，例如可以包括：MSS(MarketSupport Systerm，销售支持系统)客户端、微信客户端、网站客户端、电销系统客户端、银保通客户端、养老客户端等。

承保系统12与客户端11通信连接，其通过所提供的接口，为客户端11提供投保服务。承保系统12可以由独立的服务器组成，或者也可以由多个分布式服务器组成。

保单管理系统13例如为CSC保单管理系统，与承保系统12通信连接，用于处理承保系统12提供的承保保单。

图2是根据一示例性实施方式示出的一种保单处理方法的流程图。该方法可应用于图1所示的承保系统12中。联合参考图1和图2，该方法10包括：

在步骤S102中，接收客户端11发送的投保请求消息。

例如，承保系统12基于其提供的接口，接收客户端11发送的投保请求消息，该投保请求消息中包括：待处理的投保保单信息。保单信息例如包括：投保人、保单号、公司号等。

承保系统12例如可以使用JAVA语言开发，并提供一套统一、规范的WEB服务接口，供客户端11使用。该服务接口例如可以使用开源Axis(Apache Extensible InteractionSystem)架构技术开发。如图1所示，各个投保客户端11只需按照该服务规范的定义，将保单信息进行封装，一次性调用承保系统12提供的服务接口，将投保请求消息发送给承保系统12即可。

承保系统12对外提供统一兼容接口，并可以提供特殊流程定制。前端任意客户端11有任何正常业务流程需求，承保系统12都能在不影响其他前端客户端11的前提下实现相关功能。

由于客户端11只需调用一次承保系统12提供的接口将保单信息传递过去，系统响应快。客户或业务员在客户端投保时，体验度提高。

此外，当保单管理系统系统13中定义的产品或业务场景发生变化需要改动接口服务时，只需要相应调整保单管理系统系统13即可，改动工作量小、涉及系统少，前端客户端11无感知，系统间的交互风险也大大降低。

在一些实施例中，承保系统12还可以对接收的投保请求消息中的保单信息，如投保人、保单号、公司号进行初步校验，以确保保单信息的正确性。比如，客户端11自动生成公司号、保单号后，承保系统12接收到客户端11保单信息，会校验当前保单信息的公司号、保单号的任意一项不能为空，并且当前保单的公司号+保单号不能和既往的公司号+保单号重复。上述情况，任意一种发生，承保系统12会立即返回前端客户端11。承保系统12在对保单进行承保过程中，会对投保人信息、被保人信息的有效性、准确性等做初步校验。同时，承保系统12提供异常处理功能页面。保单的信息校验有问题时，保单会进入那个异常处理页面。然后由人工介入处理，人工处理完后点击提交，保单会继续后续承保流程。在步骤S104中，存储待处理的投保保单信息。

承保系统12存储投保保单信息，例如承保系统12包括数据库服务器，承保系统12将投保保单信息保存在自己的数据库服务器中。

在步骤S106中，向客户端11返回保单投保成功消息。

承保系统12向客户端11返回保单投保成功消息，以通知客户或业务人员投保成功。

在步骤S108中，每隔一预定时间，读取存储的待处理的投保保单信息，并将该待处理的投保保单信息发送至保单管理系统13进行处理。

例如，承保系统12通过定时任务或定时器等定时机制，定时从存储待处理的投保保单信息的装置(如本地数据库)中读取待处理的投保保单信息；之后，可以使用JDK API中org.w3c.dom.Document接口将接收到的消息转换成Document(文件)对象，并使用JAVA反射机制将上述Document对象中的数据存入JAVA虚拟机内存中；再通过消息队列(如IBM MQ)调用保单管理系统13，将当前处理的保单进行投保。保单信息最终成功在保单管理系统13中承保。

承保系统12还可以采用负载均衡分布式多服务器架。此外，每台服务器还可以采用JAVA多线程的处理方式。每个线程依次通过消息队列调用保单管理系统13，进行保单承保。承保系统12采用JAVA API中无界阻塞队列(JAVA.util.concurrent.PriorityBlockingQueue)配合JAVA API中多线程(JAVA.util.concurrent.ThreadPoolExecutor)模式处理保单承保过程。通过建立数据库连接池使应用采用JNDI(JAVA Naming and Directory Interface，JAVA命名和目录接口)的方式访问数据库资源。采用负载均衡和多线程的处理方式，能够在保证保单管理系统13稳定的情况下，使承保系统12实现最大程度的保单吞吐量，实现保单高时效承保。

为了保证承保系统12中的数据库服务器性能，还可以根据承保系统12的服务器性能，来设定数据库服务器中数据库连接池的大小；并在保证应用服务器性能的前提下来，根据服务器性能，设定应用线程池的大小。其中，例如可以使用无界阻塞队列的PriorityBlockingQueue<Object>(initSize,null)实例来实现。通过配置文件的方式对无界阻塞队列做了最大值限制(initSize为队列大小，可在配置文件中灵活调整其大小)，使其成为有界队列；并且使用ThreadPoolExecutor(corePoolSize,maximumPoolSize,keepAliveTime,TimeUnit.SECONDS,new LinkedBlockingQueue(workQueueSize))实例来实现线程池的大小灵活配置(其中corePoolSize表示池中所保存的线程数，包括空闲线程；maximumPoolSize-池中允许的最大线程数；keepAliveTime-当线程数大于核心时，此为终止前多余的空闲线程等待新任务的最长时间；TimeUnit.SECONDS-keepAliveTime参数的时间单位为秒；workQueueSize-执行前用于保持任务的队列。此队列仅保持由execute方法提交的Runnable任务。这几个线程属性全部可在配置文件中灵活调整其大小)。在保证数据库连接池最大连接数和应用线程池最大线程数平衡的前提下，充分利用服务器的软硬件资源，最高效率的进行保单承保。

承保过程还可以由多个细粒度的逻辑操作单元组成，每个操作单元发生异常后，流程暂时中止，后台数据库会做相关记录。同时操作人员可以通过承保系统12的操作页面查看当前保单的异常信息，进行人工修改后，保单会重新触发其发生异常的业务单元，并完成后续业务流程操作(如与保单管理系统13的信息交互，保证保单在保单管理系统13中正常承保)。承保系统12与手工单系统结合也提供了比较完善的保单异常处理流程，来应对新契约保单在承保流程中发生的各种异常情况，并保证保单最终正常承保。

承保系统12通过可调节的频率将暂存的保单信息从本地数据库中读取出来，与保单管理系统13进行消息交互。使得保单管理系统13的服务器可以控制在一个安全、稳定的范围内，最大程度的进行新契约保单承保流程。也即承保系统12通过可调节频率实现保单处理量的流量控制，从而保证在一定时间内发送到保单管理系统13的保单处理量在一个合理的范围内，避免保单管理系统13的负荷过重。该可调节的频率例如可以实现为，以上述预设时间向保单管理系统13发送可调数据量的待处理保单；或者也可以实现为以可调的预设时间向保单管理系统13发送定量的待处理保单；再或者也可以预设时间及所发送的保单数据量均为可调，本发明不以此为限。

此外，承保系统12还可以提供对保单的排序优化功能，例如可以根据保单的优先级，对暂存在其本地数据库中的保单进行排序，从而保证高优先级的投保保单被先发送到保单管理系统13中进行处理。

如图1所示，承保系统12与保单管理系统13进行多次数据交互过程中，承保系统12根据每次传递不同信息到保单管理系统13，以这种方式来灵活控制保单在保单管理系统中的状态。同时，承保系统12作为流程系统，保单状态大致可以分为“已受理状态”(承保系统12向保单管理系统13推送保单基本信息后)、“已录入状态”(承保系统12向保单管理系统13推送保单险种信息后)、“待核保状态”(承保系统12向保单管理系统13推送保单保费等信息后)、“签发状态”(承保系统12向保单管理系统13推送签发标记后)。承保系统12也会根据各种业务场景的要求，进行灵活配置，保证保单在正常承保流程中，可以暂停到任意想要的状态。这样可以完全支持各种业务节点的要求，例如：元旦开门红期间，要求所有保单均在预承保状态，最后元旦当天所有保单集体做签发动作。

本发明实施方式的保单处理方法，在处理客户端发起的投保业务时，可以使得客户端仅需一次交互就将保单信息传递给保单管理系统进行投保处理，系统响应快，使得客户或业务员的在投保时的用户体验度高。

本领域技术人员可以理解实现上述实施方式的全部或部分步骤被实现为由CPU执行的计算机程序。在该计算机程序被CPU执行时，执行本发明提供的上述方法所限定的上述功能。所述的程序可以存储于一种计算机可读存储介质中，该存储介质可以是只读存储器，磁盘或光盘等。

此外，需要注意的是，上述附图仅是根据本发明示例性实施方式的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

下述为本发明装置实施例，可以用于执行本发明方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明方法实施例。

图3是根据一示例性实施方式示出的一种保单处理装置的框图。该保单处理装置例如可应用于图1所示的承保系统12。联合图1和图3所示，保单处理装置20包括：消息接收模块202、信息存储模块204、消息返回模块206及信息传递模块208。

其中消息接收模块202用于接收客户端发送的投保请求消息，投保请求消息中包括：投保保单的信息。

信息存储模块204用于存储投保保单的信息。

消息返回模块206用于向客户端返回投保成功消息。

信息传递模块208用于每隔一预定时间，读取存储的投保保单的信息，并将投保保单的信息发送至保单管理系统进行处理。

本发明实施方式的保单处理装置，在处理客户端发起的投保业务时，可以使得客户端仅需一次交互就将保单信息传递给保单管理系统进行投保处理，系统响应快，使得客户或业务员的在投保时的用户体验度高。

图4是根据一示例性实施方式示出的另一种保单处理装置的框图。该装置也可以应用于图1所示的承保系统12中。与图3所示的装置20不同的是，图4所示的装置30中的信息传递模块308包括：数据转换子模块3082、数据存储子模块3084及消息调用子模块3086。

其中，数据转换子模块3082用于通过JDK API提供的接口将投保保单的信息转换成文件对象。

数据存储子模块3084用于通过JAVA反射机制将文件对象中的数据存储至JAVA虚拟机内存中。

消息调用子模块3086用于通过消息队列调用保单管理系统，以将文件对象发送至保单管理系统进行处理。

需要注意的是，上述附图中所示的框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本发明实施方式的方法。

以上具体地示出和描述了本发明的示例性实施方式。应可理解的是，本发明不限于这里描述的详细结构、设置方式或实现方法；相反，本发明意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (16)

1.一种保单处理系统，其特征在于，包括：多个客户端、承保系统及保单管理系统；其中，所述保单管理系统用于投保保单的处理；所述承保系统用于：

接收所述客户端发送的投保请求消息，所述投保请求消息中包括：投保保单的信息；

存储所述投保保单的信息；

向所述客户端返回投保成功消息；以及

每隔一预定时间，读取存储的所述投保保单的信息，并将所述投保保单的信息发送至所述保单管理系统进行处理。

2.根据权利要求1所述的系统，其特征在于，将所述投保保单的信息发送至所述保单管理系统进行处理包括：

通过JDK API提供的接口将所述投保保单的信息转换成文件对象；

通过JAVA反射机制将所述文件对象中的数据存储至JAVA虚拟机内存中；以及

通过消息队列调用所述保单管理系统，以将所述文件对象发送至所述保单管理系统进行处理。

3.根据权利要求2所述的系统，其特征在于，所述承保系统采用负载均衡的分布式多服务器架构。

4.根据权利要求3所述的系统，其特征在于，所述分布式多服务器中的每台服务器设置线程池，采用多线程方式，使每个线程通过所述消息对了调用所述保单管理系统。

5.根据权利要求4所述的系统，其特征在于，所述线程池的大小根据所述服务器的性能设定。

6.根据权利要求1或2所述的系统，其特征在于，所述承保系统包括：数据库服务器；存储所述投保保单的信息包括：将所述投保保单的信息存储至所述数据库服务器中。

7.根据权利要求6所述的系统，其特征在于，所述数据服务器包括：数据库连接池，所述数据库连接池的大小根据所述数据服务器的性能设定。

8.根据权利要求1或2所述的系统，其特征在于，所述承保系统向所述多个客户端提供统一的WEB服务接口，所述多个客户端通过所述WEB服务接口向所述承保系统发送所述投保请求消息。

9.根据权利要求1或2所述的系统，其特征在于，在接收所述客户端发送的投保请求消息之后，所述承保系统还用于校验所述投保保单的信息，以确保所述投保保单的信息的正确性。

10.根据权利要求1或2所述的系统，其特征在于，所述承保系统还用于通过一可调节频率读取存储的所述投保保单的信息，以控制所述保单管理系统对所述投保保单的信息的处理量。

11.根据权利要求1或2所述的系统，其特征在于，在读取存储的所述投保保单的信息之前，所述承保系统还用于对存储的所述投保保单的信息进行排序。

12.根据权利要求1或2所述的系统，其特征在于，所述承保系统通过多次发送所述投保保单的不同信息至所述保单管理系统，控制所述投保保单在所述保单管理系统中的状态。

13.一种保单处理方法，其特征在于，包括：

接收所述客户端发送的投保请求消息，所述投保请求消息中包括：投保保单的信息；

存储所述投保保单的信息；

向所述客户端返回投保成功消息；以及

每隔一预定时间，读取存储的所述投保保单的信息，并将所述投保保单的信息发送至所述保单管理系统进行处理。

14.根据权利要求13所述的方法，其特征在于，将所述投保保单的信息发送至所述保单管理系统进行处理包括：

通过JDK API提供的接口将所述投保保单的信息转换成文件对象；

通过JAVA反射机制将所述文件对象中的数据存储至JAVA虚拟机内存中；以及

通过消息队列调用所述保单管理系统，以将所述文件对象发送至所述保单管理系统进行处理。

15.一种保单处理装置，其特征在于，包括：

消息接收模块，用于接收所述客户端发送的投保请求消息，所述投保请求消息中包括：投保保单的信息；

信息存储模块，用于存储所述投保保单的信息；

消息返回模块，用于向所述客户端返回投保成功消息；以及

信息传递模块，用于每隔一预定时间，读取存储的所述投保保单的信息，并将所述投保保单的信息发送至所述保单管理系统进行处理。

16.根据权利要求15所述的装置，其特征在于，所述信息传递模块包括：

数据转换子模块，用于通过JDK API提供的接口将所述投保保单的信息转换成文件对象；

数据存储子模块，用于通过JAVA反射机制将所述文件对象中的数据存储至JAVA虚拟机内存中；以及

消息调用子模块，用于通过消息队列调用所述保单管理系统，以将所述文件对象发送至所述保单管理系统进行处理。