BPMN Diagrams – Flowing Intermediate Message Events

bpmn diagram

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.

BPMN diagram of message intermediate events receiving

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.
example of incorrect bpmn diagram of intermediate message event

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

example of corrected bpmn process

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.

bpmn example of intermediate message event sending message

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]

9 thoughts on “BPMN Diagrams – Flowing Intermediate Message Events

  1. What software do you use for BPMN diagrams? We use Visio for “swimlane” diagrams, but I think BPMN is more rigorous. Also, how do mesh use cases and BP diagrams during analysis. Do you do the process modeling first or use cases first?

    Thanks.

  2. Tim,

    Thanks for reading and commenting!

    We’re developing a set of visio stencils for BPMN right now – the ones that exist (that I’ve found) don’t cover all of the 1.0 spec, and leave a little to be desired in terms of functionality. We’ll publish our stencil here (for free!) once we finish it.

    As to the other question – the short answer is “we’ll cover this in a future post”, the long answer is “we’ll cover this in a future post, I’ve emailed you my not-ready-for-publishing thoughts on it”. I hope folks will stick around for the answer.

    Thanks again,
    Scott

  3. Great series on BPMN!

    In the first diagram you use an intermediate message event for receivng a message from the broker. The process step ‘SELL ACME STOCK’ waits for the message to be received.

    In the third diagram (the corect diagram) you let the message flow go directly to the process step ‘SELL ACME STOCK’. Does this mean that this step in the third diagram will not wait for the message to be recieved?

    Why did you make this change or does this has no impact on the process flow?

    Thanks in advance.
    Stefan

  4. Stefan,

    Welcome to Tyner Blain and thanks for your comments!

    You’re right – the investor would receive the message, buy the stock, and then sell the stock. In our zealousness to fix the previous mistake, we overlooked that. Great catch! I’ll leave it as it is, and keep our comments here – I think the combination makes for a better learning example for other.

    Thanks again!

  5. Dear Scott,

    congratulations for your posts on the BPMN, they are very interesting and useful.
    I noted the BPMN 1.1 spec (2005-07-31) have changed the Message Flow Rules. You can find them in the section 3.4.2 in which the Intermediate Event can be the source for Message Flow. The only restriction is that Intermediate Event can not be a source for Message Flow if the target is a Task!

    Now, according to BPMN 1.1 spec, in your wrong diagram you can use a Message Flow from the first Intermediate Message Event (Broker suggests purchase of ACME) to Start Message Event in Investor Pool.

    Is it right?
    Thanks in advance
    Antonio

  6. Antonio,

    Thanks very much for the compliment and commenting. And welcome to Tyner Blain!

    As to your point about intermediate message events sending messages across pool lines, at the time I wrote the article, I felt like the spec was a little ambiguous, and tried to cache what I drew as an interpretation. I am happy to defer to your interpretation. My recent projects have taken me away from BPMN (at least for a while), so I’m sure you know better than I.

    Thanks for letting all of us know what you’ve found!

Leave a Reply

Your email address will not be published. Required fields are marked *