1、Flowable介绍

Flowable是一个使用Java编写的轻量级业务流程引擎。Flowable流程引擎可用于部署BPMN 2.0流程定义（用于定义流程的行业XML标准）， 创建这些流程定义的流程实例，进行查询，访问运行中或历史的流程实例与相关数据，等等。

Flowable不仅仅包括BPMN，还有DMN决策表和CMMNase管理引擎，并且有自己的用户管理、微服务API等一系列功能，是一个服务平台。

所有使用Flowable方法的共同点是核心引擎。核心引擎是一组服务的集合，并提供管理与执行业务流程的API。

Flowable，2016年基于Activiti诞生。

Flowable官方网站：https://www.flowable.org/

Flowable开源代码仓库：https://github.com/flowable/flowable-engine

官方文档：https://www.flowable.org/docs/userguide/index.html

什么是BPMN

BPM (Business Process Management)，即业务流程管理，是一种规范化的构造端到端的业务流程，以持续的提高组织业务效率。常见商业管理教育如EMBA、MBA等均将BPM包含在内。

BPM软件就是根据企业中业务环境的变化，推进人与人之间、人与系统之间以及系统与系统之间的整合及调整的经营方法与解决方案的IT工具。

BPMN (Business Process Model AndNotation)-业务流程模型和符号是由BPMI (BusinessProcessManagement Initiative)开发的一套标准的业务流程建模符号，使用BPMN提供的符号可以创建业务流程。

2004年5月发布了BPMN1.0规范。BPMI于2005年9月并入OMG (The Object Management Group对象管理组织)组织。OMG于2011年1月发布BPMN2.0的最终版本。

BPMN是目前被各BPM厂商广泛接受的BPM标准。Activiti就是使用BPMN 2.0进行流程建模、流程执行管理,它包括很多的建模符号。

为什么选择Flowable

目前Flowable已经修复了activiti6很多的bug，可以实现零成本从activiti迁移到flowable。

flowable目前已经支持加签、动态增加实例中的节点、支持cmmn、dmn规范。这些都是activiti6目前版本没有的。

1、flowable已经支持所有的历史数据使用mongdb存储，activiti没有。

2、flowable支持事务子流程，activiti没有。

3、flowable支持多实例加签、减签，activiti没有。

4、flowable支持httpTask等新的类型节点，activiti没有。

5、flowable支持在流程中动态添加任务节点，activiti没有。

6、flowable支持历史任务数据通过消息中间件发送，activiti没有。

7、flowable支持java11,activiti没有。

8、flowable支持动态脚本，,activiti没有。

9、flowable支持条件表达式中自定义juel函数，activiti没有。

10、flowable支持cmmn规范，activiti没有。

11、flowable修复了dmn规范设计器，activit用的dmn设计器还是旧的框架，bug太多。

12、flowable屏蔽了pvm，activiti6也屏蔽了pvm（因为6版本官方提供了加签功能，发现pvm设计的过于臃肿，索性直接移除，这样加签实现起来更简洁、事实确实如此，如果需要获取节点、连线等信息可以使用bpmnmodel替代）。

13、flowable与activiti提供了新的事务监听器。activiti5版本只有事件监听器、任务监听器、执行监听器。

14、flowable对activiti的代码大量的进行了重构。

15、activiti以及flowable支持的数据库有h2、hsql、mysql、oracle、postgres、mssql、db2。其他数据库不支持的。使用国产数据库的可能有点失望了，需要修改源码了。

16、flowable支持jms、rabbitmq、mongodb方式处理历史数据，activiti没有。

2、Flowable基础操作

参考手册：https://tkjohn.github.io/flowable-userguide/#_introduction

创建一个简单的maveng项目，添加依赖：

<!--Flowable流程引擎-->
<dependency>
<groupId>org.flowable</groupId>
<artifactId>flowable-engine</artifactId>
<version>6.3.0</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.45</version>
</dependency>
<!--单元测试使用-->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.1</version>
<scope>test</scope>
</dependency>

2.1、创建流程引擎

@Test
public void TestProcessEngine() {
// 创建ProcessEngineConfiguration实例,该实例可以配置与调整流程引擎的设置
ProcessEngineConfiguration cfg = new StandaloneProcessEngineConfiguration()
.setJdbcUrl("jdbc:mysql://192.168.27.111:3306/flowable_learn?serverTimezone=UTC&&nullCatalogMeansCurrent=true&useSSL=false")
.setJdbcUsername("root")
.setJdbcPassword("123456")
.setJdbcDriver("com.mysql.jdbc.Driver")
// 如果数据库中的表结构不存在就新建
.setDatabaseSchemaUpdate(ProcessEngineConfiguration.DB_SCHEMA_UPDATE_TRUE);
// 获取ProcessEngine对象
ProcessEngine processEngine = cfg.buildProcessEngine();
System.out.println("processEngine==" + processEngine);
}

运行了之后，在数据库中可以看到生成了表结构，生成了34个表。

不过，应用运行没有问题，但也没有在控制台提供有用的信息，只有一条消息提示日志没有正确配置：

Flowable使用SLF4J作为内部日志框架。在这个例子中，我们使用log4j作为SLF4J的实现。因此在pom.xml文件中添加下列依赖：

<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.21</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.21</version>
</dependency>

Log4j需要一个配置文件。在src/main/resources文件夹下添加log4j.properties文件，并写入下列内容：

log4j.rootLogger=DEBUG, CA
log4j.appender.CA=org.apache.log4j.ConsoleAppender
log4j.appender.CA.layout=org.apache.log4j.PatternLayout
log4j.appender.CA.layout.ConversionPattern= %d{hh:mm:ss,SSS} [%t] %-5p %c %x - %m%n

重新运行应用。应该可以看到关于引擎启动与创建数据库表结构的提示日志：

这样就得到了一个启动可用的流程引擎。

2.2、部署流程定义

构建一个非常简单的请假流程。

Flowable引擎需要流程定义为BPMN 2.0格式，这是一个业界广泛接受的XML标准。 在Flowable术语中，我们将其称为一个流程定义(process definition)。一个流程定义可以启动多个流程实例(process instance)。流程定义可以看做是重复执行流程的蓝图。 在这个例子中，流程定义定义了请假的各个步骤，而一个流程实例对应某个雇员提出的一个请假申请。

BPMN 2.0存储为XML，并包含可视化的部分：使用标准方式定义了每个步骤类型（人工任务，自动服务调用，等等）如何呈现，以及如何互相连接。这样BPMN 2.0标准使技术人员与业务人员能用双方都能理解的方式交流业务流程。

我们要使用的流程定义为：

流程定义的说明：

• 我们假定启动流程需要提供一些信息，例如雇员名字、请假时长以及说明。当然，这些可以单独建模为流程中的第一步。 但是如果将它们作为流程的“输入信息”，就能保证只有在实际请求时才会建立一个流程实例。否则（将提交作为流程的第一步），用户可能在提交之前改变主意并取消，但流程实例已经创建了。 在某些场景中，就可能影响重要的指标（例如启动了多少申请，但还未完成），取决于业务目标。

• 左侧的圆圈叫做启动事件(start event)。这是一个流程实例的起点。

• 第一个矩形是一个用户任务(user task)。这是流程中人类用户操作的步骤。在这个例子中，经理需要批准或驳回申请。

• 取决于经理的决定，排他网关(exclusive gateway) (带叉的菱形)会将流程实例路由至批准或驳回路径。

• 如果批准，则需要将申请注册至某个外部系统，并跟着另一个用户任务，将经理的决定通知给申请人。当然也可以改为发送邮件。

• 如果驳回，则为雇员发送一封邮件通知他。

一般来说，这样的流程定义使用可视化建模工具建立，如Flowable Designer(Eclipse)或Flowable Web Modeler(Web应用)。

但在这里我们直接撰写XML，以熟悉BPMN 2.0及其概念。

与上面展示的流程图对应的BPMN 2.0 XML在下面显示。请注意这只包含了“流程部分”。如果使用图形化建模工具，实际的XML文件还将包含“可视化部分”，用于描述图形信息，如流程定义中各个元素的坐标（所有的图形化信息包含在XML的BPMNDiagram标签中，作为definitions标签的子元素）。

将下面的XML保存在src/main/resources文件夹下名为holiday-request.bpmn20.xml的文件中。

<?xml version="1.0" encoding="utf-8" ?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
xmlns:omgdc="http://www.omg.org/spec/DD/20100524/DC"
xmlns:omgdi="http://www.omg.org/spec/DD/20100524/DI"
xmlns:flowable="http://flowable.org/bpmn"
typeLanguage="http://www.w3.org/2001/XMLSchema"
expressionLanguage="http://www.w3.org/1999/XPath"
targetNamespace="http://www.flowable.org/processdef">
<process id="holiday-request" name="Holiday Request" isExecutable="true">
<!--开始事件：流程实例的起点-->
<startEvent id="startEvent"/>
<!--顺序流：执行时会从一个活动流向另一个活动-->
<sequenceFlow sourceRef="startEvent" targetRef="approveTask"/>
<!--用户任务：需要人工来进行操作-->
<userTask id="approveTask" name="Approve or reject request"/>
<sequenceFlow sourceRef="approveTask" targetRef="decision"/>
<!--排他网关-->
<exclusiveGateway id="decision"/>
<sequenceFlow sourceRef="decision" targetRef="externalSystemCall">
<!--顺序流条件：以表达式(expression)的形式定义了条件(condition) -->
<conditionExpression xsi:type="tFormalExpression">
<!--条件表达式：是${approved == true}的简写-->
<![CDATA[
${approved}
]]>
</conditionExpression>
</sequenceFlow>
<sequenceFlow sourceRef="decision" targetRef="sendRejectionMail">
<conditionExpression xsi:type="tFormalExpression">
<![CDATA[
${!approved}
]]>
</conditionExpression>
</sequenceFlow>
<!--服务任务，一个自动活动，它会调用一些服务-->
<serviceTask id="externalSystemCall" name="Enter holidays in external system" flowable:class="edu.hpu.process.CallExternalSystemDelegate"/>
<userTask id="holidayApprovedTask" name="Holiday Approve!"/>
<sequenceFlow sourceRef="holidayApprovedTask" targetRef="approveEnd"/>
<serviceTask id="sendRejectionMail" name="Send out rejection email" flowable:class="edu.hpu.process.SendRejectionMail"/>
<sequenceFlow sourceRef="sendRejectionMail" targetRef="rejectEnd"/>
<!--结束事件-->
<endEvent id="approveEnd"/>
<endEvent id="rejectEnd"/>
</process>
</definitions>

每一个步骤（在BPMN 2.0术语中称作活动(activity)）都有一个id属性，为其提供一个在XML文件中唯一的标识符。所有的活动都可以设置一个名字，以提高流程图的可读性。

活动之间通过**顺序流(sequence flow)**连接，在流程图中是一个有向箭头。在执行流程实例时，执行(execution)会从启动事件沿着顺序流流向下一个活动。

离开排他网关(带有X的菱形)的顺序流很特别：都以表达式(expression)的形式定义了条件(condition) （见第25至32行）。当流程实例的执行到达这个网关时，会计算条件，并使用第一个计算为true的顺序流。这就是排他的含义：只选择一个。当然如果需要不同的路由策略，可以使用其他类型的网关。

这里用作条件的表达式为*a p p r o v e d ? ，这是 ? {approved}*，这是*approved?，这是?{approved == true}*的简写。变量’approved’被称作流程变量(process variable)。流程变量是持久化的数据，与流程实例存储在一起，并可以在流程实例的生命周期中使用。在这个例子里，我们需要在特定的地方（当经理用户任务提交时，或者以Flowable的术语来说，完成(complete)时）设置这个流程变量，因为这不是流程实例启动时就能获取的数据。

现在我们已经有了流程BPMN 2.0 XML文件，下来需要将它**部署(deploy)**到引擎中。部署一个流程定义意味着：

• 流程引擎会将XML文件存储在数据库中，这样可以在需要的时候获取它。

• 流程定义转换为内部的、可执行的对象模型，这样使用它就可以启动流程实例。

将流程定义部署至Flowable引擎，需要使用RepositoryService，其可以从ProcessEngine对象获取。使用RepositoryService，可以通过XML文件的路径创建一个新的部署(Deployment)，并调用*deploy()*方法实际执行：

ProcessEngineConfiguration cfg = null;
@Before
public void before() {
cfg = new StandaloneProcessEngineConfiguration()
.setJdbcUrl("jdbc:mysql://192.168.27.111:3306/flowable_learn?serverTimezone=UTC&&nullCatalogMeansCurrent=true&useSSL=false")
.setJdbcUsername("root")
.setJdbcPassword("123456")
.setJdbcDriver("com.mysql.jdbc.Driver")
// 如果数据库中的表结构不存在就新建
.setDatabaseSchemaUpdate(ProcessEngineConfiguration.DB_SCHEMA_UPDATE_TRUE);
}
/**
* 部署流程定义
*/
@Test
public void TestDeployment() {
// 获取ProcessEngine对象
ProcessEngine processEngine = cfg.buildProcessEngine();
// 获取RepositoryService对象
RepositoryService repositoryService = processEngine.getRepositoryService();
Deployment deployment = repositoryService.createDeployment()
.addClasspathResource("holiday-request.bpmn20.xml")
.name("请求流程")
.deploy();
System.out.println("deployment.getId()" + deployment.getId());
System.out.println("deployment.getName()" + deployment.getName());
}

执行结果：

我们现在可以通过API查询验证流程定义已经部署在引擎中。

通过RepositoryService创建的ProcessDefinitionQuery对象实现。

/**
* 查询流程定义的信息
*/
@Test
public void TestDeploymentQuery() {
// 获取ProcessEngine对象
ProcessEngine processEngine = cfg.buildProcessEngine();
// 获取RepositoryService对象
RepositoryService repositoryService = processEngine.getRepositoryService();
ProcessDefinition processDefinition = repositoryService.createProcessDefinitionQuery()
.deploymentId("1")
.singleResult();
System.out.println("Found process definition : " + processDefinition.getName());
}
/**
* 删除流程定义
*/
@Test
public void TestDeploymentDelete() {
// 获取ProcessEngine对象
ProcessEngine processEngine = cfg.buildProcessEngine();
// 获取RepositoryService对象
RepositoryService repositoryService = processEngine.getRepositoryService();
// 第一个参数是id，如果部署的流程启动了，就不允许删除了
repositoryService.deleteDeployment("1");
// 第二个参数是级联删除，如果流程启动了，相关的任务一并会被删除
// repositoryService.deleteDeployment("1", true);
}

查询的结果：

2.3、启动流程实例

现在已经在流程引擎中部署了流程定义，因此可以使用这个流程定义作为“蓝图”启动流程实例。

要启动流程实例，需要提供一些初始化流程变量。一般来说，可以通过呈现给用户的表单，或者在流程由其他系统自动触发时通过REST API，来获取这些变量。

们使用RuntimeService启动一个流程实例。收集的数据作为一个java.util.Map实例传递，其中的键就是之后用于获取变量的标识符。这个流程实例使用key启动。这个key就是BPMN 2.0 XML文件中设置的id属性，在这个例子里是holidayRequest。

@Test
public void TestDeploymentRun() {
ProcessEngine processEngine = cfg.buildProcessEngine();
// 获取RuntimeService对象
RuntimeService runtimeService = processEngine.getRuntimeService();
// 流程变量
Map<String, Object> variables = new HashMap<String, Object>();
variables.put("employee", "张三");
variables.put("nrOfHolidays", 3);
variables.put("description", "有事需请假");
// 启动流程实例
ProcessInstance processInstance = runtimeService.startProcessInstanceByKey("holidayRequest", variables);
System.out.println("processInstance.getId()" + processInstance.getId());//7501
}

在流程实例启动后，会创建一个执行(execution)，并将其放在启动事件上。从这里开始，这个执行沿着顺序流移动到经理审批的用户任务，并执行用户任务行为。这个行为将在数据库中创建一个任务，该任务可以之后使用查询找到。用户任务是一个等待状态(wait state)，引擎会停止执行，返回API调用处。

流程变量已经存储到数据库中：

可以看到流程走到了经理的节点：

2.4、 查询任务

在更实际的应用中，会为雇员及经理提供用户界面，让他们可以登录并查看任务列表。

我们想将第一个任务指派给"经理(managers)"组，而第二个用户任务指派给请假申请的提交人。

为第一个任务添加candidateGroups属性：

<userTask id="approveTask" name="Approve or reject request" flowable:candidateGroups="managers"/>
// 当然这里也可以直接写死
flowable:assignee="zhangsan"

为第二个任务添加assignee属性。请注意我们没有像上面的’managers’一样使用静态值，而是使用一个流程变量动态指派。这个流程变量是在流程实例启动时传递的：

<userTask id="holidayApprovedTask" name="Holiday approved" flowable:assignee="${employee}"/>

要获得实际的任务列表，需要通过TaskService创建一个TaskQuery。我们配置这个查询只返回’managers’组的任务：

@Test
public void TestQueryTask() {
ProcessEngine processEngine = cfg.buildProcessEngine();
TaskService taskService = processEngine.getTaskService();
List<Task> tasks = taskService.createTaskQuery()
.taskCandidateGroup("managers") // 查询’managers’组的任务
// .taskAssignee("zhangsan") // 直接写死的分配人
.list();
for (int i=0; i<tasks.size(); i++) {
System.out.println(("查询’managers’组的任务-getId " + i+1) + ") " + tasks.get(i).getId());
System.out.println(("查询’managers’组的任务-getName " + i+1) + ") " + tasks.get(i).getName());
}
}

输出结果：

查询’managers’组的任务-getId 01) 12508

查询’managers’组的任务-getName 01) Approve or reject request

可以使用任务Id获取特定流程实例的变量，并在屏幕上显示实际的申请：

// 使用任务Id获取特定流程实例的变量
Map<String, Object> processVariables = taskService.getVariables("12508");
// 这里查询出来的就是前边存储的一些变量信息
System.out.println(processVariables.get("employee") + " wants " +
processVariables.get("nrOfHolidays") + " of holidays. Do you approve this?");

输出结果：

张三 wants 3 of holidays. Do you approve this?

2.5、 完成任务

实现JavaDelegate

在完成任务之前，我们还没有实现申请通过后执行的自动逻辑。在BPMN 2.0 XML中，这是一个服务任务(service task)：

<serviceTask id="externalSystemCall" name="Enter holidays in external system"
flowable:class="org.flowable.CallExternalSystemDelegate"/>
<serviceTask id="sendRejectionMail" name="Send out rejection email"
flowable:class="org.flowable.SendRejectionMail"/>

在现实中，这个逻辑可以做任何事情：向某个系统发起一个HTTP REST服务调用，或调用某个使用了好几十年的系统中的遗留代码。我们不会在这里实现实际的逻辑，而只是简单的日志记录流程。

public class CallExternalSystemDelegate implements JavaDelegate {
public void execute(DelegateExecution execution) {
System.out.println("审批通过了，进入另一个系统 " + execution.getVariable("employee"));
}
}
public class SendRejectionMail implements JavaDelegate {
public void execute(DelegateExecution delegateExecution) {
System.out.println("不好意思，审批没有通过，发送了一个拒绝邮件");
}
}

当执行到达服务任务时，会初始化并调用BPMN 2.0 XML中所引用的类。

完成任务

我们在完成任务时传递带有’approved’变量（这个名字很重要，因为之后会在顺序流的条件中使用！）的map来模拟：

@Test
public void TestCompleteTask() {
ProcessEngine processEngine = cfg.buildProcessEngine();
TaskService taskService = processEngine.getTaskService();
Map<String, Object> variables = new HashMap<String, Object>();
variables.put("approved", false);
taskService.complete("12508", variables);
}

现在执行这个例子的时候，就会显示出日志信息，说明已经执行了自定义逻辑：

之后，在数据库中，表act_ru_variable、act_ru_task、act_ru_execution中的这个实例的信息没有了。

2.6、查询历史数据

选择使用Flowable这样的流程引擎的原因之一，是它可以自动存储所有流程实例的审计数据或历史数据。这些数据可以用于创建报告，深入展现组织运行的情况，瓶颈在哪里，等等。

例如，如果希望显示流程实例已经执行的时间，就可以从ProcessEngine获取HistoryService，并创建*历史活动(historical activities)*的查询。在下面的代码片段中，可以看到我们添加了一些额外的过滤条件：

• 只选择一个特定流程实例的活动

• 只选择已完成的活动

结果按照结束时间排序，代表其执行顺序。

@Test
public void TestHistory() {
ProcessEngine processEngine = cfg.buildProcessEngine();
HistoryService historyService = processEngine.getHistoryService();
List<HistoricActivityInstance> activities = historyService.createHistoricActivityInstanceQuery()
.processInstanceId("12501") // 特定的实例
.finished() // 完成的
.orderByHistoricActivityInstanceEndTime().asc() // 根据实例完成时间升序排列
.list();
for (HistoricActivityInstance activity : activities) {
System.out.println(activity.getActivityId() + " took "
+ activity.getDurationInMillis() + " milliseconds");
}
}

输出结果：

startEvent took 1 milliseconds

approveTask took 2327333 milliseconds

decision took 32 milliseconds

sendRejectionMail took 5 milliseconds

rejectEnd took 3 milliseconds

作者：大仙andrew

来源：https://blog.csdn.net/bluede2015/article/details/129989914

点击关注，带你了解更多