BPMN Diagrams – Flowing Intermediate Message Events

One of the 9 intermediate events in BPMN is the message intermediate event. There are two ways to use the message intermediate event, as an element in the sequence flow, or as an attachment to the boundary of an activity for exception processing. See how to use message intermediate events in a sequence flow. [Updated to correct a glaring error on Aug 22nd, 2006]
Background

We presented an introduction to BPMN diagrams almost a month ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

Flowing Freely

Business process modeling is about a lot more than showing a sequence of steps and decisions – it is also about showing communication. Communication can be achieved with message flow objects from an activity in one pool to an activity in another pool. Or a message can come from or be received by a message intermediate event within the sequence flow of a process.

In the following BPMN example, a message start event initiates a process, which will wait until it receives another message before being completed.

The broker (who’s internal process is not defined, using what is called a “black box swim pool”, sends a message which is received by the investor, initiating the purchase of ACME stock. The investor’s process then waits until another message is received from the broker, suggesting sale of the stock. The investor then sells the stock and the end of the process is reached.

The two key takeaways are that the message intermediate event is a “step” – the equivalent of “Receive Broker Suggestion”, and that the Investor’s process waits until it receives notification from the broker in the form of a message. After the message has been received, the Investor’s process can continue, but it is hanging in limbo until then.

This BPMN example shows an intermediate message event that is an element of the sequence flow. If the message is never received, the flow will never finish.

[Update: Previously, there was a section explaining how intermediate message events can be used to send messages, with an example showing how message flow is originated from the intermediate message event. However, this is not supported, per section 8.4.2 of the 1.0 version of the spec.

• The original diagram has been replaced with one that is marked up to show the error.
• The original text associated with that diagram has been replaced with text explaining the error.
• A new diagram depicting the proper way to model the same business process has been added.]

[Start Changes 23 Aug 2006]
BPMN intermediate message events can be used to send messages, but they can not be the source of message flow because no intermediate events can be the source of message flow. What this means is that an intermediate message event can not send a message to a participant in a different pool. All message flow travels from one pool to another.

To demonstrate messages being sent from the broker to the investor (for the process diagrammed incorrectly above), we would use the following diagram.

In the corrected diagram example, we see the broker’s process as well as the investor’s process. After ACME generates a “Buy” signal, the broker calls the client and suggests that she buy shares of ACME. After ACME generates a “Sell” signal, the broker notifies the investor to sell her ACME stock.

An intermediate message event within normal flow can be used to send a message, according to table 9.8 in section 9.3.4 of the spec. The spec does not explicitly explain the apparent contradiction of this statement with the prohibition against message flow originating from an intermediate event. Our interpretation is that an intermediate message event, when sending a message, must be sending it to another participant within the same pool (who is not eligible to receive message flow).

The following example shows how this might happen.

The broker, after the “ACME Generates ‘Buy’ Signal” task, uses an intermediate message event to send a message to other brokers (within the same swim pool) notifying them of the buy event. The process has also been updated to show an alternate start to the process – a message start event can trigger the flow when the notification message is received.

Message flow is shown to the investor, but only from the task “Suggest Purchase…”

Summary

Intermediate message events can be used either to “halt” a process while it waits for a message, or they can be defined when messages are sent from within a business process. When intermediate message events are used to send messages, they can only send them to other participants within the same swim pool, because they can not be the source of message flow (even if they are the source of messages).

[End Changes 23 Aug 2006]