网关 Gateways
网关用于控制执行的流向（或者按BPMN 2.0描述的，执行的token 标志）。网关可以消耗与生成标志。
网关用其中带有图标的菱形表示。该图标显示了网关的类型
排他网关 Exclusive Gateway
- 描述
排他网关（也叫异或网关 XOR gateway，或者更专业的，基于数据的排他网关 exclusive databased gateway），用于为流程中的决策建模。当执行到达这个网关时，所有出口顺序流会按照它们定义的顺序进行计算。条件计算为true的顺序流（当没有设置条件时，认为顺序流定义为true）会被选择用于继续流程。
请注意这里出口顺序流的含义与BPMN 2.0中的一般情况不一样。一般情况下，所有条件计算为true的顺序流，都会被选择继续，并行执行。而使用排他网关时，只会选择一条顺序流。当多条顺序 流的条件都计算为true时，其中在XML中定义的第一条（也只有这条）会被选择，用于继续流程。如果没有可选的顺序流，会抛出异常。
- 图标
排他网关，用内部带有’X’图标的标准网关（菱形）表示，’X’图标代表异或（XOR）的含义。请注意内部没有图标的网关默认为排他网关。BPMN 2.0规范不允许在同一个流程中，混合使用带有及没有X的菱形标志。
- 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>并行网关 Parallel Gateway
- 描述
网关也可以用于对流程中并行的建模。在流程模型中引入并行的最简单的网关，就是并行网关。它可以将执行分支（fork）为多条路径，也可以合并（join）执行的多条入口路径。
并行网关的功能，基于其入口与出口顺序流：
（1）分支：所有的出口顺序流都并行执行，为每一条顺序流创建一个并行执行。
（2）合并：所有到达并行网关的并行执行，都在网关处等待，直到每一条入口顺序流都有一个执行到达。然后流程经过该合并网关继续。
请注意，如果并行网关同时具有多条入口与出口顺序流，可以同时具有分支与合并的行为。在这种情况下，网关首先合并所有入口顺序流，然后分裂为多条并行执行路径。
与其他网关类型的重要区别，是并行网关不计算条件。如果连接到并行网关的顺序流上定义了条件，条件会被简单地忽略。
- 图标
并行网关，用内部带有’加号’图标的网关（菱形）表示，代表与（AND）的含义。
在上面的例子中，当流程启动后，会创建两个任务
当这两个任务完成后，第二个并行网关会合并这两个执行，并且由于只有一条出口顺序流，不会再创建并行执行路径，只会激活ArchiveOrder(存档订单)任务。
请注意并行网关不需要“平衡”（也就是说，对应的并行网关，其入口/出口顺序流的数量不需要匹配）。并行网关会简单地等待所有入口顺序流，并为每一条出口顺序流创建并行执行，不受流程模型中的其他结构影响。因此，下面的流程在BPMN 2.0中是合法的：
- XML表示
<parallelGateway id="myParallelGateway"/>
<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"/>包容网关 Inclusive Gateway
- 描述
包容网关可被视作排他网关与并行网关的组合。与排他网关一样，可以在出口顺序流上定义条件，包容网关会计算它们。然而主要的区别是，包容网关与并行网关一样，可以选择多于一条（出口）顺序流。
包容网关的功能，基于其入口与出口顺序流：
（1）分支：所有出口顺序流的条件都会被计算，对于条件计算为true的顺序流，流程会并行地沿其继续，为每一条顺序流创建一个并行执行。
（2）合并：所有到达包容网关的并行执行，都会在网关处等待，直到每一条具有流程标志的入口顺序流，都有一个执行到达。这是与并行网关的重要区别。换句话说，包容网关只会等待将会被执行的入口顺序流。在合并后，流程穿过合并并行网关继续。
请注意，如果包容网关同时具有多条入口与出口顺序流，可以同时具有分支与合并的行为。在这种情况下，网关首先合并所有具有流程标志的入口顺序流，然后为条件计算为true的出口顺序流，分裂为多条并行执行路径
- 图标
包容网关，用内部带有’圆圈’图标的网关（菱形）表示。
在上面的例子中，当流程启动后，如果流程变量paymentReceived == false且shipOrder == true，将会创建两个任务。如果只有一个流程变量等于true，则只会创建一个任务。如果没有条件计算为true，会抛出异常，并可通过指定默出口顺序 流避免。在下面的例子中，只有ship order（传递订单）一个任务会被创建
当这个任务完成后，第二个包容网关会合并这两个执行，并且由于只有一条出口顺序流，不会再创建并行执行路径，只会激活ArchiveOrder(存档订单)任务。
请注意包容网关不需要“平衡”（也就是说，对应的包容网关，其入口/出口顺序流的数量不需要匹配）。包容网关会简单地等待所有入口顺序流，并为每一条出口顺序流创建并行执行，不受流程模型中的其他结构影响。
- XML表示
<inclusiveGateway id="myInclusiveGateway" />
实际行为（分支，合并或两者皆有），由连接到该包容网关的顺序流定义。
例如，上面的模型表现为下面的XML：
<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" />基于事件的网关 Eventbased Gateway
- 描述
基于事件的网关，允许基于事件做选择。网关的每一条出口顺序流，都需要连接至一个捕获中间事件。当流程执行到达基于事件的网关时，网关类似等待状态地动作：执行被暂停。并且，为每一条出口顺序流，创建一个事件订阅。
请注意基于事件的网关，其出口顺序流与一般的顺序流不同。这些顺序流从不实际被执行。相反，它们允许流程引擎决定，当执行到达一个基于事件的网关时，需要订阅什么事件。基于下列约束：
（1）一个基于事件的网关，必须有两条或更多的出口顺序流。
（2）基于事件的网关，只能连接至 intermediateCatchEvent（捕获中间事件） 类型的元素（Activiti不支持基于事件的网关后，连接接收任务，Receive Task）。
（3）连接至基于事件的网关的 intermediateCatchEvent ，必须只有一个入口顺序流。
- 图标
基于事件的网关，用内部带有特殊图标的网关（菱形）表示
- XML表示
用于定义基于事件的网关的XML元素为 eventBasedGateway
下面的流程，是带有基于事件的网关的流程的例子。当执行到达基于事件的网关时，流程执行被暂停。并且，流程实例订阅alert信号事件，并创建一个 10分钟后触发的定时器。这使得流程引擎等待10分钟，并等待信号事件。如果信号在10分钟内触发，则定时器会被取消，执行沿着信号继续。如果信号未被触 发，执行会在定时器到时后继续，并取消信号订阅
<definitions id="definitions"
xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:activiti="http://activiti.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>
