Реализация. Создание корпоративной сервисной шины

9.6 Создание потоков сообщений

В этом разделе большая задача по созданию всех потоков сообщений разбита на четыре меньших этапа:

1. Создание проектов потоков сообщений и зависимостей.
2. Создание файлов потоков сообщений.
3. Соединение потоков сообщений (разделы 9.6.2 – 9.6.5) и настройка параметров узлов.
4. Написание 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.

1. Создайте первый проект потока сообщений ( рис. 9.56). Выберите пункт меню File (Файл) New (Новый) Message Flow Project (Проект потока сообщений). Введите имя AvailabilityFlows и нажмите Next (Далее).
   

   
   Рис. 9.56. Создание нового проекта потока сообщений
2. Создайте другие проекты потоков сообщений, перечисленные в табл. 9.9.
3. Добавьте зависимости, указанные в табл. 9.9, выбирая по очереди каждый проект, набор сообщений и открывая его свойства ( рис. 9.57).
   

   
   Рис. 9.57. Зависимости в представлении Properties (Свойства)

   Таблица 9.9. Проекты потоков сообщений и потоки сообщений

   Проект потока сообщений	Поток сообщений	Набор сообщений и база данных
   Группа B CommonSOAPHttpFlows Зависимости: группа A	Common.esql4Это не поток, а общий модуль .esql. Мы будем использовать его позже.	Группа A: Assessor Message Set База данных ASSESSOR
   	Fault
   	Reply
   	ClientError
   Группа C AssessorReportFlows Зависимости: группы A, B, D	Flow6
   	Flow6a
   	Flow7
   	Flow7a
   	Flow8
   	Flow9
   Группа D AssessorReportSOAPHttpFlows Зависимости: группы A, B, C	Flow6aAck
   	Flow9Ack
   	Input6
   	Output6a
   	Output7
   	Output9
   Группа E AvailabilityFlows Зависимости: группы A, B, F	Flow3
   	Flow3a
   	Flow4
   	Flow4a
   Группа F AvailabilitySOAPHttpFlows Зависимости: группы A, B, E	Flow3aAck
   	Input3
   	Output3a
4. Создайте схему брокера в каждом проекте потока сообщений:
   • Выберите пункт меню File (Файл) New (Новый) Broker Schema (Схема брокера). Выберите один из проектов потоков сообщений и назовите схему proxyAssessorSystem. Нажмите Finish (Готово).
   • Скопируйте и вставьте схему в остальные проекты потоков сообщений.
   

   
   Рис. 9.58. Схема брокера
5. Создайте все файлы потоков сообщений, указанные в табл. 9.9, помещая потоки в схему брокера ( рис. 9.59)
   

   
   увеличить изображение
   Рис. 9.59. Потоки сообщений
6. Настройте зависимости проекта набора сообщений и проектов потоков сообщений, как показано в таблице.

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".

1. Как и во всех подпотоках, начните поток с входного узла.
2. Создайте узел TryCatch. Мы не хотим, чтобы неперехваченные ошибки приводили к рекурсивному вызову потока Fault, поэтому мы добавляем узел TryCatch и направляем перехваченные им ошибки на трассировочный узел.
3. Создайте вычислительный узел Identify fault для создания сообщения об ошибке. Реализация узла Identify fault, как и всех остальных вычислительных узлов, вставляемых в потоки на данной стадии, описывается в разделе, посвященном разработке ESQL.
   

   
   Рис. 9.60. Поток ошибок
   Пока же щелкните правой кнопкой мыши по узлу Identify fault, выберите пункт меню Open ESQL, переименуйте ESQL-модуль в Fault_Identify_Fault и сохраните созданный ESQL-файл. Убедитесь, что ESQL-модуль идентифицируется в параметре ESQL Module, как показано на рис. 9.61.
   

   
   Рис. 9.61. Указание пути к модулю ESQL
   Совет. Давайте ESQL-модулям информативные имена. Хорошей практикой является начинать имя с имени потока и добавлять суффикс в виде имени вычислительного узла. Таким образом код esql будет проще найти, и меньше будет вероятность выбрать неверный ESQL-модуль при прямом открытии ESQL-файлов через навигатор.
4. Создайте узел HttpReply, который будет возвращать ошибку.
5. Создайте три трассировочных узла, которые помогут в будущем отладить поток. Существует множество соглашений, которым нужно следовать и которые помогают при отладке. Мы используем соглашение, связанное с применением зарезервированных в каталоге сообщений WebSphere Business Integration Message Broker номеров сообщений с 3051 по 3099, используем вывод в журнал событий Windows. Каждый трассировочный узел имеет имя, соответствующее номеру ошибки, чтобы можно было быстро выявить источник ошибки в потоке ( рис. 9.62).
   

   
   Рис. 9.62. Конфигурирование трассировочного узла

Соедините узлы и сохраните их. Используйте инструмент Connection (Соединение) из палитры ( рис. 9.63).

Рис. 9.63. Использование инструмента Connection для соединения узлов

Reply

Подпоток Reply (Ответ) – это простой узел HttpReply.

Создание подпотока Reply имеет две причины:

1. Для упаковки: при использовании другого транспорт-специфического проекта потока вместо проекта HttpSOAP связи подпотоков останутся теми же, будет использован только другой узел Reply.
2. Подпоток может быть более сложным при использовании других типов транспорта, и эта сложность будет заключена в потоке Reply.

Рис. 9.64. Подпоток Reply

ClientError

Поток ClientError (Клиентская ошибка) просто отслеживает ошибки, возвращаемые брокеру Web-службами или обнаруженные в клиентских потоках, и отправляет их в журнал событий ( рис. 9.65).

Рис. 9.65. Поток ClientError

Позже, не затрагивая основного потока, можно будет добавить более сложную обработку ошибок, с непрямой трассировкой ошибки до подпотока. Трассировочный узел 3062 выводит дерево исключений и другую полезную информацию. На рис. 9.66 показано, как вывести на экран все деревья брокера.

Рис. 9.66. Задание шаблонных значений для трассировочного узла ClientError