In Business Process Model and Notation (BPMN 2.0), two primary mechanisms for handling inter-process communication: Message Events and Message Tasks. Though both enable message exchange, they serve distinct purposes and are used in different scenarios.
Before the BPMN 2.0 specification, there was never any confusion between tasks and events. ‘Tasks’ were treated as atomic activities in a process flow which could not be broken down into finer detail, whereas ‘events’ represented something that happened during the process and required a reaction.
However, since BPMN 2.0 was released, different BPMN task types can now be defined, enabling modellers to represent more types of behaviour. Among these, the new send and receive types have blurred the line between BPMN message tasks and events. This article will discuss the differences between message events and send and receive tasks.
Message Flow in Tasks and Events
In essence, message event types are either throwing or catching and can:
- Start a process (message start event), which creates a new instance when the message arrives
- End a process (message end event), which ends the current process instance when the message is sent
- Resume a process flow (message intermediate catch event) when the message arrives
- Send a message (message intermediate throw event) somewhere between the process start and end points
Finally, message intermediate catch events may be placed at any location of an activity boundary to represent exception or compensation handling.
While BPMN 1.0 mostly allowed the message flows to be connected straight into an abstract task, it did not exactly mimic the behaviour of events. Instead, it merely made it so that a message MAY be sent to or received by an activity in addition to the work it initially performed.
With the introduction of BPMN 2.0’s send-and-receive tasks, we can define that a task in the process always sends or receives a message. After the message is sent or received, the task is considered complete and no other work can be performed.
While there are certain specifics, there are no differences between message events and send or receive tasks. Bother have their advantages and disadvantages, which we will look at now:
Benefits of Using Send and Receive Tasks
Whilst activities usually represent work performed by the participant, in the case of send-and-receive tasks; such activities merely send or receive a message. As soon as this happens, they are considered finished. It is important to stress that such activities still define the presence of a performer, whereas events do not.
Standard activities enable the modeller to add different markers, representing multiple parallels, and sequential or looping types of activity. Such markers can also be used in sending or receiving tasks to describe advanced behaviour.
The image above represents a behaviour where different data sets influence the content of the message, and thus several sequential instances of the task are produced. Such behaviour would be difficult to represent using message events.
Another benefit of using send-and-receive tasks over message events is attaching a boundary event to a task. We can handle several exceptions while sending or receiving a message.
In the BPMN example above, we defined several exceptions flows in case waiting for a response takes more than an hour or an internal software error occurs. If there is no such exception, the message is received, and the next activity is performed. Similar boundary events can also be applied to a send activity.
Similarly to message start events, send activities can also instantiate processes. To this end, a slightly different symbol is used: an envelope surrounded by a circle.
Using a receive task that instantiates a process, we can define a syntactically sound model without defining a start event.
Benefits of Using Intermediate Message Events
When defining a process flow, there are several situations where send and receive activities cannot be used. In this case, Intermediate events are preferred.
Firstly, if we wanted to model a situation where receiving a message can cause an exception when performing an activity, only interrupting boundary intermediate message catch events can be used.
Secondly, if we want to represent a situation when receiving a message does not necessarily end an activity, non-interrupting boundary intermediate message catch events can be used.
The above example shows a user activity of writing a report, which can be interrupted by receiving an important update. In this case, updating the files is performed and writing an essay is instantiated anew.
However, in case of receiving an invitation to a meeting, a note is written by the performer of the activity. In contrast, the main activity of writing a report is not interrupted. Such behaviour could not be represented by using only send and receive tasks.
Common Mistakes
A common mistake when using send or receive activities is their labelling. As already stated, send activities explicitly define that a message should be sent, and no further task can be performed in the scope of such activity. Figure 6 demonstrates a common mistake when labelling sends message activities.
As can be seen from the example above, an activity is labelled in a way to represent both preparing and sending an answer, which is not by the BPMN specification.
The correct solution would be to split the ‘Prepare an answer and notify the user’ into two separate tasks, one for preparing an answer and the other for sending it.
In this case, the first activity in Pool 1 performs a specific task (i.e., ‘Prepare an answer, and the second activity sends this answer to Pool 2, where it is received in the form of a receive task named ‘Receive the message’. After receiving the message, the task ‘Analyze the content’ performs the corresponding work.
Another common mistake occurs when modelling the communication between several lanes in a pool. Intermediate message catch and throw events are tightly coupled with message flows. The latter is only used to represent the communication between two pools and, as such, are not appropriate to be used between lanes of the same pool. The same incorrect usage has been widespread when using send and receives tasks as well.
In the example above, the intermediate message throw event ‘Notify lane 2’ actually throws a message flow and continues to the ‘Receive message from lane 1’ intermediate catch message event, where it waits for incoming message flows which never arrive. A similar situation occurs in the case of the send task ‘Notify lane 2’ and the receive task ‘Receive response from lane 1’.
By the BPMN 2.0 specifications, the communication between pools can be easily represented by using only sequence flows, as represented in Figure 9.
Conclusion
ConclusionThis blog article addresses the differences between message events and send or receive tasks. While the main purpose of both types of elements is to represent communications between two or more pools using a message flow, several distinctive differences between the two can be noted.
Firstly, we can attach several different boundary events to send and receive tasks. Furthermore, additional markers can be added to the tasks to represent standard, sequential, or parallel loops. On the other hand, intermediate catching message events can be attached to activities in order to represent an exceptional flow.
New types of activities enable business process modelers to express more precisely the behavior of an activity. However, they can also introduce new mistakes if not used correctly.
Also, BPMN users are usually more accustomed to seeing intermediate messages throw and catch events. The usage of send and receive activities might be ambiguous if they are used solely to represent sending and receiving message flows, respectively.
