目录

一、Drools 简介

电商平台的促销活动

规则引擎

Drools 简介

二、Drools 快速入门 

电商平台促销积分规则

开发实现

三、Drools 规则引擎构成及其核心类

Drools规则引擎构成

Drools规则引擎概念

四、Drools 基础语法

规则文件构成

 规则体语法结构

规则注释

Pattern模式匹配

规则比较操作符

操作步骤 

执行指定规则 

关键字

 五、Drools 规则属性 attributes

enabled属性 

dialect属性

salience属性 

no-loop属性

 lock-on-active属性

activation-group属性

agenda-group属性

auto-focus属性

timer属性

date-effective属性

date-expires属性

六、Drools高级语法

 global全局变量

query查询

 function函数

条件-LHS加强

复合值限制in/not in

条件元素eval

条件元素not

条件元素exists

规则继承

结果-RHS

insert方法

update方法

modify方法

retract/delete方法

RHS加强

halt

getWorkingMemory

getRule

规则文件编码规范

七、WorkBench

 WorkBench简介

配置 Tomcat

启动服务器

WorkBench使用 

创建空间、项目

创建数据对象和drl文件

设置KieBase+KieSession

代码使用 

---

        小明是一家互联网公司的软件工程师，他们公司为了吸引新用户经常会搞活动，小明常常为了做活动加班加点很烦躁，这不今天呀又来了一个活动需求，我们大家一起帮他看看。

        活动规则是根据用户购买订单的金额给用户送相应的积分，购买的越多送的积分越多，用户可以使用积分来兑换相应的商品，我们这次活动的力度很大，肯定会吸引很多的用户参加，产品经理小王兴高采烈唾液横飞的对小明讲到。小明心想，又tm来这套，这次需求又要变更多少次呢？表面上还的配合，说赶紧把规则给我们吧，早点开发早点上线，小王说这次需求老简单啦，估计你们两个小时就搞定了，不信你看需求文档。

小明一看，这需求果然简单呀，作为一个工作了两三年的程序员来讲，这不就是小case，半天搞定，送积分的核心代码如下：

        上线运行了半天之后，财务部的小财突然监测到活动账户的金额大为减少，发现产品做活动竟然没有通知到他，非常不爽，于是给领导小马说，这样大规模的活动，对公司财务有压力，领导小马权衡了一番说，这样吧活动继续，但是金额翻倍再送积分，于是规则变成了这样：200元以下不给积分，1000元以下给100积分…

        小明看领导都发话了，没办法改呀，不过也简单，就是将里面的值都翻了倍，在投产上去，只是挨了不少测试的白眼。

        活动又进行了一天，运营人员通过后台监控发现提到2倍以后，用户积极性变的很差，活动效果不理想，和领导商议了一下，改为最初规则的1.5倍，及150元一下不给积分，750元以下给100积分… 小明这时候的心情大概是这样子的，一万个下图动物狂奔而过。

        没办法还得改不是，当然这次小明可学乖了，将这些数据（多少元送多少分）存到了数据库中，当老板再改主意的时候，只要改一下数据库的值就可以了，小明为自己的明聪明到有点小高兴。 

核心代码：

        正当小明得意洋洋的打了个最新版本投产上线之后，产品经理小王说积分规则层次太少了，由以前的4组变成8组，小明此刻的心情：kao …

        小明想这样下去非得被他们弄死，必须要找找有什么技术可以将活动规则和代码解耦，不管规则如何变化，执行端不用动。小明搜了半天还真有这样的东西，那就是规则引擎，那么规则引擎到底是什么东西呢？我们来看看。

        规则引擎：全称为业务规则管理系统，英文名为BRMS。规则引擎的主要思想是将应用程序中的业务决策部分分离出来，并使用预定义的语义模块编写业务决策（业务规则），由用户或 开发者在需要时进行配置、管理。需要注意的是规则引擎并不是一个具体的技术框架，而是指的一类系统，即业务规则管理系统。

        java开源的规则引擎有：Drools、Easy Rules、Mandarax、IBM ILOG。使用最为广泛并且开源的是Drools。

主要应用场景：

        对于一些存在比较复杂的业务规则并且业务规则会频繁变换的系统比较适合使用规则引擎，如下:

• 风控系统-------风险贷款、风险评估
• 反欺诈项目-----银行贷款、征信验证
• 决策平台-------财务计算
• 电商平台------满减、打折、加价购

        Drools 是用 Java 语言编写的开放源码规则引擎，使用 Rete 算法对所编写的规则求值。Drools 允许使用声明方式表达业务逻辑。可以使用非 XML 的本地语言编写规则，从而便于学习和理解。并且，还可以将 Java 代码直接嵌入到规则文件中，这令 Drools 的学习更加吸引人。

Drools 还具有其他优点：

• 非常活跃的社区支持
• 易用
• 快速的执行速度
• 在 Java 开发人员中流行
• 与 Java Rule Engine API（JSR 94）兼容

Drools 是业务逻辑集成平台，被分为4个项目：

• Drools Guvnor (BRMS/BPMS)：业务规则管理系统
• Drools Expert (rule engine)：规则引擎，drools的核心部分
• Drools Flow (process/workflow)：工作流引擎
• Drools Fusion (cep/temporal reasoning)：事件处理

官网：http://www.drools.org/#
官方文档：http://www.drools.org/learn/documentation.html

在项目中使用drools 时，即可以单独使用也可以整合spring使用，如果是单独使用仅需要导入以下maven 依赖即可。

Drools API 开发步骤如下：

第一步：创建Maven项目，添加Drools 规则引擎依赖。

第二步：根据drools要求创建resources/META-INF/kmodule.xml 配置文件

需要有一个配置文件告诉代码规则文件drl 在哪里，在drools中这个文件就是kmodule.xml。

第三步：创建业务实体对象

第四步：创建规则文件，在resources/rules/score-rules.drl

第五步：单元测试

效果截图:

drools规则引擎由以下几部分构成：

• Working Memory（工作内存）
• Rules（规则库）
• Inference Engine(推理引擎）

其中Inference Engine(t推理引擎）又包含如下：

• Pattern Match(匹配器）具体匹配那一个规则，由它来完成
• Agenda(议程）
• Execution Engine(执行引擎）

Working Memory：工作内存，drools规则引擎会从Working Memory中获取数据并和规则文件中定义的规则进行模式匹配，所以我们开发的应用程序只需要将我们的数据插入到Working Memory中即可，例如本案例中我们调用kieSession.insert(order)就是将order对象插入到了工作内存中。

Fact：事实，是指在drools 规则应用当中，将一个普通的JavaBean插入到Working Memory后的对象就是Fact对象，例如本案例中的Order对象就属于Fact对象。Fact对象是我们的应用和规则引擎进行数据交互的桥梁或通道。

Rules：规则库，我们在规则文件中定义的规则都会被加载到规则库中。

Pattern Matcher：匹配器，将Rule Base中的所有规则与Working Memory中的Fact对象进行模式匹配，匹配成功的规则将被激活并放入Agenda中。

Agenda：议程，用于存放通过匹配器进行模式匹配后被激活的规则。

drl是Drools Rule Language的缩写。

一套完整的规则文件内容构成如下：

一个规则通常包含三个部分：属性部分（attribute）、条件部分（LHS）和结果部分(RHS)

语法结构体：

rule：关键字，表示规则开始，参数为规则的唯一名称。

attributes：规则属性，是rule与when之间的参数，为可选项。

when：关键字，后面跟规则的条件部分。

LHS(Left Hand Side)：是规则的条件部分的通用名称。它由零个或多个条件元素组成。如果LHS为空，则它将被视为始终为true的条件元素。 （左手边）

then：关键字，后面跟规则的结果部分。

RHS(Right Hand Side)：是规则的后果或行动部分的通用名称。 （右手边）

end：关键字，表示一个规则结束。

在drl形式的规则文件中使用注释和Java类中使用注释一致，分为单行注释和多行注释。

单行注释用"//"进行标记，多行注释以"/"开始，以"/"结束。如下示例：

        Drools中的匹配器可以将Rule Base中的所有规则与Working Memory中的Fact对象进行模式匹配，那么我们就需要在规则体的LHS部分定义规则并进行模式匹配。LHS部分由一个或者多个条件组成，条件又称为pattern。

语法：

pattern的语法结构为：绑定变量名:Object(Field约束)

其中绑定变量名可以省略，通常绑定变量名的命名一般建议以$开始。如果定义了绑定变量名，就可以在规则体的RHS部分使用此绑定变量名来操作相应的Fact对象。Field约束部分是需要返回true或者false的0个或多个表达式。

入门案例中：

通过上面的例子我们可以知道，匹配的条件为：

1、工作内存中必须存在Order这种类型的Fact对象-----类型约束

2、Fact对象的price属性值必须小于100------属性约束

以上条件必须同时满足当前规则才有可能被激活。

绑定变量既可以用在对象上，也可以用在对象的属性上。入门案例如下：

LHS部分还可以定义多个pattern，多个pattern之间可以使用and或者or进行连接，也可以不写，默认连接为and。

Drools提供的比较操作符，如下表：

操作步骤 

第一步：创建实体类，用于测试比较操作符

第二步：在/resources/rules下创建规则文件comparison.drl

第三步：编写单元测试

效果截图：

        在调用规则代码时，满足条件的规则都会被执行。那么如果我们只想执行其中的某个规则如何实现呢？

        Drools给我们提供的方式是通过规则过滤器来实现执行指定规则。对于规则文件不用做任何修改，只需要修改Java代码即可，如下：

Drools的关键字分为：硬关键字(Hard keywords)和软关键字(Soft keywords)。

硬关键字是我们在规则文件中定义包名或者规则名时明确不能使用的，否则程序会报错。软关键字虽然可以使用，但是不建议使用。

硬关键字包括：true false null

软关键字包括：lock-on-active date-effective date-expires no-loop auto-focus activation-group agenda-group ruleflow-group entry-point duration package import dialect salience enabled attributes rule extend when then template query declare function global eval not in or and exists forall accumulate collect from action reverse result end over init

示例：

rule true //不可以

rule "true" 可以

前面我们已经知道了规则体的构成如下：

本章节就是针对规则体的attributes属性部分进行讲解。Drools中提供的属性如下表(部分属性)：

enabled属性 

enabled属性对应的取值为true和false，默认值为true。

用于指定当前规则是否启用，如果设置的值为false则当前规则无论是否匹配成功都不会触发

第一步：创建实体类，用于测试属性attributes

第二步：在/resources/rules下创建规则文件attributes-rules.drl

第三步：编写单元测试

dialect属性

dialect属性用于指定当前规则使用的语言类型，取值为java和mvel，默认值为java。

注：mvel是一种基于java语法的表达式语言。

虽然mvel吸收了大量的java语法，但作为一个表达式语言，还是有着很多重要的不同之处，以达到更高的效率，比如：mvel像正则表达式一样，有直接支持集合、数组和字符串匹配的操作符。

除了表达式语言外，mvel还提供了用来配置和构造字符串的模板语言。

mvel2.x表达式包含以下部分的内容：属性表达式，布尔表达式，方法调用，变量赋值，函数定义

salience属性 

        salience属性用于指定规则的执行优先级，取值类型为Integer。数值越大越优先执行。每个规则都有一个默认的执行顺序，如果不设置salience属性，规则体的执行顺序为由上到下。

attributes-rules.drl文件添加如下内容：

AttributesEnabledEntity 类新增boolean 类型(flag字段)

效果截图:

no-loop属性

        no-loop属性用于防止死循环，当规则通过update之类的函数修改了Fact对象时，可能使当前规则再次被激活从而导致死循环。取值类型为Boolean，默认值为false。测试步骤如下：

attributes-rules.drl文件添加如下内容：

第二步：编写单元测试

通过控制台可以看到，由于我们没有设置no-loop属性的值，所以发生了死循环。接下来设置no-loop的值为true再次测试则不会发生死循环。

 lock-on-active属性

lock-on-active这个属性，可以限制当前规则只会被执行一次，包括当前规则的重复执行不是本身触发的。取值类型为Boolean，默认值为false。测试步骤如下：

attributes-rules.drl文件添加如下内容：

编写单元测试:

        no-loop的作用是限制因为modify等更新操作导致规则重复执行，但是有一个限定条件，是当前规则中进行更新导致当前规则重复执行。而不是防止其他规则更新相同的fact对象，导致当前规则更新,lock-on-active可以看作是no-loop的加强版，不仅能限制自己的更新，还能限制别人的更新造成的死循环。

activation-group属性

activation-group属性是指激活分组，取值为String类型。具有相同分组名称的规则只能有一个规则被触发。

第一步：编写规则文件

编写单元测试:

        通过控制台可以发现，上面的两个规则因为属于同一个分组，所以只有一个触发了。同一个分组中的多个规则如果都能够匹配成功，具体哪一个最终能够被触发可以通过salience属性确定。

agenda-group属性

agenda-group属性为议程分组，属于另一种可控的规则执行方式。用户可以通过设置agenda-group来控制规则的执行，只有获取焦点的组中的规则才会被触发。

第一步：编写规则文件

编写单元测试:

通过控制台可以看到，只有获取焦点的分组中的规则才会触发。与activation-group不同的是，activation-group定义的分组中只能够有一个规则可以被触发，而agenda-group分组中的多个规则都可以被触发。

auto-focus属性

auto-focus属性为自动获取焦点，取值类型为Boolean，默认值为false。一般结合agenda-group属性使用，当一个议程分组未获取焦点时，可以设置auto-focus属性来控制。

第一步：编写规则文件

编写单元测试

通过控制台可以看到，设置auto-focus属性为true的规则都触发了。

注意：同一个组，只要有个设置auto-focus true 其他的设置不设置都无所谓啦。都会起作用的。

timer属性

timer属性可以通过定时器的方式指定规则执行的时间，使用方式有两种：

方式一：timer (int: ?)

此种方式遵循java.util.Timer对象的使用方式，第一个参数表示几秒后执行，第二个参数表示每隔几秒执行一次，第二个参数为可选。

方式二：timer(cron: )

此种方式使用标准的unix cron表达式的使用方式来定义规则执行的时间。

第一步：编写规则文件

编写单元测试:

注意：如果规则中有用到了timer属性，匹配规则需要调用kieSession.fireUntilHalt();这里涉及一个规则引擎的执行模式和线程问题，关于具体细节，我们后续讨论。

date-effective属性

date-effective属性用于指定规则的生效时间，即只有当前系统时间大于等于设置的时间或者日期规则才有可能触发。默认日期格式为：dd-MMM-yyyy。用户也可以自定义日期格式。

第一步：编写规则文件

编写单元测试

注意：需要在VM参数上加上日期格式:-Ddrools.dateformat=yyyy-MM-dd，在生产环境所在规则引擎的JVM设置中，也需要设置此参数，以保证开发和生产的一致性。

date-expires属性

date-expires属性用于指定规则的失效时间，即只有当前系统时间小于设置的时间或者日期规则才有可能触发。默认日期格式为：dd-MMM-yyyy。用户也可以自定义日期格式。

第一步：编写规则文件/resource/rules/dateexpires.drl

编写单元测试

注意：需要在VM参数上加上日期格式:-Ddrools.dateformat=yyyy-MM-dd，在生产环境所在规则引擎的JVM设置中，也需要设置此参数，以保证开发和生产的一致性。

我们已经知道了一套完整的规则文件内容构成如下：

global关键字用于在规则文件中定义全局变量，它可以让应用程序的对象在规则文件中能够被访问。可以用来为规则文件提供数据或服务。

语法结构为：global 对象类型 对象名称

在使用global定义的全局变量时有两点需要注意：

1、如果对象类型为包装类型时，在一个规则中改变了global的值，那么只针对当前规则有效，对其他规则中的global不会有影响。可以理解为它是当前规则代码中的global副本，规则内部修改不会影响全局的使用。

2、如果对象类型为集合类型或JavaBean时，在一个规则中改变了global的值，对java代码和所有规则都有效。

第一步：编写规则文件

编写单元测试

query查询提供了一种查询working memory中符合约束条件的Fact对象的简单方法。它仅包含规则文件中的LHS部分，不用指定“when”和“then”部分并且以end结束。

语法结构如下：

编写规则文件

编写单元测试

function关键字用于在规则文件中定义函数，就相当于java类中的方法一样。可以在规则体中调用定义的函数。使用函数的好处是可以将业务逻辑集中放置在一个地方，根据需要可以对函数进行修改。

函数定义的语法结构如下：

编写规则文件/resources/rules/function.drl

编写单元测试

前面我们已经知道了在规则体中的LHS部分是介于when和then之间的部分，主要用于模式匹配，只有匹配结果为true时，才会触发RHS部分的执行。本章节我们会针对LHS部分学习几个新的用法。

复合值限制in/not in

复合值限制是指超过一种匹配值的限制条件，类似于SQL语句中的in关键字。Drools规则体中的LHS部分可以使用in或者not in进行复合值的匹配。

语法结构如下：

编写规则文件

条件元素eval

eval用于规则体的LHS部分，并返回一个Boolean类型的值。

语法结构如下：

编写规则文件

条件元素not

not用于判断Working Memory中是否存在某个Fact对象，如果不存在则返回true，如果存在则返回false。

语法结构如下：

编写规则文件

条件元素exists

exists的作用与not相反，用于判断Working Memory中是否存在某个Fact对象，如果存在则返回true，不存在则返回false。

语法结构如下：

编写规则文件

疑问:在LHS部分进行条件编写时并没有使用exists也可以达到判断Working Memory中是否存在某个符合条件的Fact元素的目的，那么我们使用exists还有什么意义？

两者的区别：当向Working Memory中加入多个满足条件的Fact对象时，使用了exists的规则执行一次，不使用exists的规则会执行多次。

规则继承

规则之间可以使用extends关键字进行规则条件部分的继承，类似于java类之间的继承。

规则文件的部分的主要作用是通过插入，删除或修改工作内存中的Fact数据，来达到控制规则引擎执行的目的。Drools提供了一些方法可以用来操作工作内存中的数据，操作完成后规则引擎会重新进行相关规则的匹配，原来没有匹配成功的规则在我们修改数据完成后有可能就会匹配成功了。

insert方法

insert方法的作用是向工作内存中插入数据，并让相关的规则重新匹配。

编写规则文件

编写单元测试

通过控制台输出可以发现，3个规则都触发了，这是因为首先进行规则匹配时只有第一个规则可以匹配成功，但是在第一个规则中向工作内存中插入了一个数据导致重新进行规则匹配，此时第二个规则可以匹配成功。在第二个规则中同样向工作内存中插入了一个数据导致重新进行规则匹配，那么第三个规则就出发了。

update方法

update方法的作用是更新工作内存中的数据，并让相关的规则重新匹配。 （要避免死循环）

编写规则文件

编写单元测试

通过控制台的输出可以看到规则文件中定义的三个规则都触发了。

在更新数据时需要注意防止发生死循环。

modify方法

modify方法的作用跟update一样，是更新工作内存中的数据，并让相关的规则重新匹配。只不过语法略有区别 （要避免死循环）

编写规则文件

编写单元测试

通过控制台的输出可以看到规则文件中定义的三个规则都触发了。

在更新数据时需要注意防止发生死循环。

retract/delete方法

retract方法的作用是删除工作内存中的数据，并让相关的规则重新匹配。

编写规则文件

编写单元测试

通过控制台输出可以发现，只有第一个规则触发了，因为在第一个规则中将工作内存中的数据删除了导致第二个规则并没有匹配成功。

RHS部分是规则体的重要组成部分，当LHS部分的条件匹配成功后，对应的RHS部分就会触发执行。一般在RHS部分中需要进行业务处理。

在RHS部分Drools为我们提供了一个内置对象，名称就是drools。本小节我们来介绍几个drools对象提供的方法。

halt

halt方法的作用是立即终止后面所有规则的执行。

编写规则文件

getWorkingMemory

getWorkingMemory方法的作用是返回工作内存对象。

getRule

getRule方法的作用是返回规则对象。

我们在进行drl类型的规则文件编写时尽量遵循如下规范：

• 所有的规则文件(.drl)应统一放在一个规定的文件夹中，如：/rules文件夹
• 书写的每个规则应尽量加上注释。注释要清晰明了，言简意赅
• 同一类型的对象尽量放在一个规则文件中，如所有Student类型的对象尽量放在一个规则文件中
• 规则结果部分(RHS)尽量不要有条件语句，如if(...)，尽量不要有复杂的逻辑和深层次的嵌套语句
• 每个规则最好都加上salience属性，明确执行顺序
• Drools默认dialect为"Java"，尽量避免使用dialect "mvel"

WorkBench是KIE组件中的元素，也称为KIE-WB，是Drools-WB与JBPM-WB的结合体。它是一个可视化的规则编辑器。WorkBench其实就是一个war包。

WorkBench经过几次版本迭代，已经不提供tomcat启动的war包，综合考虑，本课程仍然采用 tomcat版本作为演示。

环境：

• apache-tomcat-9.0.29
• kie-drools-wb-7.6.0.Final-tomcat8 下载地址：Drools - Download

说明：

准备jar包：需要放到tomcat lib中，否则启动失败

具体安装步骤：

配置 Tomcat

1.修改tomcat-user.xml,添加用户

2.修改server.xml

3.复制jar到tomcat根目录的lib下面：

4.复制 kie-drools-wb-7.6.0.Final-tomcat8.war 到tomcat webapp下面并修改成kie-web.war

启动服务器

启动tomcat

访问http://localhost:8080/kie-web，可以看到WorkBench的登录页面。使用前面创建的kie-web/kie-web123登录

登录成功后进入系统首页：

创建空间、项目

首页中点击 project，创建空间

 

我们创建一个 ityml 的工作空间。点击 Save，保存。

 点击工作空间当中的 ityml，进入空间

点击Add Project添加项目

成功后，我们可以看见下图

 左上角的导航条，可以在空间和project之间切换

创建数据对象和drl文件

切换到pro1项目内，点击 Create New Assert

选中数据对象：

 输入Order，点击确定，成功后跳转如下页面

 

Order相当于我们代码中的实体类，在左侧 Project Explorer视图中，可以看见项目结构

接下来添加字段，点击添加字段按钮：

 ID 位置，输入java bean的字段，标签是备注信息，类型选择对应的字段类型，保存，点击创建，关闭弹窗，点击创建并继续，可以继续创建。

点击右上角的保存，至此，一个数据对象我们就创建完成，可以在源代码中查看代码内容。

接下来我们创建一个drl文件，创建过程跟创建bean类似，drl文件内容如下

保存之后，点击导航条回到项目主页

项目首页点击Settings

选择知识库跟会话

 

弹出窗口，输入Kiebase名称即可，我们以kb1为例

 同理，我们补充完软件包信息，添加只是会话，即kiesession

 操作完成后，不要忘记保存，此时，我们可在Project Explorer视图中，resource/META-INF/kmodule.xml中看见如下信息

导航回到项目首页，进行编译发布

发布成功后，我们可以在maven仓库中看到对应的jar

 

也可以访问：http://localhost:8080/kie-web/maven2/com/ityml/pro1/1.0.0/pro1-1.0.0.jar 验证是否发布成功.

代码使用 

本文参考资料：