drools规则引擎可视化_⼀⽂看懂开源⼯作流引擎
Flowable「转」
⼀、⼯作流引擎使⽤场景
⼯作流在企业管理系统中是⾼频使⽤的功能，⼀个最常见的例⼦是请假加班申请与审批的过程。事实上，⼯作流引擎能⽀持的业务场景远远不⽌单据审批，⼏乎所有涉及到业务流转、多⼈按流程完成⼯作的场景背后都可以通过⼯作流引擎作为⽀撑。基于⼯作流引擎，可以搭建客户关系管理系统(CRM)、运输管理系统(TMS)、仓储管理系统(WMS)、财务费⽤系统等多种复杂业务系统。对于达到⼀定规模的企业，良好的 BPM(业务流程管理，Business Process Management)体系可以⽀持创建公司内横跨不同部门的复杂业务流程，既提⾼⼯作效率、⼜可推动企业规范化发展。
图1 业务流转⽰意图(图⽚来源：www.flowable)
⼆、Flowable 是什么
Flowable 是⼀个使⽤ Java 编写的轻量级业务流程引擎，使⽤ Apache V2 license 协议开源。2016 年 10 ⽉，Activiti ⼯作流引擎的主要开发者离开 Alfresco 公司并在 Activiti 分⽀基础上开启了 Flowable 开源项⽬。基于 Activiti v6 beta4 发布的第⼀个 Flowable release 版本为 6.0。以 JAR 形式发布使得 Flowable 可以轻易加⼊任何Java环境：Java SE、Tomcat、Jetty 或 Spring 之类的 servlet 容器；JBoss 或 WebSphere 之类的 Java EE 服务器等等。 另外，也可以使⽤ Flowable REST API 进⾏ HTTP 调⽤。
Flowable 项⽬中包括 BPMN(Business Process Model and Notation)引擎、CMMN(Case Management Model and Notation)引擎、DMN(Decision Model and Notation)引擎、表单引擎(Form Engine)等模块。也有许多Flowable 应⽤(Flowable Modeler、Flowable Admin、Flowable IDM 与 Flowable Task)，并提供了直接可⽤的 UI ⽰例。模块之间协作关系可以参考下图：
图2 Flowable 架构⽰意图(图⽚来源：www.shareniu)
构建 OA、CRM、TMS、财务管理等系统时，若基于 Flowable ⽣态做定制化开发可以⼤⼤减少开发成本，避免写复杂⽽难以维护的条件代码。Flowable 的关键为其核⼼引擎，核⼼引擎是⼀组服务的集合，并提供管理与执⾏业务流程的API。Flowable ⽣态系统中的业务流程引擎(BPMN)可以与决策引擎(DMN)、案例模型引擎(CMMN)、表单引擎联动，开发者可以根据业务需求选⽤其中⼀个或多个模块，
通过模块之间相互协作构建业务系统、以实现强⼤的功能。Flowable 团队在开源项⽬之外也承接商业项⽬，提供 Flowable Work、Flowable Engage 等商业产品与服务，www.flowable ⽹站上提供了该团队为银⾏和保险业实施过的成功案例，展⽰了 Flowable 对复杂场景的业务⽀撑能⼒。下⽂简要介绍 Flowable 中的⼏个主要引擎模块。
三、Flowable BPMN 业务流程引擎
流程引擎是⽀持配置业务流转过程的关键模块。Flowable ⽀持 BPMN 2.0 ⾏业标准，同时提供了⼀些 Flowable ⾃定义的 BPMN 扩展(extensions)可选⽤，允许通过导⼊ XML ⽂件或通过前端可视化界⾯建⽴流程。Flowable 本⾝提供了⼀个流程绘制的 UI 界⾯(Flowable Modeler 应⽤)，如下图所⽰：
图3 Flowable Modeler 应⽤中的流程绘制界⾯
Flowable 业务流程引擎⽀持如下类型的流程元素：
1. 事件：事件(event)通常⽤于为流程⽣命周期中发⽣的事情建模。在 BPMN
2.0中，有两种主要的事件分类：捕获(catching)与抛出(throwing)事件。捕获事件为当流程执⾏到达这个事件时，会等待直到触发器动作。抛出事件当流程执⾏到达这个事件时，会触发⼀个触发器。具体事件包括定时器事件、启动事件、结束事件、消息事件、信号事件、边界事件等丰富类型。
2. 顺序流：顺序流(sequence flow)是流程中两个元素间的连接器。在流程执⾏过程中，⼀个元素被访问后，会沿着其所有出⼝顺序流继续执⾏。这意味着BPMN 2.0的默认是并⾏执⾏的：两个出⼝顺序流就会创建两个独⽴的、并⾏的执⾏路径。
顺序流上定义条件(conditional sequence flow)时为条件顺序流。当离开 BPMN 2.0活动时，默认⾏为是计算其每个出⼝顺序流上的条件。当条件计算为true时，选择该出⼝顺序流。如果该⽅法选择了多条顺序流，则会⽣成多个执⾏，流程会以并⾏⽅式继续。但这种情况并不适⽤于⽹关(gateway)，不同类型的⽹关，会⽤不同的⽅式处理带有条件的顺序流。所有的BPMN 2.0任务与⽹关都可以使⽤默认顺序流(default sequence flow)。只有当没有其他顺序流可以选择时，才会选择默认顺序流作为活动的出⼝顺序流。流程会忽略默认顺序流上的条件。
3. ⽹关：⽹关(gateway)⽤于控制执⾏的流向，可类⽐路⼝的分叉来理解。如按BPMN 2.0 的⽤词也即是执⾏的「标志(token)」。⽹关可以消费(consuming)与⽣成(generating)标志。⽹关可细分为下列类型：
排他⽹关(exclusive gateway)：也叫异或⽹关 (XOR gateway)，或者基于数据的排他⽹关 (exclusive data-based gateway)，⽤于对流程中的决策建模。当执⾏到达这个⽹关时，会按照所有出⼝顺序流定义的顺序对它们进⾏计算。选择第⼀个条件计算为 true 的顺序流(当没有设置条件时，认为顺序流为true)继续流程。使⽤排他⽹关时，只会选择⼀条顺序流。当多条顺序流的条件都计算为true 时，会且仅会选择在XML中最先定义的顺序流继续流程。
并⾏⽹关：并⾏⽹关不计算条件，如果连接到并⾏⽹关的顺序流上定义了条件，会直接忽略该条件。并⾏⽹关(parallel gateway)可以将执⾏分⽀(fork)为多条路径，也可以合并(join)多条⼊⼝路径的执⾏，并⾏⽹关的功能取决于其⼊⼝与出⼝顺序流。如果并⾏⽹关同时具有多条⼊⼝与出⼝顺序流，可以同时具有分⽀与合并的⾏为。在这种情况下，⽹关⾸先合并所有⼊⼝顺序流，然后分裂为多条并⾏执⾏路径。
包容⽹关：可看做排他⽹关与并⾏⽹关的组合。与排他⽹关⼀样，可以在包容⽹关的出⼝顺序流上定义条件，包容⽹关会计算条件。然⽽主要的区别是，包容⽹关与并⾏⽹关⼀样，可以同时选择多于⼀条出⼝顺序流。包容⽹关的汇聚⾏为⽐并⾏⽹关更复杂。
基于事件的⽹关：基于事件的⽹关(event-based gateway)提供了根据事件做选择的⽅式。⽹关的每⼀条出⼝顺序流都需要连接⾄⼀个捕获中间事件。⼀个基于事件的⽹关，必须有两条或更多的出⼝顺序流。
4. 任务：Flowable ⽀持的任务类型超过⼗五种。
⽤户任务：⽤于对需要⼈⼯执⾏的任务进⾏建模。当流程执⾏到达⽤户任务时，会为指派⾄该任务的⽤户或组的任务列表创建⼀个新任务。⽤户任务允许标识到期⽇期以及直接指派给⽤户。
邮件任务：Flowable 引擎可以向⼀个或多个收信⼈发送邮件，⽀持 cc、bcc、HTML ⽂本等等，使⽤⽀持 SMTP 的外部邮件服务器发送邮件。
业务规则任务：业务规则任务(business rule task)⽤于同步地执⾏⼀条或多条规则。在 V6.3.0 到 V6.4.1 版本中，Flowable 使⽤名为 Drools Expert 的 Drools 规则引擎执⾏业务规则。截⾄ V6.4.1 版本，业务规则中包含的 .drl ⽂件，必须与定义了业务规则服务并执⾏规则的流程定义⼀起部署。这意味着流程中使⽤的所有 .drl ⽂件都需要打包在流程 BAR ⽂件中，与任务表单等类似。由于Flowable ⾃⼰的规则引擎 DMN 功能逐渐完善，对业务规则任务的⽀持可能会在后续版本中变动，具体要看 Flowable 官⽅更新⽂档。
其他的任务类型还有脚本任务、Web 服务任务、Shell 任务、Java 服务任务、执⾏、任务等。
5. ⼦流程与调⽤活动：⼦流程(sub-process)是包含其他的活动、⽹关、事件等的活动。其本⾝构成⼀个流程，并作为更⼤流程的⼀部分。⼦流程完全在⽗流程中定义(所以也称作嵌⼊式⼦流程)。在复杂流程流转的场景下中⼦流程较为多见，使⽤这⼀特性可以⽐较灵活地维护包含⼦流程的审批路径。
调⽤活动(call activity)有别于⼀般的⼦流程，调⽤活动引⽤⼀个流程定义外部的流程，⽽⼦流程嵌⼊在原有流程定义内。调⽤活动的主要使⽤场景是，在多个不同流程定义中调⽤⼀个可复⽤的流程定义。
java开发可视化界面
Flowable⽀持两种⽅式使⽤表单：使⽤(由Flowable提供的表单设计器创建的)表单定义的内置表单渲染，以及外部表单渲染。内置表单设计器的详细内容可以查看相应的表单引擎(Form Engine)⽤户⼿册。
Flowable 以事务的⽅式执⾏流程，可按照需求进⾏配置。如果 Flowable 被触发(启动流程，完成任务，为执⾏发送信号)，Flowable 将沿流程执⾏，直到到达每个执⾏路径的等待状态。更具体地说，它以深度优先⽅式搜索流程图，并在每个执⾏分⽀都到达等待状态时返回。等待状态是「之后」再执⾏的任务，也就是说着 Flowable 将当前执⾏持久化，并等待再次触发。触发可以来⾃外部来源如⽤户任务或消息接受任务，也可以来⾃ Flowable ⾃⾝如定时器事件。
Flowable⾃带⾝份管理模块，但是从 Flowable V6 起⾝份管理(IDM IDentity Management)组件从 Flowable 引擎模块中抽出，并将其逻辑移⾄⼏个不同的模块。默认情况下，IDM引擎在Flowable引擎启动时初始化并启动。Flowable 提供的⼏个 web 应⽤中就包括 Flowable IDM(⾝份管理应⽤)，为所有Flowable UI应⽤提供单点登录认证功能，并且为拥有 IDM 管理员权限的⽤户提供了管理⽤户、组与权限的功能。其他 Web 应⽤还有：
Flowable Modeler: 让具有建模权限的⽤户可以创建流程模型、表单、选择表与应⽤定义。
Flowable Task: 运⾏时任务应⽤。提供了启动流程实例、编辑任务表单、完成任务，以及查询流程实
例与任务的功能。
Flowable Admin: 管理应⽤。让具有管理员权限的⽤户可以查询BPMN、DMN、Form及Content引擎，并提供了许多选项⽤于修改流程实例、任务、作业等。管理应⽤通过REST API连接⾄引擎，并与Flowable Task应⽤及Flowable REST应⽤⼀同部署。
所有其他的应⽤都需要 Flowable IDM 提供认证。每个应⽤的WAR⽂件可以部署在相同的servlet容器(如Apache Tomcat)中，也可以部署在不同的容器中。由于每个应⽤使⽤相同的cookie进⾏认证，因此应⽤需要运⾏在相同的域名下。
四、Flowable DMN 决策引擎
作为以 BPMN 为核⼼的⼯作流引擎，Flowable 原本与规则引擎的关联并不强，但实际业务流程中，有时需要由多个决策来决定流程⾛向，⽽每个决策都要根据⾃⾝的规则来决定，每个决策之间也可能存在关联。此时就需要规则引擎来提供决策⽀撑。在规则引擎开源产品
中，Drools 是最知名的⼀款，它实现了PMML(Predictive Model Markup Language)规范，同时⽀持 DMN (Decision Model and Notation)标准。Flowable ⽬前实现了 DMN V1.1 规范的框架，由于 DMN 规范中要求对 PMML 提供兼容性，这意味着 Flowable 具有相对强⼤的业务规则的处理能⼒。
在 Flowable Modeler 应⽤中 DMN 引擎体现为「决策表」菜单，可以通过界⾯进⾏ Input 与 Output 的配置，可导⼊ .dmn 扩展名格式的 DMN 定义。在 OMG (Object Management Group)制定的 DMN 规范中也有相应的XML格式约束。如果 DMN 引擎已经插⼊流程引擎，就可以与其他流程相关资源⼀起，将 DMN 定义打包进业务存档(BAR)⽂件中。流程引擎部署服务会将 DMN 资源部署⾄ DMN 引擎。
DMN 定义由决策(decision)和其他东西组成，决策由表达式描述。DMN 标准描述了⼏种表达式的类型，⽬前在 Flowable DMN 中仅⽀持决策表(decision table)类型的表达式。决策表分为输⼊表达式与
输出表达式两个主要区域。在输⼊表达式中，可以定义变量，⽤于规则输⼊项(input entries)的表达式。可以通过选择Add Input(添加输⼊)，定义多个输⼊表达式。在输出表达式中，可以定义选择表执⾏结果要创建的变量(变量的值将⽤于输出项表达式，在下⾯解释)。可以通过选择Add Output(添加输出)，定义多个输出表达式。
在决策表编辑界⾯，可以选择命中策略，共有两⼤类(单命中、多命中)七种命中策略可选：
(1)单命中、第⼀命中(single hit & FIRST)：多个规则允许交叉，执⾏从上到下的第⼀条命中项。
(2)单命中、唯⼀命中(single hit & UNIQUE)：多个规则不允许交叉，执⾏从上到下的第⼀条唯⼀命中项。
(3)单命中、任⼀命中(single hit & ANY)：规则允许交叉，但是所有输出的优先级相同，随机执⾏⼀条命中项。
(4)单命中、优先级(single hit & PRIORITY)：多个命中规则的优先级不同，执⾏优先级最⾼的那条。
(5)多命中、输出优先级排序(multiple hit & OUTPUT ORDER)：按照输出优先级递减的顺序返回所有命中。
(6)多命中、规则顺序排序(multiple hit & RULE ORDER)：按照规则顺序返回所有命中。
(7)多命中、聚合(multiple hit & COLLECT)：按照随机顺序返回所有命中。
五、Flowable CMMN 案例模型引擎
CMMN 是 Case Management Model 的缩写，在 Flowable Modeler 应⽤中体现为「案例模型」菜单，使⽤时可以类似于流程引擎可视化配置流程，也可通过XML格式⽂件。CMMN(Case Management Model and Notation)⾏业标准 V1.1 版本于2016年发布，⽬前Flowable 的 V6.4.1 已⽀持此标准。
与 BPMN 引擎相⽐，CMMN 引擎适⽤于如下⼏种场景：
(1)重复与并⾏的⼯作分发。BPMN 引擎在处理顺序执⾏、职责分⼯明确的⼯作流程时有优势，但⾯对动态、⾃由、并⾏的情况时，BPMN 显得灵活性不⾜，此时CMMN 则更适合应对。
(2)处理带有⽣命周期特征的场景，如客户、产品、项⽬、雇员。以项⽬为例，项⽬的⽴项、中⽌、收尾、交付等阶段(phases)，可以在CMMN 中通过阶段(Stages)概念在更⾼层次进⾏描述。
图7 CMMN 引擎使⽤场景⽰例
CMMN 中⼀个案例模型呈现为⼀个公⽂夹的样式。每个案例模型都包含⼀个⽤于安置计划元素的「计划模型」，每个计划元素包含⼀个明确其类型和可能配置选项的计划元素定义，常见计划元素如⽤户任务(human task)、⾥程碑(milestone)、流程任务(process task)、案例任务(case task)和阶段(stage)。例如下图中的计划模型包含三个⽤户任务计划项和⼀个⾥程碑。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。