前言：
不用到处百度BPMN2的博客了，本篇文章带你系统掌握BPMN2规范的核心知识点。全文2万字，全覆盖BPMN2知识点，图文并茂，泡杯咖啡，慢慢细品～

一、BPMN是什么

BPMN（Business Process Modeling Notation,业务流程建模符号）是一种流程建模的通用和标准语言，用来绘制业务流程图，以便更好地让各部门之间理解业务流程和相互关系，旨在促进业务流程的沟通和理解。

BPMN 标准发展版本历史有BPMN1.0,BPMN1.1,BPMN1.2,BPMN2.0。BPMN2.0在1.x基础上新增了元模型、存储、交互、执行。

Flowable用的是BPM2.0模型规范。

BPMN2.0结构主要有，事件、顺序流、网关、任务、子流程与调用活动等。

本篇文章也是简单描述一下BPMN的结构有哪些，不展开细致内容，后续有使用的地方详细讲解。

更多BPM相关信息可以查阅：BPMN官网

二、事件

事件（event）通常用于为流程生命周期中发生的事情建模。事件总是图形化为圆圈。在BPMN 2.0中，有两种主要的事件分类：捕获（catching）与抛出（throwing）事件。

捕获: 当流程执行到达这个事件时，会等待直到触发器动作。触发器的类型由其中的图标，或者说XML中的类型声明而定义。捕获事件与抛出事件显示上的区别，是其内部的图标没有填充（即是白色的）。
抛出: 当流程执行到达这个事件时，会触发一个触发器。触发器的类型，由其中的图标，或者说XML中的类型声明而定义。抛出事件与捕获事件显示上的区别，是其内部的图标填充为黑色。

2.1 事件定义

事件定义（event definition），用于定义事件的语义。没有事件定义的话，事件就“不做什么特别的事情”。例如，一个没有事件定义的开始事件，并不限定具体是什么启动了流程。如果为这个开始事件添加事件定义（例如定时器事件定义），就声明了启动流程的“类型”（例如对于定时器事件定义，就是到达了特定的时间点）。

2.2 定时器事件定义

定时器事件（timer event definition），是由定时器所触发的事件。可以用于开始事件，中间事件，或边界事件。定时器事件的行为取决于所使用的业务日历（business calendar）。定时器事件有默认的业务日历，但也可以为每个定时器事件定义，单独定义业务日历。

<timerEventDefinition>...
</timerEventDefinition>

定时器定义必须且只能包含下列的一种元素：

timeDate。这个元素指定了ISO 8601格式的固定时间。在这个时间就会触发触发器。例如：

<timerEventDefinition><timeDate>2022-12-06T12:13:14</timeDate>
</timerEventDefinition>

timeDuration。要定义定时器需要等待多长时间再触发，可以用timerEventDefinition的子元素timeDuration。使用ISO 8601格式（BPMN 2.0规范要求）。例如（等待10天）：

<timerEventDefinition><timeDuration>P10D</timeDuration>
</timerEventDefinition>

timeCycle。指定重复周期，可用于周期性启动流程，或者为超期用户任务多次发送提醒。这个元素可以使用两种格式。第一种是按照ISO 8601标准定义的循环时间周期。例如（三次重复间隔，每次间隔为10小时）：

<timerEventDefinition><timeCycle >R3/PT10H</timeCycle
</timerEventDefinition>

请注意：定时器只有在异步执行器启用时才能触发（需要在flowable.cfg.xml中，将asyncExecutorActivate设置为true。因为默认情况下异步执行器都是禁用的）。

2.3 错误事件定义

<endEvent id="myErrorEndEvent"><errorEventDefinition errorRef="myError" />
</endEvent>

重要提示： BPMN错误与Java异常不是一回事。事实上，这两者毫无共同点。BPMN错误事件是建模业务异常（business exceptions）的方式。而Java异常会按它们自己的方式处理。

2.4 信号事件定义

信号事件（signal event），是引用具名信号的事件。信号是全局范围（广播）的事件，并会被传递给所有激活的处理器（等待中的流程实例/捕获信号事件 catching signal events）。

使用signalEventDefinition元素声明信号事件定义。其signalRef属性引用一个signal元素，该signal元素需要声明为definitions根元素的子元素。下面摘录一个流程，使用中间事件（intermediate event）抛出与捕获信号事件。

<definitions... ><!-- 声明信号 --><signal id="alertSignal" name="alert" /><process id="catchSignal"><intermediateThrowEvent id="throwSignalEvent" name="Alert"><!-- 信号事件定义 --><signalEventDefinition signalRef="alertSignal" /></intermediateThrowEvent>...<intermediateCatchEvent id="catchSignalEvent" name="On Alert"><!-- 信号事件定义 --><signalEventDefinition signalRef="alertSignal" /></intermediateCatchEvent>...</process>
</definitions>

两个signalEventDefinition引用同一个signal元素。

2.5 消息事件定义

消息事件（message event），是指引用具名消息的事件。消息具有名字与载荷。与信号不同，消息事件只有一个接收者。

消息事件定义使用messageEventDefinition元素声明。其messageRef属性引用一个message元素，该message元素需要声明为definitions根元素的子元素。下面摘录一个流程，声明了两个消息事件，并由开始事件与消息捕获中间事件（intermediate catching message event）引用。

<definitions id="definitions"xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"xmlns:flowable="http://flowable.org/bpmn"targetNamespace="Examples"xmlns:tns="Examples"><message id="newInvoice" name="newInvoiceMessage" /><message id="payment" name="paymentMessage" /><process id="invoiceProcess"><startEvent id="messageStart" ><messageEventDefinition messageRef="newInvoice" /></startEvent>...<intermediateCatchEvent id="paymentEvt" ><messageEventDefinition messageRef="payment" /></intermediateCatchEvent>...</process></definitions>

2.6 启动事件

启动事件（start event）是流程的起点。启动事件的类型（流程在消息到达时启动，在指定的时间间隔后启动，等等），定义了流程如何启动，并显示为启动事件中的小图标。在XML中，类型由子元素声明来定义。

启动事件随时捕获：启动事件（保持）等候，直到特定的触发器被触发。

<startEvent id="request" />

2.7 结束事件

结束事件（end event）标志着流程或子流程中一个分支的结束。结束事件总是抛出（型）事件。这意味着当流程执行到达结束事件时，会抛出一个结果。结果的类型由事件内部的黑色图标表示。在XML表示中，类型由子元素声明给出。

<endEvent id="end" name="my end event" />

2.8 边界事件

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

所有的边界事件都用相同的方式定义：

<boundaryEvent id="myBoundaryEvent" attachedToRef="theActivity"><XXXEventDefinition/>
</boundaryEvent>

边界事件由下列元素定义：

（流程范围内）唯一的标识符
由attachedToRef属性定义的，对该事件所依附的活动的引用。请注意边界事件及其所依附的活动，应定义在相同级别（也就是说，边界事件并不包含在活动内）。
定义了边界事件的类型的，形如XXXEventDefinition的XML子元素（例如TimerEventDefinition，ErrorEventDefinition，等等）。查阅特定的边界事件类型，以了解更多细节。

2.9 捕获中间事件

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

<intermediateCatchEvent id="myIntermediateCatchEvent" ><XXXEventDefinition/>
</intermediateCatchEvent>

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

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

2.10 抛出中间事件

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

<intermediateThrowEvent id="myIntermediateThrowEvent" ><XXXEventDefinition/>
</intermediateThrowEvent>

抛出中间事件由下列元素定义:

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

说明：事件大类是这十种，细分小类有31种（查看的是v6.3.0版本，更新版本可能有新的事件）。

三、顺序流

3.1 描述

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

3.2 XML表示

顺序流，用从源元素指向目标元素的箭头表示。箭头总是指向目标元素。

<sequenceFlow id="flow1" sourceRef="theStart" targetRef="theTask" />

3.3 条件顺序流

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

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

<sequenceFlow id="flow" sourceRef="theStart" targetRef="theTask"><conditionExpression xsi:type="tFormalExpression"><![CDATA[${order.price > 100 && order.price < 250}]]></conditionExpression>
</sequenceFlow>

3.4 默认顺序流

所有的BPMN 2.0任务与网关都可以使用默认顺序流（default sequence flow）。只有当没有其他顺序流可以选择时，才会选择默认顺序流作为活动的出口顺序流。流程会忽略默认顺序流上的条件。

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

<exclusiveGateway id="exclusiveGw" name="Exclusive Gateway" default="flow2" /><sequenceFlow id="flow1" sourceRef="exclusiveGw" targetRef="task1"><conditionExpression xsi:type="tFormalExpression">${conditionA}</conditionExpression>
</sequenceFlow><sequenceFlow id="flow2" sourceRef="exclusiveGw" targetRef="task2"/><sequenceFlow id="flow3" sourceRef="exclusiveGw" targetRef="task3"><conditionExpression xsi:type="tFormalExpression">${conditionB}</conditionExpression>
</sequenceFlow>

四、网关

网关（gateway）用于控制执行的流向（或者按BPMN 2.0的用词：执行的“标志（token）”）。网关可以消费（consuming）与生成（generating）标志。

4.1 排他网关

排他网关（exclusive gateway），用于对流程中的决策建模。当执行到达这个网关时，会按照所有出口顺序流定义的顺序对它们进行计算。选择第一个条件计算为true的顺序流（当没有设置条件时，认为顺序流为true）继续流程。

请注意：使用排他网关时，只会选择一条顺序流。当多条顺序流的条件都计算为true时，会且仅会选择在XML中最先定义的顺序流继续流程。如果没有可选的顺序流，会抛出异常。

<exclusiveGateway id="exclusiveGw" name="Exclusive Gateway" /><sequenceFlow id="flow2" sourceRef="exclusiveGw" targetRef="theTask1"><conditionExpression xsi:type="tFormalExpression">${input == 1}</conditionExpression>
</sequenceFlow><sequenceFlow id="flow3" sourceRef="exclusiveGw" targetRef="theTask2"><conditionExpression xsi:type="tFormalExpression">${input == 2}</conditionExpression>
</sequenceFlow><sequenceFlow id="flow4" sourceRef="exclusiveGw" targetRef="theTask3"><conditionExpression xsi:type="tFormalExpression">${input == 3}</conditionExpression>
</sequenceFlow>

4.2 并行网关

并行网关（parallel gateway），它可以将执行分支（fork）为多条路径，也可以合并（join）多条入口路径的执行。
并行网关的功能取决于其入口与出口顺序流：

分支：所有的出口顺序流都并行执行，为每一条顺序流创建一个并行执行。
合并：所有到达并行网关的并行执行都会在网关处等待，直到每一条入口顺序流都到达了有个执行。然后流程经过该合并网关继续。

请注意：并行网关不计算条件。如果连接到并行网关的顺序流上定义了条件，会直接忽略该条件。

<parallelGateway id="myParallelGateway" />

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

4.3 包容网关

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

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

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

<inclusiveGateway id="myInclusiveGateway" />

简单的理解：包容网关有着和并行网关一样的功能，多条并行执行，有合并和分叉等，然后就加上计算顺序流的条件。

4.4 基于事件的网关

基于事件的网关（event-based gateway）提供了根据事件做选择的方式。网关的每一条出口顺序流都需要连接至一个捕获中间事件。当流程执行到达基于事件的网关时，与等待状态类似，网关会暂停执行，并且为每一条出口顺序流创建一个事件订阅。

请注意：基于事件的网关的出口顺序流与一般的顺序流不同。这些顺序流从不实际执行。相反，它们用于告知流程引擎：当执行到达一个基于事件的网关时，需要订阅什么事件。有以下限制：

一个基于事件的网关，必须有两条或更多的出口顺序流。
基于事件的网关，只能连接至intermediateCatchEvent（捕获中间事件）类型的元素（Flowable不支持在基于事件的网关之后连接“接收任务 Receive Task”）。
连接至基于事件的网关的intermediateCatchEvent，必须只有一个入口顺序流。

<eventBasedGateway id="gw1" />

五、任务

任务相关的图标：

5.1 用户任务

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

<userTask id="theTask" name="Important task" />

5.2 脚本任务

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

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

<scriptTask id="theScriptTask" name="Execute script" scriptFormat="groovy"><script>sum = 0for ( i in inputArray ) {sum += i}</script>
</scriptTask>

5.3 Java服务任务

Java服务任务（Java service task）用于调用Java类。

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

指定实现了JavaDelegate或ActivityBehavior的类
调用解析为委托对象（delegation object）的表达式
调用方法表达式（method expression）
对值表达式（value expression）求值

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

<serviceTask id="javaService"name="My Java Service Task"flowable:class="org.flowable.MyJavaDelegate" />

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

<serviceTask id="serviceTask" flowable:delegateExpression="${delegateExpressionBean}" />

delegateExpressionBean是一个实现了JavaDelegate接口的bean，定义在Spring容器中。

3）使用flowable:expression属性指定需要计算的UEL方法表达式。（将在名为printer的对象上调用printMessage方法（不带参数）。）

<serviceTask id="javaService"name="My Java Service Task"flowable:expression="#{printer.printMessage()}" />

也可以为表达式中使用的方法传递变量。

<serviceTask id="javaService"name="My Java Service Task"flowable:expression="#{printer.printMessage(execution, myVar)}" />

将在名为printer的对象上调用printMessage方法。传递的第一个参数为DelegateExecution，名为execution，在表达式上下文中默认可用。传递的第二个参数，是当前执行中，名为myVar变量的值。

4）可以使用flowable:expression属性指定需要计算的UEL值表达式。

<serviceTask id="javaService"name="My Java Service Task"flowable:expression="#{split.ready}" />

会调用名为split的bean的ready参数的getter方法，getReady（不带参数）。该对象会被解析为执行的流程变量或（如果可用的话）Spring上下文中的bean。

5.4 Web服务任务

Web服务任务（Web service task）用于同步地调用外部的Web服务。
Web服务任务与Java服务任务图标一样。

5.5 业务规则任务

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

<process id="simpleBusinessRuleProcess"><startEvent id="theStart" /><sequenceFlow sourceRef="theStart" targetRef="businessRuleTask" /><businessRuleTask id="businessRuleTask" flowable:ruleVariablesInput="${order}"flowable:resultVariable="rulesOutput" /><sequenceFlow sourceRef="businessRuleTask" targetRef="theEnd" /><endEvent id="theEnd" /></process>

5.6 邮件任务

Flowable让你可以通过自动的邮件服务任务（email task），增强业务流程。可以向一个或多个收信人发送邮件，支持cc，bcc，HTML文本，等等。请注意邮件任务不是BPMN 2.0规范的“官方”任务（所以也没有专用图标）。因此，在Flowable中，邮件任务实现为一种特殊的服务任务。

下面的XML代码片段是使用邮件任务的示例。

<serviceTask id="sendMail" flowable:type="mail"><extensionElements><flowable:field name="from" stringValue="order-shipping@thecompany.com" /><flowable:field name="to" expression="${recipient}" /><flowable:field name="subject" expression="Your order ${orderId} has been shipped" /><flowable:field name="html"><flowable:expression><![CDATA[<html><body>Hello ${male ? 'Mr.' : 'Mrs.' } ${recipientName},<br/><br/>As of ${now}, your order has been <b>processed and shipped</b>.<br/><br/>Kind regards,<br/>TheCompany.</body></html>]]></flowable:expression></flowable:field></extensionElements>
</serviceTask>

5.7 Http任务

Http任务（Http task）用于发出HTTP请求，增强了Flowable的集成能力。请注意Http任务不是BPMN 2.0规范的“官方”任务（所以也没有专用图标）。因此，在Flowable中，Http任务实现为一种特殊的服务任务。

Flowable使用可配置的Http客户端发出Http请求。如果不进行设置，会使用默认配置。

下面的XML片段是使用Http任务的例子。

<serviceTask id="httpGet" flowable:type="http"><extensionElements><flowable:field name="requestMethod" stringValue="GET" /><flowable:field name="requestUrl" stringValue="http://flowable.org" /><flowable:field name="requestHeaders"><flowable:expression><![CDATA[Accept: text/htmlCache-Control: no-cache]]></flowable:expression></flowable:field><flowable:field name="requestTimeout"><flowable:expression><![CDATA[${requestTimeout}]]></flowable:expression></flowable:field><flowable:field name="resultVariablePrefix"><flowable:string>task7</flowable:string></flowable:field></extensionElements>
</serviceTask>

5.8 Mule任务

Mule任务可以向Mule发送消息，增强Flowable的集成特性。请注意Mule任务不是BPMN 2.0规范的“官方”任务（所以也没有专用图标）。因此，在Flowable中，Mule任务实现为一种特殊的服务任务。

下面的XML代码片段是使用Mule任务的例子。

<extensionElements><flowable:field name="endpointUrl"><flowable:string>vm://in</flowable:string></flowable:field><flowable:field name="language"><flowable:string>juel</flowable:string></flowable:field><flowable:field name="payloadExpression"><flowable:string>"hi"</flowable:string></flowable:field><flowable:field name="resultVariable"><flowable:string>theVariable</flowable:string></flowable:field>
</extensionElements>

5.9 Camel任务

Camel任务（Camel task）可以向Camel发送消息，增强Flowable的集成特性。请注意Camel任务不是BPMN 2.0规范的“官方”任务（所以也没有专用图标）。因此，在Flowable中，Camel任务实现为一种特殊的服务任务。还请注意，需要在项目中包含Flowable Camel模块才能使用Camel任务。

Camel任务实现为特殊的服务任务，将服务任务的type定义为’camel’进行设置。

<serviceTask id="sendCamel" flowable:type="camel">

5.10 手动任务

手动任务（manual task）定义在BPM引擎之外的任务。它用于建模引擎不需要了解，也不需要提供系统或用户界面的工作。对于引擎来说，手动任务将按直接穿过活动处理，在流程执行到达手动任务时，自动继续执行流程。

<manualTask id="myManualTask" name="Call client for more information" />

5.11 Java接收任务

接收任务（receive task），是等待特定消息到达的简单任务。目前，我们只为这个任务实现了Java语义。当流程执行到达接收任务时，流程状态将提交至持久化存储。这意味着流程将保持等待状态，直到引擎接收到特定的消息，触发流程穿过接收任务继续执行。

<receiveTask id="waitState" name="wait" />

要使流程实例从接收任务的等待状态中继续执行，需要使用到达接收任务的执行id，调用runtimeService.signal(executionId)。下面的代码片段展示了如何操作：

ProcessInstance pi = runtimeService.startProcessInstanceByKey("receiveTask");
Execution execution = runtimeService.createExecutionQuery().processInstanceId(pi.getId()).activityId("waitState").singleResult();
assertNotNull(execution);runtimeService.trigger(execution.getId());

5.12 Shell任务

Shell任务（Shell task）可以运行Shell脚本与命令。请注意Shell任务不是BPMN 2.0规范的“官方”任务（因此也没有专用图标）。

<serviceTask id="shellEcho" flowable:type="shell">

下面的XML代码片段是使用Shell任务的例子。

<serviceTask id="shellEcho" flowable:type="shell" ><extensionElements><flowable:field name="command" stringValue="cmd" /><flowable:field name="arg1" stringValue="/c" /><flowable:field name="arg2" stringValue="echo" /><flowable:field name="arg3" stringValue="EchoTest" /><flowable:field name="wait" stringValue="true" /><flowable:field name="outputVariable" stringValue="resultVar" /></extensionElements>
</serviceTask>

5.13 执行监听器

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

流程实例的启动和结束。
流程执行转移。
活动的启动和结束。
网关的启动和结束。
中间事件的启动和结束。
启动事件的结束，和结束事件的启动。

5.14 任务监听器

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

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

<userTask id="myTask" name="My Task" ><extensionElements><flowable:taskListener event="create" class="org.flowable.MyTaskCreateListener" /></extensionElements>
</userTask>

5.15 多实例（for each）

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

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

网关与事件不能设置为多实例。

按照BPMN2.0规范的要求，用于为每个实例创建执行的父执行，会提供下列变量：

nrOfInstances：实例总数。
nrOfActiveInstances：当前活动的（即未完成的），实例数量。对于顺序多实例，这个值总为1。
nrOfCompletedInstances：已完成的实例数量。

可以调用execution.getVariable(x)方法获取这些值。

另外，每个被创建的执行，都有局部变量（对其他执行不可见，也不存储在流程实例级别）：

loopCounter：给定实例在for-each循环中的index。可以通过Flowable的elementIndexVariable属性为loopCounter变量重命名。

XML示例：

<userTask id="miTasks" name="My Task" flowable:assignee="${assignee}"><multiInstanceLoopCharacteristics isSequential="true"flowable:collection="${myService.resolveUsersForTask()}" flowable:elementVariable="assignee" ></multiInstanceLoopCharacteristics>
</userTask>

5.16 补偿处理器

如果要使用一个活动补偿另一个活动的影响，可以将其声明为补偿处理器（compensation handler）。补偿处理器不在正常流程中执行，而只在流程抛出补偿事件时才会执行。

补偿处理器不得有入口或出口顺序流。

补偿处理器必须通过单向的连接，关联一个补偿边界事件。

要将一个活动声明为补偿处理器，需要将isForCompensation属性设置为true：

<serviceTask id="undoBookHotel" isForCompensation="true" flowable:class="...">
</serviceTask>

六、子流程与调用活动

6.1 子流程

子流程（sub-process）是包含其他的活动、网关、事件等的活动。其本身构成一个流程，并作为更大流程的一部分。子流程完全在父流程中定义。

子流程有两个主要的使用场景：

子流程可以分层建模。子流程可以分层建模。很多建模工具都可以折叠子流程，隐藏子流程的所有细节，而只显示业务流程的高层端到端总览。
子流程会创建新的事件范围。在子流程执行中抛出的事件可以通过子流程边界上的边界事件捕获，为该事件创建了限制在子流程内的范围。
使用子流程也要注意以下几点：
子流程只能有一个空启动事件，而不允许有其他类型的启动事件。请注意BPMN 2.0规范允许省略子流程的启动与结束事件，但目前Flowable的实现尚不支持省略。
顺序流不能跨越子流程边界。

<subProcess id="subProcess"><startEvent id="subProcessStart" />... 其他子流程元素 ...<endEvent id="subProcessEnd" /></subProcess>

6.2 事件子流程

事件子流程（event sub-process）是BPMN 2.0新定义的。事件子流程是通过事件触发的子流程。可以在流程级别，或者任何子流程级别，添加事件子流程。用于触发事件子流程的事件，使用启动事件进行配置。因此可知，不能在事件子流程中使用空启动事件。事件子流程可以通过消息事件、错误事件、信号时间、定时器事件或补偿事件等触发。在事件子流程的宿主范围（流程实例或子流程）创建时，创建对启动事件的订阅。当该范围销毁时，删除订阅。

事件子流程可以是中断或不中断的。中断的子流程将取消当前范围内的任何执行。非中断的事件子流程将创建新的并行执行。宿主范围内的每个活动，只能触发一个中断事件子流程，而非中断事件子流程可以多次触发。子流程是否是中断的，通过触发事件子流程的启动事件配置。

事件子流程不能有任何入口或出口顺序流。事件子流程是由事件触发的，因此入口顺序流不合逻辑。当事件子流程结束时，要么同时结束当前范围（中断事件子流程的情况），要么是非中断子流程创建的并行执行结束。

目前的限制：

Flowable支持错误、定时器、信号与消息启动事件触发事件子流程。

事件子流程的XML表示形式与嵌入式子流程相同。但需要将triggeredByEvent属性设置为true：

<subProcess id="eventSubProcess" triggeredByEvent="true">...
</subProcess>

6.3 事务子流程

事务子流程（transaction sub-process）是一种嵌入式子流程，用于将多个活动组织在一个事务里。事务是工作的逻辑单元，可以组织一组独立活动，使得它们可以一起成功或失败。

事务子流程表示为带有两层边框的嵌入式子流程。

<transaction id="myTransaction" >...
</transaction>

6.4 调用活动（子流程）

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

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

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

<callActivity id="callCheckCreditProcess" name="Check credit" calledElement="checkCreditProcess" />

七、自定义扩展

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:命名空间前缀。

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

【参考文献】
Flowable 6.3.0中文用户手册

小白学流程引擎-FLowable(五) — BPMN2.0模型规范相关推荐

小白学流程引擎-FLowable(一) —FLowable是什么
小白学流程引擎-FLowable(一) | FLowable是什么一.什么是流程引擎? 通俗的说,流程引擎就是多种业务对象在一起合作完成某件事情的步骤,把步骤变成计算机能理解的形式就是流程引擎. 流 ...
Spring Boot 整合流程引擎 Flowable，so easy
为啥想写 flowable 呢?原因很简单,因为最近在录的 tienchin 项目视频会用到,先写一篇文章和大家打打预防针,后面视频再细讲. 流程引擎,也算是一个比较常见的工具了,我们在日常的很多开发 ...
【小白学PyTorch】扩展之Tensorflow2.0 | 20 TF2的eager模式与求导
[机器学习炼丹术]的学习笔记分享 <<小白学PyTorch>> 扩展之Tensorflow2.0 | 19 TF2模型的存储与载入扩展之Tensorflow2.0 | 18 ...
整理流程引擎Flowable的前端流程设计器Modeler
1.Flowable Modeler 官方提供的设计器,不是基于vue,另外拆分整合困难. 2.bpmn-js GitHub地址:https://github.com/bpmn-io/bpmn-js ...
Spring Boot 整合流程引擎 Flowable（附源码地址）
一.导入依赖 flowable依赖: <dependency><groupId>org.flowable</groupId><artifactId>fl ...
【小白学PyTorch】扩展之Tensorflow2.0 | 21 Keras的API详解（下）池化、Normalization
<<小白学PyTorch>> 扩展之Tensorflow2.0 | 21 Keras的API详解(上)卷积.激活.初始化.正则扩展之Tensorflow2.0 | 20 TF ...
【小白学PyTorch】扩展之Tensorflow2.0 | 21 Keras的API详解（上）卷积、激活、初始化、正则...
[机器学习炼丹术]的学习笔记分享 <<小白学PyTorch>> 扩展之Tensorflow2.0 | 20 TF2的eager模式与求导扩展之Tensorflow2.0 | ...
【小白学PyTorch】18.TF2构建自定义模型
[机器学习炼丹术]的学习笔记分享 <<小白学PyTorch>> 扩展之Tensorflow2.0 | 17 TFrec文件的创建与读取扩展之Tensorflow2.0 | 1 ...
BPMN2.0规范及流程引擎选型方案
BPMN2.0规范及流程引擎选型方案一.基本概念二.BPMN意义三.主要元素 3.1 活动任务子流程调用活动事件子流程事务 3.2 网关排他网关包容网关并行网关事件网关复杂网 ...

小白学流程引擎-FLowable(五) — BPMN2.0模型规范