В случае каждого проекта факт об исключениях заключается в том, что они обязательно произойдут. Вот почему важно отлавливать, классифицировать и обрабатывать исключения, чтобы система / приложение не оставалось в несогласованном состоянии. Существует стратегия исключений по умолчанию, которая неявно применяется ко всем приложениям Mule. Откат любой ожидающей транзакции автоматически является стратегией исключения по умолчанию.
Исключения в Муле
Прежде чем углубляться в исключительную обработку, мы должны понять, какие могут возникнуть исключения, а также три основных вопроса, которые должен задать разработчик при разработке обработчиков исключений.
Какой транспорт важен?
Этот вопрос достаточно актуален до разработки обработчиков исключений, потому что все транспорты не поддерживают транснациональность.
Файл или HTTP не поддерживает транзакции. Вот почему, если в этих случаях возникает исключение, мы должны управлять им вручную.
Базы данных поддерживают транзакции. При разработке обработчиков исключений в этом случае мы должны учитывать, что транзакции базы данных могут автоматически откатываться (при необходимости).
В случае API REST , мы должны помнить, что они должны возвращать правильные коды состояния HTTP. Например, 404 для ресурса не найден.
Какой шаблон обмена сообщениями использовать?
При разработке обработчиков исключений мы должны позаботиться о шаблоне обмена сообщениями. Может быть синхронный (запрос-ответ) или асинхронный (пожар-забыл) шаблон сообщения.
Шаблон синхронного сообщения основан на формате запроса-ответа, что означает, что этот шаблон будет ожидать ответа и будет заблокирован до тех пор, пока не будет возвращен ответ или не истечет время ожидания.
Шаблон асинхронного сообщения основан на формате fire-Forgot, что означает, что этот шаблон предполагает, что запросы будут в конечном итоге обработаны.
Какой тип исключения это?
Очень простое правило заключается в том, что вы будете обрабатывать исключение в зависимости от его типа. Очень важно знать, вызвано ли исключение системной / технической проблемой или коммерческой проблемой?
Исключение, возникшее из-за системной / технической проблемы (например, сбой сети), должно автоматически обрабатываться механизмом повторной попытки.
С другой стороны, исключение, возникшее из-за бизнес-проблемы (например, неверные данные), не должно быть решено путем применения механизма повторных попыток, поскольку повторять попытки бесполезно без устранения основной причины.
Зачем классифицировать исключения?
Поскольку мы знаем, что все исключения не одинаковы, очень важно классифицировать исключения. На высоком уровне исключения могут быть классифицированы на следующие два типа —
Бизнес-исключения
Основными причинами возникновения бизнес-исключений являются неверные данные или неправильная последовательность процессов. Подобные исключения, как правило, не повторяются по своей природе, и, следовательно, настройка отката нецелесообразна . Даже применение механизма повторных попыток не имело бы никакого смысла, поскольку повторять попытки без устранения основной причины бесполезно. Для обработки таких исключений обработка должна быть немедленно остановлена, а исключение отправлено обратно как ответ на очередь недоставленных сообщений. Уведомление также следует отправить на операции.
Исключения для некоммерческих организаций
Основными причинами возникновения некоммерческих исключений являются системные проблемы или технические проблемы. Исключения такого рода по своей природе являются повторяемыми, и поэтому хорошо настроить механизм повторных попыток , чтобы устранить эти исключения.
Стратегии обработки исключений
У Мула есть следующие пять стратегий обработки исключений:
Стратегия исключения по умолчанию
Мул неявно применяет эту стратегию к потокам Мула. Он может обрабатывать все исключения в нашем потоке, но его также можно переопределить, добавив стратегию исключений catch, Choice или Rollback. Эта стратегия исключений будет откатывать все ожидающие транзакции и также регистрирует исключения. Важной характеристикой этой стратегии исключений является то, что она также регистрирует исключение, если транзакции отсутствуют.
В качестве стратегии по умолчанию Mule реализует ее, когда в потоке возникает какая-либо ошибка. Мы не можем настроить в AnyPoint Studio.
Стратегия Откат Исключений
Предположим, что если нет решения для исправления ошибки, что делать? Решение состоит в том, чтобы использовать стратегию исключения отката, которая будет откатывать транзакцию вместе с отправкой сообщения входящему соединителю родительского потока для повторной обработки сообщения. Эта стратегия также очень полезна, когда мы хотим обработать сообщение.
пример
Эта стратегия может быть применена к банковской операции, когда средства поступают на расчетный / сберегательный счет. Здесь мы можем настроить стратегию исключений отката, потому что в случае возникновения ошибки во время транзакции эта стратегия откатывает сообщение обратно в начало потока, чтобы повторить попытку обработки.
Стратегия ловли исключений
Эта стратегия перехватывает все исключения, которые выбрасываются в его родительском потоке. Он переопределяет стратегию исключений по умолчанию Mule, обрабатывая все исключения, генерируемые родительским потоком. Мы можем использовать стратегию перехвата исключений, чтобы избежать распространения исключений на входящие соединители и родительские потоки.
Эта стратегия также гарантирует, что транзакция, обработанная потоком, не будет откатываться при возникновении исключения.
пример
Эта стратегия может быть применена к системе бронирования рейсов, в которой у нас есть поток для обработки сообщений из очереди. Обогащение сообщения добавляет к сообщению свойство для назначения места, а затем отправляет сообщение в другую очередь.
Теперь, если в этом потоке возникнет какая-либо ошибка, сообщение выдаст исключение. Здесь наша стратегия исключения исключений может добавить заголовок с соответствующим сообщением и может вытолкнуть это сообщение из потока в следующую очередь.
Выбор стратегии исключения
Если вы хотите обработать исключение на основе содержимого сообщения, тогда лучшим выбором будет стратегия выбора исключений. Работа этой стратегии исключений будет следующей:
-
Во-первых, он перехватывает все исключения, генерируемые в родительском потоке.
-
Затем он проверяет содержимое сообщения и тип исключения.
-
И наконец, он направляет сообщение в соответствующую стратегию исключения.
Во-первых, он перехватывает все исключения, генерируемые в родительском потоке.
Затем он проверяет содержимое сообщения и тип исключения.
И наконец, он направляет сообщение в соответствующую стратегию исключения.
В стратегии выбора исключений может быть несколько стратегий исключения, таких как Catch или Rollback. Если в рамках этой стратегии исключений не определена стратегия, сообщение будет перенаправлено в стратегию исключений по умолчанию. Он никогда не выполняет никаких операций фиксации, отката или использования.
Стратегия исключений
Это относится к общей стратегии исключений, которая определена в отдельном файле конфигурации. В случае, когда сообщение выдает исключение, эта стратегия исключений будет ссылаться на параметры обработки ошибок, определенные в глобальной стратегии исключения, отлова или выбора. Как и стратегия выбора исключений, она никогда не выполняет никаких операций фиксации, отката или использования.