Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Необходимые и избыточные элементы BPMN: события

В прошлой заметке мы выяснили, что при всем многообразии развилок в BPMN, строго необходимыми являются две из пяти: “или/или” и “и”.

Перейдем к событиям. События в BPMN классифицируются по типу (13 вариантов) и по месту (8 вариантов). Рассмотрим классификацию по типам:

1. Простое событие

Строго говоря, начальные и конечные события необходимыми не являются – так, приведенная ниже диаграмма формально корректна: здесь Task 1 – неявное начало (т.к. нет ни одной входящей стрелки), Task 2 – неявный конец процесса (нет ни одной исходящей).

Но такая диаграмма выглядит незаконченной, и хочется спросить у ее автора: это так специально сделано или работа не доведена до конца? Поэтому хороший стиль предписывает всегда явно обозначать начало и конец процесса.

Что касается простого промежуточного события, то оно обозначает промежуточный этап, веху, milestone. Вещь пусть и не необходимая, но интуитивно понятная и полезная.

2. Событие-ссылка

Если вам понадобилось событие-ссылка, то скорее всего, вам пора прибегнуть к структурной декомпозиции – проще говоря, начать выделять подпроцессы. Я бы рекомендовал обходиться без этого события.

3. Событие-таймер

Полезен, интуитивно понятен, часто используется на практике.

4. Событие-условие

В некоторых сценариях событие-условие бывает полезно, но оно интуитивно неочевидно. Одна из сильных сторон BPMN – то, что эта нотация, при экономном использовании, позволяет создавать процессные диаграммы, понятные даже неподготовленным пользователям, не прошедшим обучение. Решили прибегнуть к событию-условию – забудьте про интуитивную понятность.

Вторая проблема условия – большинство движков это событие не поддерживает. (Я пока не видел ни одного движка, умеющего работать с событием-условием.)

Но все не так плохо: событие-условие можно заменить комбинацией таймера и развилки или/или –

=
=

Потенциальные недостатки такой замены – лишняя нагрузка на движок и замусоривание журнала беготней по кругу.

5. Событие-сообщение

Основной, наряду с обменом данными, механизм межпроцессного взаимодействия. Берем.

6. Событие-сигнал

Сигнал принципиально отличается от сообщения двумя аспектами. Во-первых, сообщение – это коммуникации по схеме «точка-точка», сигнал – «публикация и подписка». Если вам необходимо связать отправителя с множеством получателей, в качестве альтернативы сигналу можете использовать сообщения – событие-сообщение на стороне получателя и задачу-сообщение на стороне отправителя, в цикле по объектам:

=

Во-вторых, сообщение – это сильное связывание, сигнал – слабое. Например, если вы хотите из процесса A запустить процесс B через отправку сообщения, то вы не можете это сделать, ограничив поле зрения только процессом A – у вас должна быть схема процесса B:

С сигналом проще – вы можете разрабатывать схемы процессов A и B независимо – все, что им надо знать друг о друге – это имя сигнала и, опционально, формат данных («полезной нагрузки»):

Если вы имеете дело со сложной системой процессов, то это свойство сигнала становится очень ценным – вам наверняка захочется работать над схемой одного процесса, не оглядываясь на то, готов ли уже другой. Впрочем и в этом случае можно обойтись без сигналов:

Здесь процесс A выставляет флаг в хранилище данных, а процесс B периодически его проверяет. Если флаг не выставлен, B заканчивается, в противном случае он сбрасывает флаг и переходит к основной своей работе.

7. Событие-останов

8. Событие-ошибка

9. Событие-эскалация

Эти три события более-менее взаимозаменяемы:

=
=

Ценная особенность эскалации – при помощи промежуточного события-инициатора и непрерывающего обработчика можно породить новый токен и запустить асинхронный поток управления в процессе/подпроцессе верхнего уровня:

10. Множественное событие

Без этого события можно обойтись достаточно легко.

Обработчик:

=

Инициатор:

= =

11. Параллельное множественное событие

Если событий два, то заменить параллельное множественное событие достаточно легко:

=

Если событий много, то получаем комбинаторный взрыв, и заменить параллельное множественное событие такой техникой становится проблематично. Но мне и два события ни разу не понадобились на практике, а уж больше… А если бы понадобилось, использовал бы CEP (Complex Event Processing), а не BPMN.

12. Событие-отмена

13. Событие-компенсация

События отмены, компенсации, транзакционные подпроцессы и задачи-компенсации крайне полезны в сценарии «все или ничего». Пример: я отправляюсь в командировку, и в порядке подготовки мне надо 1) получить согласие от организаторов выступить с докладом, 2) забронировать авиабилеты, 3) забронировать гостиницу, 4) получить согласие компании оплатить расходы. Все эти действия целесообразно выполнять в параллель – иначе можно не успеть. При этом каждое действие может закончиться неудачей, и в этом случае возникает нетривиальная задача выполнения компенсирующих действий – если организаторы не приняли доклад, а билеты забронированы, то надо сделать возврат билетов и т.п.

Механизм транзакционных подпроцессов и компенсаций позволяет элегантно решать такие задачи. Но встречаются такие сценарии нечасто, а в обычной жизни про транзакции, компенсации и отмены можно забыть.

Резюме

Из 13 типов событий -

  • необходимых 4: простое, таймер, сообщение, останов
  • полезных 2: сигнал, ошибка
  • для специальных случаев 4: условие, эскалация, отмена, компенсация
  • практически бесполезных 3: ссылка, множественное, параллельное множественное

Теперь рассмотрим классификацию событий по месту. На примере сообщения:

1. Начальное событие

2. Конечное событие

3. Промежуточное событие-инициатор

4. Промежуточное событие-обработчик

Эта четверка безусловно необходима.

5. Прикрепленное событие прерывающее

Полезно, интуитивно понятно, часто используется на практике.

6. Прикрепленное событие непрерывающее

Интуитивно не понятен. Более-менее можно обойтись:

=

7. Подпроцесс-обработчик прерывающий

8. Подпроцесс-обработчик непрерывающий

Подпроцессы-обработчики практически не отличаются от прикрепленных событий. Разницу можно усмотреть в том, что прикрепленное событие невозможно прикрепить к процессу верхнего уровня (только к подпроцессу), подпроцесс-обработчик - можно. Но никто ведь не мешает при необходимости превратить верхний уровень в подпроцесс.

Выводы

Итого из восьми вариантов классификации событий по месту необходимых и полезных - пять: начало, конец, промежуточный инициатор, промежуточный обработчик, прикрепленный обработчик непрерывающий (подмножество BPMN 1.x).

Если ограничиться событиями только необходимыми и полезными по типу (всего 6) и по месту (всего 5), то получим 30 потенциально возможных комбинаций, из которых реализуются 19:

Для справки, полное число комбинаций событий в BPMN 2.0 равняется 63.

07.04.17 | Статьи |    

Комментарии (4)

  1. Bogdan Nafornita 13.06.17 09:57

    Hi Anatoly, great post (as always)!

    [I would have argued in the gateway post that inclusive gateway is very useful too and it's not that difficult to explain - it's basically a parallel gateway that passes dark tokens on inactive branches - the scenario of having multiple options activated or not is very common in business and I have not found one single case where this could not be explained to a novice in as short a time as the rest of the gateways]

    Several comments on your current post:
    - conditional events are not very intuitive, but they could be helpful to model data conditionalities (especially as boundary events). Again, easy to explain (same cognitive load as XOR). BTW, camunda BPM supports conditional events.
    - signal events are very helpful as described in your pattern, especially if you need complex orchestration of multiple instances - the downside being the load on the process engine. Messaging is not necessarily a tight coupling and could be a solution to the load problem, especially at scale (volume + velocity of signals event stream interrogations).
    - error / escalation - we tend to use them with a touch of style: error is for technical handling, escalation is for business handling
    - I found in practice that working around specific exotic events by means of subprocesses actually adds to the cognitive load, because it is less intuitive to discern process and sub-process boundaries and scopes, than deal with the same concepts at activity level.

  2. Anatoly Belychook 13.06.17 15:51

    Bogdan

    Thanks for valuable input. We do not necessarily agree but your comments are always thoughts-provoking.

    Camunda is great, thanks for another proof.

    There is a subtle difference between conditional event and xor gateway: if the condition evaluates to true then the process will continue at the gateway but stop and wait at the event set to the same condition. Most people do not realize this I guess.

    As for the error vs. escalation, we discussed it here http://mainthing.ru/ru/item/446/ ages ago ) The difference between error and escalation is that the former behaves like terminator while the latter does not.

    I agree that the subprocess workaround does add a load yet it’s more versatile and explicit so it’s worth to come through it once to get more freedom and preciseness.

  3. Bogdan Nafornita 22.06.17 18:11

    Thanks Anatoly - my comment ref: conditional events and XOR was referring strictly to the similar cognitive burden of having to explain the two to users. I was not implying the two are syntactically similar.

    As for the Error vs Escalation, I agree on their different End behavior - but isn’t this countering your point in this post that Error and Escalation events are more or less interchangeable?

  4. Anatoly Belychook 25.06.17 16:35

    That’s why I wrote “more or less” instead of “fully” ;)

Комментирование закрыто

Copyright © 2008-2017 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии