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

9.4.4 Импортирование схем в брокер

Далее импортируйте файлы схем в рабочее пространство инструментария Broker Toolkit. Вы можете организовать импорт схем, поместив файлы схем, относящиеся к каждому проекту набора сообщений, в соответствующий проект, или же можно импортировать все схемы в общую папку.

9.4.5 Использование схем для создания MDF

Теперь, когда все наши файлы схем находятся в рабочем пространстве Broker Toolkit, мы можем использовать их для заполнения файлов определений сообщений (message definition file, MDF).

Вы создали новый файл определений сообщений (.mxsd). Повторите данные шаги для каждого файла схемы. Вы должны получить 10 сообщений об ошибках, связанных с конфликтом имен (рис 9.23).

Устранение дубликатов имен и типов

Легче всего устранить шесть ошибок, помеченных буквами А. Эти ошибки вызваны тем, что поток 3 и поток 4 используют одинаковые имена сообщений. Высокоуровневые элементы сообщения применять необязательно, поскольку в действительности мы будем использовать сообщение-конверт SOAP (SOAP envelope).

Оставшиеся четыре ошибки вызваны дубликатами типов CarDetails и AssessorAckMessage в одном пространстве имен. В данном случае нам повезло. Это полные дубликаты, и мы можем удалить один из дублей, заменив его ссылкой. Если бы типы имели одинаковые имена и пространства имен, но при этом различались, то у нас было бы только два варианта: заставить одну из команд разработки изменить определения в исходных материалах и внести изменения везде, где изменения определений на что-то повлияли, или использовать несколько наборов сообщений для хранения конфликтующих типов.

Решение проблемы дублирования имен сообщений

Эта ошибка, возникающая, даже если сообщения находятся в разных пространствах имен, вызвана тем, что версия 5 WebSphere Business Integration Message Broker не использует в данной ситуации пространства имен для различения сообщений. Возможно, это будет исправлено в версии 6.

Для решения проблемы дублирования имен сообщений, выполните следующие действия:

Число ошибок уменьшится до четырех.

Решение проблемы дублирования типов

Эта процедура несколько более хитрая. Проблема показана на рис 9.25.

Тип AssessorAckMessage в пространстве имен itso.lgi.broker имеет дубликаты, которые обведены на левой половине рисунка. Тип CarDetails дублируется в пространстве имен itso.assessor, как показано в правой части. Обратите внимание, что в пространстве имен itso.assessor есть дубликат типа AssessorAckMessage, но это не представляет проблемы, поскольку этот дубль находится в другом пространстве имен.

Мы удалим тип AssessorAckMessage из AssessorReport(8) и заменим его ссылкой на определение в DeliverAssessment(7).

Откройте в представлении ).(рис 9.26) Тип AssessorAckMessage в сообщении AssessReport(8)

Удалите тип и нажмите OK в появляющемся сообщении для подтверждения удаления элемента receiveAssessorReportReturn.

Выделите сообщение receiveAssessorReportResponse, щелкните правой кнопкой мыши и выберите пункт меню Add Local Element (Добавить локальный элемент). Введите значение receiveAssessorReportReturn, чтобы восстановить элемент.

Новый элемент отобразится в окне редактора определения сообщения. Выберите string в столбце Type (Тип), а в раскрывающемся списке выберите More (Еще).

Выберите тип показано восстановленное сообщение-ответ.(рис 9.27) Заново созданное сообщение-ответ receiveAssessorReportResponse

Используя сходную процедуру, удалите одно из определений CarDetails.

Удалите тип CarDetails. Нажмите OK в предупреждающем сообщении.

Откройте элемент requestAssessorAvailability в редакторе определения сообщения. Щелкните правой кнопкой мыши по элементу ** Anonymous **, выберите пункт меню Add Local Element и введите имя cardet.

Укажите тип (рис 9.28) Определение и ссылка на определение CarDetails в сообщении Availability(4)

Перетащите элемент .(рис 9.29) Заново созданный элемент requestAssessorAvailability

Сохраните файл определений сообщений. Теперь все ошибки должны быть исправлены.

9.4.6 Настройка SOAP MDF (soap11.mxsd)

У нас есть несколько вариантов определения конверта SOAP, в который заключаются схемы сообщений.

Для файла определения сообщений, созданного при помощи сданной схемы, будут выводиться предупреждения, поскольку модель сообщений MRM не полностью совпадает с XML-схемами. Мы можем решить эту проблему несколькими способами:

Мы выбрали вариант "с" – с редактированием файла определения сообщения для улучшения проверки SOAP-сообщений. Нужно выполнить два следующих действия:

Создание файла определения SOAP-сообщения

Схема SOAP 1.1 будет вызывать ошибку при преобразовании в файл определения сообщений; поэтому, прежде чем продолжить, нам нужно изменить ее. Брокер не поддерживает атрибуты списков. Откройте импортированную схему SOAP 1.1 в редакторе схем брокера, переключитесь на представление Source (Исходный код) и внесите изменения в соответствии с примером 9.8. Строка (<xs:list ... >) блокируется символом комментария и добавляются строки, начинающиеся с (<xs:restr ... >).

<xs:simpleType name="encodingStyle">
   <xs:annotation>
      <xs:documentation>'encodingStyle' indicates any canonicalization
conventions followed in the contents of the containing element. For
example, the value 'http://schemas.xmlsoap.org/soap/encoding/' 
indicates the pattern described in SOAP specification
      </xs:documentation>
   </xs:annotation>
<!-- <xs:list itemType="xs:anyURI" /> -->
   <xs:restriction base='xs:string'>
      <xs:pattern value='http://schemas.xmlsoap.org/soap/encoding%' />
   </xs:restriction>
</xs:simpleType>

Создайте новый файл определения сообщения в проекте Assessor Messageset, преобразовав измененную схему SOAP 1.1. Назовите это определение сообщения SOAP11. Вы увидите 13 предупреждений.

Создание SOAP-оболочки для сообщений

С помощью редактора файла определений сообщений внесите описанные ниже правки, что позволит избавиться от предупреждений и сжать проверку корректности SOAP-сообщений.

Удалите элементы Wildcard из элементов .

Удалите атрибут Wildcard из элемента Body.

Удалите пространства имен из трех оставшихся атрибутов Wildcard, показанных на рис 9.31. Для этого выделяйте каждый атрибут по очереди и открывайте закладку Properties (Свойства) вместо закладки Overview (Обзор) в редакторе определений сообщений (рис 9.32).(рис 9.32) Элементы, которые нужно отредактировать в схеме SOAP 1.1(рис 9.31) Удаление пространства имен из атрибутов WildcardСовет. Быстрее всего будет использовать представление Outline для выбора атрибутов, а затем вам нужно один раз перейти на закладку Properties (Свойства).

Установите в поле Content Validation (Проверка содержимого) для сложного типа Envelope значение OpenDefined (изначально там указано значение Closed ) (рис 9.33). Это означает, что потомками типа Envelope могут быть только атрибуты, определенные в данном наборе сообщений. Явными потомками его являются (рис 9.33) Параметр Content validation для сложного типа Envelope устанавливается в Open Defined

Установите в поле Content Validation (Проверка содержимого) для сложных типов Header и Detail значение Open (вместо установленного там Closed). Это означает, что здесь допустимо использовать любые атрибуты. Заголовки SOAP не являются обязательными, поэтому значение Min Occurs (Минимальное число вхождений) можно установить равным нулю, но такое значение не поддерживается в MRM, поэтому мы оставим значение 1.

Укажите в поле Complex type (Сложный тип) элемента Body вариант Composition, а в поле Content Validation (Проверка содержимого) – значение OpenDefined. Это позволит использовать в качестве потомка элемента Body любой из элементов импортированной схемы, но не элементы, отсутствующие в схеме.

Удалите шаблон (pattern facet) глобального атрибута mustUnderstand, поскольку он не является необходимым, и его удаление устраняет предупреждение, выдаваемое инструментарием Broker Toolkit (рис 9.34).(рис 9.34) Удаление шаблона из атрибута mustUnderstandПримечание. Данный шаблон представляет собой определение того, какие значения может принимать переменная. Булев тип имеет шаблон 0|1, что делает его похожим на перечислимый тип.

Добавьте в схему SOAP элемент Fault как потомок элемента Body. Для этого выделите элемент Body, щелкните правой кнопкой мыши и выберите пункт меню Add element reference (Добавить ссылку на элемент) (рис 9.35).(рис 9.35) Добавление ссылки на элемент в элемент Body

Прокрутите список до элемента ).(рис 9.36) Выбор ссылки на элемент Fault

В том же окне укажите для элемента Fault в поле Min Occurs (Минимальное число вхождений) значение 0 и сохраните изменения. Вы увидите, что все предупреждения исчезли.

Выполнив данные шаги, мы создали SOAP-оболочку для наших сообщений. Теперь нам нужно ввести сообщения в эту оболочку.

9.4.7 Создание SOAP-сообщений

При наличии SOAP-оболочки нам нужно выполнить еще пару шагов, чтобы завершить создание SOAP-сообщений в брокере:

Сохранение оболочки SOAP

Мы экспортируем оболочку SOAP в виде файла XML-схемы, и ее можно будет использовать в других проектах наборов сообщений в будущем.

Выберите файл определения сообщения SOAP11.mxsd в навигаторе ресурсов, выберите пункт меню New (Новая) $$\to$$ XML Schema (XML-схема). Выберите wire-формат XML1 и убедитесь в том, что файл SOAP11.mxsd выделен. Выберите пункт Strict Generation (Точная генерация) $$\to$$ Next (Далее), создайте новую папку для хранения XML-схемы (например, Generated) и нажмите Finish (Готово).

Преобразование сообщений Assessor в SOAP-сообщения

Последняя задача в создании набора сообщений – это объединение определения SOAP с каждым из 10 сообщений Assessor. Мы сделаем это путем импортирования файлов определений сообщений Assessor в файлы определений SOAP-сообщений, а затем сделаем сообщения Assessor потомками элементов Body SOAP-сообщения.

Начнем с определения сообщения AllocateAssessment(6).

Импортируйте файлы определений сообщений (MDF), представляющие службы Assessor в SOAP MDF:

Выделите файл SOAP11.mxsd в навигаторе ресурсов и перейдите на закладку Properties (Свойства) редактора определений сообщений, как показано на рис 9.37.(рис 9.37) Импорт сообщений Assessor в SOAP-сообщение

Щелкните правой кнопкой мыши по пункту Imports (Импорты) $$\to$$ Add (Добавить), выделите файл определения сообщения (рис 9.38) Импортирование определения сообщения Assessor в определение сообщения SOAP

Повторите эту операцию для всех файлов определений сообщений, как показано на рис 9.39.(рис 9.39) Все импортированные файлы определений сообщений

При выделенном файле определения SOAP11.mxsd откройте закладку Overview (Общий обзор) и раскройте структуру .(рис 9.40) Добавление элементов Assessor в качестве потомков в элемент Body и задание параметра Min Occurs

9.5 Реализация таблиц баз данных

База данных с этими таблицами должна располагаться на машине SAH414A, локальной для брокера сообщений. Сначала создадим на SAH414A базу данных и схему, затем создадим таблицы и, наконец, импортируем схемы и таблицы в рабочее место WebSphere Business Integration Message Broker, чтобы их можно было использовать в потоках сообщений.

9.5.1 Создание базы данных Assessor

Чтобы создать базу данных Assessor, выполните следующие шаги:

Запустите центр управления DB/2 на SAH414A. Запустите мастер создания баз данных, как показано на рис 9.43.(рис 9.43) Мастер создания баз данных

Назовите базу данных ASSESSOR (рис 9.44).(рис 9.44) Создание базы данных ASSESSOR

Поскольку объем реальной памяти для SAH414A ограничен, мы настроили использование памяти базой ASSESSOR (рис 9.45).

9.5.2 Создание схемы и таблиц

Выполните следующие шаги для создания схемы и связанных с ней таблиц.

С помощью центра управления DB/2 создайте новую схему и назовите ее EMERGE (рис 9.46).(рис 9.46) Создание схемы EMERGE

Щелкните правой кнопкой мыши по папке Tables (Таблицы), выберите пункт меню Create (Создать), укажите схеме EMERGE и назовите новую таблицу CLAIMASSESSOR (рис 9.47).(рис 9.47) Создание таблицы CLAIMASSESSOR

Используя данные, приведенные в таблица 9.5).(рис 9.48) Создание столбцов в таблице CLAIMASSESSOR

Определите два ключевых поля, назвав ограничение CA1 (рис 9.49).(рис 9.49) Определение ключей для CLAIMASSESSOR

Повторите процесс, используя данные в таблица 9.6).(рис 9.50) Таблица ACTIONASSESSOR

Таблица RESOLVEASSESSOR показана на рис 9.51.

9.5.3 Соединение базы данных с рабочим местом брокера

Чтобы присоединить базу данных, выполните следующие шаги:

Откройте из рабочего места перспективу Data (Данные) и щелкните правой кнопкой мыши в представлении DB Servers (Серверы БД). Выберите пункт меню New Connectio n (Новое соединение) (рис 9.52).(рис 9.52) Новое соединение с базой данных в Workbench

Заполните форму, как показано на рис 9.53.(рис 9.53) Определение соединения с базой данных

Импортирование базы данных в проекты брокера сообщений

Создав соединение между рабочим местом и базой данных ASSESSOR, мы хотим создавать схемы и таблицы прямо из рабочего места. Для этого нам нужно импортировать соединение с базой данных в проект в рабочем месте, который мы будем использовать для разработки таблиц.

Создайте проект потока сообщений (Message Flow) с именем ASSESSOR database. Мы обнаружили, что размещение определения базы данных в простом проекте приводит к появлению предупреждений, связанных с неидентифицируемыми сообщениями. Если разместить определение базы в проекте потока сообщений, такого не происходит. При создании проектов потоков сообщений, связывайте с каждым из них новую папку в перспективе Broker Application Development.

Выделите элемент ASSESSOR в представлении DB Servers (Серверы БД) (выполнив повторное соединение, если это необходимо). Выберите пункт Import to folder (Импортировать в папку), выберите папку базы данных ASSESSOR. Нажмите Finish (Готово) (рис 9.54).(рис 9.54) Импортирование нового соединения с базой данных в Workbench

Щелкните правой кнопкой мыши по файлу ASSESSOR_ASSESSOR.dbmxmi в папке базы ASSESSOR, выберите пункт меню New (Новый) $$\to$$ Other (Другое) $$\to$$ Schema Definition (Определение схемы) $$\to$$ Next (Далее). Укажите схему EMERGE и нажмите Finish (Готово).

Теперь база данных ASSESSOR импортирована в Workbench. Ссылки на базу дан- ных в инструкциях ESQL будут заполняться автоматически.

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

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

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

Создайте другие проекты потоков сообщений, перечисленные в табл. 9.9.

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

Проекты потоков сообщений и потоки сообщений

Проект потока сообщений	Поток сообщений	Набор сообщений и база данных
Группа B CommonSOAPHttpFlows Зависимости: группа A	Common.esqlЭто не поток, а общий модуль .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

Создайте схему брокера в каждом проекте потока сообщений:

Выберите пункт меню File (Файл) $$\to$$ New (Новый) $$\to$$ 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.(рис 9.60) Поток ошибокПока же щелкните правой кнопкой мыши по узлу Identify fault, выберите пункт меню Open ESQL, переименуйте ESQL-модуль в Fault_Identify_Fault и сохраните созданный ESQL-файл. Убедитесь, что ESQL-модуль идентифицируется в параметре ESQL Module, как показано на рис 9.61.(рис 9.61) Указание пути к модулю ESQLСовет. Давайте ESQL-модулям информативные имена. Хорошей практикой является начинать имя с имени потока и добавлять суффикс в виде имени вычислительного узла. Таким образом код esql будет проще найти, и меньше будет вероятность выбрать неверный ESQL-модуль при прямом открытии ESQL-файлов через навигатор.

Создайте узел HttpReply, который будет возвращать ошибку.

Создайте три трассировочных узла, которые помогут в будущем отладить поток. Существует множество соглашений, которым нужно следовать и которые помогают при отладке. Мы используем соглашение, связанное с применением зарезервированных в каталоге сообщений WebSphere Business Integration Message Broker номеров сообщений с 3051 по 3099, используем вывод в журнал событий Windows. Каждый трассировочный узел имеет имя, соответствующее номеру ошибки, чтобы можно было быстро выявить источник ошибки в потоке (рис 9.62).(рис 9.62) Конфигурирование трассировочного узла

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

Reply

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

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

ClientError

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

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

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

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

Поток Input3

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

Сконфигурируйте узел 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).

Создайте следующие узлы:

Вычислительный узел 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

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

Щелкните правой кнопкой мыши по связующему узлу Create Reply и выберите пункт меню Open Mappings (Открыть связи).

Щелкните правой кнопкой мыши по окну Source (Источник) и выберите пункт меню ).(рис 9.74) Выбор конверта SOAP для связи сообщений

Раскройте схемы сообщений и свяжите claimID в сообщении-источнике и в сообщении-цели.

Щелкните правой кнопкой мыши по элементу TimeStamp и выберите пункт меню Create one-sided mapping (Создать одностороннюю связь).

Нажмите на кнопку с тремя точками справа от слова ).

Сохраните файл связей.

Поток Flow4

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

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

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

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

Мы начинаем с узла TryCatch для предотвращения возврата ошибок клиенту брокера. Клиент брокера не ожидает никаких сообщений об ошибке, поскольку он уже получил подтверждение. Любые ошибки, возникающие здесь, обрабатываются брокером путем передачи управления в общую процедуру ClientError.

Используйте узел DataDelete для удаления старого экземпляра претензии из базы данных. Обратите внимание, что, если удаление производится средствами SQL, а указанный claimID не обнаруживается, возвращается предупреждение (соответствующее положительному номеру ошибки SQL). Данный узел по умолчанию сконфигурирован на игнорирование предупреждений [Опция Treat Warnings As Errors (Обрабатывать предупреждения как ошибки) в свойствах узла должна быть отключена.] За инструкциями по конфигурированию узла DataDelete обращайтесь к разделу "Конфигурирование узла Data Delete с именем Delete claim status".

Узел Prepare MQ удаляет HTTP-данные из папок сообщения и подготавливает папку MQ перед передачей папок в узел Aggregate Control. Это этап, связанный с защитным программированием. Мы не знаем, может ли функция агрегации воспринимать разные типы папок на разных узлах. Поскольку мы будем использовать WebSphere MQ в качестве интерфейса к узлам агрегирования, мы делаем так, чтобы для всех узлов агрегирования поток сообщений выглядел сходно с WebSphere MQ.

В узле Aggregate Control присвойте агрегату имя proxyAssessorSystem и укажите тайм-аут для узла Aggregate Reply. Для тестирования мы устанавливаем здесь значение, равное 115 секундам (рис 9.78).(рис 9.78) Свойства узла Aggregate Control

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

URL-адрес нужно где-то сохранить для последующего использования при создании HTTP-сообщения-запроса к оценщику, поскольку в папке сообщения URL не содержится. Мы также собираемся сохранить URL в базе данных CLAIMASSESSOR, возвращаемой в процесс ExternalClaimAssessor, как это определяется в его интерфейсе. Данный URL можно было бы сохранить в базе данных на этом этапе и прочитать позже, при задании URL пункта назначения. Нам пришлось бы сделать это таким способом, если бы мы решили считывать сообщение-запрос из очереди Assessor, а не соединять оставшуюся часть потока с выходным терминалом узла MQOut Assessor. Передача URL в локальное окружение (local environment) – несколько более эффективный способ, поэтому мы выбрали этот подход.

Вычислительный узел PrepareMQControl передает сообщение для отправки на управляющий терминал узла AggregateReply в потоке Flow3a. Снова сгенерируйте ESQL-модуль по умолчанию с именем Flow4_Control_Message.

Узел MQOutput, с именем MQOut Flow3a, посылает управляющее сообщение потоку Flow3a. Укажите в поле Queue Name (Имя очереди) на закладке Basic (Общие) значение FLOW3A.CONTROL. Поле Queue Manager (Менеджер очереди) оставьте пустым, чтобы использовался заданный по умолчанию менеджер очереди. На всех остальных закладках оставьте значения по умолчанию.

На закладке Advanced (Дополнительно) нужно указать в поле Message context (Контекст сообщения) значение Set All (Установить все).

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

В узле AggregateRequest укажите в поле Folder Name (Имя папки) значение Flow4. Это имя применяется в объединенном сообщении узла AggregateReply в качестве имени папки для хранения ответа на запрос.

Чтобы сохранить запрос в таблице CLAIMSASSESSOR, нам нужно использовать вычислительный узел Save AssessorRequest, а не узел Database Update, поскольку одно из полей связано с папкой LocalEnvironment, а не с входным сообщением. Укажите в поле Data Source (Источник данных) схему EMERGE и сгенерируйте ESQL-модуль по умолчанию с именем Flow4_Save_AssessorRequest. Сам код ESQL мы добавим позже.

Узел 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).

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

Поток Flow4a

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

Поток Flow3a

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

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

Поток Output3a

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

Поток Output3aAck

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

9.6.5 Создание потоков AssessorReport

На рис 9.84 показаны потоки, которые должны быть созданы для взаимодействий, связанных с отчетами оценщиков (Assessor Report).

Input6

Поток Input6 (рис 9.85) получает запрос на отчет об оценке от процесса ExternalClaimAssessor, передает управление в поток Flow6 для проверки и обработки и обрабатывает любые ошибки, возвращая SOAP-ошибку. Используется та же схема, что для потока Input3.

Сконфигурируйте узел Http Input следующим образом:

Поток Flow6

Поток Flow6 (рис 9.86) проверяет запрос, полученный из потока Input6, перед отправкой оценщику запроса на отчет об оценке. В потоке Flow6 используется та же схема, что и в потоке Flow3.

Поток Flow7

Поток Flow7 (рис 9.87) посылает запрос отчета об оценке конкретному оценщику. В таблице ACTIONASSESSOR для целей аудита хранится запись о запросах, в которую в потоке flow8 заносятся ответы. URL оценщика устанавливается в вычислительном узле set SOAP address. Код ESQL будет описываться ниже.

Установите связь между сообщением ActionAssessor(6) и таблицей ACTIONASSESSOR, как показано на рис 9.88.(рис 9.88) Связи для удаления претензии, направленной конкретному оценщику, в потоке Flow6

Щелкните по полям ASSESSORID и CLAIMID в представлении Outline (Общий обзор), удерживая клавишу Shift, чтобы выбрать оба столбца, и нажмите правую кнопку мыши (рис 9.89).(рис 9.89) Выбор обоих полей для формирования связующего выражения

Вы можете просмотреть выражение для удаления данных, выделив объединенную связь или одно из ее полей и щелкнув правой кнопкой мыши, выбрать пункт Edit Mapping (Редактировать связь). Нажмите OK (рис 9.91).(рис 9.91) Редактирование выражения для удаления данных

Связи, идущие от потока flow6 к потоку flow7, показаны на рис 9.92.(рис 9.92) Связи от потока flow6 к потоку flow7

Вставка в базу данных показана на рис 9.93.(рис 9.93) Вставка запроса отчета об оценке в таблицу ACTIONASSESSORВажно! Не забудьте объединить все связи в одной строке, иначе каждая связь будет вводиться в таблицу как одна строка.

Выделите все связи с помощью мыши, удерживая клавишу Shift, и выберите в меню правой кнопки мыши пункт Combine to same row (Объединить в одну строку) > Remove selected mappings (Удалить выбранные связи).

Поток Flow7a

Данный поток сообщений (рис 9.94) получает сообщение Flow7a от оценщика, который был выбран для создания отчета об оценке, проверяет сообщение, отправляет подтверждение и вызывает поток Flow6a, чтобы вернуть данные о согласии или отказе оценщика в процесс ExternalClaimAssessors. Этот поток похож на поток Flow4a.

Поток Flow6a

Поток Flow6a (рис 9.96) форматирует ответ с согласием оценщика для вывода потоком Output6a и сохраняет аудиторскую запись об ответе в таблице ACTIONASSESSORS.

Создайте связи для вызова потока Output6a, как показано на рис 9.98.(рис 9.98) Связи для потока flow6a

Поток Output6a

Поток Output6a (рис 9.99) связывает систему proxyAssessorSystem с корпоративной сервисной шиной LGI при помощи протокола SOAP/http и передает список с данными о готовности оценщиков в процесс ExternalClaimAssessor.

Поток Output6aAck

Поток Output6aAck не нужен, поскольку мы используем SOAP/http и ответ возвращается в узел Http Request потока Output6a.

Поток Flow8

Поток Flow8 (рис 9.100) получает отчет от выбранного оценщика и направляет его в поток Flow9 (рис 9.102). Он напоминает поток Flow7a.

Сконфигурируйте связующий узел Generate Reply так, как показано на рис 9.101.(рис 9.101) Конфигурирование связей для подтверждения в потоке Flow8

Поток Flow9

Поток Flow9 (рис 9.102) готовит сообщение с отчетом оценщика к передаче на принимающую партнерскую ссылку в процесс ExternalClaimAssessor. Он передает сообщение в поток Output9 для помещения на сервисную шину LGI после обновления своего аудиторского журнала.

Создайте связи для обновления данных в таблице, как показано на рис 9.103, используя процедуру, аналогичную описанной для потока Flow6a.(рис 9.103) Выражение обновления базы данных для потока Flow9

Создайте связи с сообщением, показанные на рис 9.104.(рис 9.104) Связи с сообщением для потока Flow9

Поток Output9

Поток Output9 (рис 9.105) связывает систему proxyAssessorSystem с корпоративной сервисной шиной LGI при помощи протокола SOAP/http и передает отчет оценщика в процесс ExternalClaimAssessor.

Поток Output9aAck

Поток Output9aAck не нужен, поскольку мы используем SOAP/http и ответ возвращается в узел Http Request потока Output9.

9.7 Создание кода ESQL для потоков сообщений

Последний этап конфигурирования потоков сообщений в брокере – это написание ESQL-кода для вычислительных узлов. Чтобы просмотреть все созданные нами для потоков ESQL-модули, откройте свойства любого вычислительного узла и нажмите кнопку Browse (Обзор) (рис 9.106).

На рис. рис 9.107 показан список ESQL-модулей, необходимых для proxyAssessorSystem, плюс модуль объявлений, common.esql.

Нам нужно написать 14 ESQL-модулей. Может показаться, что это очень много кода, но этот код делится лишь на такие четыре категории, как:

На рис 9.108 приводятся 15 связующих узлов, которые выполняют большую часть посреднических функций и манипуляций с данными и не требуют написания ESQL-кода.

9.7.1 ESQL-функции, поддерживающие агрегацию

В табл. 9.10 перечислены семь ESQL-модулей, необходимых для конкретных потоков сообщений.

Flow4_PrepareMQ

В примере 9.9 входное сообщение копируется в выходную папку с удалением HTTP-заголовков и заменой их новым MQMD.

CREATE COMPUTE MODULE Flow4_PrepareMQ
   CREATE FUNCTION Main() RETURNS BOOLEAN
   BEGIN
      SET OutputRoot = InputRoot;
      SET OutputRoot.HTTPInputHeader = null;
      SET OutputRoot.HTTPResponseHeader = null;
      CREATE NEXTSIBLING OF OutputRoot.Properties domain 'MQMD';
      SET OutputRoot.MQMD.StrucId = MQMD_STRUC_ID; -- create MQMD
      SET OutputRoot.MQMD.Version = MQMD_CURRENT_VERSION;
      SET OutputRoot.MQMD.Format = '          ';
      SET OutputRoot.MQMD.MsgType = MQMT_DATAGRAM;
      RETURN TRUE;
   END;

Flow4_Fan_Out

В примере 9.10 представлен ESQL-код для модуля Flow4_Fan_out. Код имеет восемь частей.

Почти весь код (за исключением данных в SQL-инструкциях Insert и ссылках LocalEnvironment) сгенерирован с помощью функции автозаполнения (Autocomplete), так что этот код написать гораздо проще, чем кажется на первый взгляд.

CREATE COMPUTE MODULE Flow4_Fan_Out
 CREATE FUNCTION Main() RETURNS BOOLEAN
 BEGIN
  DECLARE numberOfAssessors INTEGER CARDINALITY (InputRoot.MRM.soap11:Body.
      fl3:requestAssessorAvailability.fl3:assessorList.fl3:assessors[]);
  DECLARE assessorCount INTEGER 0;
  WHILE assessorCount < numberOfAssessors DO
-- Эти инструкции должны быть в цикле, т.к. при передаче OutputRoot
очищается
     CALL CopyMessageHeaders();
     SET OutputLocalEnvironment = InputLocalEnvironment;
     SET OutputRoot.MQMD.MsgType = MQMT_REQUEST;
     SET OutputRoot.MQMD.ReplyToQ = 'AggIn';
     SET OutputRoot.MQMD.Report = MQRO_COPY_MSG_ID_TO_CORREL_ID;
     SET assessorCount = assessorCount + 1;
-- Адрес SOAP/Http для узла RequestHttp в качестве пункта назначения
    SET OutputLocalEnvironment.Destination.HTTP.RequestURL = InputRoot.
MRM.soap11:Body.
fl3:requestAssessorAvailability.fl3:assessorList.fl3:assessors[assessorCount].
fl3:assessorURL;
-- Копирование данных сообщения из списка (f17 – синоним f14 – то же
пространство имен)
-- Выходные поля должны быть в том же порядке, что и элементы
    SET OutputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
claimID
    = InputRoot.MRM.soap11:Body.fl3:requestAssessorAvailability.fl3:
claimID;
   SET OutputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
assessorID=
     InputRoot.MRM.soap11:Body.fl3:requestAssessorAvailability.fl3:
assessorList.
     fl3:assessors[assessorCount].fl3:assessorID;
   SET OutputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
cardet.
    fl7:makeOfCar =
       InputRoot.MRM.soap11:Body.fl3:requestAssessorAvailability.fl3:
makeOfCar;
   SET OutputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
cardet.
     fl7:registration = 'JB 007'; -- Fixup as the registration wasn't
provided
   SET OutputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
location =
  InputRoot.MRM.soap11:Body.fl3:requestAssessorAvailability.fl3:location;
  SET OutputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
reqDate =
  InputRoot.MRM.soap11:Body.fl3:requestAssessorAvailability.fl3:
requiredDate;
SET OutputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
responseTime=
  InputRoot.MRM.soap11:Body.fl3:requestAssessorAvailability.fl3:
responseTime;
  PROPAGATE;
    END WHILE;
-- Все сообщения передаются явно, поэтому пустое сообщение не передается
   RETURN FALSE;
END;

Flow4_Control_Message

Вычислительный узел Flow4_Control_Message передает выходное сообщение с терминала Control узла Aggregate Control на узел MQOutput, который помещает его в очередь, предназначенную для узла AggregateReply.

Все, что нам нужно сделать в этом модуле, – это создать сообщение WebSphere MQ и передать ему сообщение, переданное от узла Aggregate Control в виде неструктурированного XML-сообщения.

CREATE COMPUTE MODULE Flow4_PrepareMQControl
  CREATE FUNCTION Main() RETURNS BOOLEAN
    BEGIN
      SET OutputRoot.MQMD.StrucId = MQMD_STRUC_ID;
      SET OutputRoot.MQMD.Version = MQMD_CURRENT_VERSION;
      SET OutputRoot.XML = InputRoot.XML;
    RETURN TRUE;
  END;
END MODULE;

Flow4_Save_AssessorRequest

После генерации сообщения-запроса мы сохраняем запрос к оценщику в базе данных CLAIMASSESSOR, чтобы у нас было записанное узлом AggregateRequest значение msgid. Обратите внимание, что мы сохраняем URL оценщика в Local Environment.

CREATE COMPUTE MODULE Flow4_Save_AssessorRequest
  CREATE FUNCTION Main() RETURNS BOOLEAN
  BEGIN
    CALL CopyEntireMessage();
    SET OutputLocalEnvironment = InputLocalEnvironment;
-- Сохраняем сообщение в таблице CLAIMASSESSOR
    INSERT INTO Database.EMERGE.CLAIMASSESSOR (claimID, assessorID,
  assessorURL,location, reqdate, makeofcar, registration, replytoq,
replytoqmgr,
  correlid) VALUES (
    InputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
claimID,
    InputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
assessorID,
    InputLocalEnvironment.Destination.HTTP.RequestURL,
    InputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
location,
    InputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
reqDate,
    InputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
cardet.fl7:makeOfCar,
    InputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
cardet.fl7:registration,
    'NoReplytoQ',
    'NoReplytoQmgr',
-- Сохранение корреляционного маркера из id сгенерированного сообщения
InputLocalEnvironment.WrittenDestination.MQ.DestinationData.msgId);
RETURN TRUE;
END;

Flow3a_Prepare_Reply

Узел Flow3a_Prepare_Reply получает ответы с информацией о готовности от оценщиков. Его функция – извлечь для узла Aggregate Reply идентификатор ответа и создать сообщение-запрос WebSphere MQ, которое будет послано узлу MQ Reply для возврата реального сообщения-ответа с правильной корреляционной информацией. В примере 9.13 приводится SQL-код, решающий эти задачи.

CREATE COMPUTE MODULE Flow3a_Prepare_Reply
 CREATE FUNCTION Main() RETURNS BOOLEAN
  BEGIN
   SET OutputRoot = InputRoot;
   SET OutputRoot.HTTPInputHeader = null;
   SET OutputRoot.HTTPResponseHeader = null;
-- Создание MQ-сообщения-запроса – оно будет преобразовано в ответ в
MQReply
   CREATE NEXTSIBLING OF OutputRoot.Properties domain 'MQMD';
   SET OutputRoot.MQMD.StrucId = MQMD_STRUC_ID; -- create MQMD
   SET OutputRoot.MQMD.Version = MQMD_CURRENT_VERSION;
   SET OutputRoot.MQMD.Format = ' ';
   SET OutputRoot.MQMD.Report = MQRO_COPY_MSG_ID_TO_CORREL_ID;
   SET OutputRoot.MQMD.MsgType = MQMT_REPLY;
-- Тот же msgid как в сообщении-запросе, сохраненном в таблице Claim-
Assessor. MQReply скопирует его в correlid
   SET OutputRoot.MQMD.MsgId =
   THE (SELECT ITEM A.correlid FROM Database.EMERGE.CLAIMASSESSOR AS A
   WHERE A.assessorID =
     InputRoot.MRM.soap11:Body.fl8:assessorAvailability.fl8:assessorID
   AND A.claimID =
     InputRoot.MRM.soap11:Body.fl8:assessorAvailability.fl8:claimID);
   SET OutputRoot.MQMD.ReplyToQ = 'AggIn';
   RETURN TRUE;

Этот код очищает все HTTP-данные, создает MQMD и конфигурирует его как сообщение-запрос с исходным MsgId.

Flow3a_Generate_Output3a

Модуль Flow3a_Generate_Output3a создает результирующее сообщение Flow3a, включающее список оценщиков, возвращаемый процессу ExternalClaimAssessor.

Объединенное сообщение сохраняется в массиве ComIbmAggregateReplyBody. Flow4. По некоторым причинам нужно переустановить значение MessageSet в свойствах (Properties). Значение то же, которое мы устанавливали для всех входных папок.

CREATE COMPUTE MODULE Flow3a_Generate_Output3a
 CREATE FUNCTION Main() RETURNS BOOLEAN
  BEGIN
-- Сколько ответов получено? Папка Flow4 определена в узле Aggregate
Request?
   DECLARE noofreplies INTEGER
     CARDINALITY(InputRoot.ComIbmAggregateReplyBody.Flow4[]);
   DECLARE replyno INTEGER 1;
   DECLARE assessorID INTEGER;
   SET OutputRoot.Properties =
     InputRoot.ComIbmAggregateReplyBody.Flow4.Properties;
   SET OutputRoot.Properties.MessageSet = 'PIJ0MIK002001';
   IF noofreplies > 0 THEN
     SET OutputRoot.MRM.soap11:Body.fl3a:AvailableAssessorsList.claimID =
InputRoot.ComIbmAggregateReplyBody.Flow4[replyno].MRM.soap11:Body.fl8:
assessorAvailability.fl8:claimID;
   WHILE noofreplies >= replyno DO
     SET assessorID = InputRoot.ComIbmAggregateReplyBody.
Flow4[replyno].
     MRM.soap11:Body.fl8:assessorAvailability.fl8:assessorID;
     SET
OutputRoot.MRM.soap11:Body.fl3a:AvailableAssessorsList.resultAssessor-
Collection[
       replyno].assessorEstimations.assessorID = assessorID;
-- assessorURL отсутствует в ответе, поэтому нужно брать его из базы
данных
     SET
OutputRoot.MRM.soap11:Body.fl3a:AvailableAssessorsList.resultAssessor-
Collection[
replyno].assessorEstimations.assessorURL = THE (SELECT ITEM A.assessor
URL FROM
Database.EMERGE.CLAIMASSESSOR AS A WHERE A.assessorID = assessorID);
     SET
OutputRoot.MRM.soap11:Body.fl3a:AvailableAssessorsList.resultAssessorCo
llection[replyno].assessorEstimations.preCost =
InputRoot.ComIbmAggregateReplyBody.Flow4[replyno].
MRM.soap11:Body.fl8:assessorAvailability.fl8:predCost;
     SET
OutputRoot.MRM.soap11:Body.fl3a:AvailableAssessorsList.resultAssessorCo
llection[replyno].assessorEstimations.preDate =
InputRoot.ComIbmAggregateReplyBody.Flow4[replyno].
MRM.soap11:Body.fl8:assessorAvailability.fl8:predDate;
     SET replyno = replyno + 1;
   END WHILE;
  RETURN TRUE;
 ELSE
-- Не передавать сообщение, если ответов нет
  RETURN FALSE;
 END IF;
END;

9.7.2 Динамическая установка пункта назначения SOAP/Http

В примере 9.15 модуль Flow7_Set_SOAP_address задает пункт назначения SOAP/http для использования узлом HTTPRequest при отправке запроса за оценку выбранному оценщику. URL оценщика (assessorURL) находится во входном сообщении потока Flow6, но он не копируется в сообщение Flow7, посылаемое оценщику, поэтому ESQL-код получает его из входного сообщения потока Flow6.

CREATE COMPUTE MODULE Flow7_Set_SOAP_address
 CREATE FUNCTION Main() RETURNS BOOLEAN
  BEGIN
   CALL CopyEntireMessage();
 -- Нам нужно задать URL AllocateAssessmentRequest. Определен
 --только URL AssessorAvailabilityRequest
 -- Быстрое исправление состоит в наличии соглашения об именах...
   SET OutputLocalEnvironment.Destination.HTTP.RequestURL =
    REPLACE(InputRoot.MRM.soap11:Body.fl6:actionAssessor.fl6:assessor.
            fl6:assessorURL,'Availability','DeliverAssessment');
   RETURN TRUE;
 END;

9.7.3 Объявления общих префиксов пространств имен

В табл. 9.11 приведен модуль пространств имен.

Хорошей практикой является указание укороченных префиксов для пространств имен, используемых в коде ESQL. При этом инструкции становятся более короткими и удобными для чтения. Пространства имен будут находиться в наборе сообщений Assessor, который мы создали ранее. Если есть какие-то пропущенные или дублирующиеся префиксы, сейчас можно изменить или добавить их. Одинаковым пространствам имен нужно присваивать одинаковые префиксы. Мы соблюдали осторожность при редактировании файлов схем, чтобы все они содержали разные префиксы перед их преобразованием в наборы сообщений. Результаты можно увидеть на рис 9.109.

В навигаторе ресурсов выберите элемент Assessor Messageset $$\to$$ Assessor, выберите файл messageSet.mset и перейдите на закладку XML1 в редакторе набора сообщений.

Добавьте пространства имен и префиксы из каждого набора сообщений в модуль common.eqsl, как показано в примере 9.16. Обратите внимание, что там, где у нас пространства имен дублируются, мы не можем объявлять дублирующиеся префиксы.

BROKER SCHEMA proxyAssessorSystem
DECLARE soap11  NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
DECLARE fl3     NAMESPACE 'http://broker.lgi.itso.assessavail';
DECLARE fl3a    NAMESPACE 'http://AssessorAvailabilityList.itso';
DECLARE fl7     NAMESPACE 'http://assessor.itso';
DECLARE fl8     NAMESPACE 'http://assbroker.lgi.itso';
DECLARE fl6     NAMESPACE 'http://broker.lgi.itso.allocreq';
DECLARE fl6a    NAMESPACE 'http://AllocateAssessorResponse.lgi.itso';
-- DECLARE fl4a NAMESPACE 'http://assbroker.lgi.itso';
-- DECLARE fl7a NAMESPACE 'http://assbroker.lgi.itso';
-- DECLARE f4   NAMESPACE 'http://assbroker.itso';
-DECLARE fl9    NAMESPACE 'http://broker.lgi.itso.assessrept';

9.7.4 ESQL-код для обработки ошибок

В табл. 9.12 перечислены проверочные модули, которые нужно написать, и общий обработчик ошибок. Проверочные модули мало отличаются друг от друга.

На примере модуля Flow3_Validate показана одна из этих процедур.

Flow3_Validate

Все проверочные процедуры строятся по одному образцу:

Мы используем типичное сообщение об ошибке SOAP для хранения исключения, поскольку не все WSDL, с которыми мы работаем, будут иметь интерфейс ошибок. Ошибка должна возвращаться, только если Web-служба имеет интерфейс ошибок.

В примере 9.17 показан код для проверки в потоке Flow3.

CREATE COMPUTE MODULE Flow3_Validate
  CREATE FUNCTION Main() RETURNS BOOLEAN
  BEGIN
    DECLARE xInputRoot REFERENCE TO InputRoot;
    SET Environment.Message = 'requestAssessorAvailability';
-- В следующей инструкции регистрируется факт, что Web-служба генерирует
-- свое сообщение об исключении, а не использует ошибку SOAP по умолчанию
    SET Environment.SOAP.Fault.FaultOption = 'CustomizedFault';
    DECLARE xEnvironment REFERENCE TO Environment;
-- Проверка сообщения
    CALL ValidateMessage(xInputRoot, xEnvironment);
    IF Environment.SOAP.Fault.FaultCode = ' ' THEN
      SET OutputRoot = InputRoot;
    ELSE
-- Web-служба генерирует свое сообщение об ошибке... Это оно, и за
-- ним идет путь исключения
      SET Environment.soap11:Body.Fault.faultstring =
      'Flow3 input message validation failed... claimID ' ||
      CAST(InputBody.soap11:Body.fl3:requestAssessorAvailability.fl3:
claimID AS
      CHARACTER);
      THROW USER EXCEPTION VALUES ('Flow3 Input validation failed');
    END IF;
    RETURN TRUE;
END;

Оставшаяся часть проверочных модулей

Скопируйте код из примера Flow3_Validate и внесите изменения, показанные в табл. 9.13, в каждую из копий.

В каждой ESQL-реализации вычислительного узла Validate нужно изменить код, помеченный выше жирным шрифтом.

Fault_Identify_Fault

Модуль Fault_Identify_Fault (пример 9.18) предназначен для форматирования пакета с данными об ошибке SOAP, содержащего полезные для диагностики сведения. Модуль Main – это просто выход, если пакет уже создан. Выходные данные посылаются узлу HttpReply для возврата SOAP-клиенту, в противном случае вызывается процедура FaultProc, которая создает пакет с данными об ошибке.

CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
  IF Environment.SOAP.Fault.FaultCode = 'FaultReceived' THEN
-- Получена ошибка от другой Web-службы.... копируем данные на выход
    SET OutputRoot = InputRoot;
    ELSE
      CALL FaultProc();
    END IF;
    RETURN TRUE;
END;

Процедура faultproc, приведенная в примере 9.19, содержит восемь разделов. Она компонует сведения об ошибке, в зависимости от того, какая информация об этой ошибке доступна.

CREATE PROCEDURE FaultProc()
BEGIN
-- 1. Для Web-службы требуется типичное сообщение об ошибке SOAP
  CALL CopyMessageHeaders();
  SET OutputRoot.HTTPInputHeader = null;
  SET OutputRoot.HTTPResponseHeader = null;
-- 2. Укажем подходящие значения для неопознанной ошибки в конфигура-
-- ционных данных службы
  IF Environment.SOAP.Fault.FaultCode IS NULL OR
     Environment.SOAP.Fault.FaultCode = ' '
  THEN
    SET Environment.SOAP.Fault.FaultActor ='proxyAssessorSystem';
    SET Environment.SOAP.Fault.FaultCode = 'Server';
    SET Environment.SOAP.Fault.FaultString = 'Server error in SOAP Web
        service';
  END IF;
-- 3. Создадим выходное сообщение об ошибке SOAP (MRM)
  SET OutputRoot.Properties.MessageSet = 'Assessor';
  SET OutputRoot.Properties.MessageType = 'Envelope';
  SET OutputRoot.Properties.MessageFormat = 'XML1';
-- 4. Выводится MRM-сообщение. Добавим стандартный SOAP-конверт
-- Явно добавим пространство имен к значению кода ошибки
-- Поместим в данные об ошибке тело исходного сообщения (если возмож-
-- но... )
-- 5. Web-служба требует пользовательского сообщения об ошибке
  IF Environment.SOAP.Fault.FaultOption = 'CustomizedFault' THEN
    SET OutputRoot.MRM.soap11:Body.soap11:Fault.faultcode =
        'soap11'||':'||
        Environment.SOAP.Fault.FaultCode;
    SET OutputRoot.MRM.soap11:Body.soap11:Fault.faultstring =
        Environment.SOAP.Fault.FaultString;
    SET OutputRoot.MRM.soap11:Body.soap11:Fault.faultactor =
        Environment.SOAP.Fault.FaultActor;
    SET OutputRoot.MRM.soap11:Body.soap11:Fault.detail =
        Environment.soap11:Body;
  ELSE
-- 6. Web-служба требует заданное по умолчанию сообщение об ошибке SOAP
    SET OutputRoot.MRM.soap11:Body.soap11:Fault.faultcode = 'soap11'||':'||
        Environment.SOAP.Fault.FaultCode;
    SET OutputRoot.MRM.soap11:Body.soap11:Fault.faultstring =
        Environment.SOAP.Fault.FaultString;
    SET OutputRoot.MRM.soap11:Body.soap11:Fault.faultactor =
        Environment.SOAP.Fault.FaultActor;
  IF InputExceptionList.ParserException.ParserException.ParserException.
     Number=5117
  THEN
    SET OutputRoot.MRM.soap11:Body.soap11:Fault.detail.OriginalBody =
          'Input message is not valid XML';
  ELSE
    SET OutputRoot.MRM.soap11:Body.soap11:Fault.detail.OriginalBody =
        InputRoot.*[<];
  END IF;
-- 7. Проверяем, является ли список исключений результатом выполнения 
-- ESQL THROW...
  IF InputExceptionList.RecoverableException.RecoverableException.User-
     Exception.Number = 2951 THEN
-- 8. Если нет, выводим список исключений в сообщение об ошибке SOAP
  ELSE
    SET OutputRoot.MRM.soap11:Body.soap11:Fault.detail.ExceptionList =
        InputExceptionList;
  END IF;
  END IF;
END;

9.8 Размещение набора сообщений и потоков

Наша следующая задача – это размещение наборов сообщений и потоков для их последующего тестирования, но сначала нам нужно реализовать URL: http://SAH414A:7080/UNKNOWN, который был определен в потоках 4 и 7 как URL оценщика по умолчанию на случай, если поток не сможет задать URL оценщика динамически. Это одна из ситуаций из разряда "этого не должно случиться никогда", и поэтому мы ля ее обработки используем тривиальный поток брокера.

9.8.1 Создание потока UNKNOWN

В проекте потока сообщений CommonSOAPHttpFlows создайте новый поток сообщений UnknownAssessor (рис 9.110).

Перетащите в поток узел HttpInput и подпоток Fault и задайте свойства узла HttpInput следующим образом:

9.8.2 Создание архива брокера

Чтобы разместить потоки и набор сообщений, нам нужно создать архив брокера (Broker Archive, bar-файл) и указать, какие потоки и наборы сообщений будут в него входить. Для простоты мы определили один .bar-файл, содержащий все, что нам нужно, и разместили его в одной группе выполнения на одном брокере. Если бы нам, например, захотелось разместить потоки Assessor Availability отдельно от потоков Assessor Report, мы бы создали два архива брокера.

Переключитесь на перспективу Broker Administration (Администрирование брокера).

Щелкните правой кнопкой мыши по элементу Broker Archives (Архивы брокера), выберите пункт меню New (Новый) > Message Broker Archive (Архив брокера сообщений), присвойте новому файлу имя Assessor и нажмите Finish (Готово).

В редакторе .bar-файлов [панель . Нажмите Finish (Готово).

Нажмите Details (Подробно) в диалоговом окне, чтобы проверить наличие ошибок. Нажмите (рис 9.111) Создание файла Assessor.barПолучившийся архив выглядит так, как показано на рис 9.112. Обратите внимание, что отображаются только потоки с входными (Input) узлами.(рис 9.112) Файл Assessor.bar

Сохраните файл Assessor.bar.

CREATE PROCEDURE Flow3a_DataUpdate (IN s_Envelope REFERENCE
{'http://schemas.xmlsoap.org/soap/envelope/'}:Envelope)
BEGIN
--$IBM_WBIMB_XMIID=UpdateStatement_1
UPDATE Database.EMERGE.CLAIMASSESSOR AS "T#"
--$IBM_WBIMB_XMIID=UpdateStatement_1#assignments
SET PREDCOST = s_Envelope.soap11:Body.fl8:assessorAvailability.fl8:
predCost,
PREDDATE = s_Envelope.soap11:Body.fl8:assessorAvailability.fl8:predDate
WHERE "T#".CLAIMID =
s_Envelope.soap11:Body.fl8:assessorAvailability.fl8:claimID AND
"T#".ASSESSORID =
s_Envelope.soap11:Body.fl8:assessorAvailability.fl8:assessorID ;
END;

Размещение файла Assessor.bar в брокере

Запустите сервер с брокером сообщений, если вы этого еще не сделали. Обратитесь к разделу 7.2.5, "Инсталляция и конфигурирование брокера сообщений" и установите соединение с брокером через инструментарий. Обратите внимание на раздел "Конфигурация инструментария".

В перспективе Broker Administration (Администрирование брокера) откройте представление Domain (Домен) и щелкните правой кнопкой мыши по элементу WBRK_BROKER. Выберите пункт меню New (Новая) $$\to$$ Execution Group (Группа выполнения), назовите группу выполнения Assessor и нажмите Finish (Готово) (рис 9.113).(рис 9.113) Создание группы выполнения Assessor

Перетащите файл Assessor.bar в новую группу выполнения. Изучите подробные сведения в появившемся окне, нажмите OK.

Сделайте двойной щелчок мышью по журналу событий (Event log) в представлении Domain (Домен). Изучите открывшийся журнал FMCQM (рис 9.114). При выборе сообщения отображается его содержимое. Если вы точно следовали инструкциям, ошибок быть не должно.(рис 9.114) Проверка журнала событий

Обновите группу выполнения в представлении Domains (Домены). Результат показан на рис 9.115.(рис 9.115) Группа выполнения Assessor после размещения

9.9 Модульное тестирование размещенных потоков

Для тестирования размещенных потоков необходимы:

9.9.1 Инструменты для тестирования

Существует несколько клиентских SOAP-инструментов для тестирования. Наиболее доступным и универсальным является Web services Explorer (рис 9.116), входящий в пакеты WebSphere Studio Application Development Integration Edition и Rational Software Architect. Этот инструмент позволяет загрузить WSDL-файл и изменять его части, например адрес Web-службы. В него входят представления Form (Форма) и Trace (Трассировка) для просмотра содержимого сообщений-запросов и ответов. Обе эти рабочие среды содержат также TCP-монитор, с помощью которого можно увидеть, какие данные реально передаются.

9.9.2 Каркас системы оценщика и системы для работы с претензиями

Создать каркас системы оценщика и системы для работы с претензиями для тестирования системы proxyAssessorSystem очень легко. Одна из сложностей, связанных с системой оценщика, состоит в том, что она работает асинхронно и возвращает два сообщения в ответ на запрос к выбранному оценщику. Сложно запрограммировать в EJB определенные и неопределенные задержки.

Альтернативой является создание потока сообщений в брокере и имитация задержки путем помещения сообщений WebSphere MQ в приостановленные очереди с освобождением сообщений только по требованию (флаг Get Inhibit).

На рис 9.117 показан базовый каркас системы готовности оценщика. Этот поток посылает HTTP-ответ, а затем отправляет сообщение о готовности оценщика. Узлы Mapping позволяют легко сформировать правильное содержимое сообщений. Трассировочные узлы дают возможность отлаживать и проверять решение.

На рис 9.118 показан базовый каркас системы отправки отчета оценщика. Структура практически аналогична предыдущей, но на этот раз после ответа выполняются два потока, которые посылают подтверждение, а затем сам отчет. Запросы помещаются в очереди WebSphere MQ. Два других потока принимают запросы из очередей, когда флаг Get Inhibit сбрасывается при помощи инструмента MQ Explorer, а затем генерируют HTTP-запросы, посылаемые в систему proxyAssessorSystem.

9.9.3 Потоки трассировки и отладки

Существует три основных метода отладки потоков WebSphere Business Integration Message Broker: использование трассировки, использование трассировочных узлов и отладчик в рабочей среде.

Одной из лучших функциональностей WebSphere Business Integration Message Broker является возможность отладки. Соответствующие инструменты помогают визуализировать все данные, проходящие от угла к узлу, и, если вы захотите, вы можете с помощью средств трассировки получить полную распечатку функционирования потоков, можете использовать трассировочные узлы для регистрации части операций или можете с помощью отладчика пошагово проходить разделы потока или SQL-кода с интерактивной модификацией данных в ходе выполнения.

Трассировка

Управление трассировкой осуществляется из командной строки, и она работает на уровне групп выполнения. Вы можете изменить уровень трассировки и трассировать отдельные потоки, для чего нужно установить опции в представлении Domains (Домены) рабочей среды.

Приведенные ниже пять скриптов помогут быстро выполнить трассировку.

Скрипт ClearAtrace (пример 9.21) и скрипт GetAtrace (пример 9.22) работают с интерфейсами брокера. Уровень трассировки, установленный, например, с помощью средств рабочей среды, остается без изменений. Скрипты ClearTraces и GetTraces (примеры 9.23 и 9.24) содержат списки исследуемых групп выполнения, а скрипт (пример 9.25) сводит все эти скрипты в одну команду, запускаемую каждый раз, когда нужно выполнить трассировку.

@rem очистка трассировочного журнала
@SETLOCAL
@rem первый аргумент – имя брокера, а второй – группа выполнения
@mqsichangetrace %1 -u -e %2 -r
@echo Tracing options for execution group %2 running on broker %1
@mqsireporttrace %1 -u -e %2
@ENDLOCAL

@rem Получение данных в трассировочный журнал
@SETLOCAL
@rem первый аргумент – имя брокера, а второй – группа выполнения
@mqsireadlog %1 -u -e %2 -o %2.xml
@mqsiformatlog -i %2.xml -o %2.txt
@start notepad %2.txt
@ENDLOCAL

@SETLOCAL
@Call ClearAtrace WBRK_BROKER LGIAvailability
@Call ClearAtrace WBRK_BROKER LGIReport
@Call ClearAtrace WBRK_BROKER Assessor
@ENDLOCAL

@SETLOCAL
@Call GetAtrace WBRK_BROKER LGIAvailability
@Call GetAtrace WBRK_BROKER LGIReport
@Call GetAtrace WBRK_BROKER Assessor
@Call ClearTraces
@ENDLOCAL

@SETLOCAL
@Call GetTraces
@Call ClearTraces
@ENDLOCAL

Трассировочные узлы

Трассировочные узлы () можно вставлять в любое место потока или присоединять параллельно к другому выходному коннектору.

На рис 9.119 показан типичный трассировочный узел. Он сконфигурирован на вывод в журнал событий Windows события, которое выглядит как Error 3096 и содержит информацию из дерева сообщений, локального окружения (LocalEnvironment), списка исключений и окружения (Environment). Не имеет никакого значения, если какие-то данные в период выполнения оказываются пустыми. Используйте SQL-выражения для формирования выводимых данных, ведь для отладки большой объем дампа весьма полезен.

Номер сообщения (Message number) выбирается из предустановленного каталога из зарезервированного диапазона (3051-3099), и для него существует заранее заданное сообщение. Можно определять дополнительные каталоги и сообщения, но для отладки имеющийся каталог сообщений вполне подходит.

Обычной процедурой является вызов консоли управления Windows (Windows Management Console) и просмотр журнала приложений. Очистите журнал перед запуском трассировки, и, если вы правильно выбрали номера сообщений, процесс выполнения можно легко проследить по трассировочным событиям, появляющимся в журнале.

Отладка

Последней технологией, которую мы опишем, является традиционная пошаговая отладка.

Откройте перспективу Flow Debug (Отладка потока), которая отображается в виде красного жучка (). Диалоговое окно поможет вам подключиться к брокеру, а затем – к одной или нескольким группам выполнения, а также расставить точки останова. Обратите внимание, что кнопка, на которую нужно нажимать, чтобы выполнить шаг в ESQL-коде, отличается от кнопки, которую нужно нажать, чтобы выполнить шаг в потоке сообщений, и ее часто не замечают (рис 9.120).

В окнах переменных отображаются значения переменных при прохождении ESQL-кода в вычислительном узле. Если в вашем потоке нет кода ESQL, отладчик будет не слишком полезен. В окне переменных есть специальная папка Debug Message, в которой отображаются все доступные в потоке данные (рис 9.121).

В окнах переменных отображаются значения переменных при прохождении ESQL-кода в вычислительном узле. Если в вашем потоке нет кода ESQL, отладчик будет не слишком полезен. В окне переменных есть специальная папка Debug Message, в которой отображаются все доступные в потоке данные (рис 9.121).