一、启动事件

1.1、空启动事件

图示：

描述： “空”启动事件（none Start Event），指的是未指定启动流程实例触发器的启动事件。引擎将无法预知何时启动流程实例。

注意：子流程（sub-process）必须有空启动事件。

代码示例：

java:
ProcessInstance processInstance = runtimeService.startProcessInstanceByXXX();

xml:

<startEvent id="start" name="my start event" />

<!--formKey: 引用表单定义，用户需要在启动新流程实例时填写该表单-->
<startEvent id="request" flowable:formKey="request" />

1.2、定时器启动事件

图示：（modeler上为计时器事件）

描述：定时器启动事件（timer start event）在指定时间创建流程实例。在流程只需要启动一次，或者流程需要在特定的时间间隔重复启动时，都可以使用。

注意：流程不能有定时器启动事件。定时器启动事件，在流程部署的同时就开始计时。不需要调用startProcessInstanceByXXX就会在时间启动。调用startProcessInstanceByXXX时会在定时启动之外额外启动一个流程。当部署带有定时器启动事件的流程的更新版本时，上一版本的定时器作业会被移除。这是因为通常并不希望旧版本的流程仍然自动启动新的流程实例。

代码示例：

<!--示例：流程会启动4次，间隔5分钟，从2011年11月11日，12:13开始-->
<startEvent id="theStart">
  <timerEventDefinition>
    <timeCycle>R4/2021-11-11T12:13/PT5M</timeCycle>
  </timerEventDefinition>
</startEvent>

<!--示例：流程会在设定的时间启动一次-->
<startEvent id="theStart">
  <timerEventDefinition>
    <timeDate>2021-11-11T12:13:14</timeDate>
  </timerEventDefinition>
</startEvent>

1.3、消息启动事件

图示：

描述：消息启动事件（message start event）使用具名消息启动流程实例。消息名用于选择正确的启动事件。

注意：当部署具有一个或多个消息启动事件的流程定义时，会做如下判断：

给定流程定义中，消息启动事件的名字必须是唯一的。一个流程定义不得包含多个同名的消息启动事件。如果流程定义中有两个或多个消息启动事件引用同一个消息，或者两个或多个消息启动事件引用了具有相同消息名字的消息，则Flowable会在部署这个流程定义时抛出异常。
在所有已部署的流程定义中，消息启动事件的名字必须是唯一的。如果在流程定义中，一个或多个消息启动事件引用了已经部署的另一流程定义中消息启动事件的消息名，则Flowable会在部署这个流程定义时抛出异常。
流程版本：在部署流程定义的新版本时，会取消上一版本的消息订阅，即使新版本中并没有这个消息事件）。

在启动流程实例时，可以使用下列RuntimeService中的方法，触发消息启动事件：

ProcessInstance startProcessInstanceByMessage(String messageName);
ProcessInstance startProcessInstanceByMessage(String messageName, Map<String, Object> processVariables);
ProcessInstance startProcessInstanceByMessage(String messageName, String businessKey, Map<String, Object< processVariables);

messageName是由message元素的name属性给定的名字。messageEventDefinition的messageRef属性会引用message元素。当启动流程实例时，会做如下判断：

只有顶层流程（top-level process）才支持消息启动事件。嵌入式子流程不支持消息启动事件。
如果一个流程定义中有多个消息启动事件，可以使用runtimeService.startProcessInstanceByMessage(…)选择合适的启动事件。
如果一个流程定义中有多个消息启动事件与一个空启动事件，则runtimeService.startProcessInstanceByKey(…)与runtimeService.startProcessInstanceById(…)会使用空启动事件启动流程实例。
如果一个流程定义中有多个消息启动事件而没有空启动事件，则runtimeService.startProcessInstanceByKey(…)与runtimeService.startProcessInstanceById(…)会抛出异常。
如果一个流程定义中只有一个消息启动事件，则runtimeService.startProcessInstanceByKey(…)与runtimeService.startProcessInstanceById(…)会使用这个消息启动事件启动新流程实例。
如果流程由调用活动（call activity）启动，则只有在下列情况下才支持消息启动事件
- 除了消息启动事件之外，流程还有唯一的空启动事件
- 或者流程只有唯一的消息启动事件，而没有其他启动事件。

代码示例：

<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" />

  <process id="invoiceProcess">

    <startEvent id="messageStart" >
    	<messageEventDefinition messageRef="tns:newInvoice" />
    </startEvent>
    ...
  </process>

</definitions>

1.4、信号启动事件

图示：

描述：信号启动事件（signal start event），使用具名信号启动流程实例。这个信号可以由流程实例中的信号抛出中间事件（intermediary signal throw event），或者API（runtimeService.signalEventReceivedXXX方法）触发。两种方式都会启动所有拥有相同名字信号启动事件的流程定义。

注意：可以选择异步还是同步启动流程实例。需要为API传递的signalName，是由signal元素的name属性决定的名字。signal元素由signalEventDefinition的signalRef属性引用

代码示例：

<signal id="theSignal" name="The Signal" />

<process id="processWithSignalStart1">
  <startEvent id="theStart">
    <signalEventDefinition id="theSignalEventDefinition" signalRef="theSignal"  />
  </startEvent>
  <sequenceFlow id="flow1" sourceRef="theStart" targetRef="theTask" />
  <userTask id="theTask" name="Task in process A" />
  <sequenceFlow id="flow2" sourceRef="theTask" targetRef="theEnd" />
  <endEvent id="theEnd" />
</process>

1.6、错误启动事件

图示：

描述：错误启动事件（error start event），可用于触发事件子流程（Event Sub-Process）。错误启动事件不能用于启动流程实例。

注意：错误启动事件总是中断。

代码示例：

<!--ref 是引用一个任务事件-->
<startEvent id="messageStart" >
	<errorEventDefinition errorRef="someError" />
</startEvent>

二、结束事件

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

2.1、空结束事件

图示：

描述：“空”结束事件(none end event)，意味着当到达这个事件时，没有特别指定抛出的结果。因此，引擎除了结束当前执行分支之外，不会多做任何事情。

代码示例：

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

2.2、错误结束事件

图示：

描述：当流程执行到达错误结束事件（error end event）时，结束执行的当前分支，并抛出错误。这个错误可以由匹配的错误边界中间事件捕获。如果找不到匹配的错误边界事件，将会抛出异常。

代码示例：

<!--error的errorCode用于查找匹配的错误捕获边界事件。
如果errorRef不匹配任何已定义的error，则该errorRef会用做errorCode的快捷方式。
这个快捷方式是Flowable特有的。-->


<error id="myError" errorCode="error123" />
...
<process id="myProcess">
...
<endEvent id="myErrorEndEvent">
  <errorEventDefinition errorRef="myError" />
</endEvent>
...

2.3、终止结束事件

图示：

描述：当到达终止结束事件（terminate end event）时，当前的流程实例或子流程会被终止。也就是说，当执行到达终止结束事件时，会判断第一个范围 scope（流程或子流程）并终止它。请注意在BPMN 2.0中，子流程可以是嵌入式子流程，调用活动，事件子流程，或事务子流程。有一条通用规则：当存在多实例的调用过程或嵌入式子流程时，只会终止一个实例，其他的实例与流程实例不会受影响。

可以添加一个可选属性terminateAll。当其为true时，无论该终止结束事件在流程定义中的位置，也无论它是否在子流程（甚至是嵌套子流程）中，都会终止（根）流程实例。

代码示例：

<!--终止结束事件，表示为结束事件，加上terminateEventDefinition子元素。
请注意terminateAll属性是可选的（默认为false）。-->

<endEvent id="myEndEvent >
  <terminateEventDefinition flowable:terminateAll="true"></terminateEventDefinition>
</endEvent>

2.4、取消结束事件

图示：

描述：取消结束事件（cancel end event）只能与BPMN事务子流程（BPMN transaction subprocess）一起使用。当到达取消结束事件时，会抛出取消事件，且必须由取消边界事件（cancel boundary event）捕获。取消边界事件将取消事务，并触发补偿（compensation）。

代码示例：

<endEvent id="myCancelEndEvent">
  <cancelEventDefinition />
</endEvent>

三、边界事件

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

<!-- 所有的边界事件都用相同的方式定义 -->
<boundaryEvent id="myBoundaryEvent" attachedToRef="theActivity">
      <XXXEventDefinition/>
</boundaryEvent>

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

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

3.1、定时器边界事件

边界事件问题：

所有类型的边界事件，都有一个关于并发的已知问题：不能在边界事件上附加多个出口顺序流。这个问题的解决方案，是使用一条出口顺序流，指向并行网关。

图示：（按照上续说明这个图应该是错误的。）

描述：定时器边界事件（timer boundary event）的行为像是跑表与闹钟。当执行到达边界事件所依附的活动时，将启动定时器。当定时器触发时（例如在特定时间间隔后），可以中断活动，并沿着边界事件的出口顺序流继续执行。

代码示例：

<!--定时器边界事件与一般边界事件一样定义。其中类型子元素为timerEventDefinition元素。
<boundaryEvent id="escalationTimer" cancelActivity="true" attachedToRef="firstLineSupport">
  <timerEventDefinition>
    <timeDuration>PT4H</timeDuration>
  </timerEventDefinition>
</boundaryEvent>

示例二：

边界事件问题：

图示:

描述：中断与非中断定时器事件是不同的。非中断意味着最初的活动不会被中断，而会保持原样。默认为中断行为。在XML表示中，cancelActivity属性设置为false。

一个典型使用场景，是在一段时间之后发送提醒邮件，但不影响正常的流程流向。

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

代码示例：

<boundaryEvent id="escalationTimer" cancelActivity="false" attachedToRef="firstLineSupport"/>

3.2、错误边界事件

图示：

描述：在活动边界上的错误捕获中间（事件），或简称错误边界事件（error boundary event），捕获其所依附的活动范围内抛出的错误。

在嵌入式子流程或者调用活动上定义错误边界事件最有意义，因为子流程的范围会包括其中的所有活动。错误可以由错误结束事件抛出。这样的错误会逐层向其上级父范围传播，直到在范围内找到一个匹配错误事件定义的错误边界事件。

当捕获错误事件时，会销毁边界事件定义所在的活动，同时销毁其中所有的当前执行（例如，并行活动，嵌套子流程，等等）。流程执行将沿着边界事件的出口顺序流继续。

代码示例：

<error id="myError" errorCode="123" />
...
<process id="myProcess">
...

<boundaryEvent id="catchError" attachedToRef="mySubProcess">
  <errorEventDefinition errorRef="myError"/>
</boundaryEvent>

注意：

errorCode用于匹配捕获的错误：

如果省略了errorRef，错误边界事件会捕获所有错误事件，无论error的errorCode是什么。
如果提供了errorRef，并且其引用了存在的error，则边界事件只会捕获相同错误代码的错误。
如果提供了errorRef，但BPMN 2.0文件中没有定义error，则errorRef会用作errorCode（与错误结束事件类似）。

示例：

下面的示例流程展示了如何使用错误结束事件。当'Review profitability (审核盈利能力)'用户任务完成，并指出提供的信息不足时，会抛出错误。当这个错误被子流程边界捕获时，'Review sales lead (审核销售线索)'子流程中的所有运行中活动都会被销毁（即使'Review customer rating 审核客户等级'还没有完成），并会创建'Provide additional details (提供更多信息)'用户任务。

3.3、信号边界事件

图示：

描述：依附在活动边界上的信号捕获中间（事件），或简称信号边界事件（signal boundary event），捕获与其信号定义具有相同名称的信号。

请注意：与其他事件例如错误边界事件不同的是，信号边界事件不只是捕获其所依附范围抛出的信号。信号边界事件为全局范围（广播）的，意味着信号可以从任何地方抛出，甚至可以是不同的流程实例。

与其他事件（如错误事件）不同，信号在被捕获后不会被消耗。如果有两个激活的信号边界事件，捕获相同的信号事件，则两个边界事件都会被触发，哪怕它们不在同一个流程实例里。

代码示例：

<boundaryEvent id="boundary" attachedToRef="task" cancelActivity="true">
    <signalEventDefinition signalRef="alertSignal"/>
</boundaryEvent>

3.4、信号边界事件

图示：（据说还有一个非中断型的消息边界事件，我在modeler上没找到。）

描述：在活动边界上的消息捕获中间（事件），或简称消息边界事件（message boundary event），捕获与其消息定义具有相同消息名的消息。

代码示例：

<boundaryEvent id="boundary" attachedToRef="task" cancelActivity="true">
    <messageEventDefinition messageRef="newCustomerMessage"/>
</boundaryEvent>

3.5、取消边界事件

图示：

描述：依附在事务子流程边界上的取消捕获中间事件，或简称取消边界事件（cancel boundary event），在事务取消时触发。当取消边界事件触发时，首先会中断当前范围的所有活动执行。接下来，启动事务范围内所有有效的的补偿边界事件（compensation boundary event）。补偿会同步执行，也就是说在离开事务前，边界事件会等待补偿完成。当补偿完成时，沿取消边界事件的任何出口顺序流离开事务子流程。

注意：一个事务子流程只允许使用一个取消边界事件。

如果事务子流程中有嵌套的子流程，只会对成功完成的子流程触发补偿。

如果取消边界事件放置在具有多实例特性的事务子流程上，如果一个实例触发了取消，则边界事件将取消所有实例。

代码示例：

<!--因为取消边界事件总是中断型的，因此没有cancelActivity属性。-->

<boundaryEvent id="boundary" attachedToRef="transaction" >
    <cancelEventDefinition />
</boundaryEvent>

3.5、补偿边界事件

图示：

描述：依附在活动边界上的补偿捕获中间（事件），或简称补偿边界事件（compensation boundary event），可以为活动附加补偿处理器。

补偿边界事件必须使用直接关联的方式引用单个的补偿处理器。

补偿边界事件与其它边界事件的活动策略不同。其它边界事件，例如信号边界事件，在其依附的活动启动时激活；当该活动结束时会被解除，并取消相应的事件订阅。而补偿边界事件不是这样。补偿边界事件在其依附的活动成功完成时激活，同时创建补偿事件的相应订阅。当补偿事件被触发，或者相应的流程实例结束时，才会移除订阅。请考虑下列因素：

当补偿被触发时，会调用补偿边界事件关联的补偿处理器。调用次数与其依附的活动成功完成的次数相同。
如果补偿边界事件依附在具有多实例特性的活动上，则会为每一个实例创建补偿事件订阅。
如果补偿边界事件依附在位于循环内部的活动上，则每次该活动执行时，都会创建一个补偿事件订阅。
如果流程实例结束，则取消补偿事件的订阅。

注意：嵌入式子流程不支持补偿边界事件。

代码示例：

<!--因为取消边界事件总是中断型的，因此没有cancelActivity属性。-->

<boundaryEvent id="boundary" attachedToRef="transaction" >
    <cancelEventDefinition />
</boundaryEvent>

四、捕获中间事件

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

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

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

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

4.1、定时器捕获中间事件

图示

描述：定时器捕获中间事件（timer intermediate catching event）的行为像是跑表。当执行到达捕获事件时，启动定时器；当定时器触发时（例如在一段时间间隔后），沿定时器中间事件的出口顺序流继续执行。

代码示例：

<intermediateCatchEvent id="timer">
  <timerEventDefinition>
    <timeDuration>PT5M</timeDuration>
  </timerEventDefinition>
</intermediateCatchEvent>

4.2、信号捕获中间事件

图示

描述：信号捕获中间事件（signal intermediate catching event），捕获与其引用的信号定义具有相同信号名称的信号。

注意：与其他事件如错误事件不同，信号在被捕获后不会被消耗。如果有两个激活的信号中间事件，捕获相同的信号事件，则两个中间事件都会被触发，哪怕它们不在同一个流程实例里

代码示例：

<intermediateCatchEvent id="signal">
  <signalEventDefinition signalRef="newCustomerSignal" />
</intermediateCatchEvent>

4.3、消息捕获中间事件

图示

描述：消息捕获中间事件（message intermediate catching event），捕获特定名字的消息。

代码示例：

<intermediateCatchEvent id="message">
  <messageEventDefinition signalRef="newCustomerMessage" />
</intermediateCatchEvent>

5、抛出中间事件

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

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

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

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

5.1、空抛出中间事件

图示：下面的流程图展示了空抛出中间事件（intermediate throwing none event）的简单例子。其用于指示流程已经到达了某种状态。

你也可以添加一些自己的代码，将部分事件发送给你的BAM（Business Activity Monitoring 业务活动监控）工具，或者DWH（Data Warehouse 数据仓库）。在这种情况下，引擎本身不会做任何事情，只是从中穿过。

<!--添加一个执行监听器后，空中间事件就可以成为很好的监视某些KPI（Key Performance Indicators 关键绩效指标）的钩子-->

<intermediateThrowEvent id="noneEvent">
  <extensionElements>
    <flowable:executionListener class="org.flowable.engine.test.bpmn.event.IntermediateNoneEventTest$MyExecutionListener" event="start" />
  </extensionElements>
</intermediateThrowEvent>

5.2、信号抛出中间事件

图示：

描述：信号抛出中间事件（signal intermediate throwing event），抛出所定义信号的信号事件。

在Flowable中，信号会广播至所有的激活的处理器（也就是说，所有的信号捕获事件）。可以同步或异步地发布信号。

在默认配置中，信号同步地传递。这意味着抛出信号的流程实例会等待，直到信号传递至所有的捕获信号的流程实例。所有的捕获流程实例也会在与抛出流程实例相同的事务中，也就是说如果收到通知的流程实例中，有一个实例产生了技术错误（抛出异常），则所有相关的实例都会失败。
信号也可以异步地传递。这是由到达抛出信号事件时的发送处理器来决定的。对于每个激活的处理器，JobExecutor会为其存储并传递一个异步通知消息(asynchronous notification message),即作业（Job）。

<!--同步信号事件-->

<intermediateThrowEvent id="signal">
  <signalEventDefinition signalRef="newCustomerSignal" />
</intermediateThrowEvent>

<!--异步信号事件-->

<intermediateThrowEvent id="signal">
  <signalEventDefinition signalRef="newCustomerSignal" flowable:async="true" />
</intermediateThrowEvent>

5.3、补偿抛出中间事件

图示：

(此文档参考flowable6.3.0 Modeler使用6.5.0 查看无此事件不知道是不是被删除了。)

描述：补偿抛出中间事件（compensation intermediate throwing event）用于触发补偿。

触发补偿：既可以为设计的活动触发补偿，也可以为补偿事件所在的范围触发补偿。补偿由活动所关联的补偿处理器执行。

活动抛出补偿时，活动关联的补偿处理器将执行的次数，为活动成功完成的次数。
抛出补偿时，当前范围中所有的活动，包括并行分支上的活动都会被补偿。
补偿分层触发：如果将要被补偿的活动是一个子流程，则该子流程中所有的活动都会触发补偿。如果该子流程有嵌套的活动，则会递归地抛出补偿。然而，补偿不会传播至流程的上层：如果子流程中触发了补偿，该补偿不会传播至子流程范围外的活动。BPMN规范指出，对“与子流程在相同级别”的活动触发补偿。
在Flowable中，补偿按照执行的相反顺序运行。这意味着最后完成的活动会第一个补偿。
可以使用补偿抛出中间事件补偿已经成功完成的事务子流程。

注意：如果抛出补偿的范围中有一个子流程，而该子流程包含有关联了补偿处理器的活动，则当抛出补偿时，只有该子流程成功完成时，补偿才会传播至该子流程。如果子流程内嵌套的部分活动已经完成，并附加了补偿处理器，但包含这些活动的子流程还没有完成，则这些补偿处理器仍不会执行。

<!--同步信号事件-->

<intermediateThrowEvent id="signal">
  <signalEventDefinition signalRef="newCustomerSignal" />
</intermediateThrowEvent>

<!--异步信号事件-->

<intermediateThrowEvent id="signal">
  <signalEventDefinition signalRef="newCustomerSignal" flowable:async="true" />
</intermediateThrowEvent>

6、顺序流

图示

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

代码示例

<!--顺序流需要有流程唯一的id，并引用存在的源与目标元素。 -->
<sequenceFlow id="flow1" sourceRef="theStart" targetRef="theTask" />

6.1、条件顺序流

描述：在顺序流上可以定义条件（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>

目前conditionalExpressions只能使用UEL。详细信息可以在表达式章节找到。使用的表达式需要能解析为boolean值，否则当计算条件时会抛出异常。

<!--通过典型的JavaBean的方式，使用getter引用流程变量的数据。-->
<conditionExpression xsi:type="tFormalExpression">
  <![CDATA[${order.price > 100 && order.price < 250}]]>
</conditionExpression>

<!--通过典型的JavaBean的方式，使用getter引用流程变量的数据。-->

<conditionExpression xsi:type="tFormalExpression">
  <![CDATA[${order.isStandardOrder()}]]>
</conditionExpression>

6.2、默认顺序流

描述：所有的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>

7、网关

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

网关用其中带有图标的菱形表示。该图标显示了网关的类型。

7.1、排他网关

图示

描述：排他网关（exclusive gateway）（也叫异或网关 XOR gateway，或者更专业的，基于数据的排他网关 exclusive data-based gateway），用于对流程中的决策建模。当执行到达这个网关时，会按照所有出口顺序流定义的顺序对它们进行计算。选择第一个条件计算为true的顺序流（当没有设置条件时，认为顺序流为true）继续流程。

注意：这里出口顺序流的含义与BPMN 2.0中的一般情况不一样。一般情况下，会选择所有条件计算为true的顺序流，并行执行。而使用排他网关时，只会选择一条顺序流。当多条顺序流的条件都计算为true时，会且仅会选择在XML中最先定义的顺序流继续流程。如果没有可选的顺序流，会抛出异常。

排他网关的XML表示格式很简洁：一行定义网关的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>

7.2、并行网关

图示

描述：网关也可以建模流程中的并行执行。在流程模型中引入并行的最简单的网关，就是并行网关（parallel gateway）。它可以将执行分支（fork）为多条路径，也可以合并（join）多条入口路径的执行。

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

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

请注意，如果并行网关同时具有多条入口与出口顺序流，可以同时具有分支与合并的行为。在这种情况下，网关首先合并所有入口顺序流，然后分裂为多条并行执行路径。

与其他网关类型有一个重要区别：并行网关不计算条件。如果连接到并行网关的顺序流上定义了条件，会直接忽略该条件。

代码示例

<!--定义并行网关只需要一行XML-->
<parallelGateway id="myParallelGateway" />


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

例如，上面的模型表示为下面的XML-->

<startEvent id="theStart" />
<sequenceFlow id="flow1" sourceRef="theStart" targetRef="fork" />

<parallelGateway id="fork" />
<sequenceFlow sourceRef="fork" targetRef="receivePayment" />
<sequenceFlow sourceRef="fork" targetRef="shipOrder" />

<userTask id="receivePayment" name="Receive Payment" />
<sequenceFlow sourceRef="receivePayment" targetRef="join" />

<userTask id="shipOrder" name="Ship Order" />
<sequenceFlow sourceRef="shipOrder" targetRef="join" />

<parallelGateway id="join" />
<sequenceFlow sourceRef="join" targetRef="archiveOrder" />

<userTask id="archiveOrder" name="Archive Order" />
<sequenceFlow sourceRef="archiveOrder" targetRef="theEnd" />

<endEvent id="theEnd" />

在上面的例子中，当流程启动后会创建两个任务：

ProcessInstance pi = runtimeService.startProcessInstanceByKey("forkJoin");
TaskQuery query = taskService.createTaskQuery()
    .processInstanceId(pi.getId())
    .orderByTaskName()
    .asc();

List<Task> tasks = query.list();
assertEquals(2, tasks.size());

Task task1 = tasks.get(0);
assertEquals("Receive Payment", task1.getName());
Task task2 = tasks.get(1);
assertEquals("Ship Order", task2.getName());

注意：

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

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

7.3、包容网关

图示：

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

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

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

请注意，如果包容网关同时具有多条入口与出口顺序流，可以同时具有分支与合并的行为。在这种情况下，网关首先合并所有具有流程标志的入口顺序流，然后为每一个条件计算为true的出口顺序流分裂出并行执行路径。包容网关的汇聚行为比并行网关更复杂。所有到达包容网关的并行执行，都会在网关等待，直到所有“可以到达”包容网关的执行都“到达”包容网关。判断方法为：计算当前流程实例中的所有执行，检查从其位置是否有一条到达包容网关的路径（忽略顺序流上的任何条件）。如果存在这样的执行（可到达但尚未到达），则不会触发包容网关的汇聚行为。

<!--定义包容网关只需要一行XML-->
<inclusiveGateway id="myInclusiveGateway" />



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

<startEvent id="theStart" />
<sequenceFlow id="flow1" sourceRef="theStart" targetRef="fork" />

<inclusiveGateway id="fork" />
<sequenceFlow sourceRef="fork" targetRef="receivePayment" >
  <conditionExpression xsi:type="tFormalExpression">${paymentReceived == false}</conditionExpression>
</sequenceFlow>
<sequenceFlow sourceRef="fork" targetRef="shipOrder" >
  <conditionExpression xsi:type="tFormalExpression">${shipOrder == true}</conditionExpression>
</sequenceFlow>

<userTask id="receivePayment" name="Receive Payment" />
<sequenceFlow sourceRef="receivePayment" targetRef="join" />

<userTask id="shipOrder" name="Ship Order" />
<sequenceFlow sourceRef="shipOrder" targetRef="join" />

<inclusiveGateway id="join" />
<sequenceFlow sourceRef="join" targetRef="archiveOrder" />

<userTask id="archiveOrder" name="Archive Order" />
<sequenceFlow sourceRef="archiveOrder" targetRef="theEnd" />

<endEvent id="theEnd" />

在上面的例子中，当流程启动后，如果流程变量paymentReceived == false且shipOrder == true，会创建两个任务。如果只有一个流程变量等于true，则只会创建一个任务。如果没有条件计算为true，会抛出异常（可通过指定默出口顺序流避免）。在下面的例子中，只会创建ship order（传递订单）一个任务

HashMap<String, Object> variableMap = new HashMap<String, Object>();
variableMap.put("receivedPayment", true);
variableMap.put("shipOrder", true);

ProcessInstance pi = runtimeService.startProcessInstanceByKey("forkJoin");

TaskQuery query = taskService.createTaskQuery()
    .processInstanceId(pi.getId())
    .orderByTaskName()
    .asc();

List<Task> tasks = query.list();
assertEquals(1, tasks.size());

Task task = tasks.get(0);
assertEquals("Ship Order", task.getName());

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

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

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

7.4、基于事件的网关

图示：下面是一个带有基于事件的网关的示例流程。当执行到达基于事件的网关时，流程执行暂停。流程实例订阅alert信号事件，并创建一个10分钟后触发的定时器。流程引擎会等待10分钟，并同时等待信号事件。如果信号在10分钟内触发，则会取消定时器，流程沿着信号继续执行，激活Handle alert用户任务。如果10分钟内没有触发信号，则会继续执行，并取消信号订阅。

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

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

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

代码示例：

<definitions id="definitions"
	xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
	xmlns:flowable="http://flowable.org/bpmn"
	targetNamespace="Examples">

    <signal id="alertSignal" name="alert" />

    <process id="catchSignal">

        <startEvent id="start" />

        <sequenceFlow sourceRef="start" targetRef="gw1" />

        <eventBasedGateway id="gw1" />

        <sequenceFlow sourceRef="gw1" targetRef="signalEvent" />
        <sequenceFlow sourceRef="gw1" targetRef="timerEvent" />

        <intermediateCatchEvent id="signalEvent" name="Alert">
            <signalEventDefinition signalRef="alertSignal" />
        </intermediateCatchEvent>

        <intermediateCatchEvent id="timerEvent" name="Alert">
            <timerEventDefinition>
                <timeDuration>PT10M</timeDuration>
            </timerEventDefinition>
        </intermediateCatchEvent>

        <sequenceFlow sourceRef="timerEvent" targetRef="exGw1" />
        <sequenceFlow sourceRef="signalEvent" targetRef="task" />

        <userTask id="task" name="Handle alert"/>

        <exclusiveGateway id="exGw1" />

        <sequenceFlow sourceRef="task" targetRef="exGw1" />
        <sequenceFlow sourceRef="exGw1" targetRef="end" />

        <endEvent id="end" />
    </process>
</definitions>

BPMN 2.0结构说明

一、启动事件

1.1、空启动事件

1.2、定时器启动事件

1.3、消息启动事件

1.4、信号启动事件

1.6、错误启动事件

二、结束事件

2.1、空结束事件

2.2、错误结束事件

2.3、终止结束事件

2.4、取消结束事件

三、边界事件

3.1、定时器边界事件

示例二：

3.2、错误边界事件

示例：

3.3、信号边界事件

3.4、信号边界事件

3.5、取消边界事件

3.5、补偿边界事件

四、捕获中间事件

4.1、定时器捕获中间事件

4.2、信号捕获中间事件

4.3、消息捕获中间事件

5、抛出中间事件

5.1、空抛出中间事件

5.2、信号抛出中间事件

5.3、补偿抛出中间事件

6、顺序流

6.1、条件顺序流

6.2、默认顺序流

7、 网关

7.1、排他网关

7.2、并行网关

7.3、包容网关

7.4、基于事件的网关

7、网关