规则引擎drools系列(一)

    1. 问题引出

现有一个在线申请信用卡的业务场景，用户需要录入个人信息，如下图所示：

 如果用户信息合法性检查通过后，还需要通过如下代码确定用户所办信用卡的额度：

通过上面的伪代码我们可以看到，我们的业务规则是通过Java代码的方式实现的。这种实现方式存在如下问题：

1、硬编码实现业务规则难以维护

2、硬编码实现业务规则难以应对变化

3、业务规则发生变化需要修改代码，重启服务后才能生效

那么面对上面的业务场景，还有什么好的实现方式吗？

答案是规则引擎。

2.1 什么是规则引擎

规则引擎，全称为业务规则管理系统，英文名为BRMS(即Business Rule Management System)。规则引擎的主要思想是将应用程序中的业务决策部分分离出来，并使用预定义的语义模块编写业务决策（业务规则），由用户或开发者在需要时进行配置、管理。

需要注意的是规则引擎并不是一个具体的技术框架，而是指的一类系统，即业务规则管理系统。目前市面上具体的规则引擎产品有：drools、VisualRules、iLog等。

规则引擎实现了将业务决策从应用程序代码中分离出来，接收数据输入，解释业务规则，并根据业务规则做出业务决策。规则引擎其实就是一个输入输出平台。

上面的申请信用卡业务场景使用规则引擎后效果如下：

1、业务规则与系统代码分离，实现业务规则的集中管理

2、在不重启服务的情况下可随时对业务规则进行扩展和维护

3、可以动态修改业务规则，从而快速响应需求变更

4、规则引擎是相对独立的，只关心业务规则，使得业务分析人员也可以参与编辑、维护系统的业务规则

5、减少了硬编码业务规则的成本和风险

6、使用规则引擎提供的规则编辑工具，使复杂的业务规则实现变得的简单

2.3 规则引擎应用场景

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

1、风险控制系统----风险贷款、风险评估

2、反欺诈项目----银行贷款、征信验证

3、决策平台系统----财务计算

4、促销平台系统----满减、打折、加价购

2.4 Drools介绍

drools是一款由JBoss组织提供的基于Java语言开发的开源规则引擎，可以将复杂且多变的业务规则从硬编码中解放出来，以规则脚本的形式存放在文件或特定的存储介质中(例如存放在数据库中)，使得业务规则的变更不需要修改项目代码、重启服务器就可以在线上环境立即生效。

drools官网地址：https://drools.org/

drools源码下载地址：GitHub - kiegroup/drools: Drools is a rule engine, DMN engine and complex event processing (CEP) engine for Java.

在项目中使用drools时，即可以单独使用也可以整合spring使用。如果单独使用只需要导入如下maven坐标即可：

如果我们使用IDEA开发drools应用，IDEA中已经集成了drools插件。如果使用eclipse开发drools应用还需要单独安装drools插件。

drools API开发步骤如下：

3. Drools入门案例

本小节通过一个Drools入门案例来让大家初步了解Drools的使用方式、对Drools有一个整体概念。

3.1 业务场景说明

业务场景：消费者在图书商城购买图书，下单后需要在支付页面显示订单优惠后的价格。具体优惠规则如下：

现在需要根据上面的规则计算优惠后的价格。

3.2 开发实现

第一步：创建maven工程drools_quickstart并导入drools相关maven坐标

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

注意：上面配置文件的名称和位置都是固定写法，不能更改

第三步：创建实体类Order

第四步：创建规则文件resources/rules/bookDiscount.drl

第五步：编写单元测试

通过上面的入门案例我们可以发现，使用drools规则引擎主要工作就是编写规则文件，在规则文件中定义跟业务相关的业务规则，例如本案例定义的就是图书优惠规则。规则定义好后就需要调用drools提供的API将数据提供给规则引擎进行规则模式匹配，规则引擎会执行匹配成功的规则并将计算的结果返回给我们。

可能大家会有疑问，就是我们虽然没有在代码中编写规则的判断逻辑，但是我们还是在规则文件中编写了业务规则，这跟在代码中编写规则有什么本质的区别呢？

我们前面其实已经提到，使用规则引擎时业务规则可以做到动态管理。业务人员可以像管理数据一样对业务规则进行管理，比如查询、添加、更新、统计、提交业务规则等。这样就可以做到在不重启服务的情况下调整业务规则。

3.3 小结

3.3.1 规则引擎构成

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

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

其中Inference Engine（推理引擎）又包括：

• Pattern Matcher（匹配器）
• Agenda(议程)
• Execution Engine（执行引擎）

如下图所示：

3.3.2 相关概念说明

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

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

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

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

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

Execution Engine：执行引擎，执行Agenda中被激活的规则。

3.3.3 规则引擎执行过程

通过上图可以看到，Drools是整个KIE项目中的一个组件，Drools中还包括一个Drools-WB的模块，它是一个可视化的规则编辑器。

4.1 规则文件构成

在使用Drools时非常重要的一个工作就是编写规则文件，通常规则文件的后缀为.drl。

drl是Drools Rule Language的缩写。在规则文件中编写具体的规则内容。

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

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

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

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

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

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

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

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

4.3 注释

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

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

4.4 Pattern模式匹配

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

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

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

例如我们的入门案例中：

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

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

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

3、Fact对象的originalPrice属性值必须大于等于100------属性约束

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

绑定变量既可以用在对象上，也可以用在对象的属性上。例如上面的例子可以改为：

前6个比较操作符和Java中的完全相同，下面我们重点学习后6个比较操作符。

4.5.1 语法

• contains | not contains语法结构

  Object(Field[Collection/Array] contains value)

  Object(Field[Collection/Array] not contains value)

• memberOf | not memberOf语法结构

  Object(field memberOf value[Collection/Array])

  Object(field not memberOf value[Collection/Array])

• matches | not matches语法结构

  Object(field matches "正则表达式")

  Object(field not matches "正则表达式")

4.5.2 操作步骤

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

5.1 enabled属性

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

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

5.2 dialect属性

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

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

mvel像正则表达式一样，有直接支持集合、数组和字符串匹配的操作符。

mvel还提供了用来配置和构造字符串的模板语言。

mvel表达式内容包括属性表达式，布尔表达式，方法调用，变量赋值，函数定义等。

5.3 salience属性

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

可以通过创建规则文件salience.drl来测试salience属性，内容如下：

通过控制台可以看到，由于以上三个规则没有设置salience属性，所以执行的顺序是按照规则文件中规则的顺序由上到下执行的。接下来我们修改一下文件内容：

通过控制台可以看到，规则文件执行的顺序是按照我们设置的salience值由大到小顺序执行的。

建议在编写规则时使用salience属性明确指定执行优先级。

5.4 no-loop属性

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

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

第二步：编写单元测试

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

5.5 activation-group属性

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

第一步：编写规则文件/resources/rules/activationgroup.drl

第二步：编写单元测试

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

5.6 agenda-group属性

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

第一步：创建规则文件/resources/rules/agendagroup.drl

第二步：编写单元测试

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

5.7 auto-focus属性

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

第一步：修改/resources/rules/agendagroup.drl文件内容如下

第二步：编写单元测试

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

5.8 timer属性

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

方式一：timer (int: <initial delay> <repeat interval>?)

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

方式二：timer(cron: <cron expression>)

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

第一步：创建规则文件/resources/rules/timer.drl

注意：单元测试的代码和以前的有所不同，因为我们规则文件中使用到了timer进行定时执行，需要程序能够持续一段时间才能够看到定时器触发的效果。

5.9 date-effective属性

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

第一步：编写规则文件/resources/rules/dateeffective.drl

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

本章节我们就来学习其中的几个关键字。

6.1 global全局变量

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

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

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

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

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

下面我们通过代码进行验证：

第一步：创建UserService类

第二步：编写规则文件/resources/rules/global.drl

6.2 query查询

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

具体操作步骤：

第一步：编写规则文件/resources/rules/query.drl

第二步：编写单元测试

6.3 function函数

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

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

具体操作步骤：

第一步：编写规则文件/resources/rules/function.drl

第二步：编写单元测试

6.4 LHS加强

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

6.4.1 复合值限制in/not in

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

Object(field in (比较值1,比较值2...))

举例：

6.4.2 条件元素eval

eval用于规则体的LHS部分，并返回一个Boolean类型的值。语法结构如下：

eval(表达式)

举例：

6.4.3 条件元素not

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

not Object(可选属性约束)

举例：

6.4.4 条件元素exists

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

exists Object(可选属性约束)

举例：

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

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

例如：

规则文件(只有规则体)：

Java代码：

上面第一个规则只会执行一次，因为Working Memory中存在两个满足条件的Fact对象，第二个规则会执行两次。

6.4.5 规则继承

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

例如：

6.5 RHS加强

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

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

6.5.1 halt

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

6.5.2 getWorkingMemory

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

6.5.3 getRule

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

6.6 规则文件编码规范

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

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

7.1 Spring简单整合Drools

在项目中使用Drools时往往会跟Spring整合来使用。具体整合步骤如下：

第一步：创建maven工程drools_spring并配置pom.xml

7.2 Spring整合Drools+web

本小节我们来进行Drools和Spring Web的整合。具体操作步骤如下：

第一步：创建maven的war工程drools_springweb并在pom.xml文件中导入相关maven坐标

8.3 使用方式

8.3.1 创建空间、项目

WorkBench中存在空间和项目的概念。我们在使用WorkBench时首先需要创建空间（Space），在空间中创建项目，在项目中创建数据对象、规则文件等。

• 创建空间

  第一步：登录WorkBench后进行系统首页，点击首页中的Design区域进入项目列表页面：

• 第三步：点击右上角Add Space按钮弹出创建添加空间窗口

• 创建项目

  前面已经提到，我们在WorkBench中需要先创建空间，在空间中才能创建项目。上面我们已经创建了一个空间itheima，现在需要住此空间中创建项目。

  第一步：点击itheima空间，进入此空间

• 第三步：在添加项目窗口中录入项目名称（例如项目名称为pro1），点击Add按钮完成操作

• 8.3.2 创建数据对象

  数据对象其实就是JavaBean，一般都是在drl规则文件中使用进行规则匹配。

  第一步：在itheima空间中点击pro1项目，进入此项目页面

• 第三步：在弹出的创建数据对象窗口中输入数据对象的名称，点击确定按钮完成操作

• 第四步：点击“添加字段”按钮弹出新建字段窗口

• 完成操作后可以看到刚才创建的字段：

• 注意添加完字段后需要点击右上角保存按钮完成保存操作：

• 点击左上角pro1项目链接，可以看到当前pro1项目中已经创建的各种类型的对象：

• 第二步：在添加DRL文件窗口录入DRL文件名称，点击确定按钮完成操作

• 可以看到DRL规则文件页面分为两个部分：左侧为项目浏览视图、右侧为编辑区域，需要注意的是左侧默认展示的不是项目浏览视图，需要点击上面设置按钮，选择“资料库视图”和“显示为文件夹”，如下图所示：

• 点击左上角pro1项目回到项目页面，可以看到此项目下已经存在两个对象，即person.drl规则文件和Person类：

• 第二步：在弹出的创建测试场景窗口中录入测试场景的名称，点击确定完成操作

• 第三步：因为我们编写的规则文件中需要从工作内存中获取Person对象进行规则匹配，所以在测试场景中需要准备Person对象给工作内存，点击“GIVEN”按钮弹出新建数据录入窗口，选择Person类，输入框中输入事实名称（名称任意），如下图

• 第五步：我们给工作内存提供的Person对象还需要设置age属性的值，点击“添加字段”按钮弹出窗口，选择age属性

• 第六步：点击age属性后面的编辑按钮，弹出字段值窗口

• 设置好age属性的值后点击保存按钮保存测试场景

  第八步：点击右上角“运行测试场景”按钮进行测试

• 8.3.5 设置KieBase和KieSession

  第一步：在pro1项目页面点击右上角Settings按钮进入设置页面

• 第三步：在弹出的知识库和会话页面点击“添加”按钮进行设置

• 点击右上角“Compile”按钮可以对项目进行编译，点击“Bulid&Deploy”按钮进行构建和部署。

  部署成功后可以在本地maven仓库中看到当前项目已经被打成jar包：

• 第一步：在IDEA中创建一个maven项目并在pom.xml文件中导入相关坐标

• 第二步：在项目中创建一个数据对象Person，需要和WorkBench中创建的Person包名、类名完全相同，属性也需要对应

• 第三步：编写单元测试，远程加载maven仓库中的jar包最终完成规则调用

• 执行单元测试可以发现控制台已经输出了相关内容。通过WorkBench修改规则输出内容并发布，再次执行单元测试可以发现控制台输出的内容也发生了变化。

  通过上面的案例可以发现，我们在IEDA中开发的项目中并没有编写规则文件，规则文件是我们通过WorkBench开发并安装部署到maven仓库中，我们自己开发的项目只需要远程加载maven仓库中的jar包就可以完成规则的调用。这种开发方式的好处是我们的应用可以和业务规则完全分离，同时通过WorkBench修改规则后我们的应用不需要任何修改就可以加载到最新的规则从而实现规则的动态变更。

• 9. Drools实战

• 9.1 个人所得税计算器

  本小节我们需要通过Drools规则引擎来根据规则计算个人所得税，最终页面效果如下：

• 9.1.1 名词解释

  税前月收入：即税前工资，指交纳个人所得税之前的总工资

  应纳税所得额：指按照税法规定确定纳税人在一定期间所获得的所有应税收入减除在该纳税期间依法允许减除的各种支出后的余额

  税率：是对征税对象的征收比例或征收额度

  速算扣除数：指为解决超额累进税率分级计算税额的复杂技术问题，而预先计算出的一个数据，可以简化计算过程

  扣税额：是指实际缴纳的税额

  税后工资：是指扣完税后实际到手的工资收入

  9.1.2 计算规则

  要实现个人所得税计算器，需要了解如下计算规则：

• 9.1.3 实现步骤

  本实战案例我们基于Spring Boot整合Drools的方式来实现。

  第一步：创建maven工程calculation并配置pom.xml文件

• 第二步：创建/resources/application.yml文件

• 第三步：编写配置类DroolsConfig

• 第四步：编写实体类Calculation

• 第五步：在resources/rules下创建规则文件calculation.drl文件

• 第六步：创建RuleService

• 第七步：创建RuleController

• 第八步：创建启动类DroolsApplication

• 第九步：导入静态资源文件到resources/static目录下

• 9.2 信用卡申请

  本小节我们需要通过Drools规则引擎来根据规则进行申请人的合法性检查，检查通过后再根据规则确定信用卡额度，最终页面效果如下：

• 9.2.1 计算规则

  合法性检查规则如下：

• 9.2.2 实现步骤

  第一步：创建maven工程creditCardApply并配置pom.xml文件

• 第二步：创建/resources/application.yml文件

• 第三步：编写配置类DroolsConfig

• 第四步：编写实体类CreditCardApplyInfo

• 第五步：在resources/rules下创建规则文件creditCardApply.drl文件

• 第六步：创建RuleService

• 第七步：创建RuleController

• 第八步：创建启动类DroolsApplication

• 第九步：导入静态资源文件到resources/static目录下

  9.3 保险产品准入规则

  9.3.1 决策表

  前面的课程中我们编写的规则文件都是drl形式的文件，Drools除了支持drl形式的文件外还支持xls格式的文件（即Excel文件）。这种xls格式的文件通常称为决策表（decision table）。

  决策表（decision table）是一个“精确而紧凑的”表示条件逻辑的方式，非常适合商业级别的规则。决策表与现有的drl文件可以无缝替换。Drools提供了相应的API可以将xls文件编译为drl格式的字符串。

  一个决策表的例子如下：

• 决策表语法：

• 在决策表中还经常使用到占位符，语法为$后面加数字，用于替换每条规则中设置的具体值。

  上面的决策表例子转换为drl格式的规则文件内容如下：

• 要进行决策表相关操作，需要导入如下maven坐标：

• 通过下图可以发现，由于maven的依赖传递特性在导入drools-decisiontables坐标后，drools-core和drools-compiler等坐标也被传递了过来

• Drools提供的将xls文件编译为drl格式字符串的API如下：

• Drools还提供了基于drl格式字符串创建KieSession的API：

• 基于决策表的入门案例：

  第一步：创建maven工程drools_decisiontable_demo并配置pom.xml文件

• 第二步：创建实体类PersonInfoEntity

• 第三步：创建xls规则文件（可以直接使用资料中提供的testRule.xls文件）

  第四步：创建单元测试

• 9.3.2 规则介绍

  各保险公司针对人身、财产推出了不同的保险产品，作为商业保险公司，筛选出符合公司利益最大化的客户是非常重要的，即各保险产品的准入人群是不同的，也就是说保险公司会针对不同的人群特征，制定不同的产品缴费和赔付规则。

  我们来看一下某保险产品准入规则的简化版，当不满足以下规则时，系统模块需要返回准入失败标识和失败原因

• 在本案例中规则文件是一个Excel文件，业务人员可以直接更改这个文件中指标的值，系统不需要做任何变更。

  9.3.3 实现步骤

  本案例还是基于Spring Boot整合Drools的架构来实现。

  第一步：创建maven工程insuranceInfoCheck并配置pom.xml文件

• 第二步：创建/resources/application.yml文件

• 第三步：创建实体类InsuranceInfo

• 第四步：创建决策表文件（也可以直接使用实战资料中提供的insuranceInfoCheck.xls文件）

• 第五步：封装工具类KieSessionUtils

• 第六步：创建RuleService类

• 第七步：创建RuleController类

• 第八步：创建启动类DroolsApplication

• 至此，规则引擎系列一结束，持续关注：

• 规则引擎系列一

• 规则引擎系列二

• 规则引擎系列三

• 规则引擎系列四

• 规则引擎系列........