An example:
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.
In fact, I’d go so far as to say I’d like for vendors who support this construct to respond to your blog and go on the record. I don’t particularly like the way this construct is drawn on the page, but it is eminently useful. There are workarounds but it requires quite a bit more message passing and attaching events to activities to make it work ( and this is how we’ve been able to work around the lack of this construct in the past )
Imagine, for example, a single activity with all three events attached to it: the timer, the refusal event, and the payment event (keeping in mind, refusal and payment could be attributes of the same “response” event if we wanted). The activity must be designed to “not exit” so that it stops and waits for one of these three events to transpire.
I think diagrammatically it is cleaner than the event gateway in some respects, but there’s no “never-ending activity” as a first-class notion in BPMN (um, that I’m aware of, the spec is big and getting bigger!). And I think there are even more complicated scenarios than the one that you describe that really call for an event gateway to exist.
Scott
Thank you for sharing thoughts. I had this hope in mind. Some BPMS developers will read this post for sure.
Of course the attached events is the option but implementing it probably isn’t easier. Anyway, the systems I have in mind lack both.
As for individual preferences - I considered the solution you propose but I didn’t like the idea of combining different messages into one. Such a diagram would require annotations while the diagram with the event gateway speaks for itself.
The proposed diagram is a bit eclectic - one may ask why sending the message isn’t implemented by intermediary event - but who cares.
Анатолий, а что произойдет если сообщение от покупателя об оплате будет отправлено по истечению тайм-аута?
Каким процессом будет обработано сообщение? или просто проигнорировано?
В приведенной диаграмме сообщение будет проигнорировано. Предполагается, что “Разобраться с задержкой” сделает все что надо в ручном режиме.
В BPMN 2.0 можно воспользоваться non-interrupting attached timer event, чтобы разбирательство с задержкой не прекращало ожидания сообщения.
Варианты могут быть разными для разных ситуаций, единственно правильного решения тут нет. Я ставил перед собой другую задачу - показать широко распространенную и при этом явно неправильную схему.
Все очень правильно, но меня одно в этом конструкте озадачивает. Зачем нужна сплошная стрелка от “send invoice” к блоку решения? Логичнее и понятнее было бы, если от send invoice вниз шло согласование, а вправо - блок “ожидание согласования” потом “ответ получен вовремя? да/нет” и потом уже по ветке “да” три варианта реакции в зависимости от ответа. Что я думаю не так? Спасибо.
Подумал еще, кажется я понял, чего я не понял
все так на самом деле и есть, просто символ в значке незнакомый.
Nice anti-pattern – though I’m not sure it is always an anti-pattern. In some cases you want to create simple, high-level models with not too much detail (what Bruce Silver calls Level 1/descriptive modeling). Then the first example is probably better.
I’d like to be able to combine the high-level and the more detailed view in one model, but I’m not sure this is possible. You could create a “receive payment” subprocess, and put the event gateway in the subprocess diagram, but it probably wouldn’t help, as you need to show the “exception handling” (process delay, process refusal) at the top level.
Jon
We use DFD for high-level modeling. It shows inter-process communications via messages, signals and (most often) data/business objects.
I don’t believe in high-level and low-level modeling of the same business process. The can only represent two sequential stages of process discovery but as soon as you dived into the low-level model there is no way back to high level.