Конечное событие BPMN

Конечное событие BPMN — это элемент нотации BPMN (Business Process Model and Notation), обозначающий точку завершения процесса, подпроцесса или отдельной его ветки. Конечные события визуализируются в виде круга с жирной границей и указывают на то, что дальнейшее выполнение потока управления в данной области прекращается. В отличие от начальных событий, которые запускают процесс, конечные события фиксируют его результат, включая возможные исключительные ситуации.

Типы конечных событий

В стандарте BPMN 2.0 выделяют несколько типов конечных событий, различающихся по триггеру и значению для моделируемого процесса. Каждый тип имеет свой маркер внутри круга.

Пустое конечное событие

Пустое конечное событие (None End Event) — это базовый тип, не имеющий внутреннего маркера. Оно обозначает, что поток управления в данной ветке завершается без какого-либо специального результата. Используется в простых процессах, где не требуется фиксировать итоговое состояние. Например, в процессе согласования документа пустое конечное событие может завершать ветку, по которой документ был отклонён без дополнительных действий.

Сообщающее конечное событие

Сообщающее конечное событие (Message End Event) обозначается конвертом внутри круга. Оно указывает, что при завершении процесса отправляется сообщение внешнему участнику (другому процессу, системе или человеку). Сообщение может содержать данные, например, уведомление о завершении заказа или запрос на подтверждение. В BPMN такое событие моделирует асинхронное взаимодействие.

Сигнальное конечное событие

Сигнальное конечное событие (Signal End Event) маркируется треугольником. Оно генерирует сигнал, который может быть пойман другими процессами или подпроцессами, ожидающими этот сигнал. В отличие от сообщения, сигнал не адресован конкретному получателю — он широковещательный. Пример: завершение процесса закупки генерирует сигнал «Товар поступил», который запускает процесс складского учёта.

Конечное событие-ошибка

Конечное событие-ошибка (Error End Event) обозначается молнией. Оно фиксирует аварийное завершение процесса из-за ошибки. Такое событие всегда связано с определённым кодом ошибки. При его наступлении поток управления передаётся в обработчик ошибок, который может быть задан на уровне подпроцесса или процесса. Например, если в процессе обработки платежа система возвращает ошибку «Недостаточно средств», срабатывает конечное событие-ошибка.

Конечное событие-эскалация

Конечное событие-эскалация (Escalation End Event) маркируется стрелкой вверх. Оно используется для передачи управления на более высокий уровень, когда процесс не может быть завершён стандартным образом, но ситуация не является критической ошибкой. Например, если сотрудник не может принять решение по заявке, событие-эскалация передаёт задачу руководителю.

Конечное событие-отмена

Конечное событие-отмена (Cancel End Event) обозначается крестиком. Оно применяется в транзакционных подпроцессах для отмены всех операций, выполненных в рамках транзакции. При его срабатывании все действия, выполненные в подпроцессе, откатываются, а управление передаётся в обработчик отмены. Этот тип событий характерен для бизнес-процессов, требующих строгой согласованности, например, в банковских операциях.

Конечное событие-компенсация

Конечное событие-компенсация (Compensation End Event) маркируется символами отката (две стрелки в противоположных направлениях). Оно инициирует компенсационные действия для отмены уже выполненных операций, если процесс завершается неудачно. Например, при отказе клиента от заказа после его частичной обработки конечное событие-компенсация запускает возврат средств и отмену резервирования товара.

Конечное событие-прерывание

Конечное событие-прерывание (Terminate End Event) обозначается жирной точкой внутри круга. Оно немедленно останавливает выполнение всего процесса, включая все параллельные ветки. В отличие от других конечных событий, которые завершают только текущую ветку, прерывание останавливает процесс целиком. Используется в критических ситуациях, например, при обнаружении мошенничества.

Применение в моделировании процессов

Конечные события играют ключевую роль в спецификации BPMN, так как они формализуют завершение процесса. В реальных проектах выбор типа конечного события зависит от цели моделирования:

• Для простых процессов, не требующих интеграции, достаточно пустого конечного события.
• Для процессов с внешними системами (например, отправка email-уведомлений) применяют сообщающие конечные события.
• Для процессов с возможными сбоями (например, обработка платежей) используют конечные события-ошибки.
• Для сложных транзакций (например, бронирование билетов) — события-отмены и компенсации.

Ограничения и особенности

Конечные события в BPMN имеют несколько важных ограничений:

1. Одно конечное событие на ветку. Каждая ветка процесса может иметь только одно конечное событие. Если ветка завершается несколькими способами, используются условные потоки или промежуточные события.
2. Не могут быть триггерами. Конечные события не могут запускать процессы — для этого существуют начальные события.
3. Не поддерживают множественные маркеры. В отличие от промежуточных событий, конечные события могут иметь только один маркер (например, нельзя одновременно отправить сообщение и сигнал).
4. Связь с обработчиками. Для событий-ошибок, эскалаций, отмен и компенсаций необходимо явно задавать обработчики на уровне подпроцесса или процесса, иначе событие останется необработанным.

Примеры использования

Пример 1: Процесс заказа товара

• После подтверждения заказа система отправляет письмо клиенту (сообщающее конечное событие).
• Если оплата не прошла, срабатывает конечное событие-ошибка, которое запускает обработчик возврата корзины.

Пример 2: Процесс согласования договора

• При успешном согласовании всеми сторонами — пустое конечное событие.
• Если один из участников отклоняет договор, срабатывает конечное событие-эскалация, передающее задачу руководителю.

Пример 3: Транзакция бронирования

• При успешном бронировании — пустое конечное событие.
• При отказе клиента — конечное событие-компенсация, отменяющее бронь и возвращающее средства.

Сравнение с другими элементами BPMN

Конечные события отличаются от начальных и промежуточных событий по функции:

• Начальные события запускают процесс, конечные — завершают.
• Промежуточные события могут как генерировать, так и ловить триггеры (сообщения, сигналы, ошибки), но не завершают процесс.
• Конечные события всегда генерируют триггер (если он предусмотрен типом) и прекращают выполнение.

В отличие от задач, которые выполняют действия, конечные события только фиксируют факт завершения. Они не могут содержать бизнес-логики — только маркер типа.

Интересные факты

• В BPMN 2.0 существует 8 типов конечных событий, но на практике чаще всего используются пустое, сообщающее и сигнальное.
• Событие-прерывание (Terminate End Event) — единственное, которое останавливает все параллельные ветки процесса.
• В некоторых инструментах моделирования (например, Camunda, Bizagi) конечные события могут быть связаны с автоматическими действиями, такими как отправка HTTP-запроса или запись в базу данных.
• Стандарт BPMN 2.0 не требует обязательного наличия конечного события в процессе — ветка может завершаться просто отсутствием исходящих потоков, но это считается плохой практикой.

Источники

• Business Process Model and Notation (BPMN), Version 2.0. Object Management Group (OMG), 2011.
• Silver B. BPMN Method and Style: A levels-based methodology for BPM process modeling and improvement using BPMN 2.0. Cody-Cassidy Press, 2011.
• Freund J., Rücker B. Real-Life BPMN: Using BPMN 2.0 to Analyze, Improve, and Automate Processes in Your Company. Camunda, 2019.