Лучшие практики использования Mule ESB
В данной статье собраны лучшие практики и замечания, которые были выявлены нашими инженерами при работе над проектами, где используется интеграционная платформа MuleESB:
1. Naming conventions. Все компоненты mule flow и сами mule flow должны иметь такие названия, которые давали бы чёткое понимание того, какую функцию они несут. Стандартные имена компонентов вполне допустимы для элементов трансформации, однако для остальных элементов желательно использовать более понятные имена. Например:
- Название flow должно давать понимание того, что происходит в этом flow;
- Для элемента Choice можно указать, на основании чего строится условие;
- Для коннекторов по возможности можно указать адрес или путь, по которому принимается/отправляется информация;
- Для элементов логирования название по возможности должно отображать, какая информация логируется.
2. Необходимо выносить весь код, который можно использовать в других проектах, в отдельный проект/библиотеку.
3. Стандарт в использовании проперти:
- Весь хардкод нужно выносить в файлы настроек.
- Все настройки нужно подробно описать в комментариях к ним.
4. В Mule есть очень мощный язык выражений, который позволяет сделать компоненты Mule более динамичными. Например, Mule Expression Language позволяет динамически определять адреса для http-компонента. Для этого достаточно в поле host http-коннектора использовать выражения следующего вида:
- host=»#[xpath3(‘/request/host’)]» — если на вход http-коннектора поступают данные в формате xml.
- host=”#[payload]” — если адрес необходимо извлечь из payload.
-
host=”#[flowVars.host]” — если адрес необходимо извлечь из переменных flow.
Выражения Mule можно использовать практически во всех текстовых полях компонентов Mule.
5. Для каждого flow необходимо реализовывать свои exception strategy для корректной обработки исключений. Пример mule xml:
<set-payload value="#[exception]" doc:name="Set Payload asException"/>
<component doc:name="IncomingExceptionHandler">
<spring-object bean="IncomingExceptionHandler"/>
</component>
IncomingExceptionHandler java компонент (класс), в котором может происходить обработка возникшего исключения и формирование ответа.
6. SFTP connector best practices.
Кроме стандартных настроек подключения к sftp-серверу, также полезными могут быть:
- Response timeout (время ожидания ответа);
- Reconnection policy (настройки переподключения);
- Archive directory (директория для архивации загруженных данных).
7. Dataweave transformation. Представляет собой мощный инструмент обработки данных, позволяющий конвертировать данные из/в CSV, Excel, XML, JSON, Java Object и другие форматы. Можно задавать маппинги, значения по умолчанию, добавлять условную логику, фильтровать данные, группировать, строить цепочки трансформаций.
Возможны следующие операции над массивами: селекторы (для выбора элементов), операторы (map, concat, contains и др.)
Также можно использовать Dataweave language для несложных трансформаций. Например:
#[dw("{'payload': payload, 'interface':'CompInvoice'}",
"application/json")]
8. Работа с очередями. Mule позволяет работать с разными очередями, настройки которых имеют много общего (имя очереди, операция — чтение/запись), но при этом со своими особенностями:
- VM — in-memory очередь, поддерживает транзакции, но может использоваться только для обмена сообщениями между потоками приложения, а не несколькими приложениями.
- AnypointMQ — очередь, предоставляемая Mulesoft для коммерческого использования и интегрированная в платформу Anypoint. Не требует отдельного сервера для установки, но при этом не поддерживает транзакции.
- ActiveMQ — популярное open-source решение, поддерживающее JMS. Поддерживает транзакции и обмен сообщениями между приложениями, но требует отдельного сервера для установки.
9. Профилирование. Для профилирования можно использовать стандартную java/oracle утилиту jvisualvm.exe. Её можно найти по такому пути Windows C:\Program Files\Java\jdk1.8.0_65\bin\jvisualvm.exe (в каталоге bin установленного jdk). Данная утилита позволяет отслеживать используемые ресурсы java приложениями. Можно нагружать приложение и отслеживать затраты ресурсов при определённых нагрузках.
10. MUnit-тесты: mule flows нужно покрывать MUnit-тестами. Тестирование должно осуществляться на различных уровнях. Если flow содержит несколько subflows, то желательно протестировать как subflows по отдельности, так и flow, который их использует. В данном случае MUnit-тесты являются очень хорошим примером по использованию flow и его отдельных частей. Основные алгоритмы нужно покрывать Unit-тестами. Также мы рекомендуем использовать Data Driven Testing.
11. Нагрузочное тестирование. Для тестирования Mule-приложения под нагрузкой можно использовать JMeter. Данный инструмент позволяет проверить работу приложения в условиях поступления большого количества запросов от многих пользователей и предоставить результаты тестирования в удобной для анализа форме.
12. Форматирование xml.
- Следует создать вспомогательный компонент для красивого/удобного отображения в логах xml текста. При использовании данного компонента нужно учитывать, что он меняет xml, добавляя в него пробелы/ввод и т.д., что, в свою очередь, может сделать xml невалидным для веб-сервисов и различных утилит для работы с xml, поэтому перед логированием следует сохранить исходный xml, а после логирования вернуть в payload ранее сохранённый xml.
- Иногда в xml запросе приходят символы вида < вместо скобок <>, чтобы корректно работать с xml, нужно сделать операцию замены данных символов на <>. Для этого можно использовать вспомогательный класс, который будет производить замену escape символов.
13. Деплой приложения. Для деплоя приложения на CloudHub сервер можно воспользоваться Mule Plugin for Maven. Можно конфигурировать такие параметры, как версия Mule, имя пользователя, пароль, environment, бизнес-группу, имя приложения и другие.
14. Все компоненты рекомендуется делать spring бинами. Пример:
Опубликован документ «Лучшие практики проектирования REST API» Установка и настройка Swagger