一种面向业务人员的规则引擎适配器装置的识别方法

技术领域

本发明属于通信技术领域，尤其涉及一种面向业务人员的规则引擎适配器装置的识别方法。

背景技术

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

规则引擎主要包括RETE算法、DSL、表达式等主要几类。其中基于RETE算法的规则引擎是目前使用最广泛、也是执行效率较好的一种规则算法。它是一种高效的模式匹配算法用来实现产生式规则系统，RETE可以被分为两部分：规则编译和运行时执行。规则编译是指根据规则集成生成推理网络的过程，运行时执行指将数据送入推理网络进行筛选的过程。基于RETE算法的规则设计器，在功能强大、变更灵活、界面友好方面牺牲了部分界面友好性，在面向懂技术的开发人员时，还是一个简单易用的规则设计器，但是面向业务人员时还是比较抽象，导致业务人员在使用规则引擎时不易上手，较难与业务系统无缝对接。

发明内容

本发明提供了一种面向业务人员的规则引擎适配器装置的识别方法，以解决业务人员在使用规则引擎时不易上手，较难与业务系统无缝对接的问题。

一种面向业务人员的规则引擎适配器装置的识别方法，包括以下步骤：

步骤1：定义DSL的接口报文格式，定义包括规则变量库、运算符、变量类型、数据类型、报文结构元素的属性；

步骤2：定义基于java语言的客户端SDK，定义包括SDK与规则引擎服务端交互的RPC协议、嵌入式WEB容器、JSON与DSL的转换逻辑；

步骤3：定义基于HTML的规则设计界面，定义包括界面风格、数据表单、报文格式、报文传输方式；

步骤4：将包含有轻量级WEB容器的SDK载入业务系统，业务人员通过HTTP链接访问和使用SDK中的规则设计器；

步骤5：在客户端SDK包中定义JSON数据与DSL报文的映射逻辑，用于将输入规则数据转换到DSL格式的报文，便于规则引擎服务端识别和构建规则模型；

步骤6：在客户端SDK包中定义JSON数据与JAVA类对象的映射逻辑，用于输入数据按字段存储，便于前端HTML界面展示存储的规则数据。

与现有技术相比本发明的有益效果是：1.本发明可以作为通用规则引擎设计器的适配装置，既满足开发人员在线仿真测试、版本控制、规则模型实时变更且不用修改代码的需求，同时经过适配器的转换，又满足了业务人员操作简单，与业务系统无缝集成的特点。

2.本发明能够将规则引擎界面无缝嵌入到业务系统管理后台，提供表单式的规则设计界面，方便业务人员在线实时创建、变更规则，同时对规则的执行状态提供监控接口。

附图说明

图1为本发明的流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

参见附图1，本发明所述的一种面向业务人员的规则引擎适配器装置的识别方法，包括以下步骤：

步骤1：定义DSL的接口报文格式，定义包括规则变量库、运算符、变量类型、数据类型、报文结构元素的属性；例如rule-set、rule、import-variable-library等规则元数据，也包括count、avg、sum、max、and、or等；

通过定义面向WEB表单的规则设计界面接口，用于将复杂的图形化的数据接口转换成更简洁的DSL接口；

步骤2：定义基于java语言的客户端SDK，定义包括SDK与规则引擎服务端交互的RPC协议、嵌入式WEB容器、JSON与DSL的转换逻辑；

业务人员一般通过业务管理系统进行业务运营和管理，业务规则设计也被定义为业务运营的一部分；多数银行的规则引擎作为一个可被共享的基础平台可被多个业务系统共同使用，规则引擎和业务系统也可以由不同的部门负责，规则设计器与业务系统的无缝衔接将直接影响到业务人员使用规则引擎的流畅度；而步骤2中提到定义基于java语言的客户端SDK，而由于SDK中包含了轻量级WEB容器，只要SDK被载入业务系统，规则设计器就可以直接使用，可以无缝衔接到业务系统，不需要业务系统考虑规则设计器整合和部署的问题。

步骤3：定义基于HTML的规则设计界面，定义包括界面风格、数据表单、报文格式、报文传输方式；

步骤4：将包含有轻量级WEB容器的SDK载入业务系统，业务人员通过HTTP链接访问和使用SDK中的规则设计器。

基于HTML表单的规则设计器界面部署在客户端SDK内的嵌入式WEB容器中，只要业务系统载入SDK既可以通过HTTP链接访问和使用规则设计器。这样设计主要有两个目的，一是为了规则设计器能够无缝嵌入到业务系统，方便业务人员使用规则设计器；二是避免了业务系统额外部署或代码级嵌入规则设计器，达到即开即用的目的。并且通过定义基于HTML的规则设计界面，使得业务人员操作更加简单。

步骤5：在客户端SDK包中定义JSON数据与DSL报文的映射逻辑，用于将输入规则数据转换到DSL格式的报文，便于规则引擎服务端识别和构建规则模型；

业务人员从HTML规则设计器输入的规则数据在前端页面是以通用的JSON格式封装，但是规则引擎服务器提供的是DSL报文接口，需要将JSON格式转换成DSL后再提交到规则引擎服务器。客户端SDK承担了JSON到DSL的报文转换工作。这样设计主要是避免将规则引擎的一些技术细节暴露给业务系统，业务系统只需要使用规则设计器，无需关注内部实现细节。

步骤6：在客户端SDK包中定义JSON数据与JAVA类对象的映射逻辑，用于输入数据按字段存储，便于前端HTML界面展示存储的规则数据。

基于HTML的规则设计器除了提供创建规则的能力，还需要对规则进行查阅和变更，创建规则时规则引擎服务端将规则因子构建成规则模型，再将整个规则模型储存到关系数据库。如果业务人员要查阅或变更规则模型，需要将复杂的规则模型解析成一系列的规则因子。因此，为了规则设计器能够方便的查阅和变更规则模型，在规则创建时有两条并行路径，如步骤5所述：一条是将规则因子构建成规则模型后，将整个规则模型存储在关系数据库中，用于后续的规则服务调用；另一条路径是如步骤6所述，将业务人员输入的规则因子直接存储到关系数据库，业务人员查阅规则直接读取原始规则因子，变更规则时需要同时变更上述两条路径的数据。

所述步骤1中，根据基于RETE算法的规则引擎建模要求，将规则变量、数据、计算逻辑表示为DSL格式的报文，报文类容包括但不限于rule-set、rule、import-variable-library规则元数据和count、avg、sum、max、and、or运算符。

所述步骤2中，将面向业务人员使用的规则设计界面封装在客户端SDK中，以嵌入式web容器来运行规则设计界面；从规则设计界面输入的数据通过JSON与DSL的转换逻辑，将前端数据转换成DSL格式的报文后，再以RPC协议传输到规则引擎服务端。

所述步骤3中，基于HTML的规则设计界面根据实际业务需求定制化，使得客户启动后就可以直接访问该界面，以便于以链接形式嵌入到业务管理系统中，不会对原有系统造成代码侵入，即插即用，非常便利。

所述步骤5中，前端规则设计界面的数据以JSON格式传到客户端SDK中，再经过SDK中的JSON转DSL逻辑处理后，规则数据最终以DSL格式通过RPC协议传输到规则引擎服务端构建规则模型。

所述步骤6中，前端规则设计界面除了录入数据外，还需要展示数据库中已有的规则数据；因此将前端JSON格式的原始数据在客户端SDK中转换成Java对象，再按字段存储在关系数据库中，用于前端规则设计界面展示用；使得前端展现的规则数据更加简单。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。