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