---
title: "11.6 Events"
chapter: "11 Choreography"
source: "OMG BPMN 2.0.2 — formal/2013-12-09"
pages: "339-343"
---

> 11 Choreography · páginas 339-343 · [índice](../README.md)


<a id="sec-11-6"></a>
## 11.6 Events


<a id="sec-11-6-1"></a>
### 11.6.1 Start Events


**Start Events** provide the graphical marker for the start of a **Choreography**. They are used much in the same way as they are used for a **Process** (see “Start Event” on page 237). This table shows how the types of **Start Events** are applied to **Choreography**.


<a id="tab-11-6"></a>
**Table 11.6 – Use of Start Events in Choreography**

| Type of Event | Usage in Choreography? |
| --- | --- |
| None | **Yes**. This is really just a graphical marker since the arrival of the first **Message** in the **Choreography** is really the *Trigger* for the **Choreography**. **Sub-Processes**, however, we should look at. The *Parent* **Process** can be considered the *trigger*. |
| Message | **No**. A **Message Start Event**, in a stand-alone **Choreography**, has no way to show who the senders or receivers of the **Message** should be. A **Choreography Task** should be used instead. Thus, a **None Start Event** should be used as a graphical marker for the “start” of the **Choreography**. |
| Timer | **Yes**. All *Participants* have to have an agreement to the approximate time. |
| Escalation | ***No***. An Escalation is only visible to a single *Participant*. That *Participant* will have to send a **Message** to the other *Participants*. |
| Error | ***No***. An Error is only visible to a single *Participant*. That *Participant* will have to send a **Message** to the other *Participants*. |
| Compensation | ***No***. Compensation is handled within a single *Participant* (an orchestration **Process**). |
| Conditional | **Yes**. This is actually determined internal to *Participant*, but then the other *Participants* know this has happened based the first interaction that follows. |
| Signal | **Yes**. The source of the *Signal* is NOT REQUIRED (and might not even be a *Participant* in the **Choreography**). There are no specific recipients of a *Signal*. All *Participants* of the **Choreography** (to comply) MUST be able to see the *Signal*. |
| Multiple | **Yes**. But they can only be Multiple *Signals or Timers*. As in *Orchestration*, this acts like an OR. Any one of the incoming *Signals* will Trigger the **Choreography**. Any *Signal* that follows would create a separate instance of the **Choreography**. |


<a id="sec-11-6-2"></a>
### 11.6.2 Intermediate Events


<a id="tab-11-7"></a>
**Table 11.7 – Use of Intermediate Events in Choreography**

| Type of Event | Usage in Choreography? |
| --- | --- |
| **None**: in Normal Flow | **Yes**. However, this really doesn’t have much meaning other than just documenting that a specific point has been reached in the **Choreography**. There would be no **Message** exchange or any delay in the **Choreography**. |
| **None**: Attached to Activity | **No**. There would be no way for *Participants* to know when the **Activity** should be |
| boundary | interrupted. |
| **Message**: in Normal Flow | **No**. A **Message Intermediate Event**, in a stand-alone **Choreography**, has no way to show who the senders or receivers of the **Message** should be. A **Choreography Task** should be used instead. Also, would the **Event** be a *Catch* or a *Throw*? |
| **Message**: Attached to | **Yes**. Only for **Choreography Tasks**. The Intermediate Event has to be attached |
| Activity boundary | to the **Participant Band** of the receiver of the **Message** (since it is a catch Event). The sender of the message has to be the other *Participant* of the **Choreography Task**. |
| **Message**: Use in Event | **No**. A **Message Intermediate Event**, in a stand-alone **Choreography**, has no |
| Gateway | way to show who the senders or receivers of the **Message** should be. A **Choreography Task** should be used instead. |
| **Timer**: in Normal Flow | **Yes**. Time is not precise in **Choreography**. It is established by the last visible **Choreography Activity**. The *Participants* involved in the Choreography Activity that immediately precedes will have a rough approximation of the time—there will be no exact synchronization. For relative timers: Only the *Participants* involved in the Choreography Activity that immediately precedes the Event would know the time. The sender of the Choreography Activity that immediately follows the timer MUST be involved in the Choreography Activity that immediately precedes the timer. For absolute timers (full time/date): All *Participants* would know the time. There does not have to be a relationship between the *Participants* of the Choreography Activities that are on either side the timer. The sender of the Choreography Activity that immediately follows the timer is the *Participant* that enforces the timer. |
| **Timer**: Attached to Activity | **Yes**. Time is not exact in this case. It is established by the last visible **Event**. All |
| boundary | *Participants* will have a rough approximation of the time—there will be no exact synchronization. This includes both interrupting and escalation **Events**. The *Participants* of the Choreography Activity that has the attached timer all enforce the timer. For relative timers: They all have to be involved in the Choreography Activity that immediately precedes the Activity with the attached timer. For absolute timers (full time/date): All *Participants* would know the time. They all have to be involved in the Choreography Activity that immediately precedes the Activity with the attached timer. |
| **Timer**: Used in Event Gateway | **Yes**. See Event-Based Gateway below. |
| **Error**: Attached to Activity | ***No***. An Error is only visible to a single *Participant*. That *Participant* will have to |
| boundary | send a **Message** to the other *Participants*. |
| **Escalation**: Used in | ***No***. An Escalation is only visible to a single *Participant*. That *Participant* will have |
| Normal Flow | to send a **Message** to the other *Participants*. |
| **Escalation**: Attached to Activity | ***No***. An Escalation is only visible to a single *Participant*. That *Participant* will have |
| boundary | to send a **Message** to the other *Participants*. |
| **Cancel**: in Normal Flow | **No**. These are *Throw* **Events**. As with a **Message Event**, there would be no indicator as to who is the source of the *Cancel*. |
| **Cancel**: Attached to Activity | **Yes**. These are *Catch* **Events**. As with a **Message Even**t, they would be |
| boundary | attached to the **Choreography Activity** on the **Participant Band** that is receiving the Cancel. These would only be interrupting **Events**. |
| **Compensation**: in Normal | **No**. These are *Throw* **Events**. As with a **Message**, there would be no indicator |
| Flow | as to who is the source of the *Cancel*. |
| **Compensation**: Attached to | **Yes**. These are *Catch* **Events**. As with a **Message Even**t, they would be |
| Activity boundary | attached to the **Choreography Activity** on the **Participant Band** that is receiving the *Cancel*. |
| **Conditional**: in Normal Flow | **Yes**. This is a delay that waits for a change in data to trigger the **Event**. The data are to be visible to the *Participants* as it was data of a previously sent **Message**. |
| **Conditional**: Attached to | **Yes**. This is an interruption that waits for a change in data to trigger the **Event**. |
| Activity boundary | The data are to be visible to the *Participants* as it was data of a previously sent **Message**. |
| **Conditional**: Used in Event | **Yes**. This is a delay that waits for a change in data to trigger the **Event**. The data |
| Gateway | are to be visible to the *Participants* as it was data of a previously sent **Message**. |
| **Link**: in Normal Flow | **Yes**. These types of **Events** merely create a virtual **Sequence Flows**. Thus, as long as a **Sequence Flow** between two elements is valid (and within a **Choreography Process** level), then a pair of **Link Events** can interrupt that **Sequence Flow**. |
| **Signal**: in Normal Flow | **Yes**. Only *Catch* **Events** can be used. For *Throw* **Signal Events**, there would be no indicator of who is the source *Participant*. This would be a delay in the **Choreography** that waits for the *Signal*. The source of the *Signal* is NOT REQUIRED (and might not even be a *Participant* in the **Choreography**). There are no specific recipients of a *Signal*. All *Participants* of the **Choreography** (to comply) MUST be able to see the *Signal*. |
| **Signal**: Attached to Activity | **Yes**. These are *Catch* **Events**. This would be an interruption in the **Choreogra-** |
| boundary | **phy** that waits for the *Signal*. The source of the *Signal* is NOT REQUIRED (and might not even be a *Participant* in the **Choreography**). There are no specific recipients of a *Signal*. All *Participants* of the **Choreography** (to comply) MUST be able to see the *Signal*. This **Event** MUST NOT be attached to a **Participant Band** or this would suggest that *Participant* is a specific recipient of the *Signal*. |
| **Signal**: Used in Event | **Yes**. These are *Catch* **Events**. This would be a delay in the **Choreography** that |
| Gateway | waits for the *Signal*. The source of the *Signal* is NOT REQUIRED (and might not even be a *Participant* in the **Choreography**). There are no specific recipients of a *Signal*. All *Participants* of the **Choreography** (to comply) MUST be able to see the *Signal*. |
| **Multiple**: in Normal Flow | **Yes**. But they can only be a collection of valid *Catch* **Events**. As in *Orchestra- tion*, this acts like an OR. Any one of the incoming triggers will continue the **Choreography**. |
| **Multiple**: Attached to | **Yes**. But they can only be a collection of valid *Catch* **Events**. As in *Orchestra-* |
| Activity Boundary | *tion*, this acts like an OR. Any one of the incoming triggers will interrupt the **Choreography Activity**. |


<a id="sec-11-6-3"></a>
### 11.6.3 End Events


**End Events** provide a graphical marker for the end of a path within the **Choreography**.


<a id="tab-11-8"></a>
**Table 11.8 – Use of End Events in Choreography**

| Type of Event | Usage in Choreography? |
| --- | --- |
| None | **Yes**. This is really just a graphical marker since the sending of the previous **Message** in the **Choreography** is really the end of the **Choreography**. The *Participants* of the **Choreography** would understand that they would not expect any further **Message** at that point. |
| Message | **No**. A **Message End Event**, in a stand-alone **Choreography**, has no way to show who the senders or receivers of the **Message** should be. A **Choreography** Task should be used instead. Thus, a **None End Event** should be used as a graphical marker for the “end” of the **Choreography.** |
| Error | **No**. These are *Throw* **Events** and there would be no way to indicate the *Participant* that is the source of the Error. |
| Escalation | **No**. These are *Throw* **Events** and there would be no way to indicate the *Participant* that is the source of the Escalation. |
| Cancel | **No**. These are *Throw* **Events**. As with a **Message Even**t, there would be no indicator as to who is the source of the *Cancel*. |
| Compensation | **No**. These are *Throw* **Events**. As with a **Message Event**, there would be no indicator as to who is the source of the *compensation*. |
| Signal | **No**. These are *Throw* **Events**. As with a **Message Event**, there would be no indicator as to who is the source of the *Signal*. |
| Multiple | **No**. Since there are no valid **End Event** Results (**Terminate** doesn’t count) in **Choreography**, there cannot be multiple of them. |
| Terminate | **Yes**. However, there would be no specific ability to terminate the **Choreography**, since there is no controlling system. In this case, all *Participants* in the **Choreography** would understand that when the **Terminate End Event** is reached (actually when the **Message** that precedes it occurs), then no further messages will be expected in the **Choreography**, even if there were parallel paths. The use of the **Terminate End Event** really only works when there are only two *Participants*. If there are more than two *Participants*, then any *Participant* that was not involved in the last **Choreography Task** would not necessarily know that the **Terminate End Event** had been reached. |