---
title: "9.5 Conversations"
chapter: "9 Collaboration"
source: "OMG BPMN 2.0.2 — formal/2013-12-09"
pages: "123-136"
---
> 9 Collaboration · páginas 123-136 · [índice](../README.md)
## 9.5 Conversations
The **Conversation** diagram is particular usage of and an informal description of a **Collaboration** diagram. In general, it is a simplified version of **Collaboration**, but **Conversation** diagrams do maintain all the features of a **Collaboration**. In particular, **Processes** can appear within the *Participants* (**Pools**) of **Conversation** diagrams, to show how **Conversation** and **Activities** are related. The view includes two additional graphical elements that do not exist in other **BPMN** views:
1. Conversation Node elements (Conversation, Sub-Conversation, and Call Conversation)
2. A Conversation Link
A **Conversation** is a logical grouping of **Message** exchanges (**Message Flows**) that can share a *Correlation*. A **Conversation** is the logical relation of **Message** exchanges. The logical relation, in practice, often concerns a business object(s) of interest, e.g., “Order,” “Shipment and Delivery,” and “Invoice.” Hence, a **Conversation** is associated with a set of name-value pairs, or a Correlation Key (e.g., “Order Identifier,” “Delivery Identifier”), which is recorded in the **Messages** that are exchanged. In this way, a **Message** can be routed to the specific **Process** *instance* responsible for receiving and processing the **Message**. Figure 9.16 shows a simple example of a **Conversation** diagram.
*Figure 9.16 – A Conversation diagram* (p. 124)
Figure 9.17 shows a variation of the example above where the **Conversation** node has been expanded into its component **Message Flows**. Note that the diagram looks the same as a simple **Collaboration** diagram (as in Figure 9.3, above).
*Figure 9.17 – A Conversation diagram where the Conversation is expanded into Message Flows* (p. 124)
**Message** exchanges are related to each other and reflect distinct business scenarios. The relation is sometimes simple, for example, a request followed by a response, and can be described as part of a structural interface of a service (e.g., as a WSDL operation definition). However for commercial business transactions managed through **Business Processes**, the relation can be complex, involving long-running, reciprocal **Message** exchanges, and that could extend beyond bilateral to complex, multilateral **Collaborations**. For example, in logistics, stock replenishments involve the following types scenarios: creation of sales orders, assignment of carriers for shipments combining different sales orders, crossing customs/quarantine, processing payment, and investigating exceptions.
In addition to an *orchestration* **Process**, **Conversations** are relevant to a **Choreography**, but the **Conversations** are not visualized in a **Choreography**. The difference is that a **Choreography** provides a multi-party perspective of a **Conversation**. This is because the **Message** exchanges modeled using **Choreography Activities** concern multiple Participants, unlike an *orchestration* **Process** where the **Message** sending and receiving elements relate to one Participant only. Other than the difference in perspective, the notion of **Conversation** remains the same across **Choreography** and *orchestration*, and the **Message** exchanges of a **Conversation** will be executed ultimately through an *orchestration* **Process**. Since **Collaboration** provides a top-down, design-time modeling perspective for **Message** exchanges and their **Conversations**, an abstracted view of the all **Conversations** pertaining to a domain being modeled is available through a **Conversation** diagram. A **Conversation** diagram, as depicted in Figure 9.18, shows **Conversations** (as hexagons) between *Participants*. This provides a “bird’s eye” perspective of the different **Conversations** that relate to the domain.
Customs/ Notification Notification Insurance
*Figure 9.18 – Conversation diagram depicting several conversations between Participants in a related domain* (p. 125)
Figure 9.18 depicts 13 distinct **Conversations** between collaborating Participants in a logistics domain. As examples, *Retailer* and *Supplier* are involved in a *Delivery Negotiations* **Conversation**, and *Consignee* converses with *Retailer* and *Supplier* through *Delivery/Dispatch Plan* and *Shipment Schedule* **Conversations** respectively. More than two participants MAY be involved in a **Conversation**, e.g., *Consignee, Consolidator* and *Shipper* in *Detailed Shipment*
*Schedule*. The association of Participants to a **Conversation** are constrained to indicate whether one or many of *Participants* are involved. For example, one *instance* of *Retailer* converses with one *instance* of *Supplier* for *Deliver Negotiations.* However, one *instance* of *Shipper* converses with multiple *instances* of *Carrier* (indicated by the multi-instance symbol of the **Pool** for *Carrier*) for *Carrier Planning.* Note, multiplicity in constraints of **Conversation** diagrams means one or more (not zero or more). The behavior of different **Conversations** is modeled through separate **Choreographies**, detailing the **Message** exchange sequences. In practice, **Conversations** which are closely related could be combined in the same **Choreography** models. For example, a **Message** exchange in the *Delivery Negotiation* leads to *Shipment Schedule*, *Delivery Planning,* and *Delivery/Dispatch* **Conversations** and these could be combined together in the same **Choreography**. Alternatively, they could be separated in different models. Figure 9.19 shows a subset of the larger **Conversation** diagram of Figure 9.18, above. Figure 9.20 and Figure 9.21 show the drill down into the “Delivery Negotiations” **Sub-Conversation**. This expands the **Conversation** with the **Message Flows**, providing a structural view of a **Conversation** without the “clutter” of sequencing details in the same diagram. Figure 9.19 also indicates the CorrelationKey involved in the **Message Flows** of the **Conversation**. For example, *Order Id* is necessary for in all **Messages** of **Message Flows** in Delivery Negotiation. In addition, some **Message Flows** also require *Variation Id* (for dealing with shipment variations on a per line item basis).
*Figure 9.19 – An example of a Sub-Conversation* (p. 126)
Figure 9.20 shows how the **Sub-Conversation** of Figure 9.19, above, is expanded into a set of **Message Flows** and a lower-level **Conversation**.
*Figure 9.20 – An example of a Sub-Conversation expanded to a Conversation and Message Flow* (p. 126)
Figure 9.21 shows how the **Conversation** of Figure 9.20 is also expanded into a set of **Message Flows**, combined with the previous **Message Flows**. Note that the newly exposed **Message Flows** of the lower-level **Conversation** will be correlated by the CorrelationKey of both the lower-level **Conversation** (*Variation Id*) and the higher-level **Sub- Conversations** (*Order Id*).
*Figure 9.21 – An example of a Sub-Conversation that is fully expanded* (p. 127)
In Figure 9.19 a hierarchical structure of **Conversations** can be seen with one set of **Message Flows** occurring within another in a parent-child relationship. In particular, after Planned Order Variations (keyed on Order Id) at the parent, a number of **Message Flows** of the child follow till *Retailer Order and Delivery Variations Ack* (keyed on *Variation Id* and *Order Id*). The remaining **Message Flows** (keyed on *Order Id*) are at the parent level. The child **Conversation**, as such, is part of the parent **Conversation**. Nesting is indicated graphically on a **Conversation** symbol (by a “+”), indicating a **Sub-Conversation** or a **Call Conversation** calling a **Collaboration**. Nesting can go to an arbitrary number of levels. A common dependency between **Conversations** is overlap. Overlap occurs when two or more **Conversations** have some **Message** exchanges in common but not others. As an example in Figure 9.18, a **Message** is sent as part of Detailed Shipment Schedule (keyed on Carrier Schedule Id) to trigger Delivery Monitoring (keyed on Shipment Id). During Delivery Monitoring, **Message** could be sent to Detailed Shipment Schedule (to request modifications when transportation exceptions occur). *Splits* and *joins* are special types of overlap scenarios. A **Conversation** *split* arises when, as part of a **Conversation**, a message is exchanged between two or more *Participants* that at the same time spawns a new, distinct **Conversation** (either between the same set of *Participants* or another set). Additionally, no further **Message** exchanges are shared by the split **Conversations** as well as no subsequent merges of them occur. An example is Delivery Planning which leads to Carrier Planning and Special Cover. A **Conversation** *join* occurs when several **Conversations** are merged into one **Conversation** and no further **Message** exchanges occur in the original **Conversations**, i.e., these **Conversations** are finalized. The generalization of a *split* and *join* is a **Conversation** *refactor* where **Conversations** are split into parallel **Conversations** and then are merged at a later point in time.
### 9.5.1 Conversation Node
ConversationNode is the abstract super class for all elements that can comprise the **Conversation** elements of a **Collaboration** diagram, which are **Conversation** (see page 129), **Sub-Conversation** (see page 129), and **Call Conversation** (see page 130).
*Figure 9.22 – Metamodel of ConversationNode Related Elements* (p. 128)
ConversationNodes are linked to and from *Participants* using **Conversation Links** (see page 131). The ConversationNode element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 9.10 presents the additional attributes and model associations for the ConversationNode element.
**Table 9.10 – ConversationNode Model Associations**
| Attribute Name | Description/Usage |
| --- | --- |
| **name**: string [0..1] | Name is a text description of the ConversationNode element. |
| **participantRefs**: Participant | This provides the list of *Participants* that are used in the ConversationNode |
| [2..*] | from the list provided by the ConversationNode’s parent **Conversation**. This reference is visualized through a **Conversation Link** (see page 131). |
| **messageFlowRefs**: MessageFlow [0..*] | A reference to all **Message Flows** (and consequently **Messages**) grouped by a **Conversation** element. |
| **correlationKeys**: CorrelationKey [0..*] | This is a list of the ’s , which are used to ConversationNode CorrelationKeys group **Message Flows** for the ConversationNode. |
### 9.5.2 Conversation
A **Conversation** is an atomic element for a **Conversation** (**Collaboration**) diagram. It represents a set of **Message Flows** grouped together based on a concept and/or a CorrelationKey. A **Conversation** will involve two or more *Participants*. A **Conversation** is a hexagon that MUST be drawn with a single thin line (see Figure 9.23).
*Figure 9.23 – A Communication element* (p. 129)
The **Conversation** element inherits the attributes and model associations of ConversationNode (see Table 9.10), but does not contain any additional attributes or model associations.
### 9.5.3 Sub-Conversation
A **Sub-Conversation** is a ConversationNode that is a hierarchical division within the parent **Collaboration**. A **Sub-Conversation** is a graphical object within a **Collaboration**, but it also can be “opened up” to show the lower-level details of the **Conversation**, which consist of **Message Flows**, **Conversations**, and/or other **Sub-Conversations**. The **Sub-Conversation** shares the *Participants* of its parent **Conversation**. A **Sub-Conversation** is a hexagon that MUST be drawn with a single thin line (see Figure 9.24).
*Figure 9.24 – A compound Conversation element* (p. 130)
The **Sub-Conversation** element inherits the attributes and model associations of ConversationNode (see Table 9.10). Table 9.11 presents the additional model associations for the **Sub-Conversation** element.
**Table 9.11 – Sub-Conversation Model Associations**
| Attribute Name | Description/Usage |
| --- | --- |
| **conversationNodes**: ConversationNode [0..*] | The ConversationNodes model aggregation relationship allows a **Sub- Conversation** to contain other ConversationNodes, in order to group **Message Flows** of the **Sub-Conversation** and associate correlation information. |
### 9.5.4 Call Conversation
A **Call Conversation** identifies a place in the **Conversation** (**Collaboration**) where a global **Conversation** or a
If the **Call Conversation** calls a GlobalConversation, then the shape will be the same as a **Conversation**, but the boundary of the shape will MUST have a thick line (see Figure 9.25). If the **Call Conversation** calls a **Collaboration**, then the shape will be the same as a **Sub-Conversation**, but the boundary of the shape will MUST have a thick line (see Figure 9.26).
*Figure 9.25 – A Call Conversation calling a GlobalConversation* (p. 130)
*Figure 9.26 – A Call Conversation calling a Collaboration* (p. 130)
The **Call Conversation** element inherits the attributes and model associations of ConversationNode (see Table 9.10). Table 9.12 presents the additional model associations for the **Call Conversation** element.
**Table 9.12 – Call Conversation Model Associations**
| Attribute Name | Description/Usage |
| --- | --- |
| **calledCollaborationRef:** Collaboration [0..1] | The element to be called, which MAY be either a **Collaboration** or a GlobalConversation. The called element MUST NOT be a **Choreography** or a GlobalChoreographyTask (which are subtypes of **Collaboration**) |
| **participantAssociations**: Participant | This attribute provides a list of mappings from the *Participants* of a |
| Association [0..*] | referenced GlobalConversation or **Conversation** to the *Participants* of the parent **Conversation**. |
| **NOTE:** The ConversationNode attribute | messageFlowRef doesn’t apply to **Call Conversations**. |
### 9.5.5 Global Conversation
A GlobalConversation is a reusable, atomic **Conversation** definition that can be called from within any **Collaboration** by a **Call Conversation**. The GlobalConversation element inherits the attributes and model associations and **Collaboration** (see Table 9.1), but does not have any additional attributes or model associations. A GlobalConversation is a restricted type of **Collaboration**, it is an “empty **Collaboration**.”
Since a GlobalConversation does not have any Flow Elements, it does not require It is basically a set of *Participants*, **Message Flows**, and CorrelationKeys intended for reuse. Also, the
### 9.5.6 Conversation Link
**Conversation Links** are used to connect ConversationNodes to and from *Participants* (**Pools** -- see Figure 9.27). **Conversation Links** MUST be drawn with double thin lines.
P r o c u r e m e n t R F Q S u p p lie r
*Figure 9.27 – A Conversation Link element* (p. 131)
**Processes** can appear in the Participants (**Pools**) of **Conversation** diagrams, as shown in Figure 9.28. The invoicing and ordering **Conversations** have links into **Activities** and **Events** of the **Process** in the Order Processor. The other two **Conversations** do not have their links “expanded.” **Conversation Links** into **Activities** that are not **Send** or **Receive Tasks** indicate that the **Activity** will send or receive **Messages** of the **Conversation** at some level of nesting.
Receive Request Process Send Shipping Send
*Figure 9.28 – Conversation links to Activities and Events* (p. 132)
*Figure 9.29 – Metamodel of Conversation Links related elements* (p. 133)
The **Conversation Link** element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 9.13 presents the additional attributes and model associations for the **Conversation Link** element.
**Table 9.13 – Conversation Link Attributes and Model Associations**
| Attribute Name | Description/Usage |
| --- | --- |
| **name**: string [0..1] | This attribute specifies the name of the **Conversation Link**. |
| **sourceRef**: InteractionNode | The InteractionNode that the **Conversation Link** is connecting from. A **Conversation Link** MUST connect to exactly one ConversationNode. If the sourceRef is not a ConversationNode, then the targetRef MUST be a ConversationNode. |
| **targetRef**: InteractionNode | The InteractionNode that the **Conversation Link** is connecting to. A **Conversation Link** MUST connect to exactly one ConversationNode. If the targetRef is not a ConversationNode, then the sourceRef MUST be a ConversationNode. |
**Conversation Links** for **Call Conversations** show the names of *Participants* in nested **Collaboration** or global **Collaborations**, as identified by ParticipantAssociations. For example, Figure 9.30 has a **Collaboration** on the left with a **Call Conversations** to a **Collaboration** on the right. The **Conversation Links** on the left indicate which *Participants* in the called **Collaboration** on the right correspond to which *Participants* in the calling **Collaboration** on the left. For example, the Credit Agency *Participants* on the right corresponds to the Financial Company *Participant* on the left. ParticipantAssociations (not shown) tie each *Participant* in the **Collaboration** on the left to a *Participant* in the **Collaboration** on the right. They can be used to show the names of *Participants* in nested **Collaboration** or global **Collaborations**.
*Figure 9.30 – Call Conversation Links* (p. 134)
### 9.5.7 Conversation Association
A ConversationAssociation is used within **Collaborations** and **Choreographies** to apply a reusable Conversation to the **Message Flows** of those diagrams. A ConversationAssociation is used when a diagram references a **Conversation** to provide **Message** correlation information and/or to logically group **Message Flows**. It is used when:
- A Collaboration references a Choreography for inclusion between the Collaboration’s Pools (Participants). The ConversationNodes of the **Choreography** (the inner diagram) need to be mapped to the ConversationNodes of the **Collaboration** (the outer diagram).
*Figure 9.31 – The ConversationAssociation class diagram* (p. 135)
The ConversationAssociation element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 9.14 presents the additional model associations for the ConversationAssociation element.
**Table 9.14 – ConversationAssociation Model Associations**
| Attribute Name | Description/Usage |
| --- | --- |
| **innerConversationNodeRef**: ConversationNode [0..1] | This attribute defines the ConversationNodes of the referenced element (e.g., a **Choreography** to be used in a **Collaboration**) that will be mapped to the parent element (e.g., the **Collaboration**). |
| **outerConversationNodeRef**: ConversationNode [0..*] | This attribute defines the ConversationNodes of the parent element (e.g., a **Collaboration** references a **Choreography**) that will be mapped to the referenced element (e.g., the **Choreography**). |
### 9.5.8 Correlations
Correlations are the mechanism that is used to assign the **Messages** to the proper **Process** *instance*, and can be defined for the **Message Flows** that belong to the **Conversation**. Correlations can be used to specify **Conversations** between **Processes** that follow a fairly simple **Conversation** pattern in the sense that:
- The conceptual data of the Conversation is well known and defined by the participating Processes. However this doesn’t mandate that underlying type systems are identical. It is sufficient that the data is known “conceptually” on a (potentially very high) business level.
- A Conversation takes place by means of simple Message exchange between Processes, no additional agreements MUST be considered.
- There exists send and receive Tasks accepting the conceptual data of the Conversation. (An Order send by a Task of a **Process** should be received by at least one **Task** of the participating **Process**).
- The correlation itself is defined in terms of correlation fields, which denote a subset of the conceptual data that should be used for the *correlation*. (For example, if the conceptual data comprises an order, then the correlation field might be denoted by the order ID).
In some applications it is useful to allow more **Messages** to be sent between *Participants* when a **Collaboration** is carried out than are contained in the **Collaboration** model. This enables *Participants* to exchange other **Messages** as needed without changing the **Collaboration**. If the isClosed attribute of a **Collaboration** has a value of *false* or no value, then *Participants* MAY send **Messages** to each other without additional **Message Flows** in the **Collaboration**. If the isClosed attribute of a **Collaboration** has a value of *true*, then *Participants* MAY NOT send **Messages** to each other without additional **Message Flows** in the **Collaboration**. If a **Collaboration** contains a **Choreography**, then the value of the isClosed attribute MUST be the same in both. Restrictions on unmodeled messaging specified with isClosed apply only under the **Collaboration** containing the restriction. PartnerEntities and PartnerRoles of the *Participants* MAY send **Messages** to each other under other **Choreographies**, **Collaborations**, and