Паттерны BPMN #3. 5 способов обработки ошибок

Внедрение BPMS это сложная штука, возможны баги. Чтобы баги не ломали ваши бизнес-процессы, я расскажу о простых паттернах. Паттерны актуальны для исполняемых моделей BPMN. Для описательных и аналитических схем использовать этот подход не стоит, он только захламит схему. Но держать в голове его стоит.

Ошибки в коде

Ошибки бывают двух типов — технические и бизнесовые:

• технические — не ответил сервис поиска платежей в АБС;
• бизнесовые — платеж в сервисе АБС не найден.

Я советую бизнесовые ошибки моделировать, как заранее предполагаемую часть процесса. А технические ошибки вообще не моделировать на уровне схем.

Часто технические ошибки обрабатываются движком BPMS в отдельном разделе администрирования.

Обработка на уровне данных

Сайт ЦБ может не ответить вовремя, но процесс не должен от этого зависеть. Обработка ошибки здесь сделана через шлюз и проверку наличия ответа.

Присоединенное событие типа “Ошибка”

Это вариант решает техническую проблему — движок сгенерировал Exception, мы его перехватили и передали поток управления процесса в другой подпроцесс.

“Еще разок”

Даём пользователю возможность подергать сервис:

Попытаться снова автоматически

Здесь система сама по таймеру попробует сделать запрос. Опасный вариант, т.к. экземлпяр может войти в бесконечный цикл, а движок об этом нам никак не сообщит.

Специальный процесс “Разбор ошибок”

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