В прошлой заметке мы выяснили, что при всем многообразии развилок в 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.