More On Essential And Redundant BPMN: Events
Blog: Process is the Main Thing - Anatoly Belychook
Last time we found out that only two of five BPMN gateways are absolutely necessary: XOR and AND.
Now let’s consider events. BPMN events are categorized by type (13 variants) and position (8 variants). Let’s consider event types:
1. None
Neither start nor end events are not strictly necessary – the diagram below is formally correct. Here Task 1 is the implicit start (no input flows), Task 2 is the implicit end (no output flows).
However such diagram looks incomplete and the question arises: was it done intentionally or it’s just a half-work? Therefore the good style supposes the start and end events to be always presented.
As for the intermediate none event, it depicts a process milestone. Not necessary yet useful and intuitive.
2. Link
If it came to the link event then probably it’s time for the decomposition – i.e. to leverage subprocesses. I’d recommend avoiding this event.
3. Timer
Helpful, intuitive, widely used in practice.
4. Conditional
Conditional event is helpful in certain scenarios yet it’s not the most intuitive. One of BPMN benefits is that, if used properly, it’s comprehensible by users without special trainings. It won’t be the case if conditional event is used.
The second issue is that it isn’t supported by most process engines. (In fact I haven’t seen a single one yet.)
But it isn’t that sad: conditional event can be replaced by a timer combined with XOR gateway:
= | ||
= |
Potential problems of such replacement are excessive engine load and messing the execution log.
5. Message
The major inter-process communication tool (along with data-based communications).
6. Signal
Signal is different from messages in two aspects. First, message is point-to-point while signal is publication-subscribtion. If one needs to connect a sender with a number of receivers then a signal can be replaced by a looped send task:
= |
Secondly, message assumes tight while signal – loose coupling. In order to instantiate process B from process A via a message, one needs to have process B model ready:
It’s not the case if signal is used – A and B models may be developed independently. What they they only need to know about each other is the signal name and the payload format, optionally:
When dealing with a complex system of processes, this signal feature becomes much valuable.
There is a workaround for signal in this scenario, too:
Here process A sets a flag in the datastore and process B checks it periodically. If flag isn’t set then B ends, otherwise it resets the flag and proceeds to the core job.
7. Terminate
8. Error
9. Escalation
These three events are more or less interchangeable:
= | ||
= |
Escalation has a valuable feature – it can create a new token and launch an async control flow in the outer process scope with the help of intermediate escalation initiator and non-interrupting boundary catcher.
10. Multiple
It’s relatively easy to workaround this event.
Catcher:
= |
Initiator:
= | = |
11. Parallel multiple
It’s quite easy to workaround the parallel multiple event if there are just two events:
= |
However in case of many events we’d run into the combinatorial explosion with this technique. Yet in practice I didn’t ever need even two start events. An if I did, I’d use CEP (Complex Event Processing) instead of BPMN.
12. Cancel
13. Compensation
Cancel and compensation events, transactional subprocess and compensation tasks are quite useful in a special scenario “all or nothing”. An example: I’m going to go to the conference. To be prepared, I need: 1) get my submission accepted by the conference committee, 2) book the plane, 3) book the hotel, 4) get my company’s approval on the expenses. It’d be better to perform all the activities in parallel – the less time available, the lower chances to succeed. Every single activity may not succeed and in this case a non-trivial set of compensating activities should be performed, e.g. if the submission was rejected and the plane was booked then the booking should be cancelled etc.
Transactions subprocesses and compensations provide an elegant solution to this kind of tasks. However they are relatively rare so one may not care about transactions and compensations most of the time.
Summary: from total number of 13 event types –
- 4 are essential – none, timer, message, terminate
- 2 are useful – signal, error
- 4 are for special cases – conditional, escalation, cancel, compensation
- 3 are practically useless – link, multiple, parallel multiple
Now let’s consider event categories by position, using message as example:
1. Start
2. End
3. Intermediate initiator
4. Intermediate catcher
These four are essential.
5. Attached event interrupting
Helpful, intuitive, popular.
6. Attached event non-interrupting
Not very intuitive. Can be workarounded, more or less:
= |
7. Event subprocess interrupting
8. Event subprocess non-interrupting
Event subprocesses are very similar to attached events. The major difference is that unlike event subprocess, one can’t attach an event to the top-level process. However it’s always possible to make a subprocess from the top-level flow:
Conclusions
Summing up, 5 event positions from 8 are essential: start, end, intermediate initiator and catcher, attached interrupting (this is actually BPMN 1.x subset).
If only essential plus useful types (6 totally) and essential positions (5 totally) are taken then there would be 30 combinations potentially possible from which only 19 are valid:
For the sake of comparison, the total number of valid event combinations in BPMN 2.0 is 63.
Leave a Comment
You must be logged in to post a comment.