---
title: "13.4 Gateways"
chapter: "13 BPMN Execution Semantics"
source: "OMG BPMN 2.0.2 — formal/2013-12-09"
pages: "434-438"
---
> 13 BPMN Execution Semantics · páginas 434-438 · [índice](../README.md)
## 13.4 Gateways
This sub clause describes the behavior of **Gateways**.
### 13.4.1 Parallel Gateway (Fork and Join)
*Figure 13.3 – Merging and Branching Sequence Flows for a Parallel Gateway* (p. 434)
On the one hand, the **Parallel Gateway** is used to synchronize multiple concurrent branches (merging behavior). On the other hand, it is used to spawn new concurrent threads on parallel branches (branching behavior).
**Table 13.1 – Parallel Gateway Execution Semantic**
| Operational Semantics | The **Parallel Gateway** is activated if there is at least one *token* on each |
| --- | --- |
| Operational Semantics | The **Parallel Gateway** is activated if there is at least one *token* on each incoming **Sequence Flow**. The **Parallel Gateway** consumes exactly one *token* from each incoming **Sequence Flow** and produces exactly one *token* at each outgoing **Sequence Flow**. If there are excess *tokens* at an incoming **Sequence Flow**, these *tokens* remain at this **Sequence Flow** after execution of the **Gateway**. |
| Exception Issues | The **Parallel Gateway** cannot throw any exception. |
| Workflow Patterns Support | Parallel Split (WCP-2) Synchronization (WCP-3) |
### 13.4.2 Exclusive Gateway (Exclusive Decision (data-based) and Exclusive Merge)
*Figure 13.4 – Merging and Branching Sequence Flows for an Exclusive Gateway* (p. 434)
The **Exclusive Gateway** has pass-through semantics for a set of incoming branches (merging behavior). Further on, each activation leads to the activation of exactly one out of the set of outgoing branches (branching behavior).
**Table 13.2 – Exclusive Gateway Execution Semantics**
| Operational Semantics | Each *token* arriving at any incoming **Sequence Flows** activates the |
| --- | --- |
| Operational Semantics | Each *token* arriving at any incoming **Sequence Flows** activates the gateway and is routed to exactly one of the outgoing **Sequence Flows**. In order to determine the outgoing **Sequence Flows** that receives the *token*, the conditions are evaluated in order. The first condition that evaluates to true determines the **Sequence Flow** the *token* is sent to. No more conditions are henceforth evaluated. If and only if none of the conditions evaluates to true, the *token* is passed on the default **Sequence Flow**. In case all conditions evaluate to false and a default flow has not been specified, an exception is thrown. |
| Exception Issues | The exclusive gateway throws an exception in case all conditions evaluate to false and a default flow has not been specified. |
| Workflow Patterns Support | Exclusive Choice (WCP-4) Simple Merge (WCP-5) Multi-Merge (WCP-8) |
### 13.4.3 Inclusive Gateway (Inclusive Decision and Inclusive Merge)
*Figure 13.5 – Merging and Branching Sequence Flows for an Inclusive Gateway* (p. 435)
The **Inclusive Gateway** synchronizes a certain subset of branches out of the set of concurrent incoming branches (merging behavior). Further on, each firing leads to the creation of threads on a certain subset out of the set of outgoing branches (branching behavior).
**Table 13.3 – Inclusive Gateway Execution Semantics**
| Operational Semantics | The **Inclusive Gateway** is activated if |
| --- | --- |
| Operational Semantics | The **Inclusive Gateway** is activated if • At least one incoming **Sequence Flow** has at least one *token* and • For every directed path formed by sequence flow that - starts with a **Sequence Flow** ***f*** of the diagram that has a *token*, - ends with an *incoming* **Sequence Flow** of the inclusive gateway that has no *token*, and - does not visit the **Inclusive Gateway**. • There is also a directed path formed by **Sequence Flow** that - starts with ***f***, - ends with an *incoming* **Sequence Flow** of the inclusive gateway that has a *token*, and - does not visit the **Inclusive Gateway**. Upon execution, a *token* is consumed from each incoming **Sequence Flow** that has a *token*. A *token* will be produced on some of the outgoing **Sequence Flows**. In order to determine the outgoing **Sequence Flows** that receive a *token*, all conditions on the outgoing **Sequence Flows** are evaluated. The evaluation does not have to respect a certain order. For every condition which evaluates to *true*, a *token* MUST be passed on the respective **Sequence Flow**. If and only if none of the conditions evaluates to *true*, the *token* is passed on the default **Sequence Flow**. In case all conditions evaluate to *false* and a default flow has not been specified, the **Inclusive Gateway** throws an exception. |
| Exception Issues | The inclusive gateway throws an exception in case all conditions evaluate to false and a default flow has not been specified. |
| Workflow Patterns Support | Multi-Choice (WCP-6) Structured Synchronizing Merge (WCP-7) Acyclic Synchronizing Merge (WCP-37) General Synchronizing Merge (WCP-38) |
### 13.4.4 Event-based Gateway (Exclusive Decision (event-based))
*Figure 13.6 – Merging and branching Sequence Flows for an Event-Based Gateway* (p. 437)
The **Event-Based Gateway** has pass-through semantics for a set of incoming branches (merging behavior). Exactly one of the outgoing branches is activated afterwards (branching behavior), depending on which of **Events** of the **Gateway** configuration is first triggered. The choice of the branch to be taken is deferred until one of the subsequent **Tasks** or **Events** completes. The first to complete causes all other branches to be withdrawn. When used at the **Process** start as a **Parallel Event Gateway**, only message-based triggers are allowed. The Message *triggers* that are part of the **Gateway** configuration MUST be part of a **Conversation** with the same correlation information. After the first *trigger* instantiates the **Process**, the remaining Message *triggers* will be a part of the **Process** *instance* that is already active (rather than creating new **Process** *instances*).
**Table 13.4 – Event-Based Gateway Execution Semantics**
| Exception Issues | The event-based gateway cannot throw any exception. |
| --- | --- |
| Workflow Patterns Support | Deferred Choice (WCP-16) |
### 13.4.5 Complex Gateway (related to Complex Condition and Complex Merge)
*Figure 13.7 – Merging and branching Sequence Flows for a Complex Gateway* (p. 437)
The **Complex Gateway** facilitates the specification of complex synchronization behavior, in particular race situations. The diverging behavior is similar to the **Inclusive Gateway**. Each incoming gate of the **Complex Gateway** has an attribute activationCount, which can be used in an Expression as an integer-valued variable. This variable represents the number of *tokens* that are currently on the respective *incoming* **Sequence Flows**. The **Complex** that refers to data and to the activationCount of incoming gates. For example, an activationExpression could be x1+x2+...+xm >= 3 stating that it needs 3 out of the m incoming gates to have a *token* in order to proceed. To prevent undesirable oscillation of activation of the **Complex Gateway**, ActivationCount variables should only be used in subexpressions of the form *expr* >= *const* where *expr* is an arithmetic Expression that uses only addition and *const* is an Expression whose evaluation remains constant during execution of the **Process**. Each *outgoing* **Sequence Flow** of the **Complex Gateway** has a boolean condition that is evaluated to determine whether that **Sequence Flow** receives a *token* during the execution of the **Gateway**. Such a condition MAY refer to internal state of the **Complex Gateway**. There are two states: waiting for start (represented by the runtime attribute waitingForStart = *true*) and waiting for reset (waitingForStart=*false*).
**Table 13.5 – Semantics of the Complex Gateway**
| Operational Semantics | The **Complex Gateway** is in one of the two states: *waiting for start* or *waiting |
| --- | --- |
| Operational Semantics | The **Complex Gateway** is in one of the two states: *waiting for start* or *waiting for reset*, initially it is in *waiting for start*. If it is *waiting for start*, then it waits for the activationExpression to become *true*. The activationExpres-sion is not evaluated before there is at least one *token* on some *incoming* **Sequence Flow**. When it becomes *true*, a *token* is consumed from each *incoming* **Sequence Flow** that has a *token*. To determine which *outgoing* **Sequence Flow** receive a *token*, all conditions on the *outgoing* **Sequence Flows** are evaluated (in any order). Those and only those that evaluate to *true* receive a *token*. If no condition evaluates to *true*, and only then, the *default* **Sequence Flow** receives a *token*. If no default flow is specified an exception is thrown. The **Gateway** changes its state to *waiting for reset*. The **Gateway** remembers from which of the *incoming* **Sequence Flows** it consumed *tokens* in the first phase. When *waiting for reset*, the **Gateway** waits for a *token* on each of those *incoming* **Sequence Flows** from which it has not yet received a *token* in the first phase unless such a *token* is not expected according to the join behavior of an **inclusive Gateway**. More precisely, the **Gateway** being *waiting for reset*, *resets* when for every directed path formed by sequence flow that - starts with a **Sequence Flow** ***f*** of the diagram that has a *token*, - ends with an *incoming* **Sequence Flow** of the **Complex Gateway** that has no *token* and has not consumed a *token* in the first phase, and that - does not visit the **Complex Gateway**. |
| **Table13.5 – Semantics of the Complex Gateway** | |
| Operational Semantics • There is also a directed path formed by | **Sequence Flow** that - starts with ***f***, - ends with an *incoming* **Sequence Flow** of the **Complex Gateway** that has a *token* or from which a *token* was consumed in the first phase, and that, - does not visit the **Complex Gateway**. |
| If the | **Complex Gateway** is contained in a **Sub-Process**, then no paths are |
| considered that cross the boundary of that | **Sub-Process**. |
| When the | **Gateway** resets, it consumes a *token* from each *incoming* **Sequence Flow** |
| that has a | *token* and from which it had not yet consumed a *token* in the first phase. It |
| then evaluates all conditions on the | *outgoing* **Sequence Flows** (in any order) to |
| determine which | **Sequence** **Flows** receives a *token*. Those and only those that |
| evaluate to | *true* receive a *token*. If no condition evaluates to *true*, and only then, the |
| *default* | **Sequence Flow** receives a *token*. The **Gateway** changes its state back to the |
| state | *waiting for start*. Note that the **Gateway** might not produce any *tokens* in this |
| phase and no exception is thrown. Note that the conditions on the | *outgoing* **Sequence** |
| **Flows** | MAY evaluate differently in the two phases, e.g., by referring to the state of the |
| **Gateway** | (runtime attribute waitingForStart). |
| Note that if the | activationCondition never becomes *true* in the first phase, *tokens* |
| are blocked indefinitely at the | **Complex Gateway**, which MAY cause a deadlock of the |
| entire | **Process**. |
| Exception issues The **Complex Gateway** | throws an exception when it is activated in the state *waiting* |
| *for start* | , no condition on any *outgoing* **Sequence Flow** evaluates to *true* and no |
| *default* Workflow Patterns Support Structured Discriminator (WCP-9) Blocking Discriminator (WCP-28) Structured Partial Join (WCP-30) Blocking Partial Join (WCP-31) | **Sequence Flow** is specified. |