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

9.6.4 Создание потоков AvailabilityFlows

На рис. 9.67 показаны потоки AvailabilityFlows, которые нужно определить.

увеличить изображение
Рис. 9.67. Потоки AvailabilityFlows

Поток Input3

Поток Input3 получает сообщение RequestAvailability от процесса ExternalClaimAssessors и передает его потоку 3 (Flow3) для проверки и обработки. Исключения перехватываются и передаются в процедуру Fault для возврата ошибки SOAP ( рис. 9.68).

Рис. 9.68. Поток Input3

1. Сконфигурируйте узел Http Input следующим образом:
   • На закладке Basic (Общие) установите в поле URL Selector (Выбор URL) значение, предоставленное архитектором решения в файле AssessorAvailablity(3). wsdl: http://SAH41403:7080/RequestAssessorAvailability, и значение тайм-аута 60 секунд.
     Внимание! TCP/IP порт 7080 является портом слушателя по умолчанию для брокера сообщений. Он задается командой mqsicreatebroker (-P номерпорта) и изменяется командой mqsichangebroker.
   • На закладке Default (По умолчанию) укажите свойства набора сообщений так, как показано на рис. 9.69.
     

     
     Рис. 9.69. Свойства набора сообщений для узла Http Input
   • На закладке Validation (Проверка) укажите в поле Validate (Проверять) значение Content and Value (Содержимое и значение).

Поток Flow3

Данный поток сообщений получает сообщение от потока Input3, проверяет его, посылает назад ответ-подтверждение и вызывает поток 4 (flow4) для распределения сообщения по оценщикам ( рис. 9.70).

Рис. 9.70. Основа потока 3

1. Создайте следующие узлы:
   • Вычислительный узел Validate для проверки входящего сообщения. Мы напишем код ESQL позже, в разделе 9.7.4, "ESQL-код обработки ошибок".
     • Сейчас откройте код ESQL через пункт меню, появляющегося при нажатии правой кнопки мыши, и сохраните код, заданный по умолчанию ( рис. 9.71).
       

       
       Рис. 9.71. Для создания ESQL-модуля по умолчанию выберите пункт меню Open ESQL (Открыть ESQL)
       Это позволит устранить ошибку компиляции.
     • На закладку Basic (Общие) страницы Properties (Свойства) вычислительного узла ( рис. 9.72) установите в поле Data Source (Источник данных) схему EMERGE, а в поле Compute Mode (Режим вычислений) оставьте значение Message (Сообщение). Это опция, установленная по умолчанию, которая позволяет любым изменениям, вносимым в папки сообщений в данном режиме, распространяться на последующие узлы. Мы устанавливаем в поле Compute Mode (Режим вычислений) значения Message и LocalEnvironment для узлов, которые должны изменять и распространять агрегационную информацию, хранящуюся в дереве LocalEnvironment, а также в дереве сообщений.
       

       
       Рис. 9.72. Установка общих свойств вычислительного узла
     • На закладке Validation (Проверка) установите в поле Validate (Проверять) значение Content and Value (Содержимое и значение), как показано на рис. 9.73. Эту опцию можно отключить по окончании тестирования для увеличения производительности работающей системы.
       

       
       Рис. 9.73. Установка параметров проверки
       Примечание. В дальнейшем мы предполагаем, что эти параметры вычислительных узлов и проверки установлены на всех узлах, которые занимаются передачей информации в папках.
   • Создайте связующий узел Create Reply, который будет связывать ответ с сообщением-подтверждением.
   • Создайте подпоток Flow4. Создайте пока пустой подпоток, добавив в Flow4 узел Input и сохранив его. Теперь можно добавить подпоток Flow4 в Flow3 еще до того, как будут определены детали Flow4. Перетащите Flow4 в Flow3.
   • Подпоток Reply. Перетащите поток Reply в поток Flow3.
2. Теперь сконфигурируем узел соответствия.

Конфигурирование связующего узла Create Reply

Выполните следующие шаги:

1. Щелкните правой кнопкой мыши по связующему узлу Create Reply и выберите пункт меню Open Mappings (Открыть связи).
2. Щелкните правой кнопкой мыши по окну Source (Источник) и выберите пункт меню Add Message mapping input (Добавить точку входа для связи с сообщением):
   • Выберите элемент SOAP envelope, нажмите Next (Далее), затем Finish (Готово) и сделайте то же самое в поле Target (Цель) ( рис. 9.74).
     

     
     Рис. 9.74. Выбор конверта SOAP для связи сообщений
   • Раскройте схемы сообщений и свяжите claimID в сообщении-источнике и в сообщении-цели.
   • Щелкните правой кнопкой мыши по элементу TimeStamp и выберите пункт меню Create one-sided mapping (Создать одностороннюю связь).
   • Нажмите на кнопку с тремя точками справа от слова undefined. Удалите слово undefined из поля цели. Выберите пункт Date/Time functions (Функции даты/времени) и нажмите на двойную стрелку справа. Выберите функцию CURRENT_TIMESTAMP и перетащите ее в целевое поле ( рис. 9.76).
   • Сохраните файл связей.

увеличить изображение
Рис. 9.75. Установление связей Flow3_Create_Reply

увеличить изображение
Рис. 9.76. Указание значения CURRENT_TIMESTAMP

Поток Flow4

Этот поток сообщений (рис. 9.77) получает проверенное сообщение от потока flow3 и генерирует одно или несколько сообщений, которые распространяются между оценщиками.

увеличить изображение
Рис. 9.77. Поток Flow4

Он также обновляет таблицу CLAIMASSESSOR базы данных, сохраняя информацию, которая должна быть вставлена в сообщения-ответы, возвращаемые в процесс ExternalClaimAssessors.

1. Входящее сообщение содержит URL оценщика. Для ответа, возвращаемого процессу ExternalClaimAssessors в потоке Flow3a, также нужен URL оценщика, поэтому мы сохраняем его и будем извлекать позже, используя claimID и assessorID.
2. Нам нужно сохранить идентификаторы всех сообщений (msgid) для всех сообщений потока Flow4, чтобы можно было устанавливать корреляцию с ответами оценщиков. Мы не можем делать допущение о том, что ответы будут содержать корреляционный ID (correlationId) WebSphere MQ, поскольку нам нужно реализовывать решение с использованием транспортного протокола SOAP/http и других протоколов.

Поток Flow4 генерирует уникальный идентификатор msgid для сообщения, посылаемого оценщику, путем создания реального сообщения WebSphere MQ и отправки его в узел агрегации с сохранением msgid в базе CLAIMSASSSESSOR для воссоздания корреляционного идентификатора при последующей агрегации.

Ниже приводятся данные о конфигурации потока.

1. Мы начинаем с узла TryCatch для предотвращения возврата ошибок клиенту брокера. Клиент брокера не ожидает никаких сообщений об ошибке, поскольку он уже получил подтверждение. Любые ошибки, возникающие здесь, обрабатываются брокером путем передачи управления в общую процедуру ClientError.
2. Используйте узел DataDelete для удаления старого экземпляра претензии из базы данных. Обратите внимание, что, если удаление производится средствами SQL, а указанный claimID не обнаруживается, возвращается предупреждение (соответствующее положительному номеру ошибки SQL). Данный узел по умолчанию сконфигурирован на игнорирование предупреждений [Опция Treat Warnings As Errors (Обрабатывать предупреждения как ошибки) в свойствах узла должна быть отключена.] За инструкциями по конфигурированию узла DataDelete обращайтесь к разделу "Конфигурирование узла Data Delete с именем Delete claim status".
3. Узел Prepare MQ удаляет HTTP-данные из папок сообщения и подготавливает папку MQ перед передачей папок в узел Aggregate Control. Это этап, связанный с защитным программированием. Мы не знаем, может ли функция агрегации воспринимать разные типы папок на разных узлах. Поскольку мы будем использовать WebSphere MQ в качестве интерфейса к узлам агрегирования, мы делаем так, чтобы для всех узлов агрегирования поток сообщений выглядел сходно с WebSphere MQ.
4. В узле Aggregate Control присвойте агрегату имя proxyAssessorSystem и укажите тайм-аут для узла Aggregate Reply. Для тестирования мы устанавливаем здесь значение, равное 115 секундам ( рис. 9.78).
   

   
   Рис. 9.78. Свойства узла Aggregate Control
5. Вычислительный узел Fan out передает новое сообщение-запрос каждому оценщику, указанному во входящем массиве оценщиков. Также этот узел сохраняет HTTP URL для маршрутизации сообщения в локальном окружении (Local Environment). На этой стадии просто сгенерируйте ESQL-модуль по умолчанию для этого вычислительного узла, которому присвойте имя Flow4_Fan_Out:. (К реализации этого узла мы вернемся позже.)

   URL-адрес нужно где-то сохранить для последующего использования при создании HTTP-сообщения-запроса к оценщику, поскольку в папке сообщения URL не содержится. Мы также собираемся сохранить URL в базе данных CLAIMASSESSOR, возвращаемой в процесс ExternalClaimAssessor, как это определяется в его интерфейсе. Данный URL можно было бы сохранить в базе данных на этом этапе и прочитать позже, при задании URL пункта назначения. Нам пришлось бы сделать это таким способом, если бы мы решили считывать сообщение-запрос из очереди Assessor, а не соединять оставшуюся часть потока с выходным терминалом узла MQOut Assessor. Передача URL в локальное окружение (local environment) – несколько более эффективный способ, поэтому мы выбрали этот подход.
6. Вычислительный узел PrepareMQControl передает сообщение для отправки на управляющий терминал узла AggregateReply в потоке Flow3a. Снова сгенерируйте ESQL-модуль по умолчанию с именем Flow4_Control_Message.
7. Узел MQOutput, с именем MQOut Flow3a, посылает управляющее сообщение потоку Flow3a. Укажите в поле Queue Name (Имя очереди) на закладке Basic (Общие) значение FLOW3A.CONTROL. Поле Queue Manager (Менеджер очереди) оставьте пустым, чтобы использовался заданный по умолчанию менеджер очереди. На всех остальных закладках оставьте значения по умолчанию.

   На закладке Advanced (Дополнительно) нужно указать в поле Message context (Контекст сообщения) значение Set All (Установить все).
8. Узел MQOutput с именем MQOut Assessor посылает сообщение-запрос в очередь Assessor. Это сообщение никогда не считывается и все время существует. Чтобы добиться этого в рабочей системе, можно размещать сообщения с истекшим сроком действия или, вместо того чтобы связывать выходной терминал узла с узлом AggregateRequest, создать еще один узел MQInput для считывания сообщения. Вы можете указать сгене- рированный msgid, чтобы удостовериться в том, что считывается нужное сообщение. На закладке Advanced (Дополнительно) нужно указать в поле Message context (Контекст сообщения) значение Set All (Установить все) и установить опцию New Message ID (Новый ID сообщения).
   

   
   Рис. 9.79. Параметры на закладке Advanced (Дополнительно)
9. В узле AggregateRequest укажите в поле Folder Name (Имя папки) значение Flow4. Это имя применяется в объединенном сообщении узла AggregateReply в качестве имени папки для хранения ответа на запрос.
10. Чтобы сохранить запрос в таблице CLAIMSASSESSOR, нам нужно использовать вычислительный узел Save AssessorRequest, а не узел Database Update, поскольку одно из полей связано с папкой LocalEnvironment, а не с входным сообщением. Укажите в поле Data Source (Источник данных) схему EMERGE и сгенерируйте ESQL-модуль по умолчанию с именем Flow4_Save_AssessorRequest. Сам код ESQL мы добавим позже.
11. Узел HttpRequest с именем SOAP/Http Assessors посылает запрос о готовности каждому оценщику. Для узла принимаются параметры по умолчанию, за исключением следующих:
    • На закладке Basic (Общие):
      • Укажите в поле Web service URL (URL Web-службы) значение http://SAH414A:7080/UNKNOWN. Вообще URL оценщика задается в вычислительном узле. Если используется данный URL, это означает ошибку. Мы можем либо реализовать этот URL в брокере, либо просто оставить данное довольно информативное значение, которое можно идентифицировать в журнале событий как сообщение об ошибке SOAP.
      • Для тестирования укажите в поле Request Timeout (Тайм-аут запроса) значение 60 секунд.
      • Выберите вариант Follow Http redirection (Выполнять HTTP-перенаправление) в поле Http Redirection Requests (Запросы перенаправления HTTP).
    • На закладке Advanced (Дополнительно) включите опцию Replace input message with web-service response (Замещать входное сообщение ответом Web-службы).
    • На закладке Default (По умолчанию) укажите свойства сообщения, как показано на рис. 9.69.
    • На закладке Validation (Проверка) укажите в поле Validate (Проверять) значение Content and Value (Содержимое и значение).
12. Ответы-подтверждения от оценщиков можно связать для тестирования с трассировочным узлом. В рабочей системе этот ответ можно отслеживать для измерения доступности систем оценщиков.

Конфигурирование узла Data Delete с именем Delete claim status

1. Щелкните по узлу Delete claim status правой кнопкой мыши и в его свойствах укажите в поле Data Source (Источник данных) схему EMERGE.
2. Откройте редактор связей из панели свойств и выполните следующее:
   • Выберите, как и в предыдущем разделе, SOAP envelope в поле Source (Источник).
   • Щелкните правой кнопкой мыши по полю Target (Цель) и выберите пункт Add RDB Table Mapping Output (Добавить точку выхода для связи с таблицей реляционной БД).
   • Мы предполагаем, что вы выполнили инструкции, приведенные в разделе 9.5.3, "Соединение базы данных с рабочим местом брокера". Согласитесь с пунктом Add database table schemas from workspace (Добавить схемы таблиц базы данных из рабочего пространства), нажмите Next (Далее), выберите таблицу ASSESSOR_ASSESSOR_EMERGE_CLAIMASSESSOR и нажмите Finish (Готово).
   • Щелкните правой кнопкой мыши по полю Target (Цель), выберите пункт меню Set RDB Schema name (Указать имя схемы РБД), установите переключатель Use schema name in table definition (Использовать имя схемы в определении таблицы).
   • Соедините ClaimID в поле Source (Источник) с полем Target (Цель), чтобы указать, что для удаления строки таблицы значение claimID должно совпадать.
   • Сохраните файл связей ( рис. 9.80).

увеличить изображение
Рис. 9.80. Задание условия удаления для таблицы CLAIMASSESSOR

Поток Flow4a

Этот поток сообщений получает сообщение Flow4a от оценщика, проверяет его, посылает подтверждение и вызывает поток Flow3a для выполнения агрегации ( рис. 9.81).

Рис. 9.81. Поток Flow4a

1. Создайте следующие узлы:
   • узел HttpInput для ожидания сообщения о готовности;
   • вычислительный узел Validate для проверки входного сообщения;
   • связующий узел Create Reply для связывания ответа с сообщением-ответом.
2. Перетащите потоки Reply, Fault и Flow3a в данный поток.
3. Сконфигурируйте узел HttpInput:
   • На закладке Basic (Общие):
     • Значение для поля URL selector (Селектор URL) предоставляется архитектором решения. Установите http://SAH414A:7080/AvailabilityReceive.
     • Для тестирования укажите в поле Maximum Client Wait time (Максимальное время ожидания клиента) значение 60 секунд.
   • На закладке Default (По умолчанию) укажите параметры набора сообщений так, как показано на рис. 9.69.
   • На закладке Validation (Проверка) укажите в поле Validate (Проверять) значение Content and Value (Содержимое и значение).
4. Переименуйте сгенерированный ESQL-модуль для вычислительного узла Validate в Flow4a_Validate.
5. Сконфигурируйте трансформацию связей для возврата подтверждения оценщику так, как описано в разделе "Поток Flow3".

Поток Flow3a

Данный поток сообщений ( рис. 9.82) получает все корректные сообщения из потока Flow4a и генерирует сообщение Flow3a, передаваемое в процесс ExternalClaimAssessors. Это часть агрегации, относящаяся к объединению сообщений.

Здесь мы также используем базу данных 'CLAIMASSESSOR' в силу нескольких причин:

1. Входящее сообщение не содержит URL оценщика, но для сообщения Flow3a URL оценщика необходим, поэтому мы извлекаем его, используя ключ ClaimID/AssessorID.
2. Сообщение Flow4a от оценщика не обязательно поступает из WebSphere MQ, поэтому нельзя предполагать, что оно содержит корреляционный ID (corellID), связанный с msgid исходного сообщения. При агрегации предполагается, что в corellID не содержится данное значение, поэтому поток извлекает исходный msgid из таблицы и передает его в узел AggregateReply как CorellID.
3. Для целей аудита сообщения записываются в базу данных CLAIMASSESSOR.

Рис. 9.82. Поток Flow3a

1. Узел MQInput Control получает контрольное сообщение агрегации из потока Flow3:
   • На закладке Basic (Общие) укажите в поле Queue Name (Имя очереди) значение FLOW3A.CONTROL.
   • На закладке Default (По умолчанию) укажите в поле Message Domain (Домен сообщений) значение XML. Никакие другие свойства на этой закладке не требуются.
   • На закладке Advanced (Дополнительно) укажите в поле Transaction mode (Режим транзакций) значение No. Координация с другими сообщениями MQ не требуется.
   • На закладке Validation (Проверка) укажите в поле Validate (Проверять) значение Content and Value (Содержимое и значение).
2. Создайте узел TryCatch для предотвращения возврата ошибок в предыдущий сервисный поток.
3. Соедините подпоток ClientError с терминалами Catch и Failure узлов MQInput и с терминалом Catch узла TryCatch.
4. Создайте узел типа Database update с именем Update CLAIMASSESSOR. Этот узел заносит в базу данных CLAIMASSESSOR ответ каждого оценщика.
5. Создайте вычислительный узел Prepare Reply и сгенерируйте ESQL-модуль по умолчанию с именем Flow3a_Prepare_Reply. Он будет использоваться для подготовки сообщения WebSphere MQ к передаче в узел AggregateReply.
6. Создайте узел MQ Reply с именем MQReply AggIn, где AggIn – имя очереди.
7. Создайте узел MQ Input с именем MQInput AggIn, где AggIn – имя очереди. Настройте параметры по умолчанию для обращения к набору сообщений, как описано выше.
8. В узле AggregateReply укажите в поле Aggregate Name (Имя агрегата) то же имя, что и для узла AggregateControl, – proxyAssessorSystem. Укажите тот же период тайм-аута – 115 секунд. Это период, по истечении которого неопознанные ответы отбрасываются, если они приходят до контрольного сообщения. Отключите опцию Transaction Mode (Режим транзакции), поскольку мы не ограничиваемся сообщениями WebSphere MQ.
9. Создайте вычислительный узел Generate Output3a и сгенерируйте ESQL-модуль по умолчанию с именем Flow3a_Generate_Output3a для создания отправляемого сообщения Flow3a.
10. Создайте пустой поток Output3a и установите с ним связь.
11. Свяжите терминалы Unknown и Timeout узла AggregateReply с трассировочными узлами, сконфигурированными так же, как трассировочные узлы в потоке Fault, но используйте специфические номера ошибок, которые помогут в отладке. В реальном работающем потоке можно применять несколько более контролируемый способ перехвата данных условий.
12. Свяжите терминал Out узла Timeout с потоком Output3a, поскольку мы хотим пересылать незаполненные до конца наборы ответов.

Поток Output3a

Поток Output3a ( рис. 9.83) связывает систему proxyAssessorSystem с корпоративной сервисной шиной компании LGI по протоколу SOAP/http и возвращает список готовых оценщиков в процесс ExternalClaimAsessors.

Рис. 9.83. Поток Output3a

1. Сконфигурируйте свойства узла HttpRequest следующим образом:
   • на закладке Basic (Общие):
     • укажите в поле Web service URL (URL Web-службы) ссылку на элемент Rece iveAssessorAvailabilityList в процессе ExternalClaimAssessor: http://SAH414B:9082/AssessorAvailabilityList;
     • для тестирования укажите в поле Request Timeout (Тайм-аут запросов) значение 60 секунд;
     • выберите вариант Follow Http redirection (Выполнять HTTP-перенаправление) в поле Http Redirection Requests (Запросы перенаправления HTTP);
   • оставьте без изменения параметры на закладках Advanced (Дополнительно) и Error (Ошибка);
   • параметры на закладке Default (По умолчанию) установите так, как показано на рис. 9.69;
   • укажите на закладке Validation (Проверка) в поле Validate (Проверять) значение Content and Value (Содержимое и значение).
2. Для тестирования направьте ответ в журнал событий, как показано в потоке Flow4.

Поток Output3aAck

Поток Output3aAck для SOAP/Http-реализации корпоративной сервисной шины LGI не нужен, поскольку подтверждение приходит на узел HttpRequest в потоке Output3a.