О начале обучения |
Реализация. Создание корпоративной сервисной шины
9.6 Создание потоков сообщений
В этом разделе большая задача по созданию всех потоков сообщений разбита на четыре меньших этапа:
- Создание проектов потоков сообщений и зависимостей.
- Создание файлов потоков сообщений.
- Соединение потоков сообщений (разделы 9.6.2 – 9.6.5) и настройка параметров узлов.
- Написание esql-кода для всех вычислительных узлов.
9.6.1 Создание проектов потоков сообщений и зависимостей
Изучите дизайн организации потоков сообщений в разделе 9.3.2, "Потоки сообщений и независимость от транспортных протоколов".
Хорошая организация потоков сообщений упрощает понимание решения и управление им. Существует два набора транспортно-независимых потоков: потоки, связанные с готовностью оценщика, 3, 3a, 4 и 4a и потоки, связанные с отчетом об оценке 6, 6a, 7, 7a, 8 и 9. Мы используем два проекта потоков сообщений для транспортно-независимых потоков, чтобы было понятно, где мы работаем с готовностью (Availability), а где – с отчетами (Report).
Этим двум наборам транспортно-независимых потоков будут соответствовать два набора транспортно-специфических потоков для протокола SOAP/http. Наконец, будет проект потока сообщений для общих потоков SOAP/http.
В табл. 9.9 перечислены все проекты потоков сообщений – потоки, которые мы будем создавать и их зависимости. Взаимоотношения между потоками, а также между потоками и набором сообщений должны быть определены таким образом, чтобы ссылки на потоки и наборы могли быть корректно разрешены. Мы также определим пакеты для потоков сообщений, чтобы потенциально дублирующиеся имена потоков можно было корректно различить. Эти пакеты называются схемами брокера.
Все потоки используют общую схему брокера, так что символьные ссылки разрешаются в пределах этой схемы и путаницы с аналогично названными ресурсами из других проектов не возникнет.
Зависимости между проектами потоков сообщений и проектами наборов сообщений определяются в Workbench либо при создании нового проекта, либо позже, с использованием графического интерфейса Workbench.
- Создайте первый проект потока сообщений ( рис. 9.56). Выберите пункт меню File (Файл) New (Новый) Message Flow Project (Проект потока сообщений). Введите имя AvailabilityFlows и нажмите Next (Далее).
- Создайте другие проекты потоков сообщений, перечисленные в табл. 9.9.
- Добавьте зависимости, указанные в табл. 9.9, выбирая по очереди каждый проект,
набор сообщений и открывая его свойства (
рис.
9.57).
- Создайте схему брокера в каждом проекте потока сообщений:
- Выберите пункт меню File (Файл) New (Новый) Broker Schema (Схема брокера). Выберите один из проектов потоков сообщений и назовите схему proxyAssessorSystem. Нажмите Finish (Готово).
- Скопируйте и вставьте схему в остальные проекты потоков сообщений.
- Создайте все файлы потоков сообщений, указанные в табл. 9.9, помещая потоки в схему брокера ( рис. 9.59)
- Настройте зависимости проекта набора сообщений и проектов потоков сообщений, как показано в таблице.
9.6.2 Создание потоков сообщений
В разделах 9.6.3 – 9.6.5 мы свяжем и сконфигурируем все потоки сообщений начиная с общих потоков, а затем потоки, относящиеся к готовности и отчетам. Конфигурируются все параметры потоков, а также топология потоков. Останется только запрограммировать набор ESQL-файлов.
9.6.3 Создание потоков CommonSOAPHttpFlows
К общим потокам, которые нам нужно разработать, относятся подпотоки Fault (Ошибка) и Reply (Ответ). Мы также должны создать каркасную процедуру Validate SQL в файле common.esql, чтобы на нее могли ссылаться другие потоки.
Fault
Поток Fault возвращает правильно сформированное SOAP-сообщение, содержащее информативное описание причины ошибки и правильно сформированный SOAP-код ошибки.
Данный подпоток используется для базовой обработки ошибок во всех потоках сообщений. Он вызывается из входного узла любого потока сообщений при возникновении исключения. Мы применяем одну и ту же процедуру обработки ошибок для всех наших потоков сообщений. Эта процедура связана с терминалами Failure и Catch входных (Input) узлов. Все прочие терминалы ошибок в потоках сообщений остаются неподключенными, поэтому все исключения направляются через входной узел в данную процедуру. За дополнительной информацией обращайтесь к интерактивной справочной документации WebSphere Business Integration Message Broker, "Handling errors in message flows".
- Как и во всех подпотоках, начните поток с входного узла.
- Создайте узел TryCatch. Мы не хотим, чтобы неперехваченные ошибки приводили к рекурсивному вызову потока Fault, поэтому мы добавляем узел TryCatch и направляем перехваченные им ошибки на трассировочный узел.
- Создайте вычислительный узел Identify fault для создания сообщения об ошибке. Реализация узла Identify fault, как и всех остальных вычислительных узлов, вставляемых в потоки на данной стадии, описывается в разделе, посвященном разработке ESQL.
Пока же щелкните правой кнопкой мыши по узлу Identify fault, выберите пункт
меню Open ESQL, переименуйте ESQL-модуль в Fault_Identify_Fault и сохраните созданный
ESQL-файл. Убедитесь, что ESQL-модуль идентифицируется в параметре
ESQL Module, как показано на
рис.
9.61.
Совет. Давайте ESQL-модулям информативные имена. Хорошей практикой является начинать имя с имени потока и добавлять суффикс в виде имени вычислительного узла. Таким образом код esql будет проще найти, и меньше будет вероятность выбрать неверный ESQL-модуль при прямом открытии ESQL-файлов через навигатор.
- Создайте узел HttpReply, который будет возвращать ошибку.
- Создайте три трассировочных узла, которые помогут в будущем отладить поток. Существует множество соглашений, которым нужно следовать и которые помогают при отладке. Мы используем соглашение, связанное с применением зарезервированных в каталоге сообщений WebSphere Business Integration Message Broker номеров сообщений с 3051 по 3099, используем вывод в журнал событий Windows. Каждый трассировочный узел имеет имя, соответствующее номеру ошибки, чтобы можно было быстро выявить источник ошибки в потоке ( рис. 9.62).
Соедините узлы и сохраните их. Используйте инструмент Connection (Соединение) из палитры ( рис. 9.63).
Reply
Подпоток Reply (Ответ) – это простой узел HttpReply.
Создание подпотока Reply имеет две причины:
- Для упаковки: при использовании другого транспорт-специфического проекта потока вместо проекта HttpSOAP связи подпотоков останутся теми же, будет использован только другой узел Reply.
- Подпоток может быть более сложным при использовании других типов транспорта, и эта сложность будет заключена в потоке Reply.
ClientError
Поток ClientError (Клиентская ошибка) просто отслеживает ошибки, возвращаемые брокеру Web-службами или обнаруженные в клиентских потоках, и отправляет их в журнал событий ( рис. 9.65).
Позже, не затрагивая основного потока, можно будет добавить более сложную обработку ошибок, с непрямой трассировкой ошибки до подпотока. Трассировочный узел 3062 выводит дерево исключений и другую полезную информацию. На рис. 9.66 показано, как вывести на экран все деревья брокера.