CN114926291A - 一种契约规则管理引擎 - Google Patents

Abstract

本申请提供一种契约规则管理引擎，包括接收模块，被配置为接收业务数据并进行识别，得到输入信息项和对应的输入值；规则模块包括第一数据库被配置为存储多个信息项集，每个信息项集包括预设信息项和预设值；筛选模块被配置为筛选出与输入信息项对应的信息项集，作为目标信息项集，并发送至规则引擎；规则引擎包括第二数据库被配置为存储规则框架；处理模块被配置为将接收到的目标信息项集和对应的规则框架结合，形成校验规则；并对输入信息项和输入值进行校验。本申请提供的契约规则管理引擎，将原有的校验规则分为存储于规则模块的信息项集和存储于规则引擎的规则框架，较大程度的减小了原本存储于规则引擎内的校验规则数量。

Description

一种契约规则管理引擎

技术领域

本申请涉及规则管理技术领域，尤其涉及一种契约规则管理引擎。

背景技术

在金融、保险等领域相关机构和企业中，需要通过较为复杂的业务逻辑处理多种任务。相关技术中，可通过规则引擎执行业务规则实现逻辑运算。业务规则可以理解为一组条件和在此条件下的操作。

对于现有的规则引擎，其存储有大量相近的业务规则，浪费了较多资源。同时，业务规则的创建和维护方式都较为繁琐。

发明内容

有鉴于此，本申请的目的在于提出一种契约规则管理引擎。

基于上述目的，本申请提供了契约规则管理引擎，包括：接收模块、规则模块和规则引擎，所述接收模块，被配置为接收业务数据并进行识别，得到输入信息项和对应的输入值；所述规则模块，包括：第一数据库和筛选模块；所述第一数据库被配置为存储多个信息项集，每个所述信息项集包括至少一个预设信息项，以及与所述预设信息项对应的预设值；所述筛选模块被配置为从所述第一数据库中筛选出与所述输入信息项对应的所述信息项集，作为目标信息项集，并将目标信息项集发送至所述规则引擎；所述规则引擎，包括：第二数据库和处理模块；所述第二数据库被配置为存储与所述信息项集一一对应的规则框架；所述处理模块被配置为将接收到的所述目标信息项集和对应的所述规则框架结合，形成校验规则；并根据所述校验规则对所述输入信息项和所述输入值进行校验。

可选的，所述输入信息项为多个，所述目标信息项集所包括的所述预设信息项与所述输入信息项相同。

可选的，所述规则框架包括触发逻辑和预设动作，所述触发逻辑、所述预设信息项和所述预设值结合，形成触发条件；响应于确定所述输入信息项和所述输入值满足所述触发条件，则执行与所述触发条件对应的所述预设动作。

可选的，还包括设置模块，被配置为获取设置指令，并执行所述设置指令中包括的设置动作。

可选的，所述设置动作，包括：

添加新预设信息项、和/或新预设值，和/或新规则框架；

删除原预设信息项、和/或原预设值，和/或原规则框架；

更改所述原预设值。

可选的，所述设置指令还包括生效范围，所述设置模块还被配置为根据所述生效范围执行所述设置动作。

可选的，所述生效范围包括生效机构和/或生效起止时间。

可选的，还包括前端设置界面，被配置为采集所述设置指令并发送。

可选的，还包括审批模块，被配置为获取审批指令和所述前端设置界面发送的所述设置指令，响应于确定所述审批指令为通过，则将所述设置指令发送给所述设置模块。

可选的，还包括审批界面，被配置为展示所述设置指令，以及采集所述审批指令。

从上面所述可以看出，本申请提供的契约规则管理引擎，将原有的校验规则分为存储于规则模块的信息项集和存储于规则引擎的规则框架，较大程度的减小了原本存储于规则引擎内的校验规则数量。同时，通过信息项集和规则框架可以动态拼装校验规则，将原本固定格式的校验规则进行个性化设置。

附图说明

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

图1为本申请实施例的契约规则管理引擎的一种结构示意图；

图2为本申请实施例的契约规则管理引擎的前端设置界面的示意图；

图3为本申请实施例的契约规则管理引擎的设置生效起止时间的示意图；

图4为本申请实施例的契约规则管理引擎的审批界面的示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本申请进一步详细说明。

需要说明的是，除非另外定义，本申请实施例使用的技术术语或者科学术语应当为本申请所属领域内具有一般技能的人士所理解的通常意义。本申请实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

为了方便理解，下面对本申请实施例中涉及的名词进行解释：

后端：为契约规则管理引擎的前端提供与服务器的数据请求交互的通道，以及处理业务逻辑。

前端：为契约规则管理引擎中与业务人员交互的应用部分，用于接收业务人员的数据、向后端请求数据、接收后端的返回数据、向业务人员展示数据以及处理渲染逻辑等。

申请人发现，现有技术采用的IBM规则引擎(ILog)，在使用过程中针对不同的校验规则无法复用，校验值无法动态变化，需要不断的更新底层校验逻辑。

示例一：

双录采集规则包

分省双录规则包

安徽蚌埠双录规则包

BB0001-安徽蚌埠年单位双录规则.brl

BB0002-安徽蚌埠月单位双录规则.brl

BB0003-安徽蚌埠日单位双录规则.brl

BB0004-安徽蚌埠其他单位双录规则.brl

大连市双录规则包

DL0001-大连市年单位双录规则.brl

DL0002-大连市月单位双录规则.brl

DL0003-大连市日单位双录规则.brl

DL0004-大连市其他单位双录规则.brl

从上述内容可以看出，即使校验规则的内容相同，但是由于用于不同的时间范围或地域范围，也需要重复编写，无法抽象出统一的规则，不能使用动态变量进行校验。

示例二：

如果

如下的所有条件中任何一个条件成立：

-‘投保单双录相关信息’的管理机构是“340303”

-‘投保单双录相关信息’的管理机构是“340305”

-‘投保单双录相关信息’的管理机构是“340306”

-‘投保单双录相关信息’的管理机构是“340307”

-‘投保单双录相关信息’的管理机构是“340308”

-‘投保单双录相关信息’的管理机构是“340309”

-‘投保单双录相关信息’的管理机构是“340312”

-‘投保单双录相关信息’的管理机构是“340314”

-‘投保单双录相关信息’的管理机构是“340316”

-‘投保单双录相关信息’的管理机构是“340321”

-‘投保单双录相关信息’的管理机构是“340322”

-‘投保单双录相关信息’的管理机构是“340323”，

并且当前系统时间晚于2020-10-01 00：00：00 +0800

并且‘险种信息’的保险期大于1

并且‘险种信息’的保险期间单位是Y-年

那么‘出参’的返回信息为“当前保单命中双录采集规则，请进行双录采集”

上述内容是一个校验规则，当其中的“管理机构”或者“系统时间”需要进行更改调整时，需要联系后端规则引擎开发人员实施，无法做到及时响应。

有鉴于此，如图1所示，本实施例提供了一种契约规则管理引擎，包括：接收模块1、规则模块2和规则引擎3，接收模块1，被配置为接收业务数据并进行识别，得到输入信息项和对应的输入值；规则模块2，包括：第一数据库21和筛选模块22；第一数据库21被配置为存储多个信息项集，每个信息项集包括至少一个预设信息项，以及与预设信息项对应的预设值；筛选模块22被配置为从第一数据库21中筛选出与输入信息项对应的信息项集，作为目标信息项集，并将目标信息项集发送至规则引擎3；规则引擎3，包括：第二数据库31和处理模块32；第二数据库31被配置为存储与信息项集一一对应的规则框架；处理模块32被配置为将接收到的目标信息项集和对应的规则框架结合，形成校验规则；并根据校验规则对输入信息项和输入值进行校验。

基于已有的校验规则，抽象出核心逻辑，也就是将校验规则按照业务逻辑划分为规则框架、预设信息项(即预设的校验信息项)和预设值(即预设的校验值)，并将规则框架存储于规则引擎3中的第二数据库31，将预设信息项和预设值组成信息项集，存储于规则模块2中的第一数据库21。

如示例二中的校验规则，可将其拆解为：

01规则信息项集：

预设信息项：‘投保单双录相关信息’的管理机构；机构预设值：“340303”、“340305”、“340306”、“340307”、“340308”、“340309”、“340312”、“340314”、“340316”、“340321”、“340322”和“340323”。

预设信息项：当前系统时间；时间预设值：2020-10-01 00:00:00 +0800。

预设信息项：‘险种信息’的保险期；保险期预设值：1。

预设信息项：‘险种信息’的保险期间单位；单位预设值：Y-年。

以上内容存储于第一数据库21。

01规则框架：‘投保单双录相关信息’的管理机构如果是机构预设值的任一个；且当前系统时间晚于时间预设值；且‘险种信息’的保险期大于保险期预设值；且‘险种信息’的保险期间单位是单位预设值；则‘出参’的返回信息为“当前保单命中双录采集规则，请进行双录采集”

以上内容存储于第二数据库31。

假设接收模块1接收到的业务数据为：‘投保单双录相关信息’的管理机构：340303；当前系统时间：2021-01-01 10:10:24；‘险种信息’的保险期：2；‘险种信息’的保险期间单位：Y-年。

接收模块1对其进行识别，提取输入信息项和输入值：

提取输入信息项：‘投保单双录相关信息’的管理机构；输入值：340303；

提取输入信息项：当前系统时间；输入值：2021-01-01 10:10:24；

提取输入信息项：‘险种信息’的保险期；输入值：2；

提取输入信息项：‘险种信息’的保险期间单位；输入值：Y-年

识别完成后，筛选模块22根据将上述输入信息项和输入值，从第一数据库21中选出01规则信息项集，作为目标信息项集，并发送给规则引擎3。

规则引擎3接收到01规则信息项集后，调取第二数据库31中的01规则框架，将两者组合，形成上述示例二的校验规则，并对输入信息项和输入值进行校验。可见输入值均满足预设值，那么执行：‘出参’的返回信息为“当前保单命中双录采集规则，请进行双录采集”。

本申请实施例提供的契约规则管理引擎，将原有的校验规则分为存储于规则模块2的信息项集和存储于规则引擎3的规则框架，较大程度的减小了原本存储于规则引擎3内的校验规则数量。优化整体业务处理流程，提高业务处理效率，针对业务流程处理中投保资料、影像、双录等业务信息的校验，实现了规则集中管理。同时，通过信息项集和规则框架可以动态拼装校验规则，能够将原本固定格式的校验规则进行个性化设置。

一些实施例中，输入信息项为多个，目标信息项集所包括的预设信息项与输入信息项相同。

例如，假设输入信息项为n1、n2、n3和n4，则筛选出的目标信息项集01包括的预设信息项可为n1和n2，目标信息项集02包括的预设信息项可为n1、n2、n3、n4。根据业务数据可灵活的调取信息项集。

一些实施例中，规则框架包括触发逻辑和预设动作，触发逻辑、预设信息项和预设值结合，形成触发条件；响应于确定输入信息项和输入值满足触发条件，则执行与触发条件对应的预设动作。

对于上述示例中的逻辑框架

触发逻辑为：‘投保单双录相关信息’的管理机构如果是机构预设值的任一个；且当前系统时间晚于时间预设值；且‘险种信息’的保险期大于保险期预设值；且‘险种信息’的保险期间单位是单位预设值

触发条件为：如下的所有条件中任何一个条件成立：

-‘投保单双录相关信息’的管理机构是“340303”

-‘投保单双录相关信息’的管理机构是“340305”

-‘投保单双录相关信息’的管理机构是“340306”

-‘投保单双录相关信息’的管理机构是“340307”

-‘投保单双录相关信息’的管理机构是“340308”

-‘投保单双录相关信息’的管理机构是“340309”

-‘投保单双录相关信息’的管理机构是“340312”

-‘投保单双录相关信息’的管理机构是“340314”

-‘投保单双录相关信息’的管理机构是“340316”

-‘投保单双录相关信息’的管理机构是“340321”

-‘投保单双录相关信息’的管理机构是“340322”

-‘投保单双录相关信息’的管理机构是“340323”

并且当前系统时间晚于2020-10-01 00：00：00 +0800

并且‘险种信息’的保险期大于1

并且‘险种信息’的保险期间单位是Y-年

预设动作为：‘出参’的返回信息为“当前保单命中双录采集规则，请进行双录采集”

一些实施例中，契约规则管理引擎还包括设置模块6，被配置为获取设置指令，并执行设置指令中包括的设置动作。

一些实施例中，设置动作，包括：

添加新预设信息项、和/或新预设值，和/或新规则框架。

删除原预设信息项、和/或原预设值，和/或原规则框架。

更改原预设值。

可选的，设置模块6根据设置指令，能够对原校验规则进行新增或删减。

可选的，设置模块6根据设置指令，能够对原校验规则所抽象出的预设信息项进行新增或删减。

可选的，设置模块6根据设置指令，能够对原预设信息项所对应的预设值进行新增、删减或修改。

本实施例的契约规则管理引擎，由于将校验规则分成规则框架、预设信息项和预设值，因此对于校验规则的修改方式也就更加简便灵活。

一些实施例中，设置指令还包括生效范围，设置模块6还被配置为根据生效范围执行设置动作。

如图3所示，一些实施例中，生效范围包括生效机构和/或生效起止时间。

可选的，每一个生效机构对应设有一个机构代码，如“414002”等。在对规则框架、预设信息项或预设值进行设置时，可选择执行本次设置的生效机构。对于一些分公司，能够实现其制定个性化的校验规则需求。

可选的，对于生效时间，可选择即时生效或选择日期进行定时生效，使得设置人能够完全控制设置动作的生效时间，更加智能便捷。

如图2和图3所示，一些实施例中，契约规则管理引擎还包括前端设置界面7，被配置为采集设置指令并发送。

前端业务人员即使不借助专业规则引擎开发人员，也可自行对预设信息项、预设值和规则框架进行修改设置，有效的降低了校验规则配置门槛。一方面能够降低专业规则引擎开发人员的工作量，为企业降低成本。另一方面也能够快速的进行校验规则的修改，缩减执行流程，降低时间成本。

在前端设置界面7中，当选中原信息项集时，展示包括规则ID、规则代码、规则说明、规则启用机构、已生效配置元素(即已生效的校验信息项)等。

在对配置元素(即校验信息项)进行编辑设置时，可进行设置名称、编写简要说明、选择是否能按省配置、编辑该配置元素对应的校验值上限和下限，以及选择生效机构等。

一些实施例中，契约规则管理引擎还包括审批模块5，被配置为获取审批指令和前端设置界面7发送的设置指令，响应于确定审批指令为通过，则将设置指令发送给设置模块6。

当前端业务人员通过前端设置界面7将设置指令编辑完成后，设置指令会先经过审批模块5进行人工审批或系统协助人工审批，只有当审批通过后，设置指令才会被发送到设置模块6进一步执行设置动作。这样就能较大程度的避免由于前端业务人员误操作，而生成错误的校验规则，降低本实施例的契约规则管理引擎的使用风险。

如图4所示，一些实施例中，契约规则管理引擎还包括审批界面4，被配置为展示设置指令，以及采集审批指令。

可选的，契约规则管理引擎还包括查询模块8，被配置为对已生成的配置指令进行查询展示。查询模块8中预设有多个查询条件设置项，用户可在查询条件设置项内输入对应的查询条件值，以获得查询结果。

可选的，查询条件设置项包括规则类别、变更规则说明、生效类型、申请状态、申请日期区间等。

对于筛选出的配置指令，可依照下述多个属性的全部项或部分项在审批界面4中进行展示：任务ID、规则类别、变更规则名称、变更规则代码、变更状态、申请人姓名、申请人工号、申请人机构号、审核人姓名、审核人工号、审核人机构号、生效类型、生效时间、申请日期等。

最后，在审批界面4中还包括操作项，审核人可在操作项内选择该设置指令通过或取消。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本申请的范围(包括权利要求)被限于这些例子；在本申请的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本申请实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本申请实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本申请实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本申请实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本申请的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本申请实施例。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本申请的具体实施例对本申请进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本申请实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本申请实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种契约规则管理引擎，其特征在于，包括：接收模块、规则模块和规则引擎，

所述接收模块，被配置为接收业务数据并进行识别，得到输入信息项和对应的输入值；

所述规则模块，包括：第一数据库和筛选模块；所述第一数据库被配置为存储多个信息项集，每个所述信息项集包括至少一个预设信息项，以及与所述预设信息项对应的预设值；所述筛选模块被配置为从所述第一数据库中筛选出与所述输入信息项对应的所述信息项集，作为目标信息项集，并将目标信息项集发送至所述规则引擎；

所述规则引擎，包括：第二数据库和处理模块；所述第二数据库被配置为存储与所述信息项集一一对应的规则框架；所述处理模块被配置为将接收到的所述目标信息项集和对应的所述规则框架结合，形成校验规则；并根据所述校验规则对所述输入信息项和所述输入值进行校验。

2.根据权利要求1所述的契约规则管理引擎，其特征在于，所述输入信息项为多个，所述目标信息项集所包括的所述预设信息项与所述输入信息项相同。

3.根据权利要求1所述的契约规则管理引擎，其特征在于，所述规则框架包括触发逻辑和预设动作，所述触发逻辑、所述预设信息项和所述预设值结合，形成触发条件；响应于确定所述输入信息项和所述输入值满足所述触发条件，则执行与所述触发条件对应的所述预设动作。

4.根据权利要求1所述的契约规则管理引擎，其特征在于，还包括设置模块，被配置为获取设置指令，并执行所述设置指令中包括的设置动作。

5.根据权利要求4所述的契约规则管理引擎，其特征在于，所述设置动作，包括：

添加新预设信息项、和/或新预设值，和/或新规则框架；

删除原预设信息项、和/或原预设值，和/或原规则框架；

更改所述原预设值。

6.根据权利要求4所述的契约规则管理引擎，其特征在于，所述设置指令还包括生效范围，所述设置模块还被配置为根据所述生效范围执行所述设置动作。

7.根据权利要求6所述的契约规则管理引擎，其特征在于，所述生效范围包括生效机构和/或生效起止时间。

8.根据权利要求4所述的契约规则管理引擎，其特征在于，还包括前端设置界面，被配置为采集所述设置指令并发送。

9.根据权利要求8所述的契约规则管理引擎，其特征在于，还包括审批模块，被配置为获取审批指令和所述前端设置界面发送的所述设置指令，响应于确定所述审批指令为通过，则将所述设置指令发送给所述设置模块。

10.根据权利要求9所述的契约规则管理引擎，其特征在于，还包括审批界面，被配置为展示所述设置指令，以及采集所述审批指令。

Images