Thanks to
Rick Geneva , I do not have to describe 'What' a Signal Intermediate Event is used for in a business process. He has provided the
use cases for this useful element of BPMN. I responded quickly -
now all we need is standard implementations in products like Intalio, pointing out the lack of implementation of signal in tools that support BPMN through to an executable. Of course, we can work around any lack of implementation of signal within a BPMS toolset but the meaning behind signal is not like anything else so a real implementation or common patterns of workaround would help.
You can draw the signal event in Intalio so at least the business process designer can start with a proper description of the use case even if the level-3 technical implementation diagram will differ in shape.
The BPMN specification says
A signal is a generic, simple form of communication
- Within pools (same participant)
- Across pools (different participants)
- Across Diagrams
It is communication in its simplest sense ...
- shouting out not knowing if anyone is listening, or has heard
- and listening for shouts unaware of any other listeners
Signalling within pools
This very important as BPMN deliberately restricts message flows to communcation
between pools so if you have parallel flows within a pool and you wish to communicate an
event between the flows, a signal is the only BPMN mechanism available. For example, a simple synchronisation of parallel flows would be represented like this in BPMN.
Without signal, the workaround is to use a message via another pool like this ...
This does have the merit of working in Intalio but clearly deviates
from the simple expression of the business process. Adding more
listenerswould seriously obscure the meaning of the business model with implementation artifacts.
Signalling across pools
In communication across pools, the signal has a single sender and one or more listeners while, with messages each sender is connected to a listener. Here is a simple synchronisation between parallel processes.
Replacing the signals with messages even in this simple case loses the clarity of expression of the business process
In this case the single activity of signal in master process is replaced by two message event throws and it gets progressively more complex as more processes are introduced. In addition, for every participant introduced, a change has to be made to the model of the process doing the signalling although in practice no change is made to the real business process.
Across Diagrams
The lack of a signal implementation is especially felt where the business is modelled across a number of diagrams and there is a common need for communication. An over-riding interrupt perhaps. Each separate diagram may represent a division of the organisation by end-to-end process or department with separate reactions to the communication (like a fire alarm). Implementing without signal has similar problems to the above but the separate diagrams make the implementation and business models even harder to relate together. The link element is a candidate for solution here, but implementation is missing in Intalio. So we really need a full publish - subscribe service. RSS might be a practical solution to explore.
Conclusion
There is a real need
- for an implementation of signal events within tools that develop the executable from the BPMN model.
- in the absence of the implementation of signal events, a well understood implementation method or pattern is required for each of the uses of signal.
