Пример:
Бумага конечно все стерпит, но как только мы попробуем превратить эту схему в исполняемый процесс, так сразу выясним, что в реальном мире платеж может прийти, а может и нет. Как и в антипаттерне “шаг с односторонним движением”, мы взаимодействуем с независимым субъектом (покупателем), обладающим свободой воли, и мы не можем полагаться на то, что он будет действовать предписанным нами образом.
В рассматриваемом примере мы как минимум должны предусмотреть три варианта:
- платеж поступил
- покупатель уведомил об отказе от оплаты
- платеж или отказ не поступил в указанный срок
В BPMN специально для такой ситуации предусмотрена конструкция под названием “исключающая развилка, управляемая событиями” (exclusive event gateway):
Прелесть этой конструкции в том, что после развилки процесс распараллеливается и начинает ожидать одновременно всех трех событий. Но как только одно из событий происходит, исполнение остальных ветвей автоматически и немедленно прекращается.
К большому сожалению, поставщики BPMS склонны относиться к event gateway как к излишеству. Мне известно несколько систем, разработчики которых декларируют приверженность BPMN, но не поддерживают эту конструкцию.
Боюсь, это ошибка с их стороны - ведь задача обработки альтернативных сообщений никуда не денется! В отсутствие event gatway единственный путь - использовать параллельную развилку (parallel gateway). Но тут возникает проблема “гашения” остальных путей при приходе одного из сообщений, которую приходится решать при помощи искусственных конструкций в диаграмме и/или написания программного кода. Конечно, ни о визуальной наглядности процесса, ни о следовании стандарту речь при этом уже не идет.
Таким образом, рассматриваемый антипаттерн необычен тем, что источник его - не процессный аналитик, а разработчик BPMS. С другой стороны, в силах поставщиков BPMS сделать так, чтобы этот антипаттерн исчез - для этого им достаточно изменить свое отношение к поддержке event gateway.
Пока конкретная BPMS не поддерживает event gateway, нормально работать с сообщениями (message flow) в ней невозможно. Оркестровка в ней поддерживается, хореография - нет. На мой взгляд, такая система - это старый добрый workflow вне зависимости от наличия на нем лэйбла BPMN.
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.