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