CN115185616A - 业务规则引擎及业务规则引擎的处理方法 - Google Patents

Abstract

本申请公开了一种业务规则引擎。业务规则引擎包括规则引擎核心包，规则引擎核心包包括注册接口及校验接口。注册接口用于生成营销工具的业务规则匹配链，其中，每个营销工具对应一个业务规则匹配链，业务规则匹配链包括按执行阶梯排列的多个业务规则。校验接口用于：在待校验的业务规则匹配链小于或等于预设的数量阈值时，串行校验多个业务规则匹配链；及在待校验的业务规则匹配链大于数量阈值时，重新排列所有待校验的业务规则匹配链中的业务规则的执行顺序，并按重新排列的执行顺序校验多个业务规则。本申请还公开了一种业务规则引擎的处理方法。依据校验的不同场景，动态地调整最适宜的校验顺序，提高进行校验的效率。

Description

业务规则引擎及业务规则引擎的处理方法

技术领域

本申请涉及互联网平台技术领域，特别涉及一种业务规则引擎及业务规则引擎的处理方法。

背景技术

在运营增长业务领域，留存下来实用的营销工具需要不断地改进，还要不断创造新的营销工具以满足业务量的增长，对技术侧的要求就是营销工具版本迭代要“稳、快”。营销工具迭代升级大部分是对业务规则的调整，新的营销工具诞生初期业务规则往往也会复用已有工具的业务规则。技术侧让业务规则从业务逻辑中剥离出来独立校验，并建立规则池，变得尤为重要。目前市场上惯用的技术手段就是使用规则引擎对业务规则进行统一编排校验，以达到“稳、快”的目标。

目前市场上成熟的规则引擎中编译型有DROOLS，解释型有QLEXPRESS、GROOVY、JEXL等。编译型的规则引擎基本都是基于RETE算法实现，使用的是正向推理，按照由条件推出结论的方向进行的推理方式，从一组事实出发，使用一定的推理规则，来证明目标事实或命题的成立。适用于规则多于事实的业务场景，如案件审理（法律条款远多于事实证据）、购买保险（产品的条约远多于投被保人相关信息）等。而营销工具的业务规则量远小于客户信息，静态地逐一对营销工具进行校验，效率较低。

发明内容

为解决上述背景技术中的至少一个技术问题，本申请实施方式提供了一种业务规则引擎及业务规则引擎的处理方法。

本申请实施方式的业务规则引擎包括规则引擎核心包，所述规则引擎核心包包括：

注册接口，所述注册接口用于生成营销工具的业务规则匹配链，其中，每个所述营销工具对应一个业务规则匹配链，所述业务规则匹配链包括按执行阶梯排列的多个业务规则；及

校验接口，所述校验接口用于：在待校验的业务规则匹配链小于或等于预设的数量阈值时，串行校验多个业务规则匹配链；及在待校验的业务规则匹配链大于所述数量阈值时，重新排列所有待校验的业务规则匹配链中的业务规则的执行顺序，并按重新排列的执行顺序校验多个业务规则。

在某些实施方式中，所述校验接口还用于记录校验每个业务规则的平均耗时；

在串行校验多个业务规则匹配链时，所述校验接口用于：

基于所述平均耗时，对每个业务规则匹配链中，同一阶梯内的多个业务规则按平均耗时从低到高进行第一重新排序；及

按所述第一重新排序校验同一阶梯内的多个业务规则。

在某些实施方式中，在重新排列所有待校验的业务规则匹配链中的业务规则的执行顺序时，所述校验接口用于：

将所有待校验的业务规则匹配链中，同一阶梯的多个业务规则进行整合；

基于所述平均耗时、历史通过率、及整合后同一阶梯中的相同业务规则的共用次数，对整合后同一阶梯中的业务规则进行第二重新排序；及

按所述第二重新排序校验整合后的同一阶梯内的多个业务规则。

在某些实施方式中，所述校验接口还用于：

在校验得到一个业务规则不匹配时，则判断与不匹配的业务规则对应的营销工具不适用。

在某些实施方式中，所述业务规则引擎还包括：

规则上下文数据包，所述规则上下文数据包用于定义业务规则中使用到的所有事实；

规则条件包，所述规则条件包用于从所述规则上下文数据包中提取与业务规则对应的数据；及

引擎工具包，所述引擎工具包用于定义业务规则编排使用的注解、及/或用于生成编排规则信息。

在某些实施方式中，所述规则条件包包括：

第一函数式接口，用于向规则上下文数据包中定义的事实对象中写入数据；及

第二函数式接口，用于读取规则上下文数据包中的数据，并加工成业务规则中用于判定的数据。

在某些实施方式中，所述规则条件包还包括工具类，所述工具类用于基于新增的业务规则，定义所述第一函数式接口及所述第二函数式接口的写入及/或读取规则。

在某些实施方式中，所述业务规则包括约束类规则条件、行为类规则条件和派生类规则条件中的任意一种或多种。

在某些实施方式中，所述业务规则引擎使用JAVA语言开发，所述规则引擎核心包、所述规则上下文数据包、所述规则条件包、及所述引擎工具包通过JAR包的方式接入所述业务规则引擎。

本申请实施方式的业务规则引擎的处理方法包括：

成营销工具的业务规则匹配链，其中，每个所述营销工具对应一个业务规则匹配链，所述业务规则匹配链包括按执行阶梯排列的多个业务规则；

在待校验的业务规则匹配链小于或等于预设的数量阈值时，串行校验多个业务规则匹配链；及

在待校验的业务规则匹配链大于所述数量阈值时，重新排列所有待校验的业务规则匹配链中的业务规则的执行顺序，并按重新排列的执行顺序校验多个业务规则。

本申请实施方式的业务规则引擎及业务规则引擎的处理方法中，生成营销工具的规则匹配链，在规则匹配链中按不同的执行阶梯排列多个业务规则，在触发校验时，对于业务规则匹配链较少的情况，直接串行多个业务规则匹配链，对于业务规则匹配链较多的情况，重新对所有规则匹配链进行整合，以按照新的执行顺序排列待校验的业务规则，如此，依据校验的不同场景，动态地调整最适宜的校验顺序，提高进行校验的效率。

本申请实施方式的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请的上述和/或附加的方面和优点可以从结合下面附图对实施方式的描述中将变得明显和容易理解，其中：

图1为本申请某些实施方式的业务规则引擎的模块示意图；

图2为本申请某些实施方式利用业务规则引擎进行校验的功能框架示意图；

图3为本申请某些实施方式的业务规则引擎的处理方法的流程示意图。

具体实施方式

下面详细描述本申请的实施方式，所述实施方式的示例在附图中示出，其中，相同或类似的标号自始至终表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本申请的实施方式，而不能理解为对本申请的实施方式的限制。

请参阅图1，图1为本申请某些实施方式的业务规则引擎10的模块示意图，业务规则引擎10包括规则引擎核心包11，规则引擎核心包11包括注册接口111及校验接口112。注册接口111用于生成营销工具的业务规则匹配链，其中，每个营销工具对应一个业务规则匹配链，业务规则匹配链包括按执行阶梯排列的多个业务规则。校验接口112用于在待校验的业务规则匹配链小于或等于预设的数量阈值时，串行校验多个业务规则匹配链；及在待校验的业务规则匹配链大于数量阈值时，重新排列所有待校验的业务规则匹配链中的业务规则的执行顺序，并按重新排列的执行顺序校验多个业务规则。

本申请实施方式的业务规则引擎10中，生成营销工具的规则匹配链，在规则匹配链中按不同的执行阶梯排列多个业务规则，在触发校验时，对于业务规则匹配链较少的情况，直接串行多个业务规则匹配链，对于业务规则匹配链较多的情况，重新对所有规则匹配链进行整合，以按照新的执行顺序排列待校验的业务规则，如此，依据校验的不同场景，动态地调整最适宜的校验顺序，提高进行校验的效率。

具体地，注册接口111用于生成营销工具的业务规则匹配链，其中，业务规则匹配链与营销工具一一对应，规则引擎核心包11会在各个营销工具的机器生成业务规则匹配链。业务规则匹配链包括按执行阶梯排列的多个业务规则，执行阶梯代表业务规则匹配链中被校验的先后顺序，同一个执行阶梯可以并列有多个业务规则，一个业务规则匹配链可以包括一个或多个执行阶梯。

在一个例子中，设计了两个函数式接口用于生成业务规则匹配链，分别为规则判定函数式接口及规则执行函数接口。规则判定函数式接口（Boolean Function）：用于实现业务规则中规则条件判定方法，所有规则条件生成的规则判定函数，按编排的顺序存储到Array Linked List中。规则执行函数接口（Execute Function）：用于实现按顺序执行规则条件列表中的规则判定函数，组装每个规则条件判定结果，得到业务规则的最终执行结果。

校验接口112用于根据入参，执行要校验的多个业务规则匹配链。具体地，当需要执行校验的业务规则匹配链小于或等于预设的数量阈值时，串行校验多个业务规则匹配链。当需要执行校验的业务规则匹配链大于数量阈值时，重新排列待校验的业务规则匹配链中的业务规则的执行顺序，并按重新排列的执行顺序校验多个业务规则。其中，数量阈值可以依据业务规则引擎10的不同处理能力进行设定，例如数量阈值可以是二、三、四、五等，在此不作限制。依据校验的不同场景，采用不同的校验策略，动态地调整最适宜的校验顺序，提高进行校验的效率。

请继续参阅图1，在某些实施方式中，在校验得到一个业务不匹配时，则判断与不匹配的业务规则对应的营销工具不适用。其中，若需要确定适用营销工具，需要与营销工具对应的业务规则匹配链中所有的业务规则均能够校验成功，因此，只需要校验得到一个业务规则不匹配，则可以确定该业务规则所在的业务规则匹配链不匹配，该业务规则匹配链对应的营销工具不适用，而不需要再对业务规则匹配链中其余的业务规则进行校验。故，本实施方式采用反向推理的核心思想，将业务规则的规则条件编成业务规则匹配链，当某个业务规则条件不满足，可以舍弃后面业务规则的校验，极大地提升了效率，非常符合运营增长业务等追求效率的领域。

请继续参阅图1，在某些实施方式中，校验接口112还用于记录校验每个业务规则的平均耗时。在串行校验多个业务规则匹配链时，校验接口112具体用于：

基于平均耗时，对每个业务规则匹配链中，同一阶梯内的多个业务规则按平均耗时从低到高进行第一重新排序；及按第一重新排序校验同一阶梯内的多个业务规则。

具体地，校验接口112记录校验每个业务规则的平均耗时其中，可以记录过去任意数量个相同业务规则校验时的平均耗时，以记录过去10个相同业务规则的平均耗时为例，

，其中，

为过去10次某个相同的业务规则校验的平均耗时。可以理解，当计算得到的校验业务规则的平均耗时越小，代表校验该业务规则越快。

进一步地，在串行校验多个业务规则匹配链时，基于平均耗时，对每个业务规则匹配链中，同一阶梯内的多个业务规则按平均耗时从低到高进行第一重新排序，具体地，同一业务规则匹配链中可以有多个平均耗时不同的业务规则，对该业务规则进行第一重新排序，再按第一排序校验同一阶梯内的多个业务规则，即对于同一个阶梯内的多个业务规则，优先校验平均耗时较低的业务规则，以期尽快地得到整个业务规则匹配链的校验结果。当然，对于不同阶梯内的业务规则，则还是以阶梯为顺序进行校验。

请继续参阅图1，在某些实施方式中，在重新排列所有待校验的业务规则匹配链中的业务规则的执行顺序时，校验接口112用于：

将所有待校验的业务规则匹配链中，同一阶梯的多个业务规则进行整合；基于平均耗时、历史通过率、及整合后同一阶梯中的相同业务规则的共用次数，对整合后同一阶梯中的业务规则进行第二重新排序；及按第二重新排序校验整合后的同一阶梯内的多个业务规则。

对多个业务规则匹配链中，同一阶梯的多个业务规则进行整合，例如，对所有待校验的业务规则匹配链的第一阶梯的业务规则进行整合，该整合包括但不限于对相同的业务规则进行合并。再基于平均耗时、历史通过率、及整合后同一阶梯中的相同业务规则的共用次数，对整合后同一阶梯中的业务规则进行第二重新排序，例如：

，其中，S为进行第二重新排序的衡量参数，S越小，则对应的业务规则进行第二重新排序时的位置越靠前，R为历史通过率，m为不同规则匹配链的同一阶梯中，某个业务规则的共用次数。可以理解，S越小，表示校验对应的业务规则的单位时间的效率越高，应优先被校验。按第二重新排序校验整合后的同一阶梯内的多个业务规则，极大地提升整体匹配效率。当然，本实施方式适用于第一阶梯、第二阶梯、第三阶梯等任意阶梯内的多个业务规则，在此不作限制。

请继续参阅图1，在某些实施方式中，业务规则引擎10还包括规则上下文数据包12、规则条件包13、及引擎工具包14；规则上下文数据包12用于定义业务规则中使用到的所有事实；规则条件包13用于从规则上下文数据包12中提取与业务规则对应的数据；引擎工具包14用于定义业务规则编排使用的注解、及/或用于生成编排规则信息。

具体地，业务规则引擎10使用JAVA语言开发，规则引擎核心包11、规则上下文数据包12、规则条件包13、及引擎工具包14通过JAR包的方式接入业务规则引擎10，如此，提供了已有使用JAVA语言开发的***，快速接入的解决方案，可供软件类工具参考，定义了灵活的函数式接口，对修改开放。另外，使用JAVA这种强类型语言实现规则判定，降低学习和排查问题成本，已有规则条件可快速配置引用。提供了实用的工具可以快速从业务人员配置的数据中生成规则编排信息，降低了接入成本。

如图1所示，规则上下文数据包12用于定义业务规则中使用到的所有事实，在一个例子中，规则条件包13包括第一函数式接口121及第二函数式接口122。第一函数式接口121用于向规则上下文数据包12中定义的事实对象中写入数据；第二函数式接口122用于读取规则上下文数据包12中的数据，并加工成业务规则中用于判定的数据。具体地，第一函数式接口121可以提供上下文数据函数（Context Provider）：向规则上下文数据(规则上下文数据包12中定义的事实对象)中写入数据。第二函数式接口122可以是规则的取判定数据函数（Context Customer）：读取规则上下文数据中的数据,加工成规则条件中用于判定的数据。

在一个营销例子中，自定义业务规则是活动限制车型为小面包或小货车，由订单预支付事件触发业务规则校验，则待判定数据就是订单预支付信息中的车型小面包，数据源就是KAFKA订单预支付的事件数据，提供上下文数据函数功能就是从数据源查询到订单预支付信息，写入到规则上下文数据中。规则上下文数据就是包含规则执行中使用到的所有数据的大对象。取待判定数据函数功能就是从订单预支付信息中读取订单车型值如小面包。业务规则判定就是判定小面包是否在自定义业务规则小面包或小货车中，判定结果就是通过。

请继续参阅图1，规则条件包13用于从规则上下文数据包12中提取与业务规则对应的数据，具体地，当营销工具***配置了选择的业务规则，规则条件包13会利用SpringBoot的Enable Auto Configuration功能将对应的提供上下文数据函数与规则的取判定数据函数Bean注入到营销工具***中。利用Environment Post Processor将必要的配置信息一并注入到营销工具***中，这样营销工具***就可以直接编排使用已有的业务规则。

在一个例子中，规则条件包13还包括工具类，工具类用于基于新增的业务规则，定义第一函数式接口121及第二函数式接口122的写入及/或读取规则。具体地，规则条件包13提供注册新业务规则时的提供上下文数据函数与规则的取判定数据函数的工具类，支持营销工具***新增独有业务规则，同时也提供了覆盖业务规则的取判定数据函数的工具类，支持营销工具***进行二次开发。

如图1所示，引擎工具包14包含业务规则编排使用的注解，以及生成编排规则信息的工具等。在一个例子中，引擎工具包14可以提供8个注解，支持识别编排业务规则，其中，每个注解可以有不同的代表功能，例如，第一注解用于支持行为类业务规则延后执行，以获取其他业务规则执行的结果、第二注解用于支持派生类业务规则，通过名称将业务规则分组，其他业务规则激活分组后，分组内的业务规则才执行。编排规则信息的工具用于支持解析任意存储活动业务规则信息的对象，通过分析注解信息生成业务规则编排信息。

需要说明的是，本申请实施方式的业务规则包括约束类规则条件、行为类规则条件和派生类规则条件中的任意一种或多种。其中，业务规则例如：年龄大于10，业务规则中判定类型例如：如上述业务规则中判定类型为“大于”。约束类规则条件：业务流程中某个过程节点准入或完成的制约条件，比较独立。行为类规则条件：业务中的动态规则，某一事件发生或满足条件触发的规则。派生类规则条件：利用逻辑推理或推断派生出新的实体。

请结合图2，图2为本申请某些实施方式利用业务规则引擎10进行校验的功能框架示意图，业务人员创建营销活动，并利用引擎工具包14注册编排业务规则，生成业务规则匹配链，依据发生的事件触发营销活动，准备好待判定数据后进行业务规则判定，生成判定结果，再依据判定结果进行营销活动业务逻辑处理。其中，业务规则判定的核心流程为：获取待判定数据、判定、记录判定结果、返回结果。具体的判定方式可以结合上述对业务规则引擎10的描述，在此不再赘述。

请参阅图3，图3为本申请某些实施方式的业务规则引擎的处理方法的流程示意图，业务规则引擎的处理方法包括步骤：

生成营销工具的业务规则匹配链，其中，每个营销工具对应一个业务规则匹配链，业务规则匹配链包括按执行阶梯排列的多个业务规则；

在待校验的业务规则匹配链小于或等于预设的数量阈值时，串行校验多个业务规则匹配链；及

在待校验的业务规则匹配链大于数量阈值时，重新排列所有待校验的业务规则匹配链中的业务规则的执行顺序，并按重新排列的执行顺序校验多个业务规则。

业务规则引擎的处理方法的相关实施细节可以参考上述对业务规则引擎10的相关描述，在此不再赘述。可以理解，业务规则引擎的处理方法还包括业务规则引擎10内的所有组成部分能够实现的功能，在此不再一一列出。

在本说明书的描述中，参考术语“一个实施方式”、“一些实施方式”、“示意性实施方式”、“示例”、“具体示例”或“一些示例”等的描述意指结合所述实施方式或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施方式或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施方式或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施方式或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

尽管上面已经示出和描述了本申请的实施方式，可以理解的是，上述实施方式是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施方式进行变化、修改、替换和变型。

Claims (10)

1. 一种业务规则引擎，其特征在于，所述业务规则引擎包括规则引擎核心包，所述规则引擎核心包包括：

注册接口，所述注册接口用于生成营销工具的业务规则匹配链，其中，每个所述营销工具对应一个业务规则匹配链，所述业务规则匹配链包括按执行阶梯排列的多个业务规则；及

校验接口，所述校验接口用于：在待校验的业务规则匹配链小于或等于预设的数量阈值时，串行校验多个业务规则匹配链；及在待校验的业务规则匹配链大于所述数量阈值时，重新排列所有待校验的业务规则匹配链中的业务规则的执行顺序，并按重新排列的执行顺序校验多个业务规则。

2.根据权利要求1所述的业务规则引擎，其特征在于，所述校验接口还用于记录校验每个业务规则的平均耗时；

在串行校验多个业务规则匹配链时，所述校验接口用于：

基于所述平均耗时，对每个业务规则匹配链中，同一阶梯内的多个业务规则按平均耗时从低到高进行第一重新排序；及

按所述第一重新排序校验同一阶梯内的多个业务规则。

3.根据权利要求2所述的业务规则引擎，其特征在于，在重新排列所有待校验的业务规则匹配链中的业务规则的执行顺序时，所述校验接口用于：

将所有待校验的业务规则匹配链中，同一阶梯的多个业务规则进行整合；

基于所述平均耗时、历史通过率、及整合后同一阶梯中的相同业务规则的共用次数，对整合后同一阶梯中的业务规则进行第二重新排序；及

按所述第二重新排序校验整合后的同一阶梯内的多个业务规则。

4.根据权利要求1所述的业务规则引擎，其特征在于，所述校验接口还用于：

在校验得到一个业务规则不匹配时，则判断与不匹配的业务规则对应的营销工具不适用。

5.根据权利要求1至4任意一项所述的业务规则引擎，其特征在于，所述业务规则引擎还包括：

规则上下文数据包，所述规则上下文数据包用于定义业务规则中使用到的所有事实；

规则条件包，所述规则条件包用于从所述规则上下文数据包中提取与业务规则对应的数据；及

引擎工具包，所述引擎工具包用于定义业务规则编排使用的注解、及/或用于生成编排规则信息。

6. 根据权利要求5所述的业务规则引擎，其特征在于，所述规则条件包包括：

第一函数式接口，用于向规则上下文数据包中定义的事实对象中写入数据；及

第二函数式接口，用于读取规则上下文数据包中的数据，并加工成业务规则中用于判定的数据。

7.根据权利要求6所述的业务规则引擎，其特征在于，所述规则条件包还包括工具类，所述工具类用于基于新增的业务规则，定义所述第一函数式接口及所述第二函数式接口的写入及/或读取规则。

8.根据权利要求5所述的业务规则引擎，其特征在于，所述业务规则包括约束类规则条件、行为类规则条件和派生类规则条件中的任意一种或多种。

9.根据权利要求5所述的业务规则引擎，其特征在于，所述业务规则引擎使用JAVA语言开发，所述规则引擎核心包、所述规则上下文数据包、所述规则条件包、及所述引擎工具包通过JAR包的方式接入所述业务规则引擎。

10.一种业务规则引擎的处理方法，其特征在于，所述业务规则引擎的处理方法包括：

生成营销工具的业务规则匹配链，其中，每个所述营销工具对应一个业务规则匹配链，所述业务规则匹配链包括按执行阶梯排列的多个业务规则；

在待校验的业务规则匹配链小于或等于预设的数量阈值时，串行校验多个业务规则匹配链；及

在待校验的业务规则匹配链大于所述数量阈值时，重新排列所有待校验的业务规则匹配链中的业务规则的执行顺序，并按重新排列的执行顺序校验多个业务规则。

Images