Изменение процесса изучения претензий

11.3 Создание рабочего потока ClaimInvestigation_TOBE

В разделе 7.2.4, "Инсталляция и конфигурирование WebSphere MQ Workflow", мы создали работающую систему WebSphere MQ Workflow. Теперь нам нужно изменить существующий процесс обработки претензий, чтобы автоматизировать задачу RequestExternalReports, выполняющуюся в рабочем потоке.

Сюда входят следующие задачи:

1. Повторное создание процесса ClaimInvestigation_ASIS в WebSphere MQ Workflow Buildtime.
2. Создание структур данных, которыми процесс будет обмениваться с операцией RequestExternalReports.
3. Определение интерфейса операции RequestExternalReports, через который будет вызываться прокси-процесс RequestExternalReports в WebSphere Business Integration Server Foundation. Будет использоваться JMS-совместимый интерфейс XML Enterprise Service.

11.3.1 Импортирование рабочего потока ASIS

Чтобы импортировать рабочий поток ASIS, выполните следующие шаги:

1. Откройте WebSphere MQ Workflow buildtime – FMC.
2. Выберите пункт Buildtime > Import (Импорт), найдите файл .\SG24-6636\Workflow\ClaimInvestigation_ASIS.fdl и нажмите OK ( рис. 11.2).
   

   
   увеличить изображение
   Рис. 11.2. Процесс ClaimInvestigation_ASIS
3. Чтобы открыть процесс ClaimInvestigation, сделайте двойной щелчок по процессу ClaimInvestigation на верхнем уровне.

11.3.2 Создание структур данных для RequestExternalReports

Для этого существует несколько способов, но, к сожалению, нельзя импортировать WSDL пряо из Rational Software Architect.

1. Моделировать новые структуры данных прямо в WebSphere MQ Workflow.
2. Моделировать структуры данных в WebSphere Business Integration Modeler и импортировать их в виде FDL.
3. Создать новую XML-схему в WebSphere Studio Application Development Integration Edition.

   В нашем сценарии мы использовали первый подход. Проще не вносить никаких изменений в существующие структуры данных в WebSphere MQ Workflow, а экспортировать их в FDL, а затем трансформировать в WSDL, используя инструмент FDL2WSDL. Ниже в этом разделе мы создадим прокси-процесс, являющийся частью интеграции WebSphere MQ Workflow/WebSphere Business Integration Server Foundation. В этом процессе мы производим трансформацию между структурами данных, используемыми в WebSphere MQ Workflow, и интерфейсом служб, который применяется новым процессом RequestExternalReports, работающим в WebSphere Business Integration Server Foundation.

   Альтернативный подход, где мы начинаем с WSDL, заданного целевой службой, и изменяем FDL, который используется WebSphere MQ Workflow, приводя его в соответствие с интерфейсом службы, более соответствует архитектурному направлению, которое мы пытаемся применять. Так что для полноты использования цепочки инструментов, которую мы стараемся применять, ниже описывается, как следует изменить WebSphere MQ Workflow, чтобы он играл роль клиента существующего интерфейса службы.
4. Перейдите к WSDL-файлу, который содержит структуры данных, которые нам нужно импортировать в WebSphere MQ Workflow. Для примера мы используем файл Proxy(1).wsdl.
5. В графическом редакторе WSDL раскройте тип порта RequestExternalReports_UPES и его сообщения и выберите структуру requestAssessor (см. рис. 11.3).
   

   
   Рис. 11.3. Структуры данных, которые нужно преобразовать в схемы
6. Перейдите на закладку Source (Исходный код), и курсор будет установлен в выбранной структуре. Скопируйте сложный тип requestAssessor.
7. Вставьте тип в новый файл схемы, между тегами схемы.
8. Повторите процесс для типа requestAssessorReponse.
9. Выполните глобальную замену xsd: <blank>; пространство имен для схемы – заданное по умолчанию.
10. Сохраните изменения. Ошибок не будет.
11. Укажите пространство имен схемы http://workflow.lgi.itso ( рис. 11.4).
    

    
    Рис. 11.4. Схема RequestExtenalReports
12. Экспортируйте файл схемы: выделите файл, нажмите правую кнопку мыши, выберите пункт меню Export (Экспорт) File system (Файловая система) и укажите директорию для экспорта.

Конвертирование схемы в FDL

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

1. Откройте проект ITSOLGI в WebSphere Business Integration Modeler.
2. Выберите пункт меню File (Файл) Import (Импорт) WebSphere Business Integration Modeler Import (Импорт) XML Schema (XML-схема) Next (Далее). Выберите файл RequestExternalReports.xsd, укажите в качестве целевого проекта ITSOLGI и нажмите Next (Далее). Должен быть выбран бизнес-элемент ( Business Item ). Нажмите Finish (Готово), а затем OK.
3. Выберите папку workflow.lgi.itso, нажмите Export (Экспорт) WebSphere MQ Workflow FDL. Укажите целевую директорию – папку itso.lgi.workfow, выберите Export specific items (Экспорт специфических элементов) Finish (Готово) OK.

Импортирование в WebSphere MQ Workflow

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

1. Перейдите на закладку Implementation (Реализация) в WebSphere MQ Workflow Buildtime.
2. Выберите пункт Buildtime > Import (Импорт). Укажите файл ITSOLGI.fdl, который был экспортирован из Modeler.
3. Удалите w_ из имен структур данных, открыв свойства этих двух структур данных и изменив их свойство Name (Имя).

11.3.3 Определение интерфейса для RequestExternalReports

Теперь нам нужно определить интерфейс рабочего потока для изучения претензий, который мы будем использовать для вызова процесса RequestExternalReports в WebSphere Business Integration Server Foundation.

С точки зрения WebSphere MQ Workflow-процесс RequestExternalReports – это простая автоматизированная операция, которая вызывает процесс RequestExternalReports путем отправки сообщения JMS/XML при помощи WebSphere MQ. По окончании процесс RequestExternalReports возвращает операции RequestExternalReports другое сообщение.

Единственный дополнительный этап, необходимый для того, чтобы система WebSphere MQ Workflow могла вызывать BPEL-процесс в WebSphere Business Integration Server Foundation, – это экспортирование из системы Workflow WSDL-файла, содержащего полное определение структур сообщений, передаваемых в систему Workflow и из нее. Этот файл может использоваться для определения процесса ClaimInvestigation как партнерской ссылки в процессе RequestExternalReports.

Создание UPES для операции RequestExternalReports

UPES (заданный пользователем сервер выполнения программы) определяет, как автоматизированная операция взаимодействует с внешней программой при выполнении автоматизированной операции от имени рабочего потока. Существует две формы UPES – синхронный и асинхронный. Асинхронный UPES не возвращает управление в WebSphere MQ Workflow. Синхронный UPES заставляет операцию ожидать завершения выполнения. Срок выполнения может быть длительным. Мы будем использовать синхронный UPES.

На практике UPES реализуется как очередь WebSphere MQ. Рабочий поток помещает сообщение во входную очередь UPES, когда есть работа, которую нужно выполнить, а программная операция прослушивает очередь, извлекает сообщение и выполняет операцию. По завершении работы программная операция посылает в Workflow сообщение-ответ. Хотя для прослушивания входной программной операцией создается специфическая входная очередь UPES, в Workflow по умолчанию, как правило, есть только одна очередь ответов, EXECXMLINPUTQ, которая прослушивается на предмет поступления сообщений-ответов.

Cоздание UPES

Для создания UPES выполните следующие действия:

1. Выберите пункт меню BuildTime закладка Network (Сеть) DOMAIN (Домен) FMCGRP.
2. Щелкните правой кнопкой мыши по FMCSYS и выберите пункт меню New UserDefined Program Execution Server (Новый пользовательский сервер выполнения программ).
3. На закладке General (Общие) укажите в поле имени значение UPESSVR, выберите версию 3.4.0 в раскрывающемся списке версий.
4. На закладке Message Queuing (Очереди сообщений) укажите в поле Queue Name (Имя очереди) значение WPCUPESQ, а поле Queue Manager Name (Имя менеджера очереди) оставьте пустым.
   Важно! Мы используем кластеризацию WebSphere MQ, и эта очередь будет кластерной очередью, определенной на машине с WebSphere Business Integration Server Foundation. Если вы не используете кластеризацию, то имя очереди должно представлять собой определение удаленной очереди или ее псевдоним. Плохой практикой является явное определение имени менеджера очереди, поскольку уменьшается прозрачность местоположений.
5. Укажите в поле Message Format (Формат сообщений) значение JMS-compliant XML (JMS-совместимый XML) и нажмите OK.