---
title: "11.7 Gateways"
chapter: "11 Choreography"
source: "OMG BPMN 2.0.2 — formal/2013-12-09"
pages: "344-361"
---
> 11 Choreography · páginas 344-361 · [índice](../README.md)
## 11.7 Gateways
In an *Orchestration* **Process**, **Gateways** are used to create alternative and/or parallel paths for that **Process**. **Choreography** has the same requirement of alternative and parallel paths. That is, interactions between *Participants* can happen in sequence, in parallel, or through exclusive selection. While the paths of **Choreography** follow the same basic patterns as that of an *Orchestration* **Process**, the lack of a central mechanism to maintain data visibility, and that there is no central evaluation, there are constraints as to how the **Gateways** are used in conjunction with the **Choreography Activities** that precede and follow the **Gateways**. These constraints are an extension of the basic sequencing constraints that was defined on page 335. The six (6) sub clauses that follow will define how the types of **Gateways** are used in
### 11.7.1 Exclusive Gateway
**Exclusive Gateways** (Decisions) are used to create alternative paths within a **Process** or a **Choreography**. For details of how **Exclusive Gateways** are used within an *Orchestration* **Process** see page 289. **Exclusive Gateways** are used in **Choreography**, but they are constrained by the lack of a central mechanism to store the data that will be used in the *Condition* expressions of the **Gateway’s** *outgoing* **Sequence Flows**. **Choreographies** MAY contain natural language descriptions of the **Gateway’**s *Conditions* to document the alternative paths of the **Choreography** (e.g., “large orders” will go down one path while “small orders” will go down another path), but such **Choreographies** would be underspecified and would not be *enforceable*. To create an *enforceable* **Choreography**, the **Gateway** *Conditions* MUST be formal *Condition Expressions*. However:
- The data used for **Gateway** *Conditions* MUST have been in a **Message** that was sent prior to (upstream from)
These constraints ensure that the *Participants* in the **Choreography** understand the basis (the actual value of the data) for the decision behind the **Gateway**.
One (1) or more *Participants* will actually “control” the **Gateway** decision; that is, these *Participants* make the decision through the internal *Orchestration* **Processes**. The decision is manifested by the particular **Message** that occurs in the **Choreography** (after the **Gateway**). This **Message** is the *initiating* **Message** of a **Choreography Activity** that follows the **Gateway**. Thus, only the *Participants* that are the *initiators* of the **Messages** that follow the **Gateway** are the ones that control the decision. This means that:
- The *initiating Participants* of the **Choreography Activities** that follow the **Gateway** MUST have sent or received the **Message** that provided the data upon which the decision is made.
P a rt ic ip a n t A P a rti ci p a n t B
P a rt ic ip a n t B P a rt ic ip a n t C
*Figure 11.34 – An example of the Exclusive Gateway* (p. 345)
Figure 11.35 shows the **Collaboration** that demonstrates how the above **Choreography** that includes an **Exclusive Gateway** can be enforced.
*Figure 11.35 – The relationship of Choreography Activity Participants across the sides* (p. 346)
**of the Exclusive Gateway shown through a Collaboration** Usually, the *initiators* for the **Choreography Activities** that follow the **Gateway** will be the same *Participant*. That is, there is only one *Participant* controlling the decision. Often, the receivers of the *initiating* **Message** for those Choreography Activities will be the same Participant. However, it is possible that there could be different Participants receiving the initiating Message for each Choreography Activity (see Figure 11.36).
*Figure 11.36 – Different Receiving Choreography Activity Participants* (p. 347)
**on the output sides of the Exclusive Gateway** This configuration can only be valid if all the *Participants* in the **Choreography Activities** that follow the **Gateway** have seen the data upon which the decision is made. If either “Participant B” or “Participant C” had not sent or received a **Message** with the appropriate data, then that *Participant* would not be able to know if they are suppose to receive a **Message** at that point in the **Choreography**. There is also the assumption that the value of the data is consistent from the point of view of all *Participants*. Figure 11.37 displays the corresponding **Collaboration** view of the above **Choreography Exclusive Gateway** configuration.
*Figure 11.37 – The corresponding Collaboration view of the above* (p. 348)
**Choreography Exclusive Gateway configuration** The REQUIRED execution behavior of the **Gateway** and associated **Choreography Activities** are enforced through the **Business Processes** of the *Participants* as follows:
- Each **Choreography Activity** and the **Sequence Flow** connections are reflected in each *Participant*
- The **Gateway** is reflected in the **Process** of each *Participant* **Process** that is an initiator of **Choreography**
- For the receivers in **Choreography Activities** that follow the **Gateway**, an **Event-Based Gateway** is used to consume the associated **Message** (sent as an outcome of the **Gateway**). When a *Participant* is the receiver of more than one of the alternative **Messages**, the corresponding receives follow the **Event-Based**
- If the *Participant* is the receiver of only one such **Message**, that is also consumed through a receive following the **Event-Based Gateway**. This is because the *Participant* **Process** does not know whether it will receive a **Message** (since the **Gateway** entails a choice of outcomes).
### 11.7.2 Event-Based Gateway
As described above, the **Event-Based Gateway** represents a branching point in the **Process** where the alternatives are based on **Events** that occur at that point in the **Process**, rather than the evaluation of expressions using **Process** data. For details of how **Event-Based Gateways** are used within an *Orchestration* **Process** see “Event-Based Gateway” on page 296. These **Gateways** are used in **Choreography** when the data used to make the decision is only visible to the internal **Processes** of one *Participant*. That is, there has been no **Message** sent within the **Choreography** that would expose the data used to make the *decision*. Thus, the only way that the other *Participants* can be aware of the results of the decision is by the particular **Message** that arrives next. On the right side of the **Gateway**: either
**Message Intermediate Events** MUST NOT be used in the **Event-Based Gateway**. **Timer Intermediate Events** MAY be used, but they restrict the participation in the **Gateway**.
**Signal Intermediate Events** MAY be used (they are visible to all *Participants*). No other types of **Intermediate Event**s are allowed.
C h o re o g ra p h y C h o re o g ra p h y
*Figure 11.38 – An example of an Event Gateway* (p. 349)
Figure 11.39 displays the corresponding Collaboration view of the above Choreography Event Gateway configuration.
*Figure 11.39 – The corresponding Collaboration view of the above Choreography Event Gateway configuration* (p. 350)
The REQUIRED execution behavior of the **Event-Based Gateway** and associated **Choreography Activities** are enforced through the **Business Processes** of the *Participants* as follows:
- Each Choreography Activity and the Sequence Flow connections is reflected in each Participant Process.
- If the senders following the Gateway are the same, the Event-Based Gateway is reflected as an Exclusive **Gateway** in that *Participant’s* **Process**. This is because the choice of which **Message** to send is determined by the same Participant. If the senders are different, sending occurs through different **Processes**.
- If the receivers are the same, the senders can be the same or different. In this case, the Event-Based Gateway is reflected in the receiver’s **Process**, with the different **Message** receives following the **Gateway**.
- If the receivers are different, the senders need to be the same. The Event-Based Gateway is reflected for different receiver **Processes** such that the respective receive follows the **Gateway**. A time-out can be used to ensure that the **Gateway** does not wait indefinitely.
### 11.7.3 Inclusive Gateway
**Inclusive Gateways** are used for modeling points of synchronization of a number of branches, not all of which are active, after which one or more alternative branches are chosen within a Choreography flow. For example, one of more branches MAY be activated upstream, in parallel, depending on the nature of goods in an order (e.g., large orders, fragile goods orders, orders belonging to pre-existing shipment contracts), and these are subsequently merged. The point of merge results in one or more risk mitigating outcomes (e.g., special insurance protection needed, special packaging needed, and different container categories needed). **Inclusive Gateways** are also used within an *Orchestration* **Process** see page 291. Like **Exclusive Gateways**, **Inclusive Gateways** are used in a **Choreography**, but they are constrained by the lack of a central mechanism to store the data that will be used in the *Condition* expressions of the **Gateway’s** *outgoing* **Sequence Flows. Choreographies** MAY contain natural language descriptions of the **Gateway’s** *Conditions* to document the one more alternative paths of the **Choreography** (e.g., “special insurance protection needed,” “special packaging needed,” and different “container category needed”), but such **Choreographies** would be underspecified and would not be *enforceable*. To create an *enforceable* **Choreography**, the **Gateway** *Conditions* MUST be formal *Condition Expressions*. In general the following rules apply for the *Expressions*. Like the enforceability of the **Exclusive Gateway**, the **Inclusive Gateway** in a **Choreography** requires that the data in the *Expressions* of the outgoing **Sequence Flows** of the **Gateway** be available to the initiators of the **Choreography Activities** of *outgoing* **Sequence Flows**. This means that the initiators of these **Choreography Activities** should also be senders or receivers of **Messages** in **Choreography Activities** immediately preceding the **Gateway**. The major difference, however, is that the synchronizing behavior of the **Inclusive Gateway** can only be enforced through one participant. Hence, the rules for enforceability are as follows:
- The data used for **Gateway** *Conditions* MUST have been in a **Message** that was sent prior to (upstream from) the
Figure 11.40 shows an example of a **Choreography** with an **Inclusive Gateway**. The **Gateway** is enforced in the corresponding **Business Processes** of the *Participants* involved. For the merge behavior to be enforced, the initiator of **Choreography Activities** immediately following the **Gateway** participates in the **Choreography Activities** immediately preceding the **Gateway**.
*Figure 11.40 – An example of a Choreography Inclusive Gateway configuration* (p. 352)
*Figure 11.41 – The corresponding Collaboration view of the above Choreography Inclusive Gateway configuration* (p. 353)
Figure 11.42, a variation of Figure 11.40 above, shows an example of a **Choreography** illustrating the enforcement of the split behavior of the **Inclusive Gateway**. For the split behavior to be enforced, the initiators of **Choreography Activities** immediately following the **Gateway** and the receiver of **Choreography Activities** immediately preceding the **Gateway** are the same Participant (i.e., A).
*Figure 11.42 – An example of a Choreography Inclusive Gateway configuration* (p. 354)
*Figure 11.43 – The corresponding Collaboration view of the above Choreography* (p. 355)
*Figure 11.44 – Another example of a Choreography Inclusive Gateway configuration* (p. 356)
*Figure 11.45 – The corresponding Collaboration view of the above Choreography* (p. 357)
### 11.7.4 Parallel Gateway
**Parallel Gateways** are used to create paths and are performed at the same time, within a **Choreography** flow. For details of how **Parallel Gateways** are used within an *Orchestration* **Process** see page 292. Since there is no conditionality for these **Gateways**, they are available as-is in **Choreography**. They create parallel paths of the **Choreography** that all *Participants* are aware of. The sender(s) of all the **Activities** after the **Gateway** MUST be involved in all the **Activities** that immediately precede the **Gateway**.
Figure 11.46 shows the relationship of **Choreography Activity** *Participants* across the sides of the **Parallel Gateway**.
*Figure 11.46 – The relationship of Choreography Activity Participants* (p. 358)
Figure 11.47 shows the corresponding **Collaboration** view of the above **Choreography Parallel Gateway** configuration.
*Figure 11.47 – The corresponding Collaboration view of the above* (p. 359)
**Choreography Parallel Gateway configuration** The REQUIRED execution behavior of the **Parallel Gateway** and associated **Choreography Activities** are enforced through the **Business Processes** of the *Participants* as follows:
- Each **Choreography Activity** and the **Sequence Flow** connections is reflected in each *Participant* **Process**.
- If the senders following the **Parallel Gateway** are the same, a **Parallel Gateway** is reflected in the sender’s **Process** followed by **Message** sending actions to the corresponding receivers.
- If the senders are different, the **Parallel Gateway** is manifested by **Sequence Flows** followed by the sending action in each **Process**.
### 11.7.5 Complex Gateway
**Complex Gateways** can model partial merges in **Business Processes** where when some but not all of a set of preceding branches complete, the **Gateway** fires. This can be considered the discriminator/n-of-m join pattern1 and is not supported through the inclusive OR merge since it is not concerned with sets of branches, but rather branches that have *tokens*. Applied in **Choreographies**, **Complex Gateways** can model tendering and information canvassing use cases where requests are sent to participants who respond at different times. Consider an e-tender that sends a request for quote to multiple service providers (e.g., warehouse storage) in a marketplace. The e-tender **Process** sends out requests to each service provider and anticipates their response through three **Choreography Activities**. The response branches merge at a **Complex Gateway** to model the requirement that when 66% responses have arrived, an assessment of the tender can proceed. The assessment occurs after the **Complex Gateway**. If the assessment reports that the reserve amount indicated by the customer cannot be met, a new iteration of the tender is made. A key issue is to ensure that the responses should not be mixed across tender iterations. A **Terminate End Event** ensures that all **Activities** are terminated, when a tender has been successful.
*Figure 11.48 – An example of a Choreography Complex Gateway configuration* (p. 360)
1. http://www.workflowpatterns.com/patterns/control/advanced_branching/wcp9.php
*Figure 11.49 – The corresponding Collaboration view of the above Choreography Complex Gateway configuration* (p. 361)
### 11.7.6 Chaining Gateways
It is possible to chain **Gateways**. This means that a modeler can sequence two or more **Gateways** without any intervening **Choreography Activities,** however the constraints on what participants can appear before and after the chain MUST be observed.