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 modelers to represent more types of behavior. Among these, the new send and receive types have now blurred the line between BPMN message tasks and events. In this article, we will discuss the differences between message events and the 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 behavior 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 originally 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 fundamentally 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 modeler to add different markers, which can represent either multiple parallel, sequential or looping types of activity. Such markers can also be used in case of send or receive tasks to describe advanced behavior.
The image above represents a behavior where different data sets influence the content of the message, and thus several sequential instances of the task are produced. Such behavior would be difficult to represent using message events.
Another benefit of using send and receive tasks over message events is being able to attach a boundary event to a task. As such, we can handle several exceptions that could occur whilst sending or receiving a message.
In the BPMN example above, we defined several exception 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, namely an envelope surrounded by a circle.
By using a receive task that instantiates a process, we can define a syntactically sound model without needing to also define a start event.
Benefits of Using Intermediate Message Events
When defining a flow of a process, 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 the receiving of 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 a report is instantiated anew.
However, in case of receiving an invitation to a meeting, a note is written by the performer of the activity while the main activity of writing a report is not interrupted. Such behavior could not be represented by using only send and receive tasks.
A common mistake when using send or receive activities is their labeling. 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 labeling send message activities.
As can be seen from the example above, an activity is labeled in a way to represent both preparing and sending an answer, which is not in accordance with 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 certain task (i.e., ‘Prepare an answer’) and the second activity actually sends this answer to Pool 2, where it is received in the form of a receive task named ‘Receive the message’. After the message is received, the task ‘Analyze the content’ performs the corresponding work.
Another common mistake occurs when modeling the communication between several lanes in a pool. Intermediate message catch and throw events are tightly coupled with message flows. The latter are 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 receive 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’.
In accordance with the BPMN 2.0 specifications, the communication between pools can be easily represented by using only sequence flows, as represented in Figure 9.
This 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.