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

10.4.6 Связывание данных между входными и выходными переменными

Все входные и выходные переменные теперь имеют типы, соответствующие данным во входящих и исходящих сообщениях. Следующий этап – это связать данные в переменных, полученных в одной операции, с входными переменными, необходимыми для связанной с операцией ссылки на партнера, а затем связать выходные результаты ссылки на партнера со входной переменной следующей операции. Это демонстрируется на рис. 10.20, где показан управляющий поток и поток данных, а также метаданные, используемые для связывания полей в одном сообщении с полями в следующем сообщении.

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

Связующей операцией может быть:

• фрагмент Java;
• операция трансформации;
• операция назначения (Assign activity).

Каждый вариант имеет свои преимущества и свои недостатки. Операция назначения – это самый простой способ установления прямых связей между полями одного сообщения и аналогичными полями в другой структуре. Трансформируются только пути к полям. Операция трансформации не требует написания кода и может осуществлять более сложные преобразования. Такая операция включает в себя обрабатывающие строки, которые могут оказаться сложнее, чем код. Фрагмент Java может представлять собой простой кусок кода, делающий не больше, чем операция назначения, или же выполняющий сложные преобразования.

Для потока BPEL, экспортированного из Modeler, были сгенерированны несколько базовых операций назначения. Мы собираемся заменить эти операции и добавить несколько других связей, чтобы закончить ту часть потока, которая связана с трансформацией данных. Мы в определенной степени ограничены в использовании операций назначения, поскольку в ряде сообщений WSDL-определения требуют более сложной обработки, и нам нужно применять либо Java-фрагменты, либо операции трансформации. Операция назначения в Process Choreographer версии 6 стала гораздо более гибкой, и ее, по причине ее простоты и высокой производительности, можно использовать во многих связях, которые в версии 5 осуществлялись с применением трансформаций.

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

• "Связывание операций Mapping IdentifyAssessors и ResponseTime". Используются две отдельных операции трансформации.
• "Связывание операции RequestAvailability". Показано, как выполнять агрегацию при помощи операции трансформации.
• "Связывание операции SelectAssessors". Используется еще одна простая операция трансформации.
• "Связывание операции RequestAvailability". Предлагаются фрагменты Java, а также используется операция трансформации для агрегирования данных, получаемых с трех входов.
• "Связывание операции StoreReport". Еще одна простая операция трансформации.
• "RequestExternalReport Reply". Еще одна простая операция трансформации.

Связывание операций Mapping IdentifyAssessors и ResponseTime

Первые две необходимые нам трансформации находятся в месте перехода от сообщения requestAssessorMessage к сообщению RequestListAssessorsMessag и к сообщению requestResponseTimeRequest. Мы используем две операции трансформации.

1. Удалите операцию Fork и две операции назначения, находящиеся между операцией RequestExternalReports Receive и операциями IdentifyAssessors и ResponseTimeBasedOnPolicy.
2. Создайте новую трансформирующую службу. Нажмите на соответствующий значок на панели действий или выберите пункт меню File (Файл) New (Новый) Transformer service (Трансформирующая служба) ( рис. 10.21).
   

   
   Рис. 10.21. Создание трансформирующей службы
3. Нажмите Next (Далее), введите имя IdentifyAssessorsTransformer, нажмите Next (Далее), введите в поле Operation Name (Имя действия) toIdentifyAssessors, нажмите Add (Добавить) Browse (Обзор), найдите файл ExternalClaimsAssessor.wsd, а в нем – входящее сообщение RequestExternalReports_RequestAssessorsMessage, нажмите Browse (Обзор), найдите исходящее сообщение RequestListAssessorsRequest:requestListAssessors.
4. Раскройте сообщения в редакторе трансформации и перетащите три поля входящего сообщения в соответствующие три поля исходящего сообщения. Результат показан на рис. 10.22.
   

   
   увеличить изображение
   Рис. 10.22. Связывание полей во входящем сообщении операции IdentifyAssessors
5. Повторите эти шаги для операции ResponseTimeBasedOnPolicy. Назовите службу ResponseTimeBasedOnPolicyTransformer.
6. Перетащите два WSDL-файла трансформирующих служб в процесс RequestExternalReports.bpel и переименуйте операции трансформации в ToIdentifyAssessors and ToResponseTimeBasedOnPolicy (в соответствии с названиями действий – просто для простоты документирования). Теперь BPEL-процесс будет выглядеть следующим образом ( рис. 10.23).
   

   
   увеличить изображение
   Рис. 10.23. Вставка трансформирующих служб в поток RequestExternalReports

Вы можете просматривать эти новые ссылки на партнеров точно так же, как любые другие. Откройте закладку Implementation (Реализация) операции ToIdentifyAssessors и нажмите кнопку Edit (Редактировать) для просмотра и изменения связи полей. Вы также можете выбирать новые действия и новые трансформирующие службы для данной операции. В проводнике служб (Service Explorer) найдите файл Identify AssessorsTransformer.wsdl и откройте его с помощью стандартного WSDL-редактора.

Связывание операции RequestAvailability

Эта связь обеспечивает агрегацию результатов, полученных от операций IdentifyAssessors и ResponseTimeBasedOnPolicy и некоторых исходных данных из сообщения RequestExternalReports в новое сообщение. Новое сообщение посылается на партнерскую ссылку RequestAvailability с маршрутизацией через корпоративную сервисную шину внешним оценщикам, которые, возможно, займутся обработкой претензии.

Очевидным способом решения данной задачи является использование еще одной операции трансформации, которая выполняет агрегацию. Можно повторить процедуру из предыдущего раздела для создания новой трансформирующей службы Transf ormerRequestAvailability. На этот раз к службе добавляются три входящих сообщения, как показано на рис. 10.26.

1. Убедитесь, что операции IdentifyAssessors, ResponseTimePolicy и RequestAvailability полностью соединены, как показано на рис. 10.24.
   

   
   увеличить изображение
   Рис. 10.24. Добавление операции трансформации ToRequestAvailability
2. Перетащите в поток новую операцию трансформации, присвоив ей имя ToRequestAvailability и подключив ее непосредственно перед операцией RequestAvailability, как показано в правой части рис. 10.24.
3. Откройте операцию ToRequestAvailability и задайте для ее переменной Response значение RequestAvailabilityInputCriterionVariable.
   

   
   увеличить изображение
   Рис. 10.25. Переменные, заданные в операции трансформации ToRequestAvailability
4. Нажмите кнопку Aggregate (Агрегация) и выберите входные переменные, которые должны быть агрегированы:
   • InputCriteriaVariable,
   • IdentifyAssessorsOutputCriteriaVariable,
   • ResponseTimePolicyOutputCriterionVariable.
5. На следующей панели введите имя файла AggregateRequestAvailability.
6. Приведите в порядок содержимое потока, и вы увидите, что был вставлен фрагмент Java (Java Snippet). Переименуйте фрагмент в AggregateRequestAvailability.
7. Вернувшись к новой операции трансформации, нажмите кнопку New... (Новый), чтобы создать новый файл трансформации. В диалоговом окне Create a new transform (Создание новой трансформации) переименуйте следующие элементы:
   • имя партнерской ссылки и файла в TransformRequestAvailability;
   • целевое пространство имен в http://Claim.TOBE.RequestExternalReports (тот же пакет, к которому относится процесс);
   • тип порта в TransformRequestAvailabilityPT;
   • имя действия (Operation name) в ToTransformRequestAvailability.
8. Нажмите OK.
9. Теперь соедините трансформацию так, как показано на рис. 10.26.
   

   
   увеличить изображение
   Рис. 10.26. Агрегация данных для вызова операции RequestAvailability
   Совет. Имена очень важны! Если вы переформатируете поток, гораздо проще будет восстановить операцию, утратившую свою позицию в потоке, при использовании хорошо продуманной системы имен.

   Мы решили назвать WSDL-файлы трансформирующих и агрегирующих служб так, чтобы они при сортировке в Service Navigator расположились по категориям "трансформация" и "агрегация". Альтернативным подходом является сохранение всех WSDL-файлов в пакете служб, присвоив им суффиксы Transformer или Aggregation, чтобы они сортировались в порядке сходства с исходной службой. Важно с самого начала продумать схему имен, а затем правильно применять ее. Единство схемы имен уменьшает вероятность трудноустранимых ошибок, вызванных путаницей в именах.
10. Связующая операция должна ждать до тех пор, пока все входящие данные не станут доступны. На закладке Join Behavior (Функционирование объединения) редактора свойств только что созданной операции ToRequestAvailability укажите в поле Condition Value (Значение условия) значение All (Все) ( рис. 10.27).

Рис. 10.27. Объединение результатов операций IdentifyAssessors и ResponseTimePolicy

Связывание операции SelectAssessors

Мы используем для этой связи еще одну трансформирующую службу. Назовем ее SelectAssessorTransformer. В качестве имени действия (Operation Name) укажите toSelectAssessor. В диалоговом окне создания связей трансформирующей службы укажите входное сообщение – listAvailableAssessors и выходное сообщение – selectAssessorRequest. Получившиеся связи показаны на рис. 10.28.

увеличить изображение
Рис. 10.28. Связывание запроса операции SelectAssessor

Перетащите службу в редактор процесса RequestExternalAssessors, назовите ее ToSelectAssessor и подключите ее между операциями Any Assessors? и SelectAssessors.

Связывание операции RequestAvailability

Трансформирующая служба для данной связи называется RequestAvailabilityTransformer.

1. Присвойте действию имя toRequestAvailability. Необходимо агрегировать два входящих сообщения: выходное сообщение операции SelectAssessors и исходное входное сообщение процесса, RequestExternalReports_RequestAssessors (см. рис. 10.7). Выходное сообщение называется actionAssessorRequest.

   В этот момент мы сталкиваемся с проблемой. Для сообщения actionAssessor требуется два поля, которых нет во входящих сообщениях:

   • carDetails.registration.
   • assessor.assessorURL.
2. Информация о регистрации машины была случайно пропущена во входном кон- тейнере, переданном процессу RequestExternalReports рабочим потоком ClaimInvestigation_TOBE. Это можно исправить позже, а пока мы скопируем ин- формацию о марке машины в поле registration.
3. Отсутствие URL оценщика (AssessorURL) – более серьезная проблема. Интерфейс системы бизнес-правил (Business Rules Engine) возвращает только ID выбранного оценщика, а также ID претензии (claimID). Нам нужно заново установить связь между идентификатором оценщика (assessorID) и URL оценщика (assessorURL), чтобы шина ESB могла направлять запрос об оценке нужному оценщику.

Где следует осуществлять корреляцию данных?

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

• Кому принадлежат данные, направляемые оценщикам?

  Ответ на этот вопрос простой: эти данные принадлежат системе управления оценщиками (AssessorManagement).
• Кто отвечает за сбор информации, необходимой шине ESB для взаимодействия с оценщиками?

Второй ответ не столь очевиден. За связь между assessorID и assessorURL отвечает либо система работы с процессом, либо ESB. Оба подхода имеют преимущества и недостатки.

Один шаблон потока данных должен обеспечивать как можно более слабую связь между данными в компонентах, и он требует, чтобы каждый компонент запрашивал необходимые данные у других служб по мере необходимости. Так что этот подход за то, чтобы передавать шине ESB только assessorID, claimID и информацию о функции, выполнения которой система работы с процессом ждет от ESB. Затем ESB находит в системе управления оценщиками assessorURL для выполнения маршрутизации, собирает необходимую информацию о претензии из системы работы с претензиями и направляет запрос RequestAssessment выбранному оценщику.

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