Полный гайд по развилкам (шлюзам, gateway) в BPMN: развилка «ИЛИ\ИЛИ»
Развилка «ИЛИ\ИЛИ» (exclusive gateway) используется на практике чаще всего, но даже с ней не всё понятно. В этой статье разбираемся с развилкой «ИЛИ\ИЛИ» окончательно. А в цикле статей разберем вообще все развилки.
Что нужно знать
1.Токены в BPMN
Чтобы понимать, как работают развилки в BPMN, нужно понимать концепцию токенов. Подробности есть в моей бесплатной е-мейл рассылке (подпишитесь, если еще не).
Токен — это виртуальная фишка, которая движется по схеме вашего процесса. Она отображает актуальное состояние процесса. На некоторых элементах BPMN, например на шлюзах, количество фишек может увеличиваться или уменьшаться. Когда в процессе не осталось фишек, он считается завершенным.
Токены помогают «проиграть» будущее исполнение процесса и понять, всё ли правильно нарисовано.
2.Контекст
Некоторые шлюзы используют контекст в своей работе. Контекст — это «виртуальная» таблица данных конкретного инстанса (запуска процесса), куда записываются и сохраняются ВСЕ данные конкретного запуска процесса.
Обычно каждый квадратик процесса имеет возможность прочитать контекст и записать что-то в контекст. У контекста нет визуального отображения на диаграмме.
Развилка «ИЛИ\ИЛИ»
Самая часто используемая развилка в BPMN. По-английски называется Exclusive gateway, Data-based Exclusive Gateway, XOR Gateway. По-русски еще называют «оператор исключающего ИЛИ, управляемого данными», хотя официальный перевод сообщества — развилка «или\или».
Как выглядит
Существует 2 возможных варианта отображения. Вариант не влияет не поведение схемы.
В естественных условиях (на диаграммах) в развилку входят и выходят потоки управления (стрелки).
Бывает 3 варианта этой развилки:
- Несколько входов и один выход
- Один вход и несколько выходов
- Несколько входов и несколько выходов
Как работает развилка «ИЛИ\ИЛИ»
Количество входящих и выходящих потоков управления определяет то, как работает развилка, т.е. мы имеем 3 варианта её работы:
Несколько входов и один выход
В этом случае развилка просто пропускает токены вперёд.
Такая развилка используется тогда, когда варианты бизнес-процесса надо объединить и пустить дальше уже по общей логике.
В этой роли развилка не меняет число токенов.
Один вход и несколько выходов
В этом случае развилка работает умнее. На каждой выходящей стрелке (потоке управлении) аналитик должен прописать причину, по которой процесс пойдет туда.
Причина для перехода по стрелке задается выражением. Выражение — это логический оператор, который может вернуть true или false. Выражение использует данные из контекста. Выражения могут иметь любую сложность, зависит от вашей среды автоматизации, главное чтобы они возращали true или false.
Из-за использования контекста эту развилку часто называют Data-based Exclusive Gateway, т.е. буквально «движимую данными». Если выражение истино (true), то токен переходит по такому потоку управления.
Вот что происходит в примере ниже:
- Сотрудник в задаче «Выбрать способ доставки» указывает значение переменной «delivery_method» = Courier
- Это значение сохраняется в контекст.
- Сотрудник выполняет задачу.
- Токен перемещается на развилку.
- Развилка проверяет по очереди правила на всех стрелках (проверка выполняется в том порядке, в котором были созданы ветки к развилке):
- Проверка ${delivery_method = «POST»} возвращает false
- Проверка ${delivery_method = «Courier»} возвращает true.
- Токен передается в первую сработавшую ветку. Прочие проверки не выполняются.
Количество токенов не меняется.
Несколько входов и несколько выходов
Такой вариант работает как сумма вышеописанных. Любой вошедший в развилку токен запускает проверку выражений. Но я не рекомендую объединять роли развилок, т.к. легко запутаться. Официально считается плохим стилем.
Когда применять развилку «ИЛИ\ИЛИ»
- Практически всегда, когда вы хотите показать единичный выбор между вариантами прохождения процессов можно использовать развилку «ИЛИ\ИЛИ».
- Когда вы хотите собрать различные потоки управления и дальше действовать единообразно.
Каверзные вопросы
- А что будет, если ни одно условий не подошло?
Чтобы избежать такой ситуации, одну из выходящих веток из развилки можно указать как поток «в противном случае» (Default Flow).
В таком потоке нельзя написать выражение. Токен уходит в такой поток если все остальные выражения на всех потоках вернули false.
- А почему на схемах часто развилки идут парами?
Так удобнее отслеживать логику и не путаться в токенах. Это необязательно.
- Как именно задается последовательность проверок?
В некоторых системах автоматизации есть специальные настройки для этого, в некоторых — просто номером строки в xml файле описания диаграммы (BPMN — на самом деле xml).
С этой развилкой разобрались. Поделитесь статьей и напиши в коментариях — всё ли понятно? Может есть другие каверзные вопросы?
Комментарии