We can draw whatever we wish of course but as soon as we tried to make this diagram executable we’d find out that in the real world the payment doesn’t always arrive. As well as in the case of “one-way activity” antipattern, we communicate with an independent subject having a free will (the buyer) and we can’t assume that it will follow our prescriptions.
We should consider at least three outcomes in this example:
- payment arrived
- buyer informed about refusal to pay
- neither payment nor refusal arrived in due time
There is a special BPMN construct exactly for such a case called “exclusive event gateway”:
The beauty of this construct is that the process executes in parallel after passing the gateway, expecting all three events simultaneously. But as soon as one event happens, the other branches stop executing automatically and immediately.
The big regret is that BPMS vendors tend to consider the event gatway as luxury. I know several systems being declared as supporting BPMN yet not supporting this construct.
This is mistake I’m afraid because alternative messages processing can’t be avoided! The only possible way to solve the task in the absence of the event gateway is parallel gateway. But here we hit the problem of stopping other routes as soon as one of possible events happens. It can only be resolved with ugly diagram constructs and/or program code. Of course the process visibility and standard compiance become lost on the way.
This antipattern is special because it comes not from process analysts but from BPMS developers. On the other hand, it’s BPMS vendors will to eliminate this antipattern - they only need to change their attitude towards the event gateway.
As long as particular BPMS does not support the exclusive event gateway, one cannot effectively utilize the message flow. The software supports orchestration but not choreography. An old good workflow to me, whether it has the BPMN label or not.