Events are both the most powerful component of BPMN and most difficult to learn. There are many types of events (more and more with each new versions of BPMN) and it’s not clear how, where and when to use each one. As a result not only users but also developers of BPM Suites make mistakes by implementing events not exactly as the standard prescribes.
There are two levels of understanding: 1) formal and 2) meaningful. Knowing the definition is one thing and knowing how the event of given type differs from others and what are the use cases is another.
In this article I will focus on the signal event.
Like messages, signals are used to synchronize and exchange information between different parts of the process. They differ from each other by the following:
- Message flow is drawn in the diagram explicitly by the dashed arrow while in the signal case the sender (”thrower”) and receiver (”catcher”) are linked implicitly by the signal name. That is, if there is a thrower signal (marked by a filled triangle) on a diagram labelled “we won”, then look for a catcher signal (non-filled triangle) with the same label on this and/or other diagrams .
- Messages can only pass between different pools (i.e. between different processes), there is no such limitation for signals.
- The most important difference: messages are point-to-point communcations: an instance of a sender process cummunicates to one specific instance of the receiver process (let’s forget about start events for simplicity). Accordingly for a process engine to be able to deliver a message, one must specify the process ID of the recipient - e.g. by a process attribute. A signal passes from one process instance to many: to all instances awaiting a signal of given name at the moment. Thus signals are broadcast messages.
OK, it was the formal part, now let’s go to the meaningfull one.
BPMN 2.0 standard comments: “A BPMN Signal is similar to a signal flare that shot into the sky for anyone who might be interested to notice and then react.” Well I’d prefer an example somehow related to the letter “B” in BPMN, i.e. to business.
I couldn’t find a case for signals for some time. The difficulty is that the sender must be unique in the sense that at any given time there can be only one instance of such a process. It should be a process that plays a special role in the life of the organization - a trigger for a number of other processes.
At the end of the day I’ve found examples of such processes in planning.
For example let’s consider a company accepting orders from clients. If the manager successfully agrees the terms and conditions with the client then a record is placed into production orders queue. A scheduling procedure starts at the evening of each day which analyzes the orders queued and calculates the production schedule for tomorrow. Upon completion of scheduling the process related to the client order receives a signal, notifies the client and perform other actions. A simplified case indeed yet very typical for planning.
The process diagram:
It can also be implemented by by messages but in that case we’ll have to send many messages - one for each client process instance - instead of one signal:
The diagram with signals has an advantage of being simpler but only at first glance.
Generally speaking, the incoming orders may excess the production capacity, in that case some orders would remain in the queue. To take this into account the client process must check whether the order is successfully scheduled and go back to waiting the signal if not:
You can see now that the complexity of two schemes are about the same, so it’s a matter of personal preference which one to choose.