Примечание: Этот пост является продолжением предыдущего, так как многие читатели спрашивали, что происходит, когда у асинхронных заданий заканчиваются попытки повторного выполнения.
Обработка неудачных заданий
После того как задание несколько раз завершилось с ошибкой (в зависимости от настроенного количества попыток ), движок больше не будет его выполнять. Вместо этого задание будет перемещено в отдельную таблицу базы данных под названием dead letter table (ACT_RU_DEADLETTER_JOB). Dead letter — это распространённый паттерн в системах обмена сообщениями.
Хранение всех таких заданий в отдельной таблице позволяет легко находить проблемные задания с помощью простого запроса. Кроме того, такое разделение заданий повышает общую производительность движка, так как неудачные задания не нужно фильтровать в запросах асинхронного исполнителя. Эта концепция поддерживается только в релизах Flowable 6.
Реанимация заданий
Главный вопрос — что делать с такими "мертвыми" заданиями. Flowable предоставляет два способа вернуть их к жизни: программно и вручную через интерфейс.
Программно: Flowable предоставляет API для восстановления заданий, см. org.flowable.engine.ManagementService#moveDeadLetterJobToExecutableJob(JobId, retries). В результате выполнения задание возвращается в таблицу активных заданий (ACT_RU_JOB), а количество попыток устанавливается в переданное значение.
Вручную: В Flowable Admin App есть раздел, отображающий текущий список заданий. Справа в фильтре по типу заданий есть опция показать только dead letter задания. После применения фильтра в списке будет отображаться количество оставшихся попыток (ноль) и исключение, по которому задание завершилось с ошибкой:
При нажатии на запись отображается дополнительная информация, а справа — возможные действия. Первое действие, «Переместить задание» (Move job), выведет задание из таблицы dead letter, после чего оно снова будет поставлено в очередь на выполнение. Вторая опция — «Удалить задание» (Delete job), — удалит его, но тогда связанный процесс зависнет и потребуется ручная очистка.
Наиболее подходящее действие зависит от вашего кейса и характера исключения. Flowable предоставляет инструменты и инфраструктуру, но стратегия обработки ошибок полностью определяется требованиями и командой разработки.
Несколько советов:
Сбои в коммуникации, недоступность сервера, ненадёжная сеть обычно приводят к легко узнаваемым исключениям: тайм-ауты, сетевые или I/O ошибки. В таких случаях повторное выполнение задания обычно решает проблему, если инфраструктура снова работает корректно. Можно реализовать бэкенд-компонент, который периодически проверяет dead letter-задания и, основываясь на типе исключения, возвращает их в обычную таблицу заданий.
ServiceTask, который обращается к бэкенд-сервису с ошибочной реализацией, не выполнится, даже если его пробовать несколько раз. В таком случае необходимо сначала исправить ошибку, а затем повторно активировать задание. Если проблема устранена, процесс продолжит выполнение в обычном режиме.
Если неудавшаяся задача не критична (например, не удалось отправить e-mail, но служба поддержки уже связалась с клиентом), задание можно удалить, чтобы избежать дублирующего уведомления.
См. документацию, параметр asyncExecutorNumberOfRetries.
Подписывайтесь на наш телеграм-канал BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.