规则引擎的组建方法/系统、业务管理方法/系统及设备与流程

本发明属于计算机技术领域，涉及一种组建方法和系统，及管理方法及系统，特别是涉及一种规则引擎的组建方法/系统、业务管理方法/系统及设备。

背景技术：

当下，信息系统变得越来越复杂，业务需求的变化也越来越快，业务保密性要求越来越高，业务需求的迭代周期要求反应迅速，代码的逻辑越来越难管理。传统的应用开发流程多，周期长，业务和技术的沟通成本大。企业达不到快速响应，最终跟不上市场节奏。

什么是业务规则？在需求里面我们往往把约束，完整性，校验，分支流等都可以算到业务规则里面。在规则引擎里面谈的业务规则重点是谈当满足什么样的条件的时候，需要执行什么样的操作。因此一个完整的业务规则包括了条件和触发操作两部分内容。而引擎是事物内部的重要的运行机制，规则引擎即重点是解决规则如何描述，如何执行，如何监控等一系列问题。

传统的开发平台是将业务逻辑硬编码到应用系统中，导致无法将业务逻辑与应用逻辑的分离，在面对新的应用时需要重新编译和部署应用系统，开发平台不具有可重用性和可配置性，而这大大降低了企业对市场变化的反应速。

因此，如何提供一种规则引擎的组建方法/系统、业务管理方法/系统及设备，以解决现有技术无法将业务逻辑与应用逻辑的分离，在面对新的应用时需要重新编译和部署应用系统，开发平台不具有可重用性和可配置性，而这大大降低了企业对市场变化的反应速等缺陷，实已成为本领域技术人员亟待解决的技术问题。

技术实现要素：

鉴于以上所述现有技术的缺点，本发明的目的在于提供一种规则引擎的组建方法/系统、业务管理方法/系统及设备，用于解决现有技术中现有技术无法将业务逻辑与应用逻辑的分离，在面对新的应用时需要重新编译和部署应用系统，开发平台不具有可重用性和可配置性，而这大大降低了企业对市场变化的反应速的问题。

为实现上述目的及其他相关目的，本发明一方面提供一种一种规则引擎的组建方法，所述规则引擎的组建方法包括以下步骤：提供一用于对逻辑规则进行编辑的第一规则配置界面；在所述第一规则配置界面上编译至少一种用于配置逻辑规则的规则组件；组合所述规则组件以编排各种业务逻辑，并将所编排的各种业务逻辑，组合的规则组件以预定格式存储，形成用于分离业务和应用的第二规则配置界面；其中，所述业务逻辑具有指定的工程名；所述工程名用于表示用户的业务目的。

于本发明的一实施例中，所述规则组件包括：决策树，用于以分支形式配置若干逻辑规则及规则组件的执行顺序；评分卡，用于在所述决策树的一个分支下，根据预定义的评分规则，对在所述第一规则配置界面上输入的与该工程名相关的逻辑规则进行评分；规则集，用于在所述决策树的一个分支下，根据预定义的准入规则，判断在所述第一规则配置界面上输入的与该工程名相关的逻辑规则是否准入；和/或执行脚本，用于根据工程名和所输入的逻辑规则，执行逻辑规则、评分规则和/或准入规则，并获取分别与所述评分规则、准入规则匹配的逻辑结果。

于本发明的一实施例中，所述组合所述规则组件的步骤是指以规则组件的执行顺序将所述规则组件组合起来。

于本发明的一实施例中，所述预定格式为轻量级的数据交换格式。

本发明另一方面提供一种基于规则引擎的组建方法的业务管理方法，所述业务管理方法包括以下步骤：通过所述第二规则配置界面，接收用户所指定的工程名；根据所述工程名，查找与所述工程名对应的执行脚本；在所述执行脚本的运行过程中，通过所述第二规则配置界面记录与该工程名相关的逻辑规则，以获取与所述逻辑规则匹配的业务决策；该逻辑规则是用户根据业务需求而输入。

于本发明的一实施例中，在接收所述输入逻辑规则之后，所述基于规则的业务决策管理方法还包括将所述输入逻辑规则以文本格式存储。

于本发明的一实施例中，所述业务管理方法还包括在所述执行脚本的运行过程中，需解析规则组件之间是否存在依赖性。

本发明另一方面还提供一种规则引擎的组建系统，所述规则引擎的组建系统包括：提供模块，用于提供一用于对逻辑规则进行编辑的第一规则配置界面；编译模块，用于在所述第一规则配置界面上编译至少一种用于配置逻辑规则的规则组件；第一处理模块，用于组合所述规则组件以编排各种业务逻辑，并将所编排的各种业务逻辑，组合的规则组件以预定格式存储，形成用于分离业务和应用的第二规则配置界面；其中，所述业务逻辑具有指定的工程名；所述工程名用于表示用户的业务目的。

本发明另一方面还提供一种基于规则引擎的组建系统的业务管理系统，所述业务管理系统包括：接收模块，用于通过所述第二规则配置界面，接收用户所指定的工程名；查找模块，用于根据所述工程名，查找与所述工程名对应的执行脚本；第二处理模块，用于在所述执行脚本的运行过程中，通过所述第二规则配置界面记录与该工程名相关的逻辑规则，以获取与所述逻辑规则匹配的业务决策；该逻辑规则是用户根据业务需求而输入。

本发明最后一方面提供一种设备，所述设备包括所述的规则引擎的组建系统和/或所述的业务管理系统。

如上所述，本发明的规则引擎的组建方法/系统、业务管理方法/系统及设备，具有以下有益效果：

第一，规则流程灵活配置；各种组件不同组合，完成复杂的规则流程。

第二，规则可视化易管理；编辑好的流程可视化，业务人员能迅速了解整个策略的大纲，并且能查询其中的细节。

第三，显著提升业务策略的发布速度；传统开发模式，调整一个策略，修改一个阀值，都要通过业务和研发的需求确认，研发开发，测试接入，而使用规则引擎后，业务人员自行开发，测试(规则引擎平台提供单元测试和批量测试界面)。整个发布流程大大简化，原先规则和策略修改如果需要若干天才能正式发布的话，那使用规则引擎之后在很短时间内就可以发布，简单的规则甚至半小时就可以正式生效。

第四，规则保密性；按照传统模式开发，在某些行业中，比如风控，业务人员需要将完整的风控政策告知与研发人员，才能开发出来，使用规则引擎后，研发团队无需再涉及到规则细节，提高了规则的保密性。所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。

附图说明

图1显示为本发明的规则引擎的组建方法于一实施例中的流程示意图。

图2显示为本发明的基于规则引擎的组建方法的业务管理方法于一实施例中的流程示意图。

图3显示为本发明的规则引擎的组建系统及基于规则引擎的组建系统的业务管理系统于一实施例中的原理结构示意图。

元件标号说明

2规则引擎的组建系统

21提供模块

22编译模块

23第一处理模块

3基于规则引擎的组建

系统的业务管理系统

31接收模块

32查找模块

33第二处理模块

s1～s3步骤

s1’～s4’步骤

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

本发明的所提供的规则引擎是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中的分离，并使用预定义的语义模块编写业务决策。接收数据输入，解释业务规则，并根据规则作出业务决策。

实施例一

本实施例提供一种规则引擎的组建方法，所述规则引擎的组建方法包括以下步骤：

提供一用于对逻辑规则进行编辑的第一规则配置界面；

在所述第一规则配置界面上编译至少一种用于配置逻辑规则的规则组件；

组合所述规则组件以编排各种业务逻辑，并将所编排的各种业务逻辑，组合的规则组件以预定格式存储，形成用于分离业务和应用的第二规则配置界面；其中，所述业务逻辑具有指定的工程名；所述工程名用于表示用户的业务目的。

以下将结合图示对本实施例所述的规则引擎的组建方法进行详细描述。请参阅图1，显示为规则引擎的组建方法于一实施例中的流程示意图。如图1所示，所述规则引擎的组建方法具体包括以下几个步骤：

s1，提供一用于对逻辑规则进行编辑的第一规则配置界面。在本实施例中，所述第一规则配置界面为待配置状态的初始界面。在本实施例中，在所述第一规则配置界面上可以建立、修改及删除逻辑规则。

s2，在所述第一规则配置界面上编译至少一种用于配置逻辑规则的规则组件。在本实施例中，所述规则组件包括工程名、决策树、评分卡、规则集、及执行脚本等等。

其中，所述工程名用于表示用户的业务目的。例如，计算税后工资，审批贷款等。

所述决策树用于以分支形式配置若干逻辑规则及规则组件的执行顺序。第一层分支配置逻辑规则为用户是否为一线城市。因此，收入大于10000的分为一线城市的分支和非一线城市的分支。在本实施例中，规则组件的执行顺序为建立决策树、编译评分卡、编译规则集、及编译执行脚本。

所述评分卡用于在所述决策树的一个分支下，根据预定义的评分规则，对在所述第一规则配置界面上输入的与该工程名相关的逻辑规则进行评分。

在所述第一规则配置界面上输入的与该工程名相关的逻辑规则，例如为，性别、年龄、用户收入、职位等。

预定义的评分规则，例如为，性别：男40分，女60分；

年龄：14～18岁20分，19～30岁40分，30岁以上30分；

收入：10000以下60分，10000～20000区间100分，20000以上200分；

职位：经理100分，普通职员60分。

通过以上预定义的评分规则，得出一个总体评分。

所述规则集用于在所述决策树的一个分支下，根据预定义的准入规则，判断在所述第一规则配置界面上输入的与该工程名相关的逻辑规则是否准入。

在所述第一规则配置界面上输入的与该工程名相关的逻辑规则，例如为，总体评分、总通讯录个数且有效通讯录数、联系人中是否存在黑名单、学历是否大专以上、被拒绝过评分卡中的逻辑规则，且中国评分卡中的逻辑规则中的一个、通讯录是否存在黑名单用户等。

预定义的准入规则，例如为，总体评分<220

总通讯录个数>50并且有效通讯录<10

联系人中存在黑名单(不包含紧急联系人)

学历大专以上

被拒绝过并且中过原因码10,20,30中的一个

通讯录存在黑名单用户。

在本实施例中，还需根据预定义的准入规则，为规则集中的每个逻辑规则设置一个规则号，例如，年龄小于18岁配置的规则号为1001，年龄大于等于18岁配置的规则号为1002，性别为男配置的规则号为1002等。在第一规则配置界面上输入逻辑规则后，根据预定义的准入规则设置规则号。

所述执行脚本用于根据工程名和所输入的逻辑规则，执行评分规则和/或准入规则，并获取分别与所述评分规则、准入规则匹配的逻辑结果。

例如，在所述第一规则配置界面上输入的与该工程名相关的逻辑规则为用户年龄小于18岁，则拒绝。

那么执行脚本根据准入规则，用户年龄大于等于18岁，输出逻辑结果“通过”，用户年龄小于18岁，输出逻辑结果“拒绝”。

例如，if(input.#年龄#＜18)

output.#逻辑结果#＝’d’；

else

output.#逻辑结果#＝’p’。

在本实施例中，包括工程名、决策树、评分卡、规则集、及执行脚本等等的规则组件都配置有用以识别组件的组件id。

s3，将步骤s2编译的各种规则组件，即决策树、评分卡、规则集、及执行脚本按照规则组件的执行顺序，编排各种业务逻辑，并将所编排的各种业务逻辑，组合的规则组件以预定格式存储，形成用于分离业务和应用的第二规则配置界面；其中，所述业务逻辑具有指定的工程名；所述工程名用于表示用户的业务目的。在本实施例中，所述预定格式为轻量级的数据交换格式，即json。

本实施例还提供一种基于规则引擎的组建方法的业务管理方法，所述业务管理方法包括以下步骤：

通过所述第二规则配置界面，接收用户所指定的工程名；

根据所述工程名，查找与所述工程名对应的执行脚本；

在所述执行脚本的运行过程中，通过所述第二规则配置界面记录与该工程名相关的逻辑规则，以获取与所述逻辑规则匹配的业务决策；该逻辑规则是用户根据业务需求而输入。

以下将结合图示对本实施例提供的基于规则引擎的组建方法的业务管理方法进行详细描述。请参阅图2，显示为业务管理方法于一实施例中的流程示意图。如图2所示，所述业务管理方法具体包括以下几个步骤：

s1’，通过所述第二规则配置界面，接收用户所指定的工程名。所述工程名实质上为一标记。例如，calcugongzi，其含义就是用户的业务目的为计算税后工资。

s2’，根据所述工程名，查找与所述工程名对应的执行脚本。例如，查找与计算税后工资对应的执行脚本。

s3’，在所述执行脚本的运行过程中，通过所述第二规则配置界面记录与该工程名相关的逻辑规则，以获取与所述逻辑规则匹配的业务决策；该逻辑规则是用户根据业务需求而输入。与该工程名相关的逻辑规则包括决策树上配置的逻辑规则，评分卡中配置的逻辑规则，和/或规则集中配置的逻辑规则。

在本实施例中，在所述执行脚本的运行过程中，执行脚本运行前，需解析规则组件之间是否存在依赖性。解析过程为：

根据规则组件查找与该组件对应的json内容；

判断该规则组件是否已存在；若是，解析该组件，并判断是否存在依赖于该组件的另一组件未被解析，若是，根据另一组件的组件id查找另一组件的json内容。若否，则将该组件注册到数据库中。

在本实施例中，通过所述第二规则配置界面记录与该工程名相关的逻辑规则之后，与该工程名相关的逻辑规则会以文本形式保存于硬盘上。由于硬盘删的文本是不能当程序去执行逻辑，那么就需读取这些文本，查找与这些文本对应的执行脚本来执行逻辑规则。

s4’，与所述逻辑规则匹配的业务决策以api形式输出。

本实施例所述的规则引擎的组建方法和基于规则引擎的组建方法的业务管理方法具有以下有益效果：

第一，规则流程灵活配置；各种组件不同组合，完成复杂的规则流程。

第二，规则可视化易管理；编辑好的流程可视化，业务人员能迅速了解整个策略的大纲，并且能查询其中的细节。

第三，显著提升策略的发布速度；传统开发模式，调整一个策略，修改一个阀值，都要通过业务和研发的需求确认，研发开发，测试接入，而使用规则引擎后，业务人员自行开发，测试(规则引擎平台提供单元测试和批量测试界面)。整个发布流程大大简化，原先规则和策略修改如果需要若干天才能正式发布的话，那使用规则引擎之后在很短时间内就可以发布，简单的规则甚至半小时就可以正式生效。

第四，规则保密性；按照传统模式开发，在某些行业中，比如风控，业务人员需要将完整的风控政策告知与研发人员，才能开发出来，使用规则引擎后，研发团队无需再涉及到规则细节，提高了规则的保密性。

实施例二

本实施例提供一种规则引擎的组建系统2及基于规则引擎的组建系统的业务管理系统3，请参阅图3，显示为规则引擎的组建系统及基于规则引擎的组建系统的业务管理系统3于一实施例中的原理结构示意图。如图3所示，所述规则引擎的组建系统2包括：提供模块21、编译模块22、及第一处理模块23。

所述提供模块21用于提供一用于对逻辑规则进行编辑的第一规则配置界面。在本实施例中，所述第一规则配置界面为待配置状态的初始界面。在本实施例中，用户可以在所述第一规则配置界面上可以建立、修改及删除逻辑规则。

与所述提供模块21连接的编译模块22用于在所述原始的规则配置界面规则配置界面上编译至少一种用于配置逻辑规则的规则组件。在本实施例中，所述规则组件包括工程名、决策树、评分卡、规则集、及执行脚本等等。

其中，所述工程名用于表示用户的业务目的。例如，计算税后工资，审批贷款等。

所述决策树用于以分支形式配置若干逻辑规则及规则组件的执行顺序。第一层分支配置逻辑规则为用户是否为一线城市。因此，收入大于10000的分为一线城市的分支和非一线城市的分支。在本实施例中，规则组件的执行顺序为建立决策树、编译评分卡、编译规则集、及编译执行脚本。

所述评分卡用于在所述决策树的一个分支下，根据预定义的评分规则，对在所述第一规则配置界面上输入的与该工程名相关的逻辑规则进行评分。

在所述第一规则配置界面上输入的与该工程名相关的逻辑规则，例如为，性别、年龄、用户收入、职位等。

预定义的评分规则，例如为，性别：男40分，女60分；

年龄：14～18岁20分，19～30岁40分，30岁以上30分；

收入：10000以下60分，10000～20000区间100分，20000以上200分；

职位：经理100分，普通职员60分。

通过以上预定义的评分规则，得出一个总体评分。

所述规则集用于在所述决策树的一个分支下，根据预定义的准入规则，判断在所述第一规则配置界面上输入的与该工程名相关的逻辑规则是否准入。

在所述第一规则配置界面上输入的与该工程名相关的逻辑规则，例如为，总体评分、总通讯录个数且有效通讯录数、联系人中是否存在黑名单、学历是否大专以上、被拒绝过评分卡中的逻辑规则，且中国评分卡中的逻辑规则中的一个、通讯录是否存在黑名单用户等。

预定义的准入规则，例如为，总体评分<220

总通讯录个数>50并且有效通讯录<10

联系人中存在黑名单(不包含紧急联系人)

学历大专以上

被拒绝过并且中过原因码10,20,30中的一个

通讯录存在黑名单用户。

在本实施例中，还需根据预定义的准入规则，为规则集中的每个逻辑规则设置一个规则号。在第一规则配置界面上输入逻辑规则后，根据预定义的准入规则设置规则号。

所述执行脚本用于根据工程名和所输入的逻辑规则，执行评分规则和/或准入规则，并获取分别与所述评分规则、准入规则匹配的逻辑结果。

例如，在所述第一规则配置界面上输入的与该工程名相关的逻辑规则为用户年龄小于18岁，则拒绝。

那么执行脚本根据准入规则，用户年龄大于等于18岁，输出逻辑结果“通过”，用户年龄小于18岁，输出逻辑结果“拒绝”。

在本实施例中，包括工程名、决策树、评分卡、规则集、及执行脚本等等的规则组件都配置有用以识别组件的组件id。

与所述编译模块22连接的第一处理模块23用于将所述编译模块22编译的各种规则组件，即决策树、评分卡、规则集、及执行脚本按照规则组件的执行顺序，编排各种业务逻辑，并将所编排的各种业务逻辑，组合的规则组件以预定格式存储，形成用于分离业务和应用的第二规则配置界面；其中，所述业务逻辑具有指定的工程名；所述工程名用于表示用户的业务目的。在本实施例中，所述预定格式为轻量级的数据交换格式，即json。

继续参阅图3，所述基于规则引擎的组建系统的业务管理系统3包括接收模块31、查找模块32、及第二处理模块33。

所述接收模块31通过所述第二规则配置界面，接收用户所指定的工程名。所述工程名实质上为一标记。例如，calcugongzi，其含义就是用户的业务目的为计算税后工资。

与所述接收模块31连接的查找模块32用于根据所述工程名，查找与所述工程名对应的执行脚本。例如，查找与计算税后工资对应的执行脚本。

与所述查找模块32连接的第二处理模块33用于在所述执行脚本的运行过程中，通过所述第二规则配置界面记录与该工程名相关的逻辑规则，以获取与所述逻辑规则匹配的业务决策；该逻辑规则是用户根据业务需求而输入。与该工程名相关的逻辑规则包括决策树上配置的逻辑规则，评分卡中配置的逻辑规则，和/或规则集中配置的逻辑规则。

在本实施例中，所述第二处理模块33在所述执行脚本的运行过程中，执行脚本运行前，还需解析规则组件之间是否存在依赖性。解析过程为：

根据规则组件查找与该组件对应的json内容；

判断该规则组件是否已存在；若是，解析该组件，并判断是否存在依赖于该组件的另一组件未被解析，若是，根据另一组件的组件id查找另一组件的json内容。若否，则将该组件注册到数据库中。

在本实施例中，通过所述第二规则配置界面记录与该工程名相关的逻辑规则之后，所述第二处理模块33将与该工程名相关的逻辑规则会以文本形式保存于硬盘上。由于硬盘删的文本是不能当程序去执行逻辑，那么就需读取这些文本，查找与这些文本对应的执行脚本来执行逻辑规则。

所述第二处理模块33还用于与所述逻辑规则匹配的业务决策以api形式输出。

本实施例还提供一种设备，该设备包括上述规则引擎的组建系统2和/或基于规则引擎的组建系统的业务管理系统3。

综上所述，本发明所述的规则引擎的组建方法和基于规则引擎的组建方法的业务管理方法、规则引擎的组建系统和基于规则引擎的组建方法的业务管理系统，及具有组建系统和业务管理系统的设备具有以下有益效果：

第一，规则流程灵活配置；各种组件不同组合，完成复杂的规则流程。

第二，规则可视化易管理；编辑好的流程可视化，业务人员能迅速了解整个策略的大纲，并且能查询其中的细节。

第三，显著提升策略的发布速度；传统开发模式，调整一个策略，修改一个阀值，都要通过业务和研发的需求确认，研发开发，测试接入，而使用规则引擎后，业务人员自行开发，测试(规则引擎平台提供单元测试和批量测试界面)。整个发布流程大大简化，原先规则和策略修改如果需要若干天才能正式发布的话，那使用规则引擎之后在很短时间内就可以发布，简单的规则甚至半小时就可以正式生效。

第四，规则保密性；按照传统模式开发，在某些行业中，比如风控，业务人员需要将完整的风控政策告知与研发人员，才能开发出来，使用规则引擎后，研发团队无需再涉及到规则细节，提高了规则的保密性。所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。

上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。