Все шлюзы в BPMN с примерами

Шлюзы в BPMN (gateways) это такие развилки, которые либо распараллеливают процесс на несколько потоков, либо собирают несколько потоков процесса в один.

Бизнес процесс - это последовательность действий, которая должна привести к созданию продукта или услуги. И нотация BPMN служит для моделирования именно таких процессов. Но! Иногда проще понять принцип работы того или иного инструмента на простых примерах, которые не имеют отношения к бизнесу, но зато всем знакомы. Чем я и воспользуюсь в данной статье.

Виды шлюзов BPMN

5 основных шлюзов

	Исключающий шлюз (эксклюзивный, Exclusive Gateway), «или/или» - выбор только одного пути;
	Параллельный шлюз (Parallel Gateway), «и» - выбор всех путей;
$Шлюз и\или$	Неисключающий шлюз (неэсклюзивный, Inclusive Gateway), «и/или» - выбор одного или нескольких;
	Событийный шлюз (Event Gateway) - выбор первого события, которое случится;
	Сложный шлюз (Complex Gateway) – прочие варианты.

2 дополнительных шлюза

Эти шлюзы используются как стартовые элементы.

	Эксклюзивный событийный шлюз (Exclusive Event-Based Gateway) - выбор одного из нескольких стартовых событий;
	Параллельный событийный шлюз (Parallel Event-Based Gateway) - ожидание нескольких стартовых событий.

Подробное описание шлюзов в BPMN с примерами

1. Шлюз «ИЛИ/ИЛИ» (исключающий, Exclusive Gateway)

Графически данный шлюз отображается 2 способами. Они равнозначные.

1.1 Расходящаяся развилка/шлюз или/или

На данном шлюзе можно выбрать только один путь, по которому процесс пойдет дальше.

Когда токен поступает в расходящийся шлюз «или/или», он проходит дальше по одному из выбранных путей. Тот путь, который отмечен штрихом называется путь «по умолчанию» (на картинке выше - «Прямо»). Этот путь будет выбран в том случае, если никакое из условий на потоках не сработало. Он может показывать «благополучный» вариант (happy path), который надо выбрать в любом случае. Или, наоборот, дополнительный исключающий путь, который обрабатывает все нестандартные ситуации. В приведенном выше примере, если путник пойдет, например, назад, то некая невидимая сила направит его прямо. Если бы автор процесса захотел, чтобы нестандартное действие путника приводило к его телепортации домой, то нужно было бы добавить 4-й поток управления. Затем выбрать его потоком «по умолчанию» и направить к задаче «Телепортироваться домой».

Что такое токен? Представьте, что когда процесс начинается, то в стартовом событии появляется токен. Он будет путешествовать по процессу и показывать, где мы сейчас в нем находимся. Когда этот токен будет проходить через шлюзы, то в соответствии с заданными правилами, он будет выбирать, куда ему (или им, если количество токенов увеличится) нужно двигаться дальше. Подробнее см. видео [su_youtube url="https://www.youtube.com/watch?v=Gfx5atU3YDY&ab_channel=BPMN2ru"]

1.2 Сходящаяся развилка/шлюз «или/или»

Когда в сходящийся шлюз поступает токен, он пропускает дальше тоже только один токен.

Сходящийся шлюз «или/или» позволяет избежать дублирования задач, которые будут общими для разбежавшихся веток процесса. На примере выше: если выбрал направление прямо или налево, то потом надо «Найти яблочного вора».

1.3 Сходящийся и одновременно расходящийся шлюз «или/или»

Сразу отмечу, что крайне не рекомендуется использовать одни и те же шлюзы в BPMN для обоих действий (сведение и разведение потоков). Это затрудняет чтение схемы и в некоторых случаях может приводить к нарушениям в логике. Рассмотрим еще один пример, который проиллюстрирует эту проблему.

Предположим, что документ был определен как тип А. Когда токен поступит на шлюз №2, у нас не будет результата проверки, ведь она не выполнялась. Чтобы такая ситуация обработалась корректно, надо правильно отметить «поток по умолчанию». Но до этого момента нужно будет догадываться, что усложнит чтение и понимание схемы. Как исправить эту ситуацию? Добавить еще один шлюз «или/или»:

Теперь шлюзы расставлены корректно, и схема читается без дополнительных усилий и траты времени на понимание хитрости с потоком по умолчанию. Подробнее про исключающие шлюзы в BPMN с применением контекста можно прочитать в этой статье.

2. Шлюз «И» (параллельный, Parallel Gateway)

Графически данный шлюз отображается так

2.1 Расходящаяся развилка/шлюз «И» (на схеме ниже - шлюз №1)

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

2.3 Сходящаяся развилка/шлюз «И» (на схеме выше - шлюз №2)

Этот шлюз будет собирать токены, до тех пор, пока не соберет столько, сколько потоков в него входит. Затем данный шлюз сгенерирует один токен, который отправится дальше по процессу.

2.3 Сходящийся и одновременно расходящийся шлюз «и»

Если шлюз «и» является одновременно и собирающим, и разводящим потоки (что не рекомендуется делать по правилам хорошего стиля BPMN), то он будет действовать по сумме вышеописанных правил. Рассмотрим такой шлюз на приведенной ниже схеме "Постановка спектакля". Сначала шлюз №2 дождется пока в него поступит количество токенов, равное количеству входящих потоков - 3. Затем, когда поступят все 3, он запустит по двум исходящим потокам по одному токену.

Какие ошибки возникают при совместном использовании шлюзов «или/или» и «и»? Самая распространенная ошибка при совместном использовании исключающего и параллельного шлюза, это использовать их в паре:

В приведенном выше варианте шлюз №1 сгенерирует два токена, которые запустят выполнение задач 1 и 2. А после того как выполнится любая из задач 1 или 2, ее токен пройдет дальше на шлюз №2 «или/или», где будет сразу пропущен дальше, чтобы запустить выполнение задачи №3. Затем, когда выполнится оставшаяся задача, ее токен тоже пройдет дальше и снова инициирует выполнение задачи №3. Таким образом, задача №3 выполнится 2 раза.

А что если шлюзы поменять местами? Сначала будет выполнена только одна из задач, так как шлюз «или/или» выбирает только 1 поток управления, по которому он запустит токен. Затем шлюз №2 будет ждать второй токен, чтобы запустить процесс дальше. И так как второй токен не был сгенерирован, то задача №3 не будет выполнена никогда.

3. Шлюз «и/или» (неисключающий, inclusive Gateway)

Графически данный шлюз отображается так

3.1 Расходящаяся развилка/шлюз «и/или»

На данном шлюзе процесс может пойти по одному (обязательно) или нескольким потокам управления.

На схеме мы проверяем, какие существуют способы коммуникации и дальше пользуемся теми, которые доступны. То есть, если в базе указан телефон и e-mail, то мы свяжемся этими двумя способами.

3.2 Сходящаяся развилка/шлюз «и/или»

Особенностью данного шлюза является то, что он «знает» сколько токенов ему нужно получить на вход, чтобы запустить процесс дальше. Если на расходящемся шлюзе сгенерируется два токена, то сходящийся дождется двух токенов и затем сгенерирует один исходящий.

А если в пути один из токенов завершит свое «существование», то сходящийся шлюз «и/или» ждать его не будет.

4. Событийный шлюз (Event-Based Gateway)

Графически событийный шлюз отображается так

На всех потоках, исходящих из этого шлюза, обязательно должны быть события (Message, Signal, Timer, Conditional). Когда токен поступает на такой шлюз, то для каждого исходящего потока управления создается свой токен. Они останавливаются на своих событиях и ждут, когда эти события случатся. Как только случается первое событие, все остальные токены автоматически «умирают».

«Кто первый встал - того и тапки!»

Также на потоках, исходящих из этого шлюза, могут располагаться Задачи, принимающие сообщение. Важно помнить, что согласно нотации на одном событийном шлюзе нельзя одновременно использовать и события с месседжем (кружочки со значком конверта), и задачи с месседжем (прямоугольники с конвертом). Пример:

5. Эксклюзивный событийный шлюз (Exclusive Event-Based Gateway).

Этот шлюз используется как стартовый элемент. Он похож на обычный событийный шлюз, но выглядит немного иначе (с одинарной круговой линией)

Часто в программах моделирования он встречается в виде стартового события (то есть без ромба вокруг):

В каком случае может использоваться данный шлюз/старт? Если у нас есть несколько стартовых событий, которые в дальнейшем приводят к выполнению одних и тех же задач в бизнес-процесса.

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

6. Параллельный событийный шлюз (Parallel Event-Based Gateway)

Параллельный событийный шлюз выглядит так:

Он редко встречается в программах моделирования, а если и встречается, то обычно в виде стартового события:

Когда в стартовом событии рождается токен, он всегда создает новый экземпляр процесса. И если стартовых событий несколько (или используется эксклюзивный событийный шлюз), то каждый раз, когда случается стартовое событие, создается новый экземпляр процесса. Можно провести такую аналогию: схема процесса - это класс, а экземпляр процесса - это конкретный объект класса. Или более бытовой пример: схема - это формочка для выпекания печенья, а экземпляры - сами печеньки :)

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

Допустим, клиент перечислил деньги. Создастся новый экземпляр процесса, в котором токен из события «Деньги перечислены» переместится в шлюз «и» и будет ждать там второго токена. Затем, когда мы подготовим документы, возможны два варианта. Либо будет создан второй экземпляр процесса (если это документы для другого клиента). Либо в нашем первом экземпляре процесса токен из события «Документы готовы» тоже переместится к шлюзу «и». Шлюз получит на вход 2 токена и сгенерирует новый токен, который побежит по процессу дальше. То есть начнет выполняться задача «Передать документы курьеру». Как параллельный событийный шлюз поймет, что нужно добавить токен в уже существующий экземпляр процесса, а не создать новый экземпляр? По контексту. Например, по номеру заявки который будет известен в каждом стартовом событии. А вот как этот процесс мог бы выглядеть, если бы мы использовали Эксклюзивный событийный шлюз вместо параллельного:

7. Сложный шлюз (Complex Gateway)

Еще один редко используемый в BPMN шлюз. Отображается он так:

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

Как можно изменить эту схему, чтобы она стала понятна без лишних комментариев? Например, так:

Заключение

Для большинства процессов согласовательного уровня рекомендуется использовать 2-3 вида шлюзов («или/или»

, «и»

, «и/или»

), так как в этом случае схемы легче читаются и понимаются. Однако, остальные шлюзы могут сильно выручить и упростить схему аналитического уровня, если правильно их применять. А при отрисовке схем исполнительного уровня следует помнить, что не все шлюзы в BPMN поддерживаются в различных BPMS и BPM движках. Например, в Camunda не поддерживаются эксклюзивный и параллельный событийные шлюзы. Чем отличаются BPMS и BPM движки, можно прочитать тут.

3500+ экспертов по процессам в нашем сообществе. Присоединяйтесь!

В этой статье

Все шлюзы в BPMN с примерами Виды шлюзов BPMN 5 основных шлюзов 2 дополнительных шлюза Подробное описание шлюзов в BPMN с примерами 1. Шлюз «ИЛИ/ИЛИ» (исключающий, Exclusive Gateway)1.1 Расходящаяся развилка/шлюз или/или 1.2 Сходящаяся развилка/шлюз «или/или»1.3 Сходящийся и одновременно расходящийся шлюз «или/или»2. Шлюз «И» (параллельный, Parallel Gateway)2.1 Расходящаяся развилка/шлюз «И» (на схеме ниже - шлюз №1)2.3 Сходящаяся развилка/шлюз «И» (на схеме выше - шлюз №2) 2.3 Сходящийся и одновременно расходящийся шлюз «и»3. Шлюз «и/или» (неисключающий, inclusive Gateway)3.1 Расходящаяся развилка/шлюз «и/или» 3.2 Сходящаяся развилка/шлюз «и/или»4. Событийный шлюз (Event-Based Gateway)5. Эксклюзивный событийный шлюз (Exclusive Event-Based Gateway). 6. Параллельный событийный шлюз (Parallel Event-Based Gateway)7. Сложный шлюз (Complex Gateway)Заключение

Новые статьи в вашем электрическом ящике

Обзоры конференций, лучшие практики процессного подхода и учебные статьи в вашей почте. Не чаще 1 раза в неделю.

Без спама, только то, что вы запросили.