CN117032789A - 业务规则配置和执行方法、系统、计算机设备及存储介质 - Google Patents

Abstract

本申请属于金融科技领域，涉及一种业务规则配置和执行方法，包括：获取双录规则配置页面中所勾选的配置信息；根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则；接收用户发送的投保请求，所述投保请求包括保单信息；根据所述规则属性对所述保单信息进行初筛，确定所述投保请求是否需要进行双录判定；若需要进行双录判定，则根据所述脚本表达式和所述双录规则，确定所述投保请求是否符合双录条件；若符合所述双录条件，则针对所述投保请求执行对应的双录流程。本申请还提供一种业务规则配置和执行系统、计算机设备及存储介质。本申请提高了业务规则配置和执行的效率。

Description

业务规则配置和执行方法、系统、计算机设备及存储介质

技术领域

本申请涉及金融科技技术领域，尤其涉及一种业务规则配置和执行方法、系统、计算机设备及存储介质。

背景技术

近年来，随着金融科技的迅速发展，其在保险销售行业中的应用也日益广泛，使得行业生态产生了较大的变化。为了规范保险销售行为，维护保险消费者的合法权益，中国保监会在国内全面推行了“双录”工作，即通过录音录像等技术手段记录和保存保险产品销售过程中关键环节和销售行为的重要内容等原始资料和信息，以实现对于保险销售行为的可回溯监管。

但由于双录流程较为麻烦，容易导致客户流失，不利于行业健康发展。因此，保险机构所在地对于需要进行双录的业务场景发布了监管要求，使得保险机构在满足监管要求的情况下，可以根据业务数据进行智能决策，判断保单是否符合双录规则，从而只针对符合双录规则的保单执行双录流程。

然而，不同所在地的监管要求不一致，并且时常发生变更，面对这种情况，传统的处理方式为：每当监管要求发生变更时，保险机构的开发人员都需要从代码或配置层面进行相应的调整，再通过需求优先级排期、开发编码、测试验证回归以及发版一个完整的开发流程来实现。采用这种处理方式，不仅配置繁琐容易出错，代码的频繁变也更容易对已有的双录判断逻辑造成影响，导致规则执行时出现生产问题。此外，完整的开发流程耗时耗力，导致了整个过程效率较低，降低了对业务的需求满足率，影响了业务人员对于开发人员的满意度。

发明内容

本申请实施例的目的在于提出一种业务规则配置和执行方法、系统、计算机设备及存储介质，以解决常规的配置和执行双录规则的方式容易出现错误，且效率较低的技术问题。

为了解决上述技术问题，本申请实施例提供一种业务规则配置和执行方法，采用了如下所述的技术方案：

获取双录规则配置页面中所勾选的配置信息；

根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则；

接收用户发送的投保请求，所述投保请求包括保单信息；

根据所述规则属性对所述保单信息进行初筛，确定所述投保请求是否需要进行双录判定；

若需要进行双录判定，则根据所述脚本表达式和所述双录规则，确定所述投保请求是否符合双录条件；

若符合所述双录条件，则针对所述投保请求执行对应的双录流程。

进一步的，所述若需要进行双录判定，则根据所述脚本表达式和所述双录规则，确定所述投保请求是否符合双录条件的步骤，具体包括：

若所述投保请求需要进行双录判定，则根据所述保单信息更新所述脚本表达式对应的上下文；

根据所述脚本表达式和所述上下文，对所述双录规则进行遍历，以确定所述投保请求是否匹配所述双录规则列表；

若匹配所述双录规则列表，则确定所述投保请求符合所述双录条件；

若不匹配所述双录规则列表，则确定所述投保请求不符合所述双录条件。

进一步的，所述根据所述脚本表达式和所述上下文，对所述双录规则进行遍历，以确定所述投保请求是否匹配所述双录规则列表的步骤，具体包括：

将所述上下文作为Jexl引擎的执行参数；

根据所述双录规则对所述脚本表达式进行组装，确定所述双录规则中每个规则对应的待执行表达式；

通过所述Jexl引擎依次执行每个待执行表达式，得到执行结果，并根据所述执行结果确定所述双录规则中是否存在匹配所述保单信息的目标双录规则；

若存在，则确定所述投保请求匹配所述双录规则列表；

若不存在，则确定所述投保请求不匹配所述双录规则列表。

进一步的，所述规则属性包括投保来源和业务来源，所述根据所述规则属性对所述保单信息进行初筛，确定所述投保请求是否需要进行双录判定的步骤，具体包括：

将所述规则属性与所述保单信息进行对比，以确定所述投保来源和所述业务来源是否匹配所述保单信息；

若所述投保来源和所述业务来源匹配所述保单信息，则确定所述投保请求需要进行双录判定；

若所述投保来源和/或所述业务来源不匹配所述保单信息，则确定所述投保请求不需要进行双录判定。

进一步的，所述根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则的步骤，具体包括：

对所述配置信息进行筛选，得到所述配置信息中的各个配置因子；

根据各个所述配置因子，确定所述规则属性和所述双录规则，并根据所述规则属性和所述双录规则生成所述双录规则列表；

根据各个所述配置因子，构建所述脚本表达式。

进一步的，所述根据各个所述配置因子，确定所述规则属性和所述双录规则，并根据所述规则属性和所述双录规则生成所述双录规则列表的步骤，具体包括：

根据各个所述配置因子，确定初始双录规则；

根据预设参数将所述初始双录规则划分为所述规则属性和所述双录规则；

根据所述规则属性和所述双录规则生成所述双录规则列表，并将所述规则属性单独存储。

进一步的，在所述根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则的步骤之后，还包括：

在所述双录规则配置页面中所勾选的配置信息发生变更时，获取所述双录规则配置页面中所勾选的更新配置信息；

根据所述更新配置信息，对所述双录规则列表和所述脚本表达式进行更新，得到更新后的双录规则列表和更新后的脚本表达式。

为了解决上述技术问题，本申请实施例还提供一种业务规则配置和执行系统，包括：

获取模块，用于获取双录规则配置页面中所勾选的配置信息；

配置模块，用于根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则；

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

第一确定模块，用于根据所述规则属性对所述保单信息进行初筛，确定所述投保请求是否需要进行双录判定；

第二确定模块，用于若需要进行双录判定，则根据所述脚本表达式和所述双录规则，确定所述投保请求是否符合双录条件；

执行模块，用于若符合所述双录条件，则针对所述投保请求执行对应的双录流程。

为了解决上述技术问题，本申请实施例还提供一种计算机设备，采用了如下所述的技术方案：

一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述处理器执行所述计算机可读指令时实现如上所述的业务规则配置和执行方法的步骤。

为了解决上述技术问题，本申请实施例还提供一种计算机可读存储介质，采用了如下所述的技术方案：

一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机可读指令，所述计算机可读指令被处理器执行时实现如上所述的业务规则配置和执行方法的步骤。

与现有技术相比，本申请实施例主要有以下有益效果：

本申请公开的业务规则配置和执行方法，通过获取双录规则配置页面中所勾选的配置信息；根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则；接收用户发送的投保请求，所述投保请求包括保单信息；根据所述规则属性对所述保单信息进行初筛，确定所述投保请求是否需要进行双录判定；若需要进行双录判定，则根据所述脚本表达式和所述双录规则，确定所述投保请求是否符合双录条件；若符合所述双录条件，则针对所述投保请求执行对应的双录流程。本申请通过实时生成满足当前监管要求的双录规则配置，并利用规则执行引擎执行动态脚本以对投保用户是否需要双录进行判定，使得业务人员可以自定义业务规则的配置，同时整个过程不需要开发人员参与，降低了过程中出现错误和生产问题的概率，提高了业务规则配置和执行的灵活性，并且大大地提高了效率。

附图说明

为了更清楚地说明本申请中的方案，下面将对本申请实施例描述中所需要使用的附图作一个简单介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请可以应用于其中的示例性系统架构图；

图2根据本申请的业务规则配置和执行方法的一个实施例的流程图；

图3是根据本申请的业务规则配置和执行系统的一个实施例的结构示意图；

图4是根据本申请的计算机设备的一个实施例的结构示意图。

具体实施方式

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

为了使本技术领域的人员更好地理解本申请方案，下面将结合附图，对本申请实施例中的技术方案进行清楚、完整地描述。

如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3(MPEG Audio Layer III，动态影像专家压缩标准音频层面3)播放器、MP4(MPEG Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对终端设备101、102、103上显示的页面提供支持的后台服务器。

需要说明的是，本申请实施例所提供的业务规则配置和执行方法一般由服务器执行，相应地，业务规则配置和执行系统一般设置于服务器中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

继续参考图2，示出了根据本申请的业务规则配置和执行方法的一个实施例的流程图。所述的业务规则配置和执行方法，包括以下步骤：

步骤S201，获取双录规则配置页面中所勾选的配置信息；

在本实施例中，首先需要获取双录规则页面中所勾选的配置信息，以使得后续可以根据配置信息配置双录规则列表，以及构建双录规则列表对应的脚本表达式。

具体地，可以预先在前端开发双录规则配置页面，双录规则配置页面中可以设有双录业务对应的所有配置信息，例如业务来源、投保来源、险种、保件类型、保费限额、险种、投保人社保情况、投保人年龄、保险生效时间等，业务人员可以根据实时的监管要求，在双录规则配置页面中勾选配置信息，并在完成勾选后发出指令，将勾选的配置信息发送至后台，后台接收到该配置信息后，根据该配置信息，即可确定满足当前监管要求的双录规则配置。

可选地，在双录规则配置页面中，所勾选的配置信息支持的规则数量不受限制，可以支持单条规则或多条规则，并且投保人年龄的区间和保费限额的额度等存在范围的变量可以支持自定义，提高了业务规则配置的灵活性。

步骤S202，根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则；

在本实施例中，获取双录规则配置页面中所勾选的配置信息后，即可根据该配置信息，配置双录规则列表，并构建双录规则列表对应的脚本表达式，其中，双录规则列表包括了规则属性和双录规则。

具体地，根据获取到的配置信息，可以初步筛选出配置信息中的各个配置因子，例如，将投保来源和其对应的范围作为一个配置因子。之后，可以将各个配置因子作为初始双录规则，并根据预设参数将初始双录规则划分为规则属性和双录规则，例如，将投保来源和业务来源作为规则属性，以使得后续可以根据规则属性对投保请求进行初筛。在确定规则属性和双录规则后，即可根据规则属性和双录规则生成双录规则列表，同时根据各个配置因子构建一个双录规则列表对应的脚本表达式，并存储得到的双录规则列表和脚本表达式。

可选地，得到上述双录规则列表和脚本表达式后，若前端双录规则配置页面所勾选的配置信息存在更新，则可以根据更新后的配置信息实时地重新生成双录规则列表以及重新构建脚本表达式，以确保双录业务规则的配置和执行符合最新的监管要求。

步骤S203，接收用户发送的投保请求，所述投保请求包括保单信息；

在本实施例中，当用户进行投保时，接收用户发送的投保请求，其中，该投保请求包括了保单信息。具体地，保单信息中的每一项都可以在双录规则配置页面中找到对应的配置信息，例如业务来源、投保来源、险种、保件类型、保费限额、险种、投保人社保情况、投保人年龄、保险生效时间等，在接收投保请求并得到保单信息后，即可根据配置好的双录规则列表和构建的脚本表达式，确定该投保请求是否符合双录条件。

步骤S204，根据所述规则属性对所述保单信息进行初筛，确定所述投保请求是否需要进行双录判定；

在本实施例中，接收用户发送的投保请求后，即可根据双录规则列表的规则属性对投保请求的保单信息进行初筛，确定该投保请求是否需要进行双录判定。具体地，规则属性可以包括投保来源和业务来源，当接收到投保请求后，首先对该投保请求的保单信息进行初步筛选，将规则属性与保单信息进行对比，确定投保来源和业务来源是否匹配该保单信息，若投保来源和业务来源匹配该保单信息，则确定该投保请求需要进行后续的双录判定，以确定其是否需要双录；若投保来源或业务来源不匹配该保单信息，则确定该投保请求不需要进行双录判定，即该投保请求不需要双录，参照步骤S2041，可以直接针对投保请求执行投保流程。

步骤S205，若需要进行双录判定，则根据所述脚本表达式和所述双录规则，确定所述投保请求是否符合双录条件；

需要说明的是，本实施例需要借助Jexl引擎作为技术依托，Jexl引擎即为Java表达式语言(Java Expression Language)引擎，可以配合Java程序运算一些简单的表达式，其在本实施例中应用于业务规则的执行。

在本实施例中，根据规则属性对用户发送的投保请求进行初筛后，若确定该投保请求需要进行双录判定，则根据双录规则列表对应的脚本表达式和双录规则列表包括的双录规则，确定该投保请求是否符合双录条件。

具体地，双录规则列表对应的脚本表达式为可以boolean类型的动态脚本表达式，双录规则列表包括规则属性和双录规则，通过规则属性对保单信息进行初筛并确定投保请求需要进行双录判定后，即可通过双录规则和脚本表达式对保单信息进行具体的双录判定。由于规则属性包括投保来源和业务来源，因此在已根据规则属性对保单信息进行初筛的情况下，首先需要获取保单信息中除投保来源和业务来源之外的其他基本信息，例如险种、投保人年龄、保费限额等，根据这些基本信息更新脚本表达式对应的上下文，而后即可根据脚本表达式和上下文对双录规则进行遍历，每当判定一个具体的双录规则时，根据该双录规则和脚本表达式进行组装，获得该双录规则对应的待执行表达式，再通过Jexl引擎执行该待执行表达式，并将上下文作为执行需要的参数，即可获得执行结果，根据该执行结果确定该双录规则是否匹配保单信息。在对双录规则进行遍历的过程中，只要存在一个匹配保单信息的具体的双录规则，就可以认为接收到的投保请求需要符合双录条件；若不存在匹配保单信息的具体的双录规则，则确定该投保请求不符合双录条件，参照步骤S2051，可以直接针对投保请求执行投保流程。

步骤S206，若符合所述双录条件，则针对所述投保请求执行对应的双录流程。

在本实施例中，接收到用户发送的投保请求，并确定投保请求符合双录条件后，则需要针对该投保请求执行对应的双录流程，具体地，可以自动向该用户发送信息，以通知用户需要双录；也可以接入审批系统，由审批人员进一步地确认该投保请求是否需要双录。

本申请通过实时生成满足当前监管要求的双录规则配置，并利用规则执行引擎执行动态脚本以对投保用户是否需要双录进行判定，使得业务人员可以自定义业务规则的配置，同时整个过程不需要开发人员参与，降低了过程中出现错误和生产问题的概率，提高了业务规则配置和执行的灵活性，并且大大地提高了效率。

在本实施例的一些可选的实现方式中，上述若需要进行双录判定，则根据所述脚本表达式和所述双录规则，确定所述投保请求是否符合双录条件的步骤包括：

若所述投保请求需要进行双录判定，则根据所述保单信息更新所述脚本表达式对应的上下文；

根据所述脚本表达式和所述上下文，对所述双录规则进行遍历，以确定所述投保请求是否匹配所述双录规则列表；

若匹配所述双录规则列表，则确定所述投保请求符合所述双录条件；

若不匹配所述双录规则列表，则确定所述投保请求不符合所述双录条件。

在本实施例中，根据规则属性对保单信息进行初筛，并确定投保请求需要进行双录判定后，则根据保单信息更新脚本表达式对应的上下文，再根据脚本表达式和其对应的上下文，对双录规则进行遍历，以确定投保请求是否匹配双录规则列表，若投保请求匹配双录规则列表，则确定投保请求符合双录条件，若投保请求不匹配双录规则列表，则确定投保请求不符合双录条件。

具体地，由于规则属性包括投保来源和业务来源，首先需要获取保单信息中除投保来源和业务来源之外的其他基本信息，例如险种、投保人年龄、保费限额等，将这些基本信息放入脚本表达式对应的上下文中，而后运用Jexl引擎对双录规则中每一个具体的双录规则进行遍历，并将上下文作为Jexl引擎的执行参数，在判定一个具体的双录规则时，可以根据该双录规则和脚本表达式进行组装，得到该双录规则对应的待执行表达式，再通过Jexl引擎执行该待执行表达式，以得到执行结果，并且由于脚本表达式的类型为boolean类型，因此得到的执行结果为一个boolean的结果，根据该结果可以确定该双录规则是否匹配放入上下文中的基本信息，若匹配，则确定该双录规则匹配保单信息。对双录规则进行遍历后，若双录规则中存在匹配保单信息的目标双录规则，则确定投保请求匹配双录规则列表，此时，确定投保请求符合双录条件；否则，确定投保请求不符合双录条件。

本申请通过动态脚本和上下文实现了对于配置好的双录规则的快速执行，并确保其符合监管要求，避免了开发层面容易导致的错误和生产问题，提高了业务规则执行的灵活性和效率。

在本实施例的一些可选的实现方式中，上述根据所述脚本表达式和所述上下文，对所述双录规则进行遍历，以确定所述投保请求是否匹配所述双录规则列表的步骤包括：

将所述上下文作为Jexl引擎的执行参数；

根据所述双录规则对所述脚本表达式进行组装，确定所述双录规则中每个规则对应的待执行表达式；

通过所述Jexl引擎依次执行每个待执行表达式，得到执行结果，并根据所述执行结果确定所述双录规则中是否存在匹配所述保单信息的目标双录规则；

若存在，则确定所述投保请求匹配所述双录规则列表；

若不存在，则确定所述投保请求不匹配所述双录规则列表。

在本实施例中，在根据投保请求的保单信息更新脚本表达式对应的上下文后，需要将该上下文作为Jexl引擎的执行参数，并在脚本表达式的基础上，根据双录规则进行组装，以确定双录规则中每个规则对应的待执行表达式，再通过Jexl引擎依次执行每个待执行表达式，得到执行结果，从而根据执行结果确定双录规则中是否存在匹配保单信息的目标双录规则，若存在目标双录规则，则确定投保请求匹配双录规则列表，若不存在目标双录规则，则确定投保请求不匹配双录规则列表。具体地，由于脚本表达式为boolean类型，因此Jexl引擎执行每个待执行表达式都可以得到一个boolean类型的结果，而boolean类型的结果只能为true或者false，在执行每个待执行表达式时，若返回的执行结果为true，则确定该待执行表达式所对应的特定双录规则与保单信息匹配，为目标双录规则；若返回的执行结果为false，则确定该待执行表达式所对应的特定双录规则与保单信息不匹配。

本申请利用了规则执行引擎执行动态脚本以对投保用户是否需要双录进行判定，对配置好的双录规则进行遍历，提高了业务规则执行的准确性，降低了过程中出现错误和生产问题的概率。

在本实施例的一些可选的实现方式中，上述规则属性包括投保来源和业务来源，上述根据所述规则属性对所述保单信息进行初筛，确定所述投保请求是否需要进行双录判定的步骤包括：

将所述规则属性与所述保单信息进行对比，以确定所述投保来源和所述业务来源是否匹配所述保单信息；

若所述投保来源和所述业务来源匹配所述保单信息，则确定所述投保请求需要进行双录判定；

若所述投保来源和/或所述业务来源不匹配所述保单信息，则确定所述投保请求不需要进行双录判定。

在本实施例中，接收到用户发送的投保请求后，首先将规则属性与该投保请求的保单信息进行对比，以确定规则属性中的投保来源和业务来源是否匹配保单信息，若投保来源和业务来源匹配保单信息，则确定该投保请求需要进行双录判定；若投保来源和业务来源不匹配保单信息，则确定该投保请求不需要进行双录判定。具体地，投保来源和业务来源作为每一个投保请求的基本属性，在配置双录规则列表时，可以将配置信息中的投保来源和业务来源划分为规则属性，将其他内容划分为双录规则，从而在接收到投保请求后，可以首先根据投保来源和业务来源确定该投保请求是否需要进行双录判定进行初筛，即确定该投保请求的保单信息是否匹配投保来源和业务来源，例如，投保来源对应了用户发送投保请求的渠道，如移动端APP、投保机构官网等，业务来源对应了用户选择的投保机构，如财险公司、寿险公司等，若该投保请求的保单信息中用户发送投保请求的渠道属于投保来源的范围，则视为该投保请求的保单信息匹配投保来源，若该投保请求的保单信息中用户选择的投保机构属于业务来源的范围，则视为该投保请求的保单信息匹配业务来源。因此对投保请求进行初筛时，若该投保请求的保单信息同时匹配投保来源和业务来源，则确定该投保请求需要进行下一步判定，以确定是否需要双录；若该投保请求的保单信息不匹配投保来源和业务来源中的任意一项，或者两项都不匹配，则直接确定该投保请求不需要双录，可以直接进入正常投保流程。

本申请通过设定的规则属性对投保请求进行初筛，确定有必要进行双录规则判定的投保请求再后续的判定流程，避免了无效的业务规则执行，提高了业务规则执行的效率。

在本实施例的一些可选的实现方式中，上述根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则的步骤包括：

对所述配置信息进行筛选，得到所述配置信息中的各个配置因子；

根据各个所述配置因子，确定所述规则属性和所述双录规则，并根据所述规则属性和所述双录规则生成所述双录规则列表；

根据各个所述配置因子，构建所述脚本表达式。

在本实施例中，获取双录规则配置页面中所勾选的配置信息后，可以对配置信息进行筛选，得到配置信息中的各个配置因子，从而根据各个配置因子，确定规则属性和双录规则，并根据规则属性和双录规则生成双录规则列表，同时根据各个配置因子，构建双录规则列表对应的脚本表达式。具体地，双录规则配置页面中所勾选的配置信息可以包括如业务来源、投保来源、险种、保件类型、保费限额、险种、投保人社保情况、投保人年龄、保险生效时间等信息，对配置信息进行筛选，即可得到各个配置因子，类似于键值对(key-value)的形式，例如，将投保人年龄和其对应的区间范围作为一个配置因子，形成各个配置因子后，即可根据各个配置因子确定各个初始双录规则，再根据预设参数将初始双录规则划分为规则属性和双录规则，而后根据规则属性和双录规则生成双录规则列表，同时，根据各个配置因子，还可以构建一个boolean类型的动态的脚本表达式，作为双录规则列表对应的脚本表达式，其形式类似于"((applicantAge>＝55))&&",D,B,".indexOf(busiSrcType)>-1&&",218,104695,".indexOf(applicationSourceType)>-1&&"N".equals(orderSocialSecurity)&&orderPremium>100"，后续可以根据该脚本表达式进行双录规则的判定过程。

本申请通过业务人员在双录规则配置页面自定义的双录规则的配置信息，实时生成双录规则列表和脚本表达式，后续用于执行以对双录规则进行判定，提高了业务规则配置和执行的灵活性，并提高了效率。

在本实施例的一些可选的实现方式中，上述根据各个所述配置因子，确定所述规则属性和所述双录规则，并根据所述规则属性和所述双录规则生成所述双录规则列表的步骤包括：

根据各个所述配置因子，确定初始双录规则；

根据预设参数将所述初始双录规则划分为所述规则属性和所述双录规则；

根据所述规则属性和所述双录规则生成所述双录规则列表，并将所述规则属性单独存储。

在本实施例中，得到配置信息中的各个配置因子后，根据各个配置因子确定初始双录规则，并根据预设参数将初始双录规则划分为规则属性和双录规则，再根据规则属性和双录规则生成双录规则列表，并将规则属性单独存储。具体地，每个初始双录规则对应一个配置因子，根据预设参数可以将各个初始双录规则划分为规则属性和双录规则，例如，预设参数为投保来源和业务来源，则将投保来源和业务来源对应的初始双录规则作为规则属性，将其他初始双录规则作为双录规则，而后根据规则属性和双录规则生成双录规则列表，并将规则属性单独存储起来，以使得后续可以根据规则属性对投保请求的保单信息进行初筛。

本申请通过预设参数提前划分并存储规则属性，以使得后续对双录规则进行判定时可以通过规则属性进行初筛，大大地提高了业务规则配置的执行的效率。

在本实施例的一些可选的实现方式中，上述根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则的步骤之后，还包括：

在所述双录规则配置页面中所勾选的配置信息发生变更时，获取所述双录规则配置页面中所勾选的更新配置信息；

根据所述更新配置信息，对所述双录规则列表和所述脚本表达式进行更新，得到更新后的双录规则列表和更新后的脚本表达式。

在本实施例中，根据双录规则配置页面中所勾选的配置信息，配置双录规则列表并生成双录规则列表对应的表达式后，当双录规则配置页面中所勾选的配置信息发生变更时，获取双录规则配置页面中所勾选的更新配置信息，并根据更新配置信息，对双录规则列表和脚本表达式进行更新，得到更新后的双录规则列表和更新后的脚本表达式。具体地，由于双录规则配置页面中配置信息由业务人员自定义进行勾选，当监管要求发生变化时，业务人员可以根据最新的监管要求重新勾选配置信息，作为更新配置信息，获取更新配置信息后，需要根据更新配置信息实时生成新的双录规则列表和双录规则列表对应的脚本表达式，作为更新后的双录规则列表和更新后的脚本表达式。

本申请通过业务人员在前端自定义选择的配置信息，实时生成满足当前监管要求的双录规则配置，提高了业务规则配置的灵活性，同时过程中不需要开发人员参与，降低了出现错误和生产问题的概率。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，该计算机可读指令可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

进一步参考图3，作为对上述图2所示方法的实现，本申请提供了一种业务规则配置和执行系统的一个实施例，该系统实施例与图2所示的方法实施例相对应，该系统具体可以应用于各种电子设备中。

如图3所示，本实施例所述的业务规则配置和执行系统300包括：获取模块301、配置模块302、接收模块303、第一确定模块304、第二确定模块305以及执行模块306。其中：

获取模块301，用于获取双录规则配置页面中所勾选的配置信息；

配置模块302，用于根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则；

接收模块303，用于接收用户发送的投保请求，所述投保请求包括保单信息；

第一确定模块304，用于根据所述规则属性对所述保单信息进行初筛，确定所述投保请求是否需要进行双录判定；

第二确定模块305，用于若需要进行双录判定，则根据所述脚本表达式和所述双录规则，确定所述投保请求是否符合双录条件；

执行模块306，用于若符合所述双录条件，则针对所述投保请求执行对应的双录流程。

本申请提供的业务规则配置和执行系统，有益效果如下：

本申请公开的业务规则配置和执行系统，通过实时生成满足当前监管要求的双录规则配置，并利用规则执行引擎执行动态脚本以对投保用户是否需要双录进行判定，使得业务人员可以自定义业务规则的配置，同时整个过程不需要开发人员参与，降低了过程中出现错误和生产问题的概率，提高了业务规则配置和执行的灵活性，并且大大地提高了效率。

在本实施例的一些可选的实现方式中，第二确定模块305还用于：

若所述投保请求需要进行双录判定，则根据所述保单信息更新所述脚本表达式对应的上下文；

根据所述脚本表达式和所述上下文，对所述双录规则进行遍历，以确定所述投保请求是否匹配所述双录规则列表；

若匹配所述双录规则列表，则确定所述投保请求符合所述双录条件；

若不匹配所述双录规则列表，则确定所述投保请求不符合所述双录条件。

本申请提供的业务规则配置和执行系统，通过动态脚本和上下文实现了对于配置好的双录规则的快速执行，并确保其符合监管要求，避免了开发层面容易导致的错误和生产问题，提高了业务规则执行的灵活性和效率。

在本实施例的一些可选的实现方式中，业务规则配置和执行系统还用于：

将所述上下文作为Jexl引擎的执行参数；

根据所述双录规则对所述脚本表达式进行组装，确定所述双录规则中每个规则对应的待执行表达式；

通过所述Jexl引擎依次执行每个待执行表达式，得到执行结果，并根据所述执行结果确定所述双录规则中是否存在匹配所述保单信息的目标双录规则；

若存在，则确定所述投保请求匹配所述双录规则列表；

若不存在，则确定所述投保请求不匹配所述双录规则列表。

本申请提供的业务规则配置和执行系统，利用了规则执行引擎执行动态脚本以对投保用户是否需要双录进行判定，对配置好的双录规则进行遍历，提高了业务规则执行的准确性，降低了过程中出现错误和生产问题的概率。

在本实施例的一些可选的实现方式中，规则属性包括投保来源和业务来源，第一确定模块304还用于：

将所述规则属性与所述保单信息进行对比，以确定所述投保来源和所述业务来源是否匹配所述保单信息；

若所述投保来源和所述业务来源匹配所述保单信息，则确定所述投保请求需要进行双录判定；

若所述投保来源和/或所述业务来源不匹配所述保单信息，则确定所述投保请求不需要进行双录判定。

本申请提供的业务规则配置和执行系统，通过设定的规则属性对投保请求进行初筛，确定有必要进行双录规则判定的投保请求再后续的判定流程，避免了无效的业务规则执行，提高了业务规则执行的效率。

在本实施例的一些可选的实现方式中，配置模块302还用于：

对所述配置信息进行筛选，得到所述配置信息中的各个配置因子；

根据各个所述配置因子，确定所述规则属性和所述双录规则，并根据所述规则属性和所述双录规则生成所述双录规则列表；

根据各个所述配置因子，构建所述脚本表达式。

本申请提供的业务规则配置和执行系统，通过业务人员在双录规则配置页面自定义的双录规则的配置信息，实时生成双录规则列表和脚本表达式，后续用于执行以对双录规则进行判定，提高了业务规则配置和执行的灵活性，并提高了效率。

在本实施例的一些可选的实现方式中，业务规则配置和执行系统还用于：

根据各个所述配置因子，确定初始双录规则；

根据预设参数将所述初始双录规则划分为所述规则属性和所述双录规则；

根据所述规则属性和所述双录规则生成所述双录规则列表，并将所述规则属性单独存储。

本申请提供的业务规则配置和执行系统，通过预设参数提前划分并存储规则属性，以使得后续对双录规则进行判定时可以通过规则属性进行初筛，大大地提高了业务规则配置的执行的效率。

在本实施例的一些可选的实现方式中，业务规则配置和执行系统还用于：

在所述双录规则配置页面中所勾选的配置信息发生变更时，获取所述双录规则配置页面中所勾选的更新配置信息；

根据所述更新配置信息，对所述双录规则列表和所述脚本表达式进行更新，得到更新后的双录规则列表和更新后的脚本表达式。

本申请提供的业务规则配置和执行系统，通过业务人员在前端自定义选择的配置信息，实时生成满足当前监管要求的双录规则配置，提高了业务规则配置的灵活性，同时过程中不需要开发人员参与，降低了出现错误和生产问题的概率。

为解决上述技术问题，本申请实施例还提供计算机设备。具体请参阅图4，图4为本实施例计算机设备基本结构框图。

所述计算机设备4包括通过系统总线相互通信连接存储器41、处理器42、网络接口43。需要指出的是，图中仅示出了具有组件41-43的计算机设备4，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。其中，本技术领域技术人员可以理解，这里的计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(ApplicationSpecific Integrated Circuit，ASIC)、可编程门阵列(Field－Programmable GateArray，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。

所述计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述计算机设备可以与用户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互。

所述存储器41至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器41可以是所述计算机设备4的内部存储单元，例如该计算机设备4的硬盘或内存。在另一些实施例中，所述存储器41也可以是所述计算机设备4的外部存储设备，例如该计算机设备4上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(FlashCard)等。当然，所述存储器41还可以既包括所述计算机设备4的内部存储单元也包括其外部存储设备。本实施例中，所述存储器41通常用于存储安装于所述计算机设备4的操作系统和各类应用软件，例如业务规则配置和执行方法的计算机可读指令等。此外，所述存储器41还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器42在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器42通常用于控制所述计算机设备4的总体操作。本实施例中，所述处理器42用于运行所述存储器41中存储的计算机可读指令或者处理数据，例如运行所述业务规则配置和执行方法的计算机可读指令。

所述网络接口43可包括无线网络接口或有线网络接口，该网络接口43通常用于在所述计算机设备4与其他电子设备之间建立通信连接。

本申请提供的计算机设备，有益效果如下：

本申请提供的计算机设备，通过实时生成满足当前监管要求的双录规则配置，并利用规则执行引擎执行动态脚本以对投保用户是否需要双录进行判定，使得业务人员可以自定义业务规则的配置，同时整个过程不需要开发人员参与，降低了过程中出现错误和生产问题的概率，提高了业务规则配置和执行的灵活性，并且大大地提高了效率。

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令可被至少一个处理器执行，以使所述至少一个处理器执行如上述的业务规则配置和执行方法的步骤。

本申请提供的计算机可读存储介质，有益效果如下：

本申请提供的计算机可读存储介质，通过实时生成满足当前监管要求的双录规则配置，并利用规则执行引擎执行动态脚本以对投保用户是否需要双录进行判定，使得业务人员可以自定义业务规则的配置，同时整个过程不需要开发人员参与，降低了过程中出现错误和生产问题的概率，提高了业务规则配置和执行的灵活性，并且大大地提高了效率。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

显然，以上所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例，附图中给出了本申请的较佳实施例，但并不限制本申请的专利范围。本申请可以以许多不同的形式来实现，相反地，提供这些实施例的目的是使对本申请的公开内容的理解更加透彻全面。尽管参照前述实施例对本申请进行了详细的说明，对于本领域的技术人员来而言，其依然可以对前述各具体实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等效替换。凡是利用本申请说明书及附图内容所做的等效结构，直接或间接运用在其他相关的技术领域，均同理在本申请专利保护范围之内。

Claims (10)

1.一种业务规则配置和执行方法，其特征在于，包括下述步骤：

获取双录规则配置页面中所勾选的配置信息；

根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则；

接收用户发送的投保请求，所述投保请求包括保单信息；

根据所述规则属性对所述保单信息进行初筛，确定所述投保请求是否需要进行双录判定；

若需要进行双录判定，则根据所述脚本表达式和所述双录规则，确定所述投保请求是否符合双录条件；

若符合所述双录条件，则针对所述投保请求执行对应的双录流程。

2.根据权利要求1所述的业务规则配置和执行方法，其特征在于，所述若需要进行双录判定，则根据所述脚本表达式和所述双录规则，确定所述投保请求是否符合双录条件的步骤，具体包括：

若所述投保请求需要进行双录判定，则根据所述保单信息更新所述脚本表达式对应的上下文；

根据所述脚本表达式和所述上下文，对所述双录规则进行遍历，以确定所述投保请求是否匹配所述双录规则列表；

若匹配所述双录规则列表，则确定所述投保请求符合所述双录条件；

若不匹配所述双录规则列表，则确定所述投保请求不符合所述双录条件。

3.根据权利要求2所述的业务规则配置和执行方法，其特征在于，所述根据所述脚本表达式和所述上下文，对所述双录规则进行遍历，以确定所述投保请求是否匹配所述双录规则列表的步骤，具体包括：

将所述上下文作为Jex l引擎的执行参数；

根据所述双录规则对所述脚本表达式进行组装，确定所述双录规则中每个规则对应的待执行表达式；

通过所述Jexl引擎依次执行每个待执行表达式，得到执行结果，并根据所述执行结果确定所述双录规则中是否存在匹配所述保单信息的目标双录规则；

若存在，则确定所述投保请求匹配所述双录规则列表；

若不存在，则确定所述投保请求不匹配所述双录规则列表。

4.根据权利要求1所述的业务规则配置和执行方法，其特征在于，所述规则属性包括投保来源和业务来源，所述根据所述规则属性对所述保单信息进行初筛，确定所述投保请求是否需要进行双录判定的步骤，具体包括：

将所述规则属性与所述保单信息进行对比，以确定所述投保来源和所述业务来源是否匹配所述保单信息；

若所述投保来源和所述业务来源匹配所述保单信息，则确定所述投保请求需要进行双录判定；

若所述投保来源和/或所述业务来源不匹配所述保单信息，则确定所述投保请求不需要进行双录判定。

5.根据权利要求1所述的业务规则配置和执行方法，其特征在于，所述根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则的步骤，具体包括：

对所述配置信息进行筛选，得到所述配置信息中的各个配置因子；

根据各个所述配置因子，确定所述规则属性和所述双录规则，并根据所述规则属性和所述双录规则生成所述双录规则列表；

根据各个所述配置因子，构建所述脚本表达式。

6.根据权利要求5所述的业务规则配置和执行方法，其特征在于，所述根据各个所述配置因子，确定所述规则属性和所述双录规则，并根据所述规则属性和所述双录规则生成所述双录规则列表的步骤，具体包括：

根据各个所述配置因子，确定初始双录规则；

根据预设参数将所述初始双录规则划分为所述规则属性和所述双录规则；

根据所述规则属性和所述双录规则生成所述双录规则列表，并将所述规则属性单独存储。

7.根据权利要求1至6任一项所述的业务规则配置和执行方法，其特征在于，在所述根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则的步骤之后，还包括：

在所述双录规则配置页面中所勾选的配置信息发生变更时，获取所述双录规则配置页面中所勾选的更新配置信息；

根据所述更新配置信息，对所述双录规则列表和所述脚本表达式进行更新，得到更新后的双录规则列表和更新后的脚本表达式。

8.一种业务规则配置和执行系统，其特征在于，包括：

获取模块，用于获取双录规则配置页面中所勾选的配置信息；

配置模块，用于根据所述配置信息，配置双录规则列表，并构建所述双录规则列表对应的脚本表达式，所述双录规则列表包括规则属性和双录规则；

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

第一确定模块，用于根据所述规则属性对所述保单信息进行初筛，确定所述投保请求是否需要进行双录判定；

第二确定模块，用于若需要进行双录判定，则根据所述脚本表达式和所述双录规则，确定所述投保请求是否符合双录条件；

执行模块，用于若符合所述双录条件，则针对所述投保请求执行对应的双录流程。

9.一种计算机设备，其特征在于，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述处理器执行所述计算机可读指令时实现如权利要求1至7中任一项所述的业务规则配置和执行方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机可读指令，所述计算机可读指令被处理器执行时实现如权利要求1至7中任一项所述的业务规则配置和执行方法的步骤。