Представьте: после задачи в BPMN вместо исключающего шлюза поставили параллельный. Как изменится выполнение процесса?
Параллельный шлюз запустит все исходящие ветви одновременно, тогда как исключающий шлюз выберет только одну ветвь по условиям. Поэтому замена может привести к выполнению взаимоисключающих действий одновременно, созданию лишних побочных эффектов и ожиданию ветвей в последующих точках синхронизации.
BPMN создавался для единого графического описания бизнес-процессов, чтобы бизнес-заказчики, аналитики и разработчики одинаково понимали логику потока. Одной из ключевых задач было явно различать последовательное выполнение, выбор сценария и параллельное выполнение.
Шлюзы позволяют отделить обычные действия от правил управления потоком. Это важно не из-за внешнего вида диаграммы, а из-за различной семантики создаваемых и ожидаемых токенов процесса.
Допустим, после проверки заявки процесс должен выбрать один из вариантов: одобрить заявку или отклонить её. Если вместо исключающего шлюза использовать параллельный, процесс попытается запустить обе ветви.
Это может привести к одновременному одобрению и отклонению заявки, двойной отправке уведомлений, созданию противоречивых записей или зависанию на последующем объединении. Ошибка особенно опасна тем, что диаграмма визуально может выглядеть правдоподобно.
Исключающий шлюз, обычно обозначаемый ромбом с маркером «X», выбирает одну исходящую ветвь. Условия проверяются по правилам модели: выбирается подходящая ветвь, а при необходимости задаётся ветвь по умолчанию. В рамках одного прохождения процесса несколько исходящих ветвей такого шлюза не должны запускаться одновременно.
Параллельный шлюз, обозначаемый ромбом с маркером «+», не выбирает условие между ветвями. При разветвлении он создаёт поток по каждой исходящей ветви, поэтому все ветви становятся активными. Указанные рядом условия не превращают его в выборочный шлюз.
При объединении поведение также различается. Параллельный шлюз ожидает токены от всех соответствующих входящих ветвей, а исключающий шлюз объединяет альтернативные ветви без ожидания всех вариантов. Поэтому использование параллельного шлюза после альтернативного пути может вызвать ожидание токена, который никогда не появится.
Выбор шлюза определяется бизнес-правилом: если нужно выполнить ровно один вариант — используется исключающий шлюз; если необходимо выполнить все независимые действия — параллельный. Если несколько вариантов могут запускаться одновременно, но выбор зависит от условий, следует рассматривать другие виды шлюзов, например инклюзивный, и явно проверять правила синхронизации.
В процессе обработки страхового заявления после проверки данных требовалось либо запросить дополнительные документы, либо передать заявление на выплату. Аналитик использовал параллельный шлюз, потому что обе ветви имели разные условия на диаграмме.
Рассматривались два варианта. Можно было оставить параллельный шлюз и добавить последующую проверку, но это усложняло процесс и не устраняло двойной запуск действий. Можно было заменить его на исключающий шлюз, однако требовалось уточнить приоритет условий и поведение при их неполноте.
Выбрали исключающий шлюз, определили взаимоисключающие правила и добавили ветвь по умолчанию для некорректных или неполных данных. В результате заявление перестало одновременно попадать в разные сценарии, а нештатные случаи стали видимыми для оператора вместо тихого запуска неверных действий.
1. Что произойдёт, если условия двух исходящих ветвей исключающего шлюза одновременно истинны?
Это зависит от конкретной разновидности шлюза и правил моделирования. Для обычного исключающего шлюза модель должна обеспечивать однозначный выбор: условия делают взаимоисключающими, задают порядок проверки или явно определяют ветвь по умолчанию. Если этого не сделать, поведение становится неоднозначным для участников процесса и реализации движка.
2. Почему параллельный шлюз опасен при объединении ветвей?
Потому что он выполняет синхронизацию: ожидает поступления токенов от всех входящих ветвей, которые должны участвовать в данном объединении. Если одна из ветвей была альтернативной и в текущем экземпляре процесса не запускалась, ожидаемый токен не появится, поэтому процесс может остановиться перед следующим действием.
3. Можно ли заменить параллельный шлюз несколькими последовательными задачами?
Только если параллельность не является функциональным требованием. Последовательные задачи изменят порядок выполнения и увеличат общее время процесса, а также могут повлиять на транзакционные границы, сроки и возможность независимой обработки ошибок. Если действия действительно независимы и должны выполняться одновременно, последовательная замена меняет семантику процесса и требует отдельного согласования.