От переводчика: компенсации, возможно, самый недооцененный паттерн в BPMN. Если воплощать всю эту кухню просто в коде, то можно мозги свернуть. У вас неизбежно будет куча try/catch, флагов состояния, и скрытых зависимостей между сервисами, где понять сценарий отката можно только изрядно вникув в реализацию. С BPMN вся логика становится прозрачнее — надо только один раз сделать усилие и разобраться с нотацией
Пускай сам механизм компенсаций немного по-разному реализован в движках Camunda 7 и 8, для общего понимания, зачем эти компенсации нужны, это не так принципиально. Важнее увидеть кейсы, где компенсации дают реальный выигрыш. Собственно, о этом статья.
Ограниченные строгими регуляциями и перегруженные высокими объемами транзакций, требующих быстрой обработки, банки должны обеспечивать надежность и безопасность финансовых операций, какие бы проблемы ни возникали на их пути. Хотя в сложных банковских процессах многое может пойти не так, распределенная архитектура систем современных финансовых институтов добавляет сложности в обработку сбоев. Мы собираемся объяснить, как банки могут эффективно автоматизировать откат транзакций через несколько микросервисов и предоставить реальный пример работы компенсационных событий Camunda в банке.
Что такое компенсационные события?
Одной из выдающихся функций, предоставляемых Camunda, является ее способность легко обрабатывать бизнес-транзакции, которые пошли не так. Этот шаблон рабочего процесса позволяет бизнесам определять компенсационные действия и "отмену" шагов в рабочем процессе, если некоторые операции в последовательности терпят неудачу. В сегодняшних сложных бизнес-процессах, охватывающих распределенные архитектуры, мы можем найти множество примеров, где выполненные задачи нужно отменить, чтобы отразить реальное состояние мира.
Например, когда система выполняет финансовые транзакции, денежные переводы или онлайн-заявки на кредит, ей нужно подтвердить запрос, обработать транзакцию и обновить счет. Если любой из этапов не завершен, система должна быть способна откатить предыдущие шаги назад, чтобы избежать некорректных транзакций или несоответствий данных. А именно, было бы неподходяще оставить заявку на кредит в подтвержденном состоянии, если заемные деньги не поступили на счет клиента, скажем, из-за сбоя микросервиса.
Итак, в бизнес-операциях компенсационные события Camunda позволяют автоматически обратить действия, которые были успешно завершены, но их результаты и побочные эффекты больше не считаются желательными. Таким образом, функция компенсации обеспечивает сохранение процесса в согласованном состоянии в случае ошибок, исключений и отмен.
Как работают компенсационные события в Camunda?
Saga
Чтобы обеспечить эффективную компенсацию, Camunda поддерживает Saga, шаблон взаимодействия, который хорошо работает в управлении согласованностью данных в сложных архитектурах микросервисов. В отличие от протокола двухфазной фиксации, часто используемого в распределенных системах, шаблон Saga не снижает общей доступности системы с помощью блокировок транзакций. Он также идеально подходит для современных NoSQL баз данных и брокеров сообщений, которые не поддерживают двухфазную фиксацию.
Таким образом, Saga является предпочтительным вариантом для долгосрочных бизнес-процессов и высоко распределенных систем, которые в настоящее время почти универсальны в банковском деле. Он разбивает сложные процессы на маленькие, управляемые шаги, каждый из которых сопровождается компенсационным действием, необходимым для правильного восстановления в случае сбоя. В результате система остается отказоустойчивой и согласованной, сохраняя при этом масштабируемость и производительность.
Zeebe и BPMN
Движок Zeebe от Camunda работает как координатор саги, отвечающий за завершение общей транзакции или её прерывание с приведением системы в известное конечное состояние. Архитектура движка основана на событиях и использует журнал, в котором каждое изменение состояния фиксируется в режиме "только добавление". Такой подход обеспечивает эффективное восстановление и управление состоянием, что особенно важно для реализации компенсирующих событий.
Компенсационные события в Camunda создаются в Camunda Modeler по стандарту BPMN 2.0. Они тесно взаимодействуют с движком, который эффективно управляет выполнением процессов и хорошо масштабируется.
Когда экземпляр процесса достигает промежуточного или конечного компенсирующего события (compensation throw event), это запускает компенсацию в его области действия (scope) и вызывает все обработчики компенсации для завершенных действий. Обработчики для активных или прерванных действий не вызываются. Компенсирующее событие остается активным до тех пор, пока все вызванные обработчики компенсации не завершат свою работу.
Особенности реализации компенсирующих событий в Camunda
Camunda упрощает моделирование компенсации в сложных бизнес-процессах с помощью наглядных BPMN-диаграмм.
Пользователи могут создавать компенсирующую активность для каждой задачи в модели процесса — будь то сервисная задача, пользовательская задача или подпроцесс.
Механизм компенсации в Camunda способен обрабатывать сложные ситуации, такие как множественные экземпляры активностей, прерывание обработчиков компенсации, вызов компенсирующих обработчиков в заданном порядке и многое другое.
Благодаря этому пользователям не нужно вручную писать логику отката между несколькими микросервисами — надёжные механизмы обработки ошибок можно встроить прямо в модель процесса.
В целом, компенсационные потоки, создаваемые в Camunda, избавляют от необходимости отслеживать каждую транзакцию отдельно и упрощают управление откатами.
Реальный кейс компенсирующего события в банке
Рассмотрим, как компенсация в Camunda работает в реальном банковском сценарии перевода средств. Поскольку внимание уделяется именно компенсирующим событиям, процесс упрощен: все проверки клиента до перевода средств объединены в одну сервисную задачу. Эти проверки включают:
Проверку формата и корректности введенных данных, таких как IBAN и реквизиты банка.
Подтверждение, что указанная сумма не превышает установленные лимиты.
Проверку достаточности средств на счете отправителя.
Идентификацию личности клиента.
Антифрод‑проверки, проверку на отмывание денег и соответствие нормативным требованиям (compliance).
На диаграмме ниже рассматриваются следующие сценарии:
Если в ходе проверки данн��х обнаруживаются какие-либо проблемы, Camunda отправляет уведомление, информируя клиента об отмене перевода средств. Процесс завершается.
Если проверка проходит успешно, процесс продолжается.
На следующем шаге банк отправителя списывает указанную сумму со счета клиента. Все операции со счетом журналируются в системе.
Если в процессе списания что-то идет не так (было разорвано соединение, банк не прислал ответ о списании средств со счета и т. п.), Camunda информирует клиента о том, что процесс перевода средств завершился с ошибкой. Процесс завершается.
Если операция списания проходит успешно, процесс продолжается.
Следующий шаг — зачисление указанной суммы на счет получателя.
Если система фиксирует граничное событие ошибки во время выполнения этой операции, Camunda информирует клиента и инициирует компенсирующее событие — откат списания средств со счета клиента. Затем процесс завершается.
Если при зачислении не возникает ошибок, Camunda журналирует операцию пополнения счета и уведомляет получателя о зачислении средств на его баланс. Процесс завершается.
Реализуя компенсирующее событие, банк гарантирует, что средства не будут потеряны или обработаны некорректно, сохраняя целостность данных и соблюдая регуляторные требования.
Компенсационные события: сценарии использования и преимущества для банковской сферы
Компенсационные события не ограничиваются простыми операциями списания и зачисления средств. Их можно использовать в самом широком спектре банковских процессов.
Обработка заявок на кредит. Одобренный кредит можно автоматически откатить, если последующая проверка одобрения не проходит.
Выявление мошенничества. Можно отменить помеченную как мошенническую транзакцию и уведомить по ходу процесса соответствующие подразделения.
Платежи через границу. В случае расхождений в курсе валют или нарушений требований комплаенса множественные валютные конверсии и международные переводы можно эффективно обрабатывать с помощью компенсирующих действий.
Кредитные и ипотечные операции. Если получатель кредита передумал или были выявлены ошибки в расчетах, уместно изменить условия договора или откатить весь процесс с помощью компенсирующих событий.
Расчет комиссий и сборов. Если с клиента по ошибке списана комиссия или сбор, возврат средств — надежный способ исправить ситуацию.
Расчеты и клиринг. При сбоях в клиринговых процессах (например, при межбанковских переводах) компенсирующие события могут откатить и повторно выполнить транзакции или обеспечить возврат средств.
Платежные системы и эквайринг. Если платежная система не смогла обработать платеж, она может использовать компенсирующие события для отмены транзакции и возврата средств клиенту.
Карточные операции. Возврат средств или отмена транзакции также полезны при ошибочном списании, например из-за дублирования операций.
Валютные операции. Если во время конвертации изменился валютный курс, компенсирующие события могут скорректировать исходную транзакцию или вернуть средства с учетом новых условий.
Операции по вкладам. Если клиент досрочно расторгает депозитный договор или выявлены ошибки в расчете процентов, компенсирующие события могут скорректировать расчеты или откатить транзакции.
Переход на автоматизированную компенсацию и использование Camunda для координации сложных банковских процессов позволяет финансовым организациям получить множество преимуществ:
Минимизация финансовых рисков. Определяя компенсационные потоки, банки могут снизить риск незавершенных или ошибочных транзакций, обеспечивая точную обработку средств.
Гарантированный комплаенс. Автоматические откаты помогают предотвратить несанкционированные или незавершенные транзакции и способствуют соблюдению регуляторных требований, таких как PCI DSS и GDPR.
Снижение ручного труда. Компенсационные события позволяют банкам исключить ручное вмешательство при сбоях транзакций, освобождая ценные человеческие ресурсы для более значимых задач.
Повышение доверия клиентов. Банки могут укрепить доверие клиентов, внедряя точную и прозрачную обработку транзакций.
Использование компенсирующих событий за пределами банковской сферы
Поскольку событийно-ориентированные распределенные архитектуры часто встречаются за пределами финансовой отрасли, решение Camunda для компенсации имеет гораздо более широкую область применения. Вот несколько примеров использования компенсирующих событий в других отраслях:
Управление цепочками поставок: предотвратить расхождения в запасах, откатывая изменения инвентаря при неудачной отгрузке.
Здравоохранение: обработка ошибок в обработке данных пациентов или планировании лечения при управлении клиническими испытаниями.
Электронная коммерция: автоматическая отмена подтверждений заказов и возврат платежей в случае ошибок в обработке заказов или авторизации платежей.
Страхование: обеспечение точности финансовых записей путем отмены переплат или исправления ошибок в обработке полисов.
Заключение
Используя компенсирующие события, организации могут создавать более устойчивые и гибкие фреймворки автоматизации процессов. Благодаря быстрому восстановлению после сбоев и снижению риска простоев процессов, обеспеченному автоматизированной компенсацией, бизнес становится более гибким и конкурентоспособным.
Camunda предоставляет мощный механизм для банков, чтобы уверенно справляться со сложностью современных финансовых транзакций. Автоматизируя действия отката, они могут соответствовать регуляторным требованиям и повышать операционную эффективность, предлагая клиентам более безопасный и надежный банковский опыт.
BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.
Компенсации в Camunda 7 и 8: в чем разница?
С точки зрения бизнеса разницы никакой. Все кейсы можно реализовать на любом движке. И не тол��ко Camunda.
Для аналитика есть кое-какие отличия: в "восьмерке" нет transaction subprocess, cancel event и compensation start event, но без этого вполне можно жить. Обычный подпроцесс с сагой внутри вполне моделирует транзакционный.
В "семерке" компенсации были давно, реализованы полностью по стандарту BPMN 2.0. А в "восьмерке" поддержка компенсации появилась постепенно начиная с версий 8.5+: ранние релизы 8.1–8.4 не обеспечивали корректную обработку compensation catch и компенсация не работала полностью.
Это что касается моделирования. Но есть еще отличия в реализации, которые на глаз незаметны, но о них стоит знать. Вы же в курсе, что архитектура Camunda 8 принципиально отличается от Camunda 7, да? Так, вот, это влияет на порядок выполнения компенсаций.
Camunda 7:
- Поведение относительно порядка и прерываемости на уровне BPMN-спецификации достаточно детерминировано и следовало ожиданиям BPMN 2.0 (в рамках механизма транзакций и компенсаций).
- Обработчики могут быть прерваны в соответствующих сценариях (например, при terminate end event).Camunda 8:
Хотя компенсационные обработчики поддерживаются, их поведение отличается:
При прерывании области compensation handler продолжает выполняться в зоне процесса (и не будет прерван точно так же, как в 7-ке, если throw event и handler находятся в разных областях).
Порядок одновременного запуска компенсаторов не гарантируется внутренне в строгом порядке, особенно для внешних рабочих задач.
Так где компенсации лучше — в старой доброй "семерке" или в модной "восьмерке"? Постановка вопроса неправомерна. Механизм компенсаций просто отражает архитектуру движка, вот и все.
