Process Interactions - Involving Externals

Business process interact with each other.

External Participants

Process model with message flows crossing the border of a pool, as explained in the following text.

External participants can be perfectly modeled with a collapsed pool - and hence be considered as a black box. The interaction with such "externals" can only be represented by message flows, which always indicate an exchange of information.

Note

Sequence flows can never cross the border of a pool - but message flows can.

Usage of Message Flows

Message flows are used for communication between pools only. They are not used for internal communication as we have the sequence flow for this occasion. The other way around we cannot use sequence flows to communicate with other pools but rather use message flows.

Two process models showing a correct and incorrect example of message flows, as described in the preceding text.

Business Example - Let's Apply What You've Learned

Order Management

This example shows a more realistic example of how to interact with external participants and contains different elements that you have already learned in the course:

External participants and interaction.
Expanded subprocess for summarizing task.
with a cancel condition.
Collapsed subprocess - and evaluating the result.
Attached intermediate event (here: conditional event).
Starting message events.
Usage of IT-systems (spoiler: next lesson).

Using these different elements allows us to model an easy-to-follow order management process, which has some exceptional conditions with a loop in it.

Process Collaboration (Correspondence Diagrams)

The supreme discipline in process modeling is to model different processes and their interactions. However, there are some considerations as this is not always useful and can easily lead to problems and the entire process model can no longer be understood by others.

We only recommend modeling different processes in one model, when:

it is important to show interaction on task level.
the processes are not too complex.
it is still "easy to follow" and not too overloaded.

In this correspondence model, we trigger the process: Our sent order triggers the process at the pizzeria. The tasks get grouped: This (expanded) sub process summarizes both tasks to process pizza order. It allows you to attach our incoming request as a catching intermediate event, so the pizzeria can react to it, whenever they receive it. Our request arrives. The request could arrive (if at all) to the pizzeria at any time, either when they’re preparing the pizza or delivering it. But in any case, they proceed with their tasks. Hence, this attached intermediate message event is non-interrupting (dashed circle). It doesn’t cancel the sub processes but creates an additional token instead for the response. We pay the pizza: with out payment we reach the state pizza paid and the pizzeria is waiting for it.

Note

If you use this way of process communication, remember that both pools are self-contained and have their independent processes - including their individual goals.

Key Takeaways - Process Collaboration and Interaction

1 - Collapsed pools are used for external participants, where we don’t know or don’t need to know their inner process. 2 - Message Flows are used for interactions between Pools, but not for interactions within a pool. 3 - As soon as multiple extended pools are used, keep in mind that every pool contains a process that is self-explaining.