A gateway is used to control the flow of execution. A gateway is capable of consuming or generating executions (or execution tokens as they are officially known).
There are four types of gateway.
Exclusive Gateway
An exclusive gateway (also called the XOR gateway), is used to model a decision in a process. When the execution arrives at this gateway, outgoing sequence flows are evaluated in the order in which they are defined. Remember that conditions are placed upon the sequence flows (the arrows themselves) not the gateway element.
The sequence flow which evaluates to true (or which doesn't have a condition set) is selected for continuing the process.
Note that the semantics of outgoing sequence flow is different to that of the general case in BPMN 2.0. While in general all sequence flows which evaluate to true are selected to continue in a parallel way, only one sequence flow is selected when using the exclusive gateway. Should multiple sequence flows have a condition that evaluates to true, the first one defined in the flow order is selected for continuing the process. If no sequence flow can be selected, an exception will be thrown.
| Property | Description |
|---|---|
| ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
| Name | A name for this element |
| Description | An optional description for this element |
| Asynchronous | When execution reaches a task that has been marked as asynchronous the engine will commit the current transaction and schedule a background job to continue the process from the asynchronous task |
| Flow Order | The order in which the outgoing sequence flow conditions will be evaluated. This can be used to set priority should more than one evaluate to true (because only the first flow found to be true will be followed) |
Example
The above diagram shows an example where a document will be given to either user A or user B for approval, and the second gateway waits for either incoming path to reach it before continuing.
Parallel Gateway
Gateways can also be used to model concurrency in a process. The most straightforward gateway to introduce concurrency in a process model is the parallel gateway, which allows the execution to fork into multiple paths or join multiple incoming paths together.
The functionality of the parallel gateway is based on the incoming and outgoing sequence flow:
- Fork: all outgoing sequence flows are followed in parallel, creating a concurrent execution for each
- Join: all concurrent executions arriving at the parallel gateway wait in the gateway until an execution has arrived from each of the incoming sequence flows. Then the process continues past the joining gateway
A parallel gateway can have both fork and join behaviour, if there are multiple incoming and outgoing sequence flows for the same parallel gateway. In that case, the gateway will first join all incoming sequence flows, before splitting into multiple concurrent paths of execution.
An important difference with other gateway types is that the parallel gateway does not evaluate conditions. If conditions are defined on the sequence flows connected to the parallel gateway, they are ignored.
A parallel gateway does not need to be balanced (ie a matching number of incoming/outgoing sequence flow for corresponding parallel gateways). A parallel gateway will simply wait for all incoming sequence flows and create a concurrent path of execution for each outgoing sequence flow, not influenced by other constructs in the process model.
Note that parallel executions are not strictly concurrent. While each will exist in a concurrent state once created, executions are created sequentially, with each subsequent execution coming into existence once the previous reaches a wait state (ie a user task, timer, or asynchronous task). All paths of execution must reach a wait state before the execution transaction is committed. See Workflow Transactions - Foreground and Background Jobs for more information.
| Property | Description |
|---|---|
| ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
| Name | A name for this element |
| Description | An optional description for this element |
| Asynchronous | When execution reaches a task that has been marked as asynchronous the engine will commit the current transaction and schedule a background job to continue the process from the asynchronous task |
| Flow Order | As all sequence flows will be followed, this setting serves no purpose |
The above diagram shows an example where a document will be given to both user A and user B for approval and they must both approve it before the second gateway will allow execution to proceed past it.
Inclusive Gateway
The inclusive gateway can be seen as a combination of an exclusive and a parallel gateway. Like an exclusive gateway you can define conditions on outgoing sequence flows and the inclusive gateway will evaluate them. But the main difference is that the inclusive gateway can take more than one sequence flow, like the parallel gateway.
The functionality of the inclusive gateway is based on the incoming and outgoing sequence flow:
- Fork: all outgoing sequence flow conditions are evaluated and, for the sequence flow conditions that evaluate to true, the flows are followed in parallel, creating one concurrent execution for each sequence flow.
- Join: all concurrent executions arriving at the inclusive gateway wait in the gateway until an execution has arrived for each of the incoming sequence flows that have a process token. This is an important difference with the parallel gateway. So in other words, the inclusive gateway will only wait for the incoming sequence flows that will be executed. After the join, the process continues past the joining inclusive gateway.
Note that an inclusive gateway can have both fork and join behaviour, if there are multiple incoming and outgoing sequence flows for the same inclusive gateway. In that case, the gateway will first join all incoming sequence flows that have a process token, before splitting into multiple concurrent paths of executions for the outgoing sequence flows that have a condition that evaluates to true.
Note that an inclusive gateway does not need to be balanced (i.e. a matching number of incoming/outgoing sequence flow for corresponding inclusive gateways). An inclusive gateway will simply wait for all incoming sequence flows and create a concurrent path of execution for each outgoing sequence flow, not influenced by other constructs in the process model.
| Property | Description |
|---|---|
| ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
| Name | A name for this element |
| Description | An optional description for this element |
| Asynchronous | When execution reaches a task that has been marked as asynchronous the engine will commit the current transaction and schedule a background job to continue the process from the asynchronous task |
| Flow Order | The order in which the outgoing sequence flow conditions will be evaluated |
Example
In the above example, the document will be sent to either user A, user B, or both for approval. The gateway will wait for as many approvals as were requested to complete before continuing. Note the lack of any default flow on the first gateway, the conditions must be written to ensure that at least one path is always selected.
Event Gateway
The event gateway allows the process to take a decision based on events. An event gateway will have multiple outgoing paths, each of which is waiting for a timer, signal or message. It will wait for all these events in parallel, but as soon as one branch becomes active (because the timer has fired, its message has been received etc.), the other branches are terminated. The same kind of behaviour could be modelled using a sub-process with multiple boundary events with "cancel activity" set, but the event gateway is more elegant and compact.
The following restrictions apply:
- An event gateway must have two or more outgoing sequence flows.
- An event gateway must be connected to intermediate catching events.
- An intermediate catching event connected to an event gateway must have a single incoming sequence flow.
| Property | Description |
|---|---|
| ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
| Name | A name for this element |
| Description | An optional description for this element |
| Asynchronous | When execution reaches a task that has been marked as asynchronous the engine will commit the current transaction and schedule a background job to continue the process from the asynchronous task |
| Flow Order | The order in which the outgoing sequence flows will be followed |
Example
The above example shows a process where a publication will be released on its publication date unless the process receives a message indicating that it has been cancelled, or a signal indicating that all upcoming publications have been cancelled. The event gateway makes all these events mutually exclusive, whichever one happens first will prevent the process from continuing to listen for the others.
Share this page
