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.

Graphical Notation

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.

XML Representation

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.

Properties

Here are Collaboration properties:

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.

Behavior

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.

Documentation Purpose

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:

collaboration example 1

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:

collaboration example 2

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.