Исключающий шлюз выбирает один маршрут. Параллельный шлюз запускает все исходящие маршруты. Особенно важна разница в точке их объединения: исключающее слияние не ждёт завершения параллельной работы, а параллельное — ждёт.
Когда вы рисуете процесс в общем пространстве для блок-схем Boardmix, сначала сформулируйте правило, а затем выбирайте ромб. На примере обработки заказа разберём, почему «самовывоз или доставка» и «проверить оплату и наличие товара» требуют разного поведения, хотя в обоих случаях видны две ветви.
Сравните поведение шлюзов
BPMN — Business Process Model and Notation, стандарт моделирования бизнес-процессов. Его шлюзы описывают поведение процесса, а не только форму рисунка. Правила разделения и объединения потоков определены в спецификации BPMN организации OMG.
| Вопрос | Исключающий шлюз | Параллельный шлюз |
|---|---|---|
| Что происходит при разделении? | Выбирается один исходящий маршрут по условиям модели. | Активируются все исходящие маршруты. |
| Что происходит при слиянии? | Пришедший маркер проходит дальше; одновременные поступления не синхронизируются. | Шлюз ждёт маркер на каждом входящем маршруте, затем продолжает процесс. |
| Какой вопрос решает? | Какой один вариант подходит? | Завершения каких задач нужно дождаться? |
| Как обозначается? | Ромб с X; исключающий шлюз также может изображаться без X. | Ромб со знаком +. |
Маркер, или токен, помогает рассуждать о движении отдельного экземпляра процесса. В примерах ниже представляйте фишку на каждом активном маршруте. Это не запись клиента и не единица товара.
Документация Camunda об исключающих шлюзах объясняет выбор одной ветви и проход через слияние без синхронизации. В документации о параллельных шлюзах описаны запуск всех ветвей и ожидание входящих потоков. Логическая параллельность не обещает, что два сотрудника или две машины выполнят работу строго в один момент.
Используйте исключающий шлюз для самовывоза или доставки
Рассмотрим заказ, в котором уже выбран самовывоз или доставка. После получения заказа процесс задаёт вопрос «Как получить заказ?». Одна ветвь готовит инструкции для самовывоза, другая — сведения для доставки.
Для этого заказа должна выполниться только одна ветвь. Подпишите маршруты «Самовывоз» и «Доставка» и поставьте исключающий шлюз. Затем маршруты могут соединиться в исключающем слиянии перед следующей стадией.
Проведите по схеме заказ с самовывозом. Один маркер идёт по выбранной ветви, достигает слияния и продолжает движение. С ветви доставки ничего не ожидается: её не выбирали.
Отдельно решите, что делать с отсутствующими или неожиданными данными. Если способ получения не выбран, доставка не должна становиться случайным ответом. Добавьте явный маршрут уточнения или задайте допустимое предварительное условие. В исполняемой модели нужно настроить условия и, при необходимости, поток по умолчанию: подпись на стрелке сама по себе не является исполняемым правилом.
Используйте параллельный шлюз для проверки оплаты и наличия
Теперь предположим, что до подготовки заказа нужно проверить и оплату, и наличие товара. В этом примере для начала одной проверки не нужен результат другой. Параллельное разделение активирует обе ветви: «Проверить оплату» и «Проверить наличие».
В параллельном слиянии заказ ждёт завершения обеих проверок. Если проверка оплаты закончилась первой, её маркер ждёт. После завершения проверки наличия шлюз принимает оба маркера и пропускает дальше один.
Завершение проверки не означает положительный результат. Проверка наличия может вернуть «товара нет», а проверка оплаты — «не подтверждена». После слияния нужна отдельная развилка, которая оценивает эти результаты. Сам шлюз только синхронизирует завершение, а не решает, что заказ готов к обработке.
Короткая последовательность для этой стадии: запустить обе проверки → дождаться обоих результатов → решить, можно ли продолжать. Если оба результата подходят, заказ готовят. В остальных случаях его направляют на устранение соответствующей проблемы.
Найдите два ошибочных варианта слияния
На некоторых схемах задачи выбраны верно, а слияние — нет. Проследите один заказ вместо того, чтобы оценивать симметрию рисунка.
| Ошибочная схема | Что видно при прохождении | Исправление для этого примера |
|---|---|---|
| Исключающий выбор самовывоза или доставки и параллельное слияние | Маркер самовывоза приходит, но шлюз ждёт ещё и невыбранную ветвь доставки. Второй маркер не появится. | Использовать слияние без синхронизации для взаимоисключающих вариантов. |
| Параллельные проверки оплаты и наличия и исключающее слияние | Первая проверка может продолжить процесс без ожидания. Позже вторая тоже пойдёт дальше и может запустить последующую работу повторно. | Синхронизировать обязательные проверки параллельным слиянием, затем оценить результаты. |
Это ошибки поведения, а не оформления. Изменение значка в ромбе может привести к бесконечному ожиданию, преждевременному продолжению или повторному запуску работы.
Но правило не сводится к «всегда соединяйте одинаковые шлюзы». В реальных процессах бывают вложенные решения, циклы и ветви с отдельным завершением. Выбирайте слияние по тому, какие маркеры могут до него дойти и что должно произойти перед продолжением. Одинаковые символы не заменяют этот анализ.
Учтите проверку, которая не завершилась обычным образом
Что делать, если сервис складского учёта недоступен? Если просто удалить эту ветвь, маркер оплаты останется ждать в слиянии. Определите, что считается завершённой проверкой, когда результат получить нельзя.
На обзорной бизнес-схеме проверка может завершаться явным результатом «неизвестно — нужна проверка сотрудником». Тогда решение после слияния направит заказ на разбор, а не сочтёт неизвестный остаток доступным товаром. Исполняемая BPMN-модель требует подходящей обработки ошибок, тайм-аутов, отмен и повторных попыток с учётом движка и бизнес-требований.
Сначала ответьте на вопрос: должен ли весь заказ ждать, перейти на ручную проверку или остановиться? Не ведите неудачную проверку в обход шлюза прямо к задаче «Подготовить заказ», если такой порядок не был действительно согласован. Обход синхронизации может лишить смысла требование выполнить две проверки.
Пройдите процесс вместе на доске Boardmix
Разделите доску Boardmix на две заметные зоны. В первой покажите исключающий выбор самовывоза или доставки и слияние маршрутов. Во второй — параллельные проверки оплаты и наличия, их синхронизацию и отдельное решение по результатам.
Используйте короткие названия задач с глаголами, заметные символы шлюзов и подписи альтернативных ветвей. Под схемами оставьте место для ручного разбора. Передвигайте небольшую фигуру по маршруту самовывоза, а для параллельных проверок возьмите две фигуры. Обсуждайте логику на доске, а исполняемый процесс запускайте в BPMN-движке.
Откройте доску Boardmix и пригласите сотрудников, выполняющих проверки, пройти пример вместе. Выясните, где может не хватить результата, какая работа начинается независимо и что нужно знать до следующей задачи.
Если правило звучит как «выполнить одну или несколько подходящих проверок», простой исключающий выбор и безусловное параллельное разделение не выражают его полностью. Зафиксируйте правило и рассмотрите нужный вариант условного ветвления. Две стрелки ещё не определяют, должна ли сработать одна ветвь, обе или переменный набор.
