BPMN 2.0 Message Events Vs.

Message Tasks
By Gregor Polančič - May 6, 2014

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.

Common Mistakes
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.
Conclusion
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.

Are you interested in writing for Good e-Learning? We are currently

accepting guest contributions and content exchanges in areas like
ITSM, DevOps, and Cyber Resilience. Visit our Write for Us page to find
out more, or contact a member of our team today!

Gregor Polančič
Gregor received his PhD in 2008 in the fields of software engineering and
information systems and has nearly a decade of experience in BPMN, starting to
investigate and actively use BPMN since its introduction in 2004. In addition, he
has participated in the development of one of the first BPMN modeling utilities - a
package of plugins for Visio, which were introduced early in 2005 and is the main
author of the first BPMN poster (bpmn.itposter.net), which has been translated into
several languages and already exceeded 50.000 downloads.