At the risk of raising the ire of those that want to avoid precise meaning in their process flow diagrams, I recommend a study of Anatoly Belychook's handy primer on the use of the signal event.
I would emphasise that the signal event allows the ultimate "late binding". You do not have to design the world process ... only the bit you are in control of at the moment. When you come to an event that you know will be useful to another bit of the enterprise ... Signal ... then when a use is found in another bit of process design you do not have to redo the process design work again. Of course, you will need a way to hunt down these useful signals and some standardisation of how they will look in your enterprise.
For those of us that look forward to the executable process, Signals also provide a simple communication method between parallel flows within the same pool and avoid the process designer having to think too much about implementation level stuff like writing data to a store somewhere.
see also
Subscribe to:
Post Comments (Atom)
6 comments:
Good point about "world process", Dave, let me use it.
As for the communication within a single pool, either the diagrams using this pattern I've seen were badly wrong or I missed something important about BPMN. They all assumed that a signal will go from this point to that within a single process isntance whereas I believe it'll be catched by all instances, screwing the communcations completely.
Your welcome to the point! I use most of your collected works anyway.
I may have been guilty of thinking about how I would have implemented signals rather than looking at actual instances because my interested dated back to a time when Intalio did not even let you draw them. Looking at the BPMN spec gives food for more thought. The flare analogy is certainly becoming inappropriate.
(1) There is a distinction between interrupting and non-interrupting events so For an interrupting Event (Error, Escalation, Message, Signal, Timer,
Conditional, Multiple, and Parallel Multiple), only one Event Sub-Process for the same Event Declaration may
be modeled. This excludes any further non-interrupting handlers for that Event Declaration.
This could be interpreted as a single point-point communication for interrupting signal events.
(2) For non-interrupting events, I do not see that identifying data is precluded from the signal event.
(3) Given the disconnect between signaller and signalled, I did wonder how you should deal with arriving at a signal event catch after the throw has occurred.
(1) I believe this only means that you can't have more than one hanlder in a given (sub)process model. For a timer or escalation the event propagation is limited by a given process instance. Yet for a signal one handler in a process model may mean hundreds of active handlers, one per each process instance.
(2) Sorry, didn't get this point.
(3) If a receiving process instance missed the signal because it arrived to the catching point after the signal happened then the receiving process will wait unlimited amount of time until the signal will be raised once again by whoever.
Has anyone actually implemented signal events at execution level? I have high hopes for the attitude of Activiti but they appear to be planning only a partial implementation after November.
After a fairly extensive search of writings on subject, I suggest that you are in the lead on thought about this Anatoly, but that there is a heap of work to be done to deliver a working pattern that is both understandable at the business level, and consistently implemented. Of course, with business process you are not limited to a single application package or development, the process could involve multiple enterprises with independent execution engines.
The signal will have to carry some information with it (even the flare analogy allows for a distinction between distress or calling for a pilot) the listening instances will have to work with that information to determine the necessary action.
Try BizAgi. I believe it's the most complete executable BPMN at the moment. There are messages, signals and even compensations - all of them working. Free fully-functional non-expiring evaluation available.
Unfortunately they implemented messages and signals so that one cannot pass the information. But there is a workaround: direct manipulation of data within the context of other process.
We successfully implemented a demo process similar to one presented in my original post, hopefully will publish a video some day. In case of trouble please don't hesitate to ask.
I believe Signal event is supported in Oracle BPM11gR1, using Oracle event delivery network.
Post a Comment