Компания IBM
Опубликован: 14.08.2008 | Доступ: свободный | Студентов: 1090 / 150 | Оценка: 4.75 / 3.75 | Длительность: 27:55:00
Лекция 9:

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

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 (Файл) \to New (Новый) \to Message Flow Project (Проект потока сообщений). Введите имя AvailabilityFlows и нажмите Next (Далее).
    Создание нового проекта потока сообщений

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

    Рис. 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 (Файл) \to New (Новый) \to 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.
    Указание пути к модулю ESQL

    Рис. 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).

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

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

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

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

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

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

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

Поток ClientError

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

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

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

Рис. 9.66. Задание шаблонных значений для трассировочного узла ClientError
Надежда Белякова
Надежда Белякова
Россия
Pavel Pelevin
Pavel Pelevin
Украина, Одесса