Collaboration
A collaboration represents the interaction between multiple participants in a business process. Each participant is defined with a unique ID and name, and is associated with a specific process definition through the processRef attribute.
A collaboration does not have a distinct visual representation on its own. However, the presence of at least one pool in the diagram indicates that it is part of a collaboration.
In the XML, a collaboration is defined by the <collaboration>
element containing <participant>
child elements. Each <participant>
is associated with a specific process via the processRef
attribute, which references the ID of the process definition.
<definitions . . .
<collaboration id="Collaboration_1px6goz" name="Collaboration">
<participant id="Participant_1" name="Participant One" processRef="Process_01" />
<participant id="Participant_2" name="Participant Two" processRef="Process_02" />
</collaboration>
Besides, collaboration may have isClosed
attribute that is ignored in Jmix BPM.
Here are Collaboration properties:
- ID
-
Identifies the collaborations.
- Name
-
The name property describes what the collaboration does. Its maximal length is 255 characters. But the name isn’t displayed anywhere on the diagram.
- Documentation
-
Place here a process description. The maximal length is 4000 characters.
Message Flows
Collaboration objects often involve message flows, which illustrate the communication between different pools. Message flows indicate how information or tasks are exchanged between participants, enhancing the understanding of inter-process interactions.
A message flow is depicted as a dotted line in BPMN and is used to illustrate the flow of messages between two participants (pools) that are prepared to send and receive them. It does not imply a specific order for the messages exchanged.
Message flows can connect:
-
Two nodes in different pools
-
A node in one pool to a different pool
-
Two pools
However, message flows cannot link nodes within the same pool.
Flowable does not handle the actual reception of messages, as this depends on the application environment. Developers must implement the logic for receiving messages, which may include connecting to external services like JMS or REST APIs.
While message flows are useful for visualizing interactions between processes, they are typically not considered during the execution of business processes. Their primary role is to serve as documentation tools to clarify how different entities communicate within a BPMN model.
Examples
You can use collaborations in different scenarios. In the first case, using the collaboration allows to place the main process and its subprocess on the single diagram:
Message flows just illustrate that the same subprocess is called from the different points of the main process. |
This approach can be more convenient than storing the main process and its subprocess in separate XML files.
In the second case, the inter-process communications can be modeled:
Here, the process One sends a message to start process Two, and then waits until a message from the process Two will be received. Or the timer event fires and the signal from process One starts process Three.
Again, it is better to see all collaborating processes together.