Клиенту отправляют предложение: процесс должен продолжиться по первому ответу клиента либо завершиться по таймеру. Какую конструкцию BPMN выбрать для этой развилки?
Нужно использовать шлюз, управляемый событиями, за которым расположены два ожидающих события: получение ответа клиента и срабатывание таймера. Процесс пойдёт по ветви того события, которое наступит первым; альтернативная ветвь после этого становится неактуальной.
Процессные нотации развивались как способ согласовать единое понимание работы бизнеса между аналитиками, владельцами процессов и техническими командами. Обычные условные развилки хорошо описывают выбор по уже известным данным, но плохо подходят для ситуации, когда процесс должен ждать внешнее событие.
Шлюз, управляемый событиями, решает именно эту проблему: он моделирует ожидание одного из возможных событий, а не вычисление логического условия в текущий момент.
После отправки предложения аналитик не знает заранее, что произойдёт первым: клиент ответит или истечёт допустимый срок ожидания. Это не обычный выбор по атрибуту заявки, потому что результат зависит от будущего события и его времени наступления.
Если выбрать неправильную конструкцию, модель может показать невозможное поведение: например, одновременно ожидать ответ и закрывать предложение по таймеру, либо проверять условие до того, как появились необходимые данные. Это приводит к ошибкам в автоматизации, неверной оценке сроков и спорным трактовкам ответственности.
После отправки предложения размещают шлюз, управляемый событиями. Из него проводят ветви к:
Оба события должны быть ожидающими: процесс не выбирает ветвь мгновенно, а приостанавливается до наступления одного из них. Если первым приходит ответ, выполняется обработка ответа; если первым срабатывает таймер, запускается сценарий просрочки или закрытия предложения.
Эксклюзивный шлюз здесь менее точен: он выбирает путь на основании условия, которое проверяется в момент прохождения шлюза. В описанной ситуации нужного результата ещё нет, поэтому такой шлюз потребовал бы дополнительной логики ожидания и повторной проверки.
Параллельный шлюз также неверен: он запускает обе ветви, хотя ответ и истечение срока являются альтернативными исходами. Это может привести к одновременному закрытию предложения и обработке позднего ответа.
Если ожидание ответа оформлено как отдельная задача, таймер можно представить как прерывающее граничное событие этой задачи. Такой вариант уместен, когда таймер является именно ограничением времени выполнения задачи. Событийный шлюз лучше отражает симметричную конкуренцию нескольких внешних событий.
Нужно отдельно определить правила для пограничных случаев: что делать при ответе, поступившем точно в момент истечения срока, можно ли принять запоздалый ответ и как предотвращается двойная обработка. Эти правила относятся уже к бизнес-логике и должны быть явно согласованы, а не подразумеваться диаграммой.
В компании после отправки коммерческого предложения менеджер должен либо обработать ответ клиента, либо закрыть предложение через 48 часов. Рассматривались три варианта.
Эксклюзивный шлюз после отправки был простым для чтения, но не описывал ожидание и требовал отдельного механизма повторной проверки. Параллельная развилка была наглядной, однако допускала одновременное выполнение обработки ответа и закрытия предложения. Событийный шлюз точно выразил условие гонки между сообщением и таймером.
Выбрали событийный шлюз с сообщением и таймером. Дополнительно зафиксировали правило: после закрытия предложения поздний ответ не изменяет его статус автоматически, а переводится на ручную обработку. Это устранило неоднозначность границы срока и позволило корректно сопоставить каждый экземпляр процесса с одним исходом.
Эксклюзивный шлюз принимает решение по данным или условиям, доступным в момент его прохождения. Событийный шлюз не вычисляет, какое условие истинно: он переводит процесс в состояние ожидания и выбирает ветвь по первому наступившему событию.
Это различие важно не по названию элемента, а по времени принятия решения. Если ответ клиента ещё не получен, условие «клиент ответил» нельзя надёжно проверить обычной развилкой без дополнительного ожидания.
Она должна быть отменена или считаться недоступной для данного экземпляра процесса. Иначе позднее сообщение может запустить обработку, хотя таймер уже закрыл предложение, или наоборот.
Поэтому модель и реализация должны обеспечивать корреляцию сообщения с конкретным экземпляром процесса, а также идемпотентность и защиту от повторной обработки. Сам BPMN-элемент не заменяет согласованные правила обработки запоздалых и дублирующихся событий.
Граничный таймер подходит, когда процесс выполняет конкретную длительную задачу, а срок ограничивает именно её выполнение. Например, задача «ожидать ответ клиента» может быть прервана таймером через 48 часов.
Событийный шлюз предпочтительнее, когда нужно явно показать конкуренцию нескольких независимых событий, например ответа, отмены клиентом и истечения срока. Выбор зависит от смысла процесса: таймер ограничивает задачу или является одним из равноправных возможных исходов ожидания.