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” in the process and required a reaction.
However, since BPMN 2.0, different types of tasks 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 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 events 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 start and end of a process
Finally, message intermediate catch events may be placed to any location of an activity boundary to represent exception or compensation handling.
While BPMN 1.x mostly allowed the message flows to be connected straight into an abstract task, it did not exactly mimic the behavior of events.
It merely allowed 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 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 a work performed by the participant, in the case of send and receive tasks, such activities merely send or receive a message and 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, which can represent either multiple parallel, sequential or looping types of an activity. Such markers can also be used in case of send or receive tasks, additionally describing the advanced behavior of a task.
The image above represents a behavior, where different data sets influence the content of the message, thus several sequential instances of task are produced. Such behavior would be difficult to represent with the usage of message events.
Another benefit of using send and receive tasks over the message events is the capability of attaching a boundary event to a task. As such, we can handle several exceptions that could occur whilst sending or receiving a message.
As can be seen from the example above, we defined several exception flows, in case waiting for a response takes more than an hour or if 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.
Same as message start event, send activity can also instantiate a process. 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 additionally 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, the intermediate message 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 represents a common mistake when labeling send 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 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 the “Pool 1” performs a certain work (i.e. “prepare an answer”) and the second activity actually sends this answer to the “Pool 2”, where it is received in the form of a receive task, named “Receive the message”. After the message is received, task “Analyze the content” performs the corresponding work.
Another common mistake is also when modelling 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 are as such 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 lane2” actually throws a message flow and continues to the “Receive message from lane1” intermediate catch message event, where it waits for an incoming message flows, which never arrives. A similar situation occurs in case of send task “Notify lane2” and receive task “Receive response from lane1”.
In accordance with the BPMN 2.0 specifications, the communication between pools can be easily represent by using only the 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 a communication 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 modellers to more precisely express the behavior of an activity yet can also introduce new mistakes if not used correctly.
Also, BPMN users are usually more accustomed to seeing intermediate message 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.