Реализация. Создание процесса Request External Reports

10.3 Интеграция процесса и его служб

Откройте редактор бизнес-процессов, сделав двойной щелчок по файлу Service Projects (Проекты служб) (ITSOLGI) Claim.TOBE.RequestExternalReports RequestExternalReports.bpel в представлении Services (Службы).

Возможно появление ошибок. Пока не обращайте на них внимания. Мы исправим эти ошибки позже.

В центре окна редактора можно видеть бизнес-процесс. Этот процесс унаследовал определение процесса из Modeler. Процесс в Modeler ориентирован в направлении справа налево, но в WebSphere Studio Application Development Integration Edition он ориентирован сверху вниз. В правой части редактора процесса ( рис. 10.5) можно видеть ссылки на партнеров, которые являются интерфейсами Web-служб, вызываемых операциями процесса. Эти службы в данный момент являются абстрактными. Modeler генерирует WSDL-файлы, но эти определения служб не имеют реализации. В нашем случае мы собираемся полностью заменить определения, поскольку они были созданы архитектором решения в Rational Software Architect.

увеличить изображение
Рис. 10.5. Редактор BPEL

В левой части окна редактора находится палитра для редактирования процесса. Добавляйте новые операции в процесс, выбирая значок в палитре и перетаскивая его в редактор. Информация о каждом элементе процесса отображается в разделе Detail (Подробно) в нижней части окна редактора. Содержимое этой области меняется в зависимости от того, какой элемент процесса был выбран.

На рис. 10.6 показаны рядом друг с другом редактор процесса из Modeler (слева) и редактор процесса из WebSphere Studio Application Development Integration Edition (справа).

Рис. 10.6. Импортированный процесс

Элементы Modeler и определения WSDL и BPEL соответствуют друг другу следующим образом:

• Локальные задачи (Local tasks) Modeler становятся вызывающими операциями (Invoke activities).
• Если локальной задаче назначен кадровый ресурс, то в WebSphere Studio Application Development Integration Edition эта задача превращается в операцию персонала (Staff activity). Выполняемая вручную задача ManualChooseAssesor превращается в операцию персонала.
• Разделения (Forks) и слияния (Merges) превращаются в операции назначения (Assign activity) и операции очистки (Empty activity).
• Операции назначения вставляются между всеми операциями. Операции назначения связывают выходную структуру данных предыдущей операции с входными данными следующей операции.

10.4 Интеграция процесса и его служб

В этом разделе мы возьмем поток BPEL, импортированный из WebSphere Business Integration Modeler, и преобразуем его в исполняемый поток BPEL. Нужно написать несколько фрагментов Java-кода, но в основном процедура будет связана с использованием мастеров конфигурирования или графического редактора процессов. Преобразование BPEL-процесса в исполняемую форму включает в себя девять этапов:

1. В разделе 10.4.1, "Исправление списка ссылок на партнеров в модели", мы заменим абстрактные ссылки на партнеров в модели бизнес-процесса, созданной бизнес-аналитиком, ссылками на партнеров, которые вызывают реальные службы, указанные архитектором решения.
2. В разделе 10.4.2, "Интеграция ссылок на партнеров с процессом", новые ссылки на партнеров связываются с соответствующими операциями потока и в поток добавляются дополнительные операции, расширяющие BPEL-модель для приведения ее в соответствие с архитектурой решения.
3. В разделе 10.4.3, "Конфигурирование ссылок на партнеров", мы проверяем, чтобы каждая ссылка была должным образом сконфигурирована в соответствии со своей ролью в операции (вызываемой или вызывающей) и чтобы в ссылке был правильно указан тип порта (или интерфейс).
4. В разделе 10.4.4, "Конфигурирование операций", мы проверяем, чтобы каждой операции были присвоены глобальные входные и выходные переменные и чтобы действия, необходимые для каждой операции, были выбраны правильно.
5. В разделе 10.4.5, "Конфигурирование типов входных и выходных переменных", мы проверяем, чтобы каждая входная и выходная переменная имела верный тип, указанный в соответствующем входном или выходном сообщении для данной операции.
6. В разделе 10.4.6, "Связывание данных между входными и выходными переменными", мы связываем входящие и исходящие данные для каждой ссылки на партнера, внося необходимые корректировки, чтобы данные соответствовали требованиям, которые предъявляют службы, связанные со ссылками.
7. В разделе 10.4.7, "Конфигурирование потока для ожидания ответа от оценщиков", мы добавляем в поток корреляционный набор, позволяющий ему ожидать получения асинхронных сообщений от оценщиков, и конфигурируем три операции, которые должны ожидать ответа оценщика, чтобы они использовали данный корреляционный набор.
8. В разделе 10.5.1, "Проверка результатов, полученных от RequestAvailability", мы проверяем результаты запроса готовности оценщиков, используя Java-фрагмент, а также конфигурируем две дополнительные ссылки для вызова ручной или автоматической операции выбора оценщика, которому будет предложено выполнить оценку.
9. В разделе 10.5.2, "Создание операции While для проверки согласования оценки", добавляется операция while, которая проверяет, согласен ли выбранный оценщик произвести оценку.

10.4.1 Исправление списка ссылок на партнеров в модели

Если вы посчитаете в правой части окна редактора ссылки на партнеров, которые были сгенерированы по модели RequestExternalReports, импортированной из WebSphere Business Integration Modeler, и сравните полученный результат с количеством WSDL-интерфейсов, необходимых для кооперации RequestExternalReports и импортированных из Rational Software Architect, вы увидите несовпадение. Это несовпадение обусловлено тем, что в модели бизнес-процесса не детализованы дополнительные взаимодействия, которые необходимы для реализации асинхронных потоков.

В табл. 10.1 приводятся WSDL-файлы для интерфейсов, в которых процесс RequestExternalReports играет роль либо клиента, либо сервера, и соответствующие ссылки на партнеров. Элементы, выделенные синим цветом, присутствуют в BPEL-модели, импортированной из WebSphere Business Integration Modeler, а элементы, выделенные красным цветом, – это отсутствующие элементы, которые нужно добавить наряду со способами маршрутизации запросов от ссылок на партнеров обратно – в поток процесса. Черные строки – это взаимодействия, не использующие компонент Automated Assessor.

С помощью следующей процедуры мы откорректируем список ссылок на партнеров.

1. Удалите ссылки на партнеров, импортированные с BPEL-процессом из модели Automated Assessors: откройте файл requestExternalReports.bpel в окне редактора, перейдите в представление Outline (Общий обзор), выделите все ссылки на партнеров и удалите их ( рис. 10.7).
   

   
   Рис. 10.7. Удаление сразу всех ссылок на партнеров
2. Создайте новые ссылки на партнеров по WSDL-файлам, предоставленным архитектором: выбирайте по очереди все WSDL-файлы и перетаскивайте на канву редактора с открытым файлом RequestExternalReports.bpel. WebSphere Studio Application Development Integration Edition предложит вам подтвердить выбранные порты служб и типы портов ( рис. 10.8).
   

   
   Рис. 10.8. Подтверждение выбора порта и типа порта

Добавляйте ссылки на партнеров в том порядке, в котором они находятся в потоке, и канва редактора будет выглядеть так, как показано на рис. 10.9.

увеличить изображение
Рис. 10.9. Ссылки на партнеров, основанные на интерфейсах из Rational Software Architect

10.4.2 Интеграция ссылок на партнеров с процессом

Итак, мы импортировали процесс RequestExternalReports из WebSphere Business Integration Modeler в виде BPEL-процесса и определения интерфейсов из Rational Software Architect в виде ссылок на партнеров. Следующая задача – связать ссылки на партнеров с процессом, добавив в поток новые операции, соответствующие добавленным ссылкам.

Связывание операций в потоке со ссылками на партнеров

1. Первая задача – связать каждую ссылку с соответствующей операцией.

   Выберите операцию в потоке и выберите действие со ссылкой из палитры, появляющейся около указателя мыши, как показано на рис. 10.10. В качестве альтернативы щелкните правой кнопкой мыши по операции и выберите пункт меню Set Partner Link (Задать ссылку на партнера).

   

   
   увеличить изображение
   Рис. 10.10. Создание соединения между операцией и ссылкой на партнера

   Протяните линию к соответствующей ссылке на партнера. Используйте табл. 10.1, в которой указаны соответствия для установления этих связей.

   Альтернативным способом создания соединения является выделить операцию, а затем открыть закладку Implementation (Реализация) в редакторе свойств, расположенном под канвой графического редактора. Далее выберите нужную ссылку на партнера, как показано на рис. 10.11. Этот метод можно использовать, если значки ссылки на партнера и операции находятся слишком далеко друг от друга и их нельзя соединить в одном окне.

   

   
   увеличить изображение
   Рис. 10.11. Указание типа ссылки на партнера в редакторе свойств
2. Переименуйте ссылки на партнеров в соответствии с записями в табл. 10.1 (это нужно только для ясности, на функционирование процесса это не влияет). После этого останется две ссылки, не связанные ни с одной операцией (AssessorAvailabilityLstPartner и AllocateAssessorResponsePartner). Третья новая ссылка, AssessorReportPartner, связана с операцией AssessorSendReport, имеющейся в потоке, но это не тот тип операции. Мы исправим эти проблемы далее.

Создание новых операций для получения сообщений от оценщиков

Сначала внесите исправления в операцию AssessorSendReport. Сейчас это вызывающая операция (invoke activity). Мы хотим сделать ее принимающей операцией (receive activity), чтобы она получала отчет об оценке претензии.

1. Щелкните правой кнопкой мыши по операции AssessorSendReport, выберите пункт меню Change Type (Изменить тип) Receive (Прием).

   Далее добавьте две новые принимающие операции, названные так, как показано красным цветом в графе "Assessor Automation: операция и роль" табл. 10.1 - AssessorAvailabilityReceive и AllocateAssessorResponse.
2. Выберите принимающую операцию из палитры ( рис. 10.12) и перетащите ее в процесс. Введите в поле имени AssessorAvailabilityReceive.
   

   
   Рис. 10.12. Выбор принимающей операции в палитре
3. Выделите коннектор, находящийся между вызывающей операцией RequestAvailability и операцией очистки Any assessor?, и удалите его ( рис. 10.13).
   

   
   Рис. 10.13. Выделение коннектора
4. Соедините операции RequestAvailability и AssessorAvailabilityReceive: щелкните правой кнопкой мыши по RequestAvailability и выберите пункт меню Set Link between Flow activities (Задать связь между операциями потока).
5. Соедините операции AvailabilityReceive и Any assessor?. Чтобы настроить расположение содержимого потока, щелкните правой кнопкой мыши по области потока и выберите пункт меню Align Flow Contents Automatically (Выровнять содержимое потока автоматически).
6. Соедините операцию со ссылкой на партнера AssessAvailabilityListPartner. Результат должен выглядеть так, как показано на рис. 10.14. Обратите внимание, что стрелка между ссылкой на партнера и операцией теперь имеет черный цвет и указывает на операцию, что обозначает направление сообщения.
   

   
   Рис. 10.14. Вставка новой операции AssessorAvailabilityReceive в поток
7. Повторите эти действия для вставки в поток операции AllocateAssessorReponse и соединения ее со ссылкой. Результат показан на рис. 10.15.
   

   
   Рис. 10.15. Вставка новой операции AllocateAssessorReponse в поток
8. На этом этапе стоит сохранить рабочее пространство в zip-файле. Выберите проект службы ITSOLGI в навигаторе служб, щелкните по нему правой кнопкой мыши, выберите пункт меню Export (Экспорт) Project Interchange выберите ITSOLGI и введите имя файла, в который будет производиться экспорт. Нажмите Finish (Готово).