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