MuleSoft - обработка исключений Mule

В случае каждого проекта исключения заключаются в том, что они неизбежны. Вот почему важно улавливать, классифицировать и обрабатывать исключения, чтобы система / приложение не оставались в несогласованном состоянии. Существует стратегия исключения по умолчанию, которая неявно применяется ко всем приложениям Mule. Откат любой ожидающей транзакции автоматически является стратегией исключения по умолчанию.

Исключения в Mule

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

Какой транспорт важен?

Этот вопрос имеет большое значение перед проектированием обработчиков исключений, потому что все транспорты не поддерживают транснациональность.

File или же HTTPне поддерживает транзакции. Поэтому, если в этих случаях возникает исключение, мы должны управлять им вручную.

Databasesсопровождение сделок. При разработке обработчиков исключений в этом случае мы должны помнить, что транзакции базы данных могут автоматически откатываться (при необходимости).

В случае REST APIs, мы должны помнить, что они должны возвращать правильные коды состояния HTTP. Например, 404 для ресурса, который не найден.

Какой шаблон обмена сообщениями использовать?

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

Synchronous message pattern основан на формате запрос-ответ, что означает, что этот шаблон будет ожидать ответа и будет заблокирован до тех пор, пока ответ не будет возвращен или не истечет время ожидания.

Asynchronous message pattern основан на формате «огонь-забыл», что означает, что этот шаблон предполагает, что запросы в конечном итоге будут обработаны.

Какой это тип исключения?

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

Исключение произошло system/technical issue (например, отключение сети) должны автоматически обрабатываться механизмом повтора.

С другой стороны, произошло исключение by a business issue (например, недопустимые данные) не следует устранять с помощью механизма повторной попытки, потому что повторять попытку без устранения основной причины бесполезно.

Зачем категоризировать исключения?

Поскольку мы знаем, что все исключения не одинаковы, очень важно классифицировать исключения. На высоком уровне исключения можно разделить на следующие два типа:

Исключения для бизнеса

Основными причинами возникновения бизнес-исключений являются неверные данные или неправильная последовательность операций. Подобные исключения обычно не допускают повторного использования, поэтому настраиватьrollback. Даже применяяretryмеханизм не имеет смысла, потому что повторять попытку без устранения основной причины бесполезно. Чтобы обработать такие исключения, обработка должна быть немедленно остановлена, а исключение отправлено обратно в качестве ответа на очередь недоставленных сообщений. Уведомление также следует отправить в операции.

Исключения, не связанные с бизнесом

Основными причинами возникновения исключений, не связанных с бизнесом, являются системные проблемы или технические проблемы. Эти виды исключений имеют повторяющийся характер, поэтому рекомендуется настроитьretry механизм для устранения этих исключений.

Стратегии обработки исключений

У Mule есть следующие пять стратегий обработки исключений -

Стратегия исключения по умолчанию

Mule неявно применяет эту стратегию к потокам Mule. Он может обрабатывать все исключения в нашем потоке, но его также можно переопределить, добавив стратегию исключения catch, Choice или Rollback. Эта стратегия исключения откатит все ожидающие транзакции и также записывает исключения. Важной характеристикой этой стратегии исключений является то, что она также регистрирует исключение, если транзакция отсутствует.

Как стратегия по умолчанию, Mule реализует ее, когда в потоке возникает какая-либо ошибка. Мы не можем настроить в AnyPoint studio.

Откат стратегии исключения

Предположим, что нет возможности исправить ошибку, что делать? Решение состоит в том, чтобы использовать стратегию исключения отката, которая откатит транзакцию вместе с отправкой сообщения на входящий соединитель родительского потока для повторной обработки сообщения. Эта стратегия также очень полезна, когда мы хотим повторно обработать сообщение.

Example

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

Стратегия перехвата исключений

Эта стратегия перехватывает все исключения, возникающие в родительском потоке. Он переопределяет стратегию исключений по умолчанию Mule, обрабатывая все исключения, созданные родительским потоком. Мы можем использовать стратегию перехвата исключений, чтобы избежать распространения исключений на входящие соединители и родительские потоки.

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

Example

Эту стратегию можно применить к системе бронирования авиабилетов, в которой у нас есть поток обработки сообщений из очереди. Обогатитель сообщения добавляет к сообщению свойство для назначения места, а затем отправляет сообщение в другую очередь.

Теперь, если в этом потоке возникает какая-либо ошибка, сообщение генерирует исключение. Здесь наша стратегия исключения исключения может добавить заголовок с соответствующим сообщением и может вытолкнуть это сообщение из потока в следующую очередь.

Выбор стратегии исключения

Если вы хотите обработать исключение на основе содержимого сообщения, лучшим выбором будет стратегия выбора исключения. Работа этой стратегии исключения будет следующей:

• Во-первых, он перехватывает все исключения, возникающие в родительском потоке.
• Затем он проверяет содержимое сообщения и тип исключения.
• И, наконец, он направляет сообщение в соответствующую стратегию исключения.

В стратегии исключения выбора может быть несколько стратегий исключения, например Catch или Rollback. В случае, если для этой стратегии исключений не определена стратегия, она направит сообщение в стратегию исключений по умолчанию. Он никогда не выполняет никаких операций фиксации, отката или потребления.

Ссылочная стратегия исключения

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