Figure 168: Conversation diagram
A conversation diagram provides an overview of which partners of a certain domain co-operate on which tasks. In figure 168, three conversations can be seen. When processing an order for an advertisement, one customer works together with one advertising agency and several designers. On the other hand, a customer and an advertising agency can jointly run an advertising campaign. For this, they co-operate with several media. A designer can also be part of another inter-company activity: Together with a publisher, he handles orders for illustrations.
In the end, such a conversation is realized by a series of message flows. The details can be modeled e.g. in a choreography diagram or a collaboration diagram. As an example, the message flow of the conversation “Process Order for Advertisement” is described by the collaboration diagram in figure 159, as well as by the choreography diagram in figure 160. However, it is not required for a collaboration or choreography diagram to specify exactly one conversation. It is also possible to combine the message flows from two or more conversations in one diagram.
Figure 168: Conversation diagram
The contents of the message flows within one conversation are always related to each other. For example, all messages that are exchanged within one instance of the conversation “Process Order for Advertisement” relate to the same advertisement order. It is, therefore, possible to use the order ID for the correlation, i.e. the assignment of messages to a process instance. If a customer receives an advertisement for approval, he can determine the corresponding order – and thus the process instance – based on the order ID. All messages of a conversation have a common correlation.
The connection between a conversation and a participant is called conversation link. A conversation is always connected to two or more participants.
It is possible that there are several partners of the same type involved in a conversation. “Process Order for Advertisement” has exactly one customer and one advertising agency as participants, but multiple designers. Therefore, the designer’s pool contains a multiple marker. However, it is not clear which conversations have several partners of the same type. For example, the participant “Designer” is also connected with the conversation “Handle Order for an Illustration”. Maybe in this conversation, there is only one designer involved. If such information is important, more detailed collaboration or choreography diagrams are required.
Figure 169: Conversation diagram for sub-conversation “Process Order for Advertisement”
Conversations can be further detailed using sub-conversations. Similar to sub-processes they are marked with a ‘+’-sign. The details of a sub-conversation can be described in another conversation diagram. The diagram of a sub-conversation can only contain those participants who are linked to the sub-conversation within the parent diagram.
Figure 169 shows the detailed conversation diagram for the sub-conversation “Process Order for Advertisement” As can be seen from this diagram, it is also possible to draw message flows directly into the conversation diagram. Other than collaboration diagrams, conversation diagrams are not allowed to show processes in the pools or choreographies between the pools.
The diagram contains those message flows that are related to the same order. To be more precise, they relate to the same inquiry. In the beginning, an order has not been placed yet, and not every inquiry turns into an order. Therefore, the common reference point is the inquiry.
Besides the explicitly displayed message flows between customer and advertising agency, the diagram also contains the conversation “Handle Assignment of Graphics Design”. All message flows of this conversation are also related to the same inquiry, but this information is not sufficient for the advertising agency in order to assign all incoming messages correctly. This is because availability requests are sent to several designers. The advertising agency has to assign each incoming availability notice to the correct availability request. Thus, additional information is required for correlating these messages, e.g. the IDs of the availability requests. Therefore, it is possible to define a separate Conversation for the message flows between the advertising agency and the designers.
The message exchanges of this conversation can also be modeled in a collaboration diagram (figure 170) or a choreography diagram (figure 171). Of course, it is also possible to show the message flows of the entire sub-conversation within a single diagram (figures 159 and 160 in the previous chapter).
Figure 170: Collaboration diagram for conversation “Handle Assignment of Graphics Design”
Figure 171: Choreography diagram for conversation “Handle Assignment of Graphics Design”
Like sub-processes, sub-conversations can also be expanded, i.e. the hexagon is enlarged, and the detailed conversation is shown in its interior. However, it is graphically not easy to include, for example, the contents of figure 169 into an expanded sub-conversation in figure 168. Unfortunately, the BPMN specification draft does not contain any examples for expanded sub-conversations either.
Similar to processes and choreographies it is possible within conversation diagrams to call global conversations. A global conversation is defined independently from the conversation diagram from which it is called. A global conversation is specified by its own, independent conversation diagram. The border of a calling conversation is drawn with a thick line (figure 172).
Since a called conversation is defined elsewhere, it may be necessary to map its participants and correlation information to the participants and correlation information of the conversation diagram from which it is called. This, however, is mainly a topic for automating inter-company processes. In business-oriented diagrams, such mappings can be deduced from the context, or they are explained by annotations.
Figure 172: Calls of a collaboration (left) and a global conversation (right)
For most BPMN modelers, the exact definition of correlations and thus the modeling of conversations will not be a primary concern. In the context of platforms for SOA (Service-Oriented Architecture) and process engines for supporting complex inter-company processes between several partners, on the other hand, this topic can be quite important. For such problems, conversations can provide a useful view of the entire scenario.
In many other cases, detailed correlation mechanisms are not of interest, but a conversation diagram can still be useful for the first overview of a network of partners. It can be seen which partners communicate with each other about which topics and business transactions. The details can then be modeled in choreography diagrams and collaboration diagrams.