flowable简介

1 简介
1.1 Flowable是什么
Flowable是一个使用Java编写的轻量级业务流程引擎。Flowable流程引擎可用于部署BPMN 2.0流程定义（用于定义流程的行业XML标准）， 创建这些流程定义的流程实例，进行查询，访问运行中或历史的流程实例与相关数据，等等。这个章节将用一个可以在你自己的开发环境中使用的例子，逐步介绍各种概念与API。

Flowable可以十分灵活地加入你的应用/服务/构架。可以将JAR形式发布的Flowable库加入应用或服务，来嵌入引擎。 以JAR形式发布使Flowable可以轻易加入任何Java环境：Java SE；Tomcat、Jetty或Spring之类的servlet容器；JBoss或WebSphere之类的Java EE服务器，等等。 另外，也可以使用Flowable REST API进行HTTP调用。也有许多Flowable应用（Flowable Modeler, Flowable Admin, Flowable IDM 与 Flowable Task），提供了直接可用的UI示例，可以使用流程与任务。

1.2 Flowable与Activiti
Flowable是Activiti(Alfresco持有的注册商标)的fork。在下面的章节中，你会注意到包名，配置文件等等，都使用flowable。

1.3 基本概念
流程定义：使用国际通用的bpmn2.0标准绘制的流程文件（xml），流程定义可以看做是重复执行流程的蓝图。
流程实例：从流程定义中发起的具体的事情，就是流程实例。一个流程定义可以发起多个流程实例。
BPMN2.0：BPMN是一个广泛接受与支持的，展现流程的注记方法。规定了绘制的流程定义的xml文件格式。
活动：流程定义中的每一个步骤，叫做活动。每一个活动都有一个id属性，为其提供一个在XML文件中唯一的标识符。
顺序流：活动之间的带有方向的连接线，叫顺序流。
流程变量：流程变量是持久化的数据，与流程实例存储在一起，并可以在流程实例的生命周期中使用。

2、BPMN2.0结构

2.1、自定义扩展
BPMN 2.0标准对流程的所有的参与者都很有用。最终用户不会因为依赖专有解决方案，而被供应商“绑架”。Flowable之类的开源框架，也可以提供与大型供应商的解决方案相同（经常是更好;-）的实现。有了BPMN 2.0标准，从大型供应商解决方案向Flowable的迁移，可以十分简单平滑。

缺点则是标准通常是不同公司（不同观点）大量讨论与妥协的结果。作为阅读BPMN 2.0 XML流程定义的开发者，有时会觉得某些结构或方法十分笨重。Flowable将开发者的感受放在最高优先，因此引入了一些Flowable BPMN扩展（extensions）。这些“扩展”并不在BPMN 2.0规格中，有些是新结构，有些是对特定结构的简化。

尽管BPMN 2.0规格明确指出可以支持自定义扩展，我们仍做了如下保证：

自定义扩展保证是在标准方式的基础上进行简化。因此当你决定使用自定义扩展时，不用担心无路可退（仍然可以用标准方式）。

使用自定义扩展时，总是通过flowable:命名空间前缀，明确标识出XML元素、属性等。请注意Flowable引擎也支持activiti:命名空间前缀。

因此是否使用自定义扩展，完全取决于你自己。有些其他因素会影响选择（图形化编辑器的使用，公司策略，等等）。我们提供扩展，只是因为相信标准中的某些地方可以用更简单或效率更高的方式处理。请不要吝啬给我们反馈你对扩展的评价（正面的或负面的），也可以给我们提供关于自定义扩展的新想法。说不定某一天，你的想法会成为标准的一部分！

2.2、事件
2.2.1、简单说明
事件（event）通常用于为流程生命周期中发生的事情建模。事件总是图形化为圆圈。在BPMN 2.0中，有两种主要的事件分类：捕获（catching）与抛出（throwing）事件。
（一）捕获: 当流程执行到达这个事件时，会等待直到触发器动作。触发器的类型由其中的图标，或者说XML中的类型声明而定义。捕获事件与抛出事件显示上的区别，是其内部的图标没有填充（即是白色的）。
（二）抛出: 当流程执行到达这个事件时，会触发一个触发器。触发器的类型，由其中的图标，或者说XML中的类型声明而定义。抛出事件与捕获事件显示上的区别，是其内部的图标填充为黑色。

2.2.1、事件种类
定时器事件、错误事件、信号事件、消息事件、启动事件、空启动事件、定时器启动事件、消息启动事件、信号启动事件、结束事件等。

简单介绍几个：
启动事件（start event）是流程的起点。启动事件的类型（流程在消息到达时启动，在指定的时间间隔后启动，等等），定义了流程如何启动，并显示为启动事件中的小图标。在XML中，类型由子元素声明来定义。
定时器事件（timer event definition），是由定时器所触发的事件。可以用于开始事件，中间事件，或边界事件。定时器事件的行为取决于所使用的业务日历（business calendar）。定时器事件有默认的业务日历，但也可以为每个定时器事件定义，单独定义业务日历。

边界事件（boundary event）是捕获型事件，依附在活动（activity）上。边界事件永远不会抛出。这意味着当活动运行时，事件将监听特定类型的触发器。当捕获到事件时，会终止活动，并沿该事件的出口顺序流继续。下图为定时器边界事件

捕获中间事件：所有的捕获中间事件（intermediate catching events）都使用相同方式定义：

捕获中间事件由下列元素定义:

（流程范围内）唯一的标识符

定义了捕获中间事件类型的，形如XXXEventDefinition的XML子元素（例如TimerEventDefinition等）。查阅特定中间捕获事件类型，以了解更多细节。

抛出中间事件：所有的抛出中间事件（intermediate throwing evnet）都使用相同方式定义：

抛出中间事件由下列元素定义:
（流程范围内）唯一的标识符
定义了抛出中间事件类型的，形如XXXEventDefinition的XML子元素（例如signalEventDefinition等）。查阅特定中间抛出事件类型，以了解更多细节。

2.3、顺序流
顺序流（sequence flow）是流程中两个元素间的连接器。在流程执行过程中，一个元素被访问后，会沿着其所有出口顺序流继续执行。这意味着BPMN 2.0的默认是并行执行的：两个出口顺序流就会创建两个独立的、并行的执行路径。

xml表示
顺序流需要有流程唯一的id，并引用存在的源与目标元素。

2.3.1、条件顺序流
在顺序流上可以定义条件（conditional sequence flow）。当离开BPMN 2.0活动时，默认行为是计算其每个出口顺序流上的条件。当条件计算为true时，选择该出口顺序流。如果该方法选择了多条顺序流，则会生成多个执行，流程会以并行方式继续。

请注意：上面的介绍针对BPMN 2.0活动（与事件），但不适用于网关（gateway）。不同类型的网关，会用不同的方式处理带有条件的顺序流。

2.3.1.1、xml表示
条件顺序流的XML表示格式为含有conditionExpression（条件表达式）子元素的普通顺序流。请注意目前只支持tFormalExpressions。可以省略xsi:type=""定义，默认为唯一支持的表达式类型。

2.3.2、默认顺序流
所有的BPMN 2.0任务与网关都可以使用默认顺序流（default sequence flow）。只有当没有其他顺序流可以选择时，才会选择默认顺序流作为活动的出口顺序流。流程会忽略默认顺序流上的条件
默认顺序流用起点带有“斜线”标记的一般顺序流表示。

2.3.2.1、xml表示
活动的默认顺序流由该活动的default属性定义。下面的XML片段展示了一个排他网关（exclusive gateway），带有默认顺序流flow 2。只有当conditionA与conditionB都计算为false时，才会选择默认顺序流作为网关的出口顺序流。

2.4、网关

网关（gateway）用于控制执行的流向（或者按BPMN 2.0的用词：执行的“标志（token）”）。网关可以消费（consuming）与生成（generating）标志。
网关用其中带有图标的菱形表示。该图标显示了网关的类型。

2.4.1、排他网关
2.4.1.1 描述：
排他网关（exclusive gateway）（也叫异或网关 XOR gateway，或者更专业的，基于数据的排他网关 exclusive data-based gateway），用于对流程中的决策建模。当执行到达这个网关时，会按照所有出口顺序流定义的顺序对它们进行计算。选择第一个条件计算为true的顺序流（当没有设置条件时，认为顺序流为true）继续流程。
请注意这里出口顺序流的含义与BPMN 2.0中的一般情况不一样。一般情况下，会选择所有条件计算为true的顺序流，并行执行。而使用排他网关时，只会选择一条顺序流。当多条顺序流的条件都计算为true时，会且仅会选择在XML中最先定义的顺序流继续流程。如果没有可选的顺序流，会抛出异常。

2.4.1.2、图示
排他网关用内部带有’X’图标的标准网关（菱形）表示，'X’图标代表异或的含义。请注意内部没有图标的网关默认为排他网关。BPMN 2.0规范不允许在同一个流程中混合使用有及没有X的菱形标志。

2.4.1.3、xml表示
排他网关的XML表示格式很简洁：一行定义网关的XML。条件表达式定义在其出口顺序流上。查看条件顺序流章节了解这种表达式的可用选项。

以下面的模型为例：

其XML表示如下：

2.4.2、并行网关
2.4.2.1、描述
网关也可以建模流程中的并行执行。在流程模型中引入并行的最简单的网关，就是并行网关（parallel gateway）。它可以将执行分支（fork）为多条路径，也可以合并（join）多条入口路径的执行。
并行网关的功能取决于其入口与出口顺序流：
分支：所有的出口顺序流都并行执行，为每一条顺序流创建一个并行执行。
合并：所有到达并行网关的并行执行都会在网关处等待，直到每一条入口顺序流都到达了有个执行。然后流程经过该合并网关继续。
请注意，如果并行网关同时具有多条入口与出口顺序流，可以同时具有分支与合并的行为。在这种情况下，网关首先合并所有入口顺序流，然后分裂为多条并行执行路径。
与其他网关类型有一个重要区别：并行网关不计算条件。如果连接到并行网关的顺序流上定义了条件，会直接忽略该条件。
2.4.2.2、图示
并行网关，用内部带有’加号’图标的网关（菱形）表示，代表与（AND）的含义。

2.4.2.3、xml表示
定义并行网关只需要一行XML：

实际行为（分支，合并或两者皆有），由连接到该并行网关的顺序流定义。

当这两个任务完成后，第二个并行网关会合并这两个执行。由于它只有一条出口顺序流，因此就不会再创建并行执行路径，而只是激活Archive Order(存档订单)任务。
请注意并行网关不需要“平衡”（也就是说，前后对应的两个并行网关，其入口/出口顺序流的数量不需要一致）。每个并行网关都会简单地等待所有入口顺序流，并为每一条出口顺序流创建并行执行，而不受流程模型中的其他结构影响。

2.4.3、包容网关
2.4.3.1、描述

可以把包容网关（inclusive gateway）看做排他网关与并行网关的组合。与排他网关一样，可以在包容网关的出口顺序流上定义条件，包容网关会计算条件。然而主要的区别是，包容网关与并行网关一样，可以同时选择多于一条出口顺序流。

包容网关的功能取决于其入口与出口顺序流：

分支：流程会计算所有出口顺序流的条件。对于每一条计算为true的顺序流，流程都会创建一个并行执行。

合并：所有到达包容网关的并行执行，都会在网关处等待。直到每一条具有流程标志（process token）的入口顺序流，都有一个执行到达。这是与并行网关的重要区别。换句话说，包容网关只会等待可以被执行的入口顺序流。在合并后，流程穿过合并并行网关继续。

请注意，如果包容网关同时具有多条入口与出口顺序流，可以同时具有分支与合并的行为。在这种情况下，网关首先合并所有具有流程标志的入口顺序流，然后为每一个条件计算为true的出口顺序流分裂出并行执行路径。

包容网关的汇聚行为比并行网关更复杂。所有到达包容网关的并行执行，都会在网关等待，直到所有“可以到达”包容网关的执行都“到达”包容网关。 判断方法为：计算当前流程实例中的所有执行，检查从其位置是否有一条到达包容网关的路径（忽略顺序流上的任何条件）。如果存在这样的执行（可到达但尚未到达），则不会触发包容网关的汇聚行为。

2.4.3.2、图示

包容网关，用内部带有’圆圈’图标的网关（菱形）表示。

2.4.3.3、xml表示

定义包容网关需要一行XML：

实际行为（分支，合并或两者皆有），由连接到该包容网关的顺序流定义。
例如，上面的模型表现为下面的XML：

当这个任务完成后，第二个包容网关会合并这两个执行。并且由于它只有一条出口顺序流，所有不会再创建并行执行路径，而只会激活Archive Order(存档订单)任务。

请注意包容网关不需要“平衡”（也就是说，对应的包容网关，其入口/出口顺序流的数量不需要匹配）。包容网关会简单地等待所有入口顺序流，并为每一条出口顺序流创建并行执行，不受流程模型中的其他结构影响。

请注意包容网关不需要“平衡”（也就是说，前后对应的两个包容网关，其入口/出口顺序流的数量不需要一致）。每个包容网关都会简单地等待所有入口顺序流，并为每一条出口顺序流创建并行执行，不受流程模型中的其他结构影响。

2.5、任务
2.5.1、用户任务

描述
“用户任务（user task）”用于对需要人工执行的任务进行建模。当流程执行到达用户任务时，会为指派至该任务的用户或组的任务列表创建一个新任务。

图示
用户任务用左上角有一个小用户图标的标准任务（圆角矩形）表示。

XML表示

用户任务在XML中如下定义。其中id是必须属性，name是可选属性。

到期日期

每个任务都可以使用一个字段标志该任务的到期日期（due date）。可以使用查询API，查询在给定日期前或后到期的任务。
可以在任务定义中使用扩展指定表达式，以在任务创建时设定到期日期。该表达式必须解析为java.util.Date，java.util.String (ISO8601格式)，ISO8601时间长度（例如PT50M），或者null。例如，可以使用在流程里前一个表单中输入的日期，或者由前一个服务任务计算出的日期。如果使用的是时间长度，则到期日期基于当前时间加上给定长度计算。例如当dueDate使用“PT30M”时，任务在从现在起30分钟后到期。

用于任务指派的Flowable扩展

很明显，当指派关系不复杂时，这种用户与组的指派方式十分笨重。为避免这种复杂性，可以在用户任务上使用自定义扩展。
assignee（办理人）属性：这个自定义扩展用于直接将用户指派至用户任务。
candidateUsers（候选用户）属性：这个自定义扩展用于为任务指定候选用户。
candidateGroups（候选组）attribute：这个自定义扩展用于为任务指定候选组。

2.5.2、脚本任务

描述
脚本任务（script task）是自动执行的活动。当流程执行到达脚本任务时，会执行相应的脚本。

图示
脚本任务用左上角有一个小“脚本”图标的标准BPMN 2.0任务（圆角矩形）表示。

XML表示

脚本任务使用script与scriptFormat元素定义。

scriptFormat属性的值，必须是兼容JSR-223（Java平台脚本）的名字。默认情况下，JavaScript包含在每一个JDK中，因此不需要添加任何JAR文件。如果想使用其它（兼容JSR-223的）脚本引擎，则需要在classpath中添加相应的jar，并使用适当的名字。例如，Flowable单元测试经常使用Groovy，因为其语法与Java十分相似。

请注意Groovy脚本引擎与groovy-all JAR捆绑在一起。在Groovy 2.0版本以前，脚本引擎是Groovy JAR的一部分。因此，必须添加如下依赖：

2.5.3、java服务任务
描述
Java服务任务（Java service task）用于调用Java类。

图示
服务任务用左上角有一个小齿轮图标的圆角矩形表示。

XML表示

有四种方法声明如何调用Java逻辑：

指定实现了JavaDelegate或ActivityBehavior的类

调用解析为委托对象（delegation object）的表达式

调用方法表达式（method expression）

对值表达式（value expression）求值

使用flowable:class属性提供全限定类名（fully qualified classname），指定流程执行时调用的类。

也可以使用解析为对象的表达式。该对象必须遵循的规则，与使用flowable:class创建的对象规则相同

使用flowable:expression属性指定需要计算的UEL方法表达式。

字段注入
可以为委托类的字段注入值。支持下列注入方式：
字符串常量
表达式

如果可以的话，会按照Java Bean命名约定（例如，firstName成员使用setter setFirstName(…​)），通过委托类的公有setter方法，注入变量。如果该字段没有可用的setter，会直接设置该委托类的私有成员的值。有的环境中，SecurityManagers不允许修改私有字段，因此为想要注入的字段暴露一个公有setter方法，是更安全的做法。
不论在流程定义中声明的是什么类型的值，注入对象的setter/私有字段的类型，总是org.flowable.engine.delegate.Expression。解析表达式后，可以被转型为合适的类型。
'flowable:class’属性支持字段注入。也可以在使用flowable:delegateExpression属性时，进行字段注入。然而考虑到线程安全，需要遵循特殊的规则

字段注入与线程安全
通常情况下，在服务任务中使用Java委托与字段注入是线程安全的。然而，有些情况下不能保证线程安全。这取决于设置，或Flowable运行的环境。
当使用flowable:class属性时，使用字段注入总是线程安全的（译者注：仍不完全安全，如对于多实例服务任务，使用的是同一个实例）。对于引用了某个类的每一个服务任务，都会实例化新的实例，并且在创建实例时注入一次字段。在不同的任务或流程定义中多次使用同一个类没有问题。
当使用flowable:expression属性时，不能使用字段注入。只能通过方法调用传递变量。总是线程安全的。
当使用flowable:delegateExpression属性时，委托实例的线程安全性，取决于表达式解析的方式。如果该委托表达式在多个任务或流程定义中重复使用，并且表达式总是返回相同的示例，则字段注入不是线程安全的。让我们看几个例子。
假设表达式为$factory.createDelegate(someVariable)，其中factory为引擎可用的Javabean（例如使用Spring集成时的Springbean），并在每次表达式解析时创建新的实例。这种情况下，使用字段注入时，没有线程安全性问题：每次表达式解析时，都会注入新实例的字段。然而，如果表达式为${someJavaDelegateBean}，解析为JavaDelegate的实现，并且在创建单例的环境（如Spring）中运行。当在不同的任务或流程定义中使用这个表达式时，表达式总会解析为相同的实例。这种情况下，使用字段注入不是线程安全的。

最简单的解决方法是：
使用表达式代替直接使用Java委托，并将所需数据通过方法参数传递给委托。
或者，在每次委托表达式解析时，返回委托类的新实例。这意味着这个bean的scope必须是prototype（原型）（例如在委托类上加上@Scope(SCOPE_PROTOTYPE)注解）。

服务任务的结果
服务执行的返回值（仅对使用表达式的服务任务），可以通过为服务任务定义的’flowable:resultVariable’属性设置为流程变量。可以是已经存在的，或者新的流程变量。 如果指定为已存在的流程变量，则流程变量的值会被服务执行的结果值覆盖。 如果使用’flowable:useLocalScopeForResultVariable’，则会将结果值设置为局部变量。 如果不指定结果变量名，则服务任务的结果值将被忽略。

在上例中，服务执行的结果（流程变量或Spring bean中，使用’myService’名字所获取的对象，调用’doSomething()'方法的返回值），在服务执行完成后，会设置为名为’myVar’的流程变量。
2.5.4、web服务任务

2.5.5、业务规则任务

业务规则任务（business rule task）用于同步地执行一条或多条规则。Flowable使用名为Drools Expert的Drools规则引擎执行业务规则。目前，业务规则中包含的.drl文件，必须与定义了业务规则服务并执行规则的流程定义一起部署。这意味着流程中使用的所有.drl文件都需要打包在流程BAR文件中，与任务表单等类似。要了解如何为Drools Expert创建业务规则，请访问位于JBoss Drools的Drools文档。

如果想要使用自己的规则任务实现，比如希望通过不同方法使用Drools，或者想使用完全不同的规则引擎，则可以使用BusinessRuleTask的class或expression属性。这样它会与服务任务的行为完全相同。

2.5.6、邮件任务

2.5.7、http任务

2.5.8、mule任务

2.5.9、Camel任务

2.5.10、手动任务

2.5.11、java接受任务

2.5.12、Shell任务

2.5.13、执行监听器
执行监听器（execution listener）可以在流程执行中发生特定的事件时，执行外部Java代码或计算表达式。可以被捕获的事件有：

流程实例的启动和结束。

流程执行转移。

活动的启动和结束。

网关的启动和结束。

中间事件的启动和结束。

启动事件的结束，和结束事件的启动。

2.5.14、任务监听器
任务监听器（task listener）用于在特定的任务相关事件发生时，执行自定义的Java逻辑或表达式。

任务监听器只能在流程定义中作为用户任务的子元素。请注意，任务监听器是一个Flowable自定义结构，因此也需要作为BPMN 2.0 extensionElements，放在flowable命名空间下。

任务监听器包含下列属性：
event（事件）（必填）：触发任务监听器的任务事件类型。可用的事件有：
create（创建）：当任务已经创建，并且所有任务参数都已经设置时触发。
assignment（指派）：当任务已经指派给某人时触发。请注意：当流程执行到达用户任务时，在触发create事件之前，会首先触发assignment事件。这顺序看起来不太自然，但是有实际原因的：当收到create事件时，我们通常希望能看到任务的所有参数，包括办理人。
complete（完成）：当任务已经完成，从运行时数据中删除前触发。

    delete（删除）：在任务即将被删除前触发。请注意任务由completeTask正常完成时也会触发。

2.5.15、多实例
多实例活动（multi-instance activity）是在业务流程中，为特定步骤定义重复的方式。在编程概念中，多实例类似for each结构：可以为给定集合中的每一条目，顺序或并行地，执行特定步骤，甚至是整个子流程。

多实例是一个普通活动，加上定义（被称作“多实例特性的”）额外参数，会使得活动在运行时被多次执行。
下列活动可以成为多实例活动：
用户任务
脚本任务
Java服务任务
Web服务任务
业务规则任务
邮件任务
人工任务
接收任务
（嵌入式）子流程
调用活动

2.5.16、补偿处理器
如果要使用一个活动补偿另一个活动的影响，可以将其声明为补偿处理器（compensation handler）。补偿处理器不在正常流程中执行，而只在流程抛出补偿事件时才会执行。
补偿处理器不得有入口或出口顺序流。
补偿处理器必须通过单向的连接，关联一个补偿边界事件。

2.6、子流程和调用活动
2.6.1、子流程

描述
子流程（sub-process）是包含其他的活动、网关、事件等的活动。其本身构成一个流程，并作为更大流程的一部分。子流程完全在父流程中定义（这就是为什么经常被称作嵌入式子流程）。
子流程有两个主要的使用场景：
子流程可以分层建模。很多建模工具都可以折叠子流程，隐藏子流程的所有细节，而只显示业务流程的高层端到端总览。
子流程会创建新的事件范围。在子流程执行中抛出的事件可以通过子流程边界上的边界事件捕获，为该事件创建了限制在子流程内的范围。
使用子流程也要注意以下几点：
子流程只能有一个空启动事件，而不允许有其他类型的启动事件。请注意BPMN 2.0规范允许省略子流程的启动与结束事件，但目前Flowable的实现尚不支持省略。
顺序流不能跨越子流程边界。

图示

子流程表示为标准活动(圆角矩形)。若折叠了子流程，则只显示其名字与一个加号，以展示流程的高层概览：

若展开了子流程，则在子流程内显示子流程的所有步骤：

使用子流程的一个主要原因是为事件定义范围。下面的流程模型展示了这种用法：investigate software（调查硬件）/investigate hardware（调查软件）两个任务需要并行执行，且需要在给定时限内，在Level 2 support（二级支持）响应前完成。在这里，定时器的范围（即需要按时完成的活动）通过子流程进行限制。

2.6.2、调用活动

描述

尽管看起来很相像，但在BPMN 2.0中，调用活动（call activity）有别于一般的子流程——通常也称作嵌入式子流程。从概念上说，两者都在流程执行到达该活动时，调用一个子流程。

两者的区别为，调用活动引用一个流程定义外部的流程，而子流程嵌入在原有流程定义内。调用活动的主要使用场景是，在多个不同流程定义中调用一个可复用的流程定义。

当流程执行到达调用活动时，会创建一个新的执行，作为到达调用活动的执行的子执行。这个子执行用于执行子流程，也可用于创建并行子执行（与普通流程中行为类似）。父执行将等待子流程完成，之后沿原流程继续执行。
图示

调用过程表现为带有粗边框（折叠与展开都是）的子流程。取决于建模工具，调用过程可以展开，但默认表现为折叠形式。

Xml表示
调用活动是一个普通活动，在calledElement中通过key引用流程定义。在实际使用中，通常在calledElement中配置流程的ID。

请注意子流程的流程定义在运行时解析。这意味着如果需要的话，子流程可以与调用流程分别部署。

传递变量
可以向子流程传递与接收流程变量。数据将在子流程启动时复制到子流程，并在其结束时复制回主流程。

可以将inheritVariables设置为true，将所有流程变量传递给子流程。

2.7、事务和并发
2.7.1、异步延续
Flowable以事务方式执行流程，并可按照你的需求配置。让我们从Flowable一般如何为事务划分范围开始介绍。如果Flowable被触发（启动流程，完成任务，为执行发送信号），Flowable将沿流程执行，直到到达每个执行路径的等待状态。更具体地说，它以深度优先方式搜索流程图，并在每个执行分支都到达等待状态时返回。等待状态是“之后”再执行的任务，也就是说着Flowable将当前执行持久化，并等待再次触发。触发可以来自外部来源如用户任务或消息接受任务，也可以来自Flowable自身如定时器事件。以下面的图片说明：

这是一个BPMN流程的片段，有一个用户任务、一个服务任务，与一个定时器事件。用户任务的完成操作与验证地址（validate address）在同一个工作单元内，因此需要原子性地（atomically）成功或失败。这意味着如果服务任务抛出了异常，我们会想要回滚当前事务，以便执行返回到用户任务，并希望用户任务仍然保存在数据库中。这也是Flowable的默认行为。在（1）中，应用或客户端线程完成任务。在相同的线程中，Flowable执行服务并继续，直到到达等待状态，在这个例子中，是定时器事件（2）。然后将控制权返回至调用者（3），同时提交事务（如果事务由Flowable开启）。

在有的情况下，我们不想要这样。有时我们需要在流程中自定义地控制事务边界，以便为工作的逻辑单元划分范围。这就需要使用异步延续。考虑下面的流程（片段）：

完成用户任务，生成发票，并将发票发送给客户。这次发票的生成不再是同一个工作单元的一部分，因此我们不希望当发票生成失败时，回滚用户任务。所以我们希望Flowable做的，是完成用户任务（1），提交事务，并将控制权返回给调用程序。然后我们希望在后台线程中，异步地生成发票。这个后台线程就是Flowable作业执行器（事实上是一个线程池），它周期性地将作业保存至数据库。因此在幕后，当到达"generate invoice（生成发票）"任务时，Flowable会创建“消息”作业并将其持久化到数据库中，用于继续执行流程。这个作业之后会被作业执行器选中并执行。Flowable也会向本地的作业执行器进行提示，告知其有新作业到来，以提升性能。
要使用这个特性，可以使用flowable:async="true"扩展。因此，一个示例的服务任务会像是这样：

可以为下列BPMN任务类型指定flowable:async：任务，服务任务，脚本任务，业务规则任务，发送任务，接收任务，用户任务，子流程，调用活动。
对于用户任务、接收任务与其他等待状态来说，异步操作允许我们在一个独立的线程/事务中启动执行监听器。

2.7.2、失败重试

默认配置下，如果作业执行中有任何异常，Flowable将三次重试执行作业。对异步作业也是这样。需要更灵活的配置时可以使用这两个参数：

重试的次数

重试的间隔

这两个参数可以通过flowable:failedJobRetryTimeCycle元素配置。这有一个简单的例子：

时间周期表达式与定时器事件表达式一样遵循ISO 8601标准。上面的例子会让作业执行器重试5次，并在每次重试前等待7分钟。

2.7.3、排他任务

从近期版本开始，JobExecutor确保同一个流程实例的作业永远不会并发执行。为什么这样？

为什么使用排他作业？
考虑下面的流程定义：

一个并行网关，之后是三个服务任务，都使用异步操作执行。其结果是在数据库中添加了三个作业。当作业储存在数据库后，就由JobExecutor处理。JobExecutor获取作业，并将其委托至工作线程的线程池，由它们实际执行作业。这意味着通过使用异步操作，可以将工作分发至线程池（在集群场景下，甚至会在集群中跨越多个线程池）。通常这都是好事。但也有其固有问题：一致性。考虑服务任务后的并行合并：当服务任务的执行完成时到达并行合并，并需要决定等待其他执行，还是需要继续向前。这意味着，对于每一个到达并行合并的分支，都需要选择继续执行，还是需要等待其他分支上的一个或多个其他执行。
为什么这是问题呢？这是因为服务任务配置为使用异步延续，有可能所有相应的作业都同时被作业执行器处理，并委托至不同的工作线程。结果是服务执行的事务，与到达并行合并的3个独立执行所在的事务会发生重叠。如果这样，每一个独立事务都“看不到”其他事物已经并发地到达了同样的并行合并，并因此判断自己需要等待其他事务。然而，如果每个事务都判断需要等待其他事务，在并行合并后不会有继续流程的事务，而流程实例也就会永远保持这个状态。
Flowable如何解决这个问题呢？Flowable使用乐观锁。每当需要基于数据进行判断，而数据可能不是最新值（因为其他事务可能在我们提交前修改了这个数据）时，我们确保会在每个事务中都增加同一个数据库记录行的版本号。这样，无论哪个事务第一个提交，都将成功，而其他的会抛出乐观锁异常并失败。这样就解决了上面流程中讨论的问题：如果多个执行并发到达并行合并，它们都判断需要等待，增加其父执行（流程实例）的版本号并尝试提交。无论哪个执行第一个提交，都可以成功提交，而其他的将会抛出乐观锁异常并失败。因为这些执行由作业触发，Flowable会在等待给定时间后，重试执行相同的作业，期望这一次通过这个同步的网关。
这是好的解决方案么？我们可以看到乐观锁使Flowable避免不一致状态。它确保了我们不会“在合并网关卡住”，也就是说：要么所有的执行都通过网关，要么数据库中的作业能确保可以重试通过它。然而，尽管这是一个持久化与一致性角度的完美解决方案，但从更高层次看，仍然不一定总是理想行为：
Flowable只会为同一个作业重试一个固定的最大次数（默认配置为3次）。在这之后，作业仍然保存在数据库中，但不会再重试。这就需要手动操作来触发作业。
如果一个作业有非事务性的副作用，则副作用将不会由于事务失败而回滚。例如，如果"book concert tickets（预定音乐会门票）"服务与Flowable不在同一个事务中，则重试执行作业将预定多张票。

排他作业不能与同一个流程实例中的其他排他作业同时执行。考虑上面展示的流程：如果我们将服务任务都声明为排他的，则JobExecutor将确保相关的作业都不会并发执行。相反，它将确保不论何时从特定流程实例中获取了排他作业，都会从同一个流程实例中获取所有其他的排他作业，并将它们委托至同一个工作线程。这保证了作业的顺序执行。

如何启用这个特性？从近期版本开始，排他作业成为默认配置。所有异步操作与定时器事件都默认为排他的。另外，如果希望作业成为非排他的，可以使用flowable:exclusive="false"配置。例如，下面的服务任务是异步，但非排他的。

这是好的解决方案么？有很多人都在问这个问题。他们的顾虑是，这将阻止并行操作，因此会有性能问题。但也需要考虑以下两点：
如果你是专家，并且知道你在做什么（并理解“为什么排他作业？”章节的内容），可以关掉排他。否则，对大多数用户来说，异步操作与定时器能够正常工作才更重要。
事实上不会有性能问题。只有在重负载下才会有性能问题。重负载意味着作业执行器的所有的工作线程都一直忙碌。对于排他作业，Flowable会简单的根据负载不同进行分配。排他作业意味着同一个流程实例的作业都将在同一个线程中顺序执行。但是请想一下：我们有不止一个流程实例。其他流程实例的作业将被委托至其他线程，并与本实例的作业并发执行。也就是说Flowable不会并发执行同一个流程实例的排他作业，但会并发执行多个实例。从总吞吐量角度来看，可以期望大多数场景下都可以保证实例很快地完成。此外，执行同一个流程实例中下一个作业所需的数据，已经缓存在同一个执行集群节点中。如果作业与节点没有关联关系，则可能需要重新从数据库中获取数据。

3、数据库表

Flowable的所有数据库表都以ACT_开头。第二部分是说明表用途的两字符标示符。服务API的命名也大略符合这个规则。
ACT_RE_：其中“RE”表示repository（存储）的意思，是RepositoryService 接口操作的表。带此前缀的表包含的是静态信息，如，流程定义，流程的资源（图片，规则等）。
ACT_RU_：其中“RU”表示runtime（运行时）的意思，是RuntimeService接口操作的表。存储着流程变量，用户任务，变量，职责（job）等运行时的数据。flowable 只存储实例执行期间的运行时数据，当流程实例结束时，将删除这些记录。这就保证了这些运行时的表小且快。
ACT_ID_* ：其中“ID”表示 identity (组织机构)。这些表包含标识的信息，如用户，用户组，等等。
ACT_HI_* ：其中 “HI”表示 history（历史记录），是HistoryService接口操作的表。这些表包含着历史的相关数据，如结束的流程实例，变量，任务，等等。
ACT_GE_* : 普通数据，各种情况都使用的数据。

3.1.ACT_GE_*
ACT_GE_BYTEARRAY：保存流程的bpmn的xml以及流程的Image缩略图等信息
ACT_GE_PROPERTY：Flowable相关的基本信息。比如各个module使用的版本信息。
3.2.ACT_RE_*
ACT_RE_DEPLOYMENT: 部署对象，存储流程名称
ACT_RE_MODEL：基于流程的模型信息
ACT_RE_PROCDEF：流程定义表
3.3.ACT_RU_*
ACT_RU_ACTINST：运行中实例的活动表
ACT_RU_DEADLETTER_JOB：当JOB执行很多次都无法执行，就会被记录在此表
ACT_RU_ENTITYLINK：还没使用到。后续更新此表。
ACT_RU_EVENT_SUBSCR：运行时的事件
ACT_RU_EXECUTION：运行的实例表
ACT_RU_HISTORY_JOB； 运行中的定时任务历史表
ACT_RU_IDENTITYLINK： 当前任务执行人的信息
ACT_RU_JOB：运行中的异步任务
ACT_RU_SUSPENDED_JOB：暂停的任务表。如果一个异步任务在运行中，被暂停。就会记录在词表
ACT_RU_TASK：运行中的正常节点任务
ACT_RU_TIMER_JOB：定时作业表
ACT_RU_VARIABLE：运行中的流程实例变量
3.4.ACT_ID_*
ACT_ID_BYTEARRAY：
ACT_ID_GROUP：用户组信息
ACT_ID_INFO：用户详情
ACT_ID_MEMBERSHIP：用户组和用户的关系
ACT_ID_PRIV：权限
ACT_ID_PRIV_MAPPING：用户组和权限之间的关系
ACT_ID_PROPERTY：用户或者用户组属性拓展表
ACT_ID_TOKEN：登录相关日志
ACT_ID_USER：用户
3.5.ACT_HI_*
ACT_HI_ACTINST: 流程实例历史
ACT_HI_ATTACHMENT：实例的历史附件，几乎不会使用，会加大数据库很大的一个loading
ACT_HI_COMMENT：实例的历史备注
ACT_HI_DETAIL：实例流程详细信息
ACT_HI_IDENTITYLINK: 实例节点中，如果指定了目标人，产生的历史
ACT_HI_PROCINST：流程实例历史
ACT_HI_TASKINST：流程实例的任务历史
ACT_HI_VARINST：流程实例的变量历史
3.6.FLW_*
FLW_CHANNEL_DEFINITION: 泳池管道定义表
FLW_EVENT_DEFINITION：事件定义
FLW_EVENT_DEPLOYMENT：事件必输
FLW_EVENT_RESOURCE：事件所需资源
FLW_EV_DATABASECHANGELOG：Liquibase执行的记录
FLW_EV_DATABASECHANGELOGLOCK：Liquibase执行锁

4、配置介绍

Core (Process) FlowableProperties

核心（流程）

flowable.check-process-definitions=true # 是否需要自动部署流程定义。
flowable.custom-mybatis-mappers= # 需要添加至引擎的自定义Mybatis映射的FQN。
flowable.custom-mybatis-x-m-l-mappers= # 需要添加至引擎的自定义Mybatis XML映射的路径。
flowable.database-schema= # 如果数据库返回的元数据不正确，可以在这里设置schema用于检测/生成表。
flowable.database-schema-update=true # 数据库schema更新策略。
flowable.db-history-used=true # 是否要使用db历史。
flowable.deployment-name=SpringBootAutoDeployment # 自动部署的名称。
flowable.history-level= # 要使用的历史级别。
flowable.process-definition-location-prefix=classpath*:/processes/ # 自动部署时查找流程的目录。
flowable.process-definition-location-suffixes=.bpmn20.xml,.bpmn # 'processDefinitionLocationPrefix’路径下需要部署的文件的后缀（扩展名）。

Process FlowableProcessProperties

流程

flowable.process.definition-cache-limit=-1 # 流程定义缓存中保存流程定义的最大数量。默认值为-1（缓存所有流程定义）。
flowable.process.enable-safe-xml=true # 在解析BPMN XML文件时进行额外检查。参见 https://www.flowable.org/docs/userguide/index.html#advanced.safe.bpmn.xml 。不幸的是，部分平台（JDK 6，JBoss）上无法使用这个功能，因此如果你所用的平台在XML解析时不支持StaxSource，需要禁用这个功能。
flowable.process.servlet.load-on-startup=-1 # 启动时加载Process servlet。
flowable.process.servlet.name=Flowable BPMN Rest API # Process servlet的名字。
flowable.process.servlet.path=/process-api # Process servelet的context path。

Process Async Executor

流程异步执行器

flowable.process.async-executor-activate=true # 是否启用异步执行器。
flowable.process.async.executor.async-job-lock-time-in-millis=300000 # 异步作业在被异步执行器取走后的锁定时间（以毫秒计）。在这段时间内，其它异步执行器不会尝试获取及锁定这个任务。
flowable.process.async.executor.default-async-job-acquire-wait-time-in-millis=10000 # 异步作业获取线程在进行下次获取查询前的等待时间（以毫秒计）。只在当次没有取到新的异步作业，或者只取到很少的异步作业时生效。默认值 = 10秒。
flowable.process.async.executor.default-queue-size-full-wait-time-in-millis=0 # 异步作业（包括定时器作业与异步执行）获取线程在队列满时，等待执行下次查询的等待时间（以毫秒计）。默认值为0（以向后兼容）
flowable.process.async.executor.default-timer-job-acquire-wait-time-in-millis=10000 # 定时器作业获取线程在进行下次获取查询前的等待时间（以毫秒计）。只在当次没有取到新的定时器作业，或者只取到很少的定时器作业时生效。默认值 = 10秒。
flowable.process.async.executor.max-async-jobs-due-per-acquisition=1 # （译者补）单次查询的异步作业数量。默认值为1，以降低乐观锁异常的可能性。除非你知道自己在做什么，否则请不要修改这个值。
flowable.process.async.executor.retry-wait-time-in-millis=500 # ???（译者补不了了）
flowable.process.async.executor.timer-lock-time-in-millis=300000 # 定时器作业在被异步执行器取走后的锁定时间（以毫秒计）。在这段时间内，其它异步执行器不会尝试获取及锁定这个任务。

CMMN FlowableCmmnProperties

flowable.cmmn.deploy-resources=true # 是否部署资源。默认值为’true’。
flowable.cmmn.deployment-name=SpringBootAutoDeployment # CMMN资源部署的名字。
flowable.cmmn.enable-safe-xml=true # 在解析CMMN XML文件时进行额外检查。参见 https://www.flowable.org/docs/userguide/index.html#advanced.safe.bpmn.xml 。不幸的是，部分平台（JDK 6，JBoss）上无法使用这个功能，因此如果你所用的平台在XML解析时不支持StaxSource，需要禁用这个功能。
flowable.cmmn.enabled=true # 是否启用CMMN引擎。
flowable.cmmn.resource-location=classpath*:/cases/ # CMMN资源的路径。
flowable.cmmn.resource-suffixes=.cmmn,.cmmn11,.cmmn.xml,.cmmn11.xml # 需要扫描的资源后缀名。
flowable.cmmn.servlet.load-on-startup=-1 # 启动时加载CMMN servlet。
flowable.cmmn.servlet.name=Flowable CMMN Rest API # CMMN servlet的名字。
flowable.cmmn.servlet.path=/cmmn-api # CMMN servlet的context path。

CMMN Async Executor

CMMN异步执行器

flowable.cmmn.async-executor-activate=true # 是否启用异步执行器。
flowable.cmmn.async.executor.async-job-lock-time-in-millis=300000 # 异步作业在被异步执行器取走后的锁定时间（以毫秒计）。在这段时间内，其它异步执行器不会尝试获取及锁定这个任务。
flowable.cmmn.async.executor.default-async-job-acquire-wait-time-in-millis=10000 # 异步作业获取线程在进行下次获取查询前的等待时间（以毫秒计）。只在当次没有取到新的异步作业，或者只取到很少的异步作业时生效。默认值 = 10秒。
flowable.cmmn.async.executor.default-queue-size-full-wait-time-in-millis=0 # 异步作业（包括定时器作业与异步执行）获取线程在队列满时，等待执行下次查询的等待时间（以毫秒计）。默认值为0（以向后兼容）
flowable.cmmn.async.executor.default-timer-job-acquire-wait-time-in-millis=1000 # 定时器作业获取线程在进行下次获取查询前的等待时间（以毫秒计）。只在当次没有取到新的定时器作业，或者只取到很少的定时器作业时生效。默认值 = 10秒。
flowable.cmmn.async.executor.max-async-jobs-due-per-acquisition=1 # （译者补）单次查询的异步作业数量。默认值为1，以降低乐观锁异常的可能性。除非你知道自己在做什么，否则请不要修改这个值。
flowable.cmmn.async.executor.retry-wait-time-in-millis=500 #（译者补不了了）
flowable.cmmn.async.executor.timer-lock-time-in-millis=300000 # 定时器作业在被异步执行器取走后的锁定时间（以毫秒计）。在这段时间内，其它异步执行器不会尝试获取及锁定这个任务。

Content FlowableContentProperties

flowable.content.enabled=true # 是否启动Content引擎。
flowable.content.servlet.load-on-startup=-1 # 启动时加载Content servlet。
flowable.content.servlet.name=Flowable Content Rest API # Content servlet的名字。
flowable.content.servlet.path=/content-api # Content servlet的context path。
flowable.content.storage.create-root=true # 如果根路径不存在，是否需要创建？
flowable.content.storage.root-folder= # 存储content文件（如上传的任务附件，或表单文件）的根路径。

DMN FlowableDmnProperties

flowable.dmn.deploy-resources=true # 是否部署资源。默认为’true’。
flowable.dmn.deployment-name=SpringBootAutoDeployment # DMN资源部署的名字。
flowable.dmn.enable-safe-xml=true # 在解析DMN XML文件时进行额外检查。参见 https://www.flowable.org/docs/userguide/index.html#advanced.safe.bpmn.xml 。不幸的是，部分平台（JDK 6，JBoss）上无法使用这个功能，因此如果你所用的平台在XML解析时不支持StaxSource，需要禁用这个功能。
flowable.dmn.enabled=true # 是否启用DMN引擎。
flowable.dmn.history-enabled=true # 是否启用DMN引擎的历史。
flowable.dmn.resource-location=classpath*:/dmn/ # DMN资源的路径。
flowable.dmn.resource-suffixes=.dmn,.dmn.xml,.dmn11,.dmn11.xml # 需要扫描的资源后缀名。
flowable.dmn.servlet.load-on-startup=-1 # 启动时加载DMN servlet。
flowable.dmn.servlet.name=Flowable DMN Rest API # DMN servlet的名字。
flowable.dmn.servlet.path=/dmn-api # DMN servlet的context path。
flowable.dmn.strict-mode=true # 如果希望避免抉择表命中策略检查导致失败，可以将本参数设置为false。如果检查发现了错误，会直接返回错误前一刻的中间结果。

Form FlowableFormProperties

flowable.form.deploy-resources=true # 是否部署资源。默认为’true’。
flowable.form.deployment-name=SpringBootAutoDeployment # Form资源部署的名字。
flowable.form.enabled=true # 是否启用Form引擎。
flowable.form.resource-location=classpath*:/forms/ # Form资源的路径。
flowable.form.resource-suffixes=**.form # 需要扫描的资源后缀名。
flowable.form.servlet.load-on-startup=-1 # 启动时加载Form servlet。
flowable.form.servlet.name=Flowable Form Rest API # Form servlet的名字。
flowable.form.servlet.path=/form-api # Form servlet的context path。

IDM FlowableIdmProperties

flowable.idm.enabled=true # 是否启用IDM引擎。
flowable.idm.password-encoder= # 使用的密码编码类型。
flowable.idm.servlet.load-on-startup=-1 # 启动时加载IDM servlet。
flowable.idm.servlet.name=Flowable IDM Rest API # IDM servlet的名字。
flowable.idm.servlet.path=/idm-api # IDM servlet的context path。

IDM Ldap FlowableLdapProperties

flowable.idm.ldap.attribute.email= # 用户email的属性名。
flowable.idm.ldap.attribute.first-name= # 用户名字的属性名。
flowable.idm.ldap.attribute.group-id= # 用户组ID的属性名。
flowable.idm.ldap.attribute.group-name= # 用户组名的属性名。
flowable.idm.ldap.attribute.group-type= # 用户组类型的属性名。
flowable.idm.ldap.attribute.last-name= # 用户姓的属性名。
flowable.idm.ldap.attribute.user-id= # 用户ID的属性名。
flowable.idm.ldap.base-dn= # 查找用户与组的DN（标志名称 distinguished name）。
flowable.idm.ldap.cache.group-size=-1 # 设置{@link org.flowable.ldap.LDAPGroupCache}的大小。这是LRU缓存，用于缓存用户及组，以避免每次都查询LDAP系统。
flowable.idm.ldap.custom-connection-parameters= # 用于设置所有没有专用setter的LDAP连接参数。查看 http://docs.oracle.com/javase/tutorial/jndi/ldap/jndi.html 介绍的自定义参数。参数包括配置链接池，安全设置，等等。
flowable.idm.ldap.enabled=false # 是否启用LDAP IDM 服务。
flowable.idm.ldap.group-base-dn= # 组查找的DN。
flowable.idm.ldap.initial-context-factory=com.sun.jndi.ldap.LdapCtxFactory # 初始化上下文工厂的类名。
flowable.idm.ldap.password= # 连接LDAP系统的密码。
flowable.idm.ldap.port=-1 # LDAP系统的端口。
flowable.idm.ldap.query.all-groups= # 查询所有组所用的语句。
flowable.idm.ldap.query.all-users= # 查询所有用户所用的语句。
flowable.idm.ldap.query.groups-for-user= # 按照指定用户查询所属组所用的语句
flowable.idm.ldap.query.user-by-full-name-like= # 按照给定全名查找用户所用的语句。
flowable.idm.ldap.query.user-by-id= # 按照userId查找用户所用的语句。
flowable.idm.ldap.search-time-limit=0 # 查询LDAP的超时时间（以毫秒计）。默认值为’0’，即“一直等待”。
flowable.idm.ldap.security-authentication=simple # 连接LDAP系统所用的’java.naming.security.authentication’参数的值。
flowable.idm.ldap.server= # LDAP系统的主机名。如’ldap://localhost’。
flowable.idm.ldap.user= # 连接LDAP系统的用户ID。
flowable.idm.ldap.user-base-dn= # 查找用户的DN。

Flowable Mail FlowableMailProperties

flowable.mail.server.default-from=flowable@localhost # 发送邮件时使用的默认发信人地址。
flowable.mail.server.host=localhost # 邮件服务器。
flowable.mail.server.password= # 邮件服务器的登录密码。
flowable.mail.server.port=1025 # 邮件服务器的端口号。
flowable.mail.server.use-ssl=false # 是否使用SSL/TLS加密SMTP传输连接（即SMTPS/POPS)。
flowable.mail.server.use-tls=false # 使用或禁用STARTTLS加密。
flowable.mail.server.username= # 邮件服务器的登录用户名。如果为空，则不需要登录。

Actuator

management.endpoint.flowable.cache.time-to-live=0ms # 缓存响应的最大时间。
management.endpoint.flowable.enabled=true # 是否启用flowable端点。

本项目的配置：

5、提供的接口
flowable提供了7个常见的api，这些api就对应着上文的所有逻辑，所以只要掌握这些api就可以完成审批业务的开发了
5.1、FormService
表单数据的管理。
formService.getStartFormKey() 获取表单key
formService.getRenderedStartForm()查询表单json（无数据）

5.2、RepositoryService
提供了在编辑和发布审批流程的api。主要是模型管理和流程定义的业务api。
1.提供了带条件的查询模型流程定义的api
repositoryService.createXXXQuery()
例如：
repositoryService.createModelQuery().list() 模型查询
repositoryService.createProcessDefinitionQuery().list() 流程定义查询

repositoryService.createXXXXQuery().XXXKey(XXX) （查询该key是否存在）

2.提供一大波模型与流程定义的通用方法
模型相关
repositoryService.getModel() （获取模型）
repositoryService.saveModel() （保存模型）
repositoryService.deleteModel() （删除模型）
repositoryService.createDeployment().deploy(); （部署模型）
repositoryService.getModelEditorSource() （获得模型JSON数据的UTF8字符串）
repositoryService.getModelEditorSourceExtra() （获取PNG格式图像）

3.流程定义相关
repositoryService.getProcessDefinition(ProcessDefinitionId); 获取流程定义具体信息
repositoryService.activateProcessDefinitionById() 激活流程定义
repositoryService.suspendProcessDefinitionById() 挂起流程定义
repositoryService.deleteDeployment() 删除流程定义
repositoryService.getProcessDiagram()获取流程定义图片流
repositoryService.getResourceAsStream()获取流程定义xml流
repositoryService.getBpmnModel(pde.getId()) 获取bpmn对象（当前进行到的那个节点的流程图使用）

4.流程定义授权相关
repositoryService.getIdentityLinksForProcessDefinition() 流程定义授权列表
repositoryService.addCandidateStarterGroup()新增组流程授权
repositoryService.addCandidateStarterUser()新增用户流程授权
repositoryService.deleteCandidateStarterGroup() 删除组流程授权
repositoryService.deleteCandidateStarterUser() 删除用户流程授权
5.3、RuntimeService
处理正在运行的流程。
runtimeService.createProcessInstanceBuilder().start() 发起流程
runtimeService.deleteProcessInstance() 删除正在运行的流程
runtimeService.suspendProcessInstanceById() 挂起流程定义
runtimeService.activateProcessInstanceById() 激活流程实例
runtimeService.getVariables(processInstanceId); 获取表单中填写的值
runtimeService.getActiveActivityIds(processInstanceId)获取以进行的流程图节点 （当前进行到的那个节点的流程图使用）

runtimeService.createChangeActivityStateBuilder().moveExecutionsToSingleActivityId(executionIds, endId).changeState(); 终止流程
5.4、HistoryService
在用户发起审批后，会生成流程实例。historyService为处理流程实例的api，但是其中包括了已经完成的和未完成的流程实例。
historyService.createHistoricProcessInstanceQuery().list() 查询流程实例列表（历史流程,包括未完成的）
historyService.createHistoricProcessInstanceQuery().list().foreach().getValue() 可以获取历史中表单的信息
historyService.createHistoricProcessInstanceQuery().processInstanceId(processInstanceId).singleResult(); 根绝id查询流程实例
historyService.deleteHistoricProcessInstance() 删除历史流程
historyService.deleteHistoricTaskInstance(taskid); 删除任务实例
historyService.createHistoricActivityInstanceQuery().processInstanceId(processInstanceId).list() 流程实例节点列表 （当前进行到的那个节点的流程图使用）
5.5、TaskService
对流程实例的各个节点的审批处理。
流转的节点审批
taskService.createTaskQuery().list() 待办任务列表
taskService.createTaskQuery().taskId(taskId).singleResult(); 待办任务详情
taskService.saveTask(task); 修改任务
taskService.setAssignee() 设置审批人
taskService.addComment() 设置审批备注
taskService.complete() 完成当前审批
taskService.getProcessInstanceComments(processInstanceId); 查看任务详情（也就是都经过哪些人的审批，意见是什么）
taskService.delegateTask(taskId, delegater); 委派任务
taskService.claim(taskId, userId);认领任务
taskService.unclaim(taskId); 取消认领
taskService.complete(taskId, completeVariables); 完成任务

任务授权
taskService.addGroupIdentityLink()新增组任务授权
taskService.addUserIdentityLink() 新增人员任务授权
taskService.deleteGroupIdentityLink() 删除组任务授权
taskService.deleteUserIdentityLink() 删除人员任务授权
5.6、ManagementService
主要是执行自定义命令。
managementService.executeCommand(new classA()) 执行classA的内部方法

在自定义的方法中可以使用以下方法获取repositoryService。
ProcessEngineConfiguration processEngineConfiguration =
CommandContextUtil.getProcessEngineConfiguration(commandContext);
RepositoryService repositoryService = processEngineConfiguration.getRepositoryService();

也可以获取流程定义方法集合。
ProcessEngineConfigurationImpl processEngineConfiguration =
CommandContextUtil.getProcessEngineConfiguration(commandContext);
ProcessDefinitionEntityManager processDefinitionEntityManager =
processEngineConfiguration.getProcessDefinitionEntityManager();
如findById/findLatestProcessDefinitionByKey/findLatestProcessDefinitionByKeyAndTenantId等。
5.7、IdentityService
用于身份信息获取和保存，这里主要是获取身份信息。
identityService.createUserQuery().userId(userId).singleResult(); 获取审批用户的具体信息
identityService.createGroupQuery().groupId(groupId).singleResult(); 获取审批组的具体信息