BPMN Basics: Providing Information to a Process

One aspect of BPMN that usually surprises newbies is attention to what entities or actors are inside the process vs outside.

In traditional flowcharting, for example, the Customer is often represented as a swimlane in the Seller’s process, but not so in BPMN.  A BPMN process represents one participant’s view of the steps, that of the process automation engine… no matter that few BPMN models are intended for automation.  The Seller typically has no knowledge of the Customer’s process.  Actually, the Customer often has no defined process at all.  In BPMN, the Customer, along with various Suppliers, Regulators, and other interacting stakeholders, is represented abstractly in the Seller’s process as a black-box pool.  The Customer is outside the Seller’s process.

So the question arises, how is information communicated to the process from outside?  The most familiar way is via a message, represented in the diagram as a dashed line connector called a message flow.  A message always connects a message node in the process – either an activity or a message event – with an entity or actor outside the process.  An email exchanged between two actors inside the process is NOT a BPMN message.

BPMN defines a variety of message event types that specify different ways that the process reacts upon receipt of a message flow.  They all are denoted by a circle shape with a white envelope icon inside, and their specific behavior is indicated by the border style and placement in the diagram.

• A message start event, a thin single ring with an outgoing sequence flow and no incoming, in a top-level process diagram means that a new process instance is created upon receipt of the message.
  
• A catching message event, a double ring with sequence flow in and out, means the process stops and waits for the message flow to arrive, and then proceeds.  It doesn’t do anything else, just stop then go.
  
• If the catching message event shape is attached to an activity boundary, no sequence flow in and one sequence flow out, it is called an interrupting boundary event.  It means that if the message arrives while the activity is running, the activity is terminated immediately and the flow proceeds on the sequence flow out of the event, called the exception flow.  If the activity completes and the message does not arrive, the flow proceeds on the sequence flow out of the activity, called the normal flow.
  
• If a message boundary event is a dashed double ring, it is non-interrupting, meaning if the message arrives while the activity is running, do not terminate the activity but instantiate a new parallel thread of the process on the exception flow.  When the activity completes, the original thread continues on the normal flow, so in this case the normal flow and exception flow threads are conditionally parallel, and merging them downstream requires an OR-gateway join.
  

That’s a lot of different ways to respond to an incoming message flow, but wait, there’s more!

• An event subprocess is a special kind of subprocess that is triggered by an event.  It is drawn with a dotted border and has no incoming or outgoing sequence flows. A message event subprocess is triggered by an incoming message, represented as the subprocess start event.  (A regular subprocess is triggered by incoming sequence flow, not an event; it must have a None start event, meaning no trigger icon inside.)
• If the event subprocess has a message start event shown as a solid thin ring, it is interrupting, meaning the process level in which it is placed is terminated immediately and the event subprocess runs.
  
• If the event subprocess has a message start event shown as a dashed thin ring, it is non-interrupting, meaning the subprocess runs as a separate thread in parallel with the regular process level.  The process level is not complete until both the regular flow and the event subprocess are complete.
  

Your head is spinning, I see.  The point is BPMN provides many different specific behaviors that can occur on receipt of a message, information sent from an entity or actor outside the process.  But all of them have a couple things in common.  First, the information is pushed by the external party, so the timing of the message is outside the control of the process or its actors.  The process doesn’t know exactly when it will arrive.  Second, the triggered behavior occurs immediately upon receipt of the message.

If you think about those two things in combination, you realize that it cannot be the only way a process obtains information from outside.  There must be a way where the process pulls the information when it wants to get it.  And there is, but it is less well-known.  It uses a cylinder shape called a data store, meaning information stored in a file, database, or application outside the process.  Dotted arrow connectors called data associations represent reading and writing the data store.  If the arrow comes out of the data store, that is a read operation; if the arrow goes into the data store, that is a write.

It is generally understood that both the process and external entities and actors can read or write information in the data store, presenting an alternative way to get information from an external source into a process.  The external source writes it to the data store, and sometime later the process reads it from the data store.  This shared data pattern works differently from a message.  The process is not a passive recipient, but actively gets the information when it wants to use it.  If the information isn’t available in the data store, the process may need to wait and try again, called polling.  With message, you don’t need to poll; nothing happens until the message arrives.

Above you see an example that illustrates both mechanisms.  When you submit an order to an online store, the store’s website (acting as a proxy for you, the Customer) sends the message labeled Order to the Seller’s fulfillment process.  That message provides details about the items in the order, but often it does not contain your credit card information.  If you are a registered Customer, your credit card information is stored in your profile, the data store labeled Account Info.  This is not only more secure, but saves you the trouble of typing it in.  When it receives the Order message, the Seller’s process reads the credit card info from the data store and processes the transaction.  If your credit card on file doesn’t work any more, the process may send you a message asking you to update it and submit again.  You are then writing the data store, and on Submit the process is reading it again.

Both mechanisms of providing information are involved in the same process, and clearly both have their place.  Students in my BPMN Method and Style training ask me, which method should I use, message or shared data?  And I always respond, do it the way it actually works.  If the process is a passive recipient and responds immediately upon receipt, that’s a message.  If the process actively pulls the information when it is ready to use it, that’s shared data, a data store.

One small side note of importance to modelers:  A data association to or from a data store can connect only to a process activity at the other end.  But remember, the Customer pool is black-box; it contains no activities.  So a dotted arrow connector from a black-box pool to the data store, as shown in the diagram above, cannot be a data association!  To me, that’s a bug in the spec, since the intended semantics – even though not executable – are extremely common in real-life scenarios.  But not to worry:  An association connector, configured as a One-Way (i.e. directional, with an arrow), looks exactly the same as a data association, and it is allowed anywhere in the diagram.

If you want to learn the ins and outs of BPMN modeling, check out my BPMN Method and Style training.  It is self-paced, and includes 60-day use of the Trisotech Workflow Modeler and post-class certification.