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

10.6 Реализация операции для специалиста по обработке претензий

Последний этап разработки – это реализация операции, выполняемой персоналом (staff activity).

Операция персонала используется для представления той точки процесса, где требуется участие специалиста по обработке претензий (Claim handler). Такая операция рассматривается как специальный тип вызывающей операции, однако в ее сигнатуре не используется ссылка на партнера. Операция персонала определяется как действие, имеющее входящее и исходящее сообщения. Это действие и сообщения определяются в WSDL-файле, как правило в интерфейсах процесса. Затем в процессе определяются две переменные с типами сообщений, соответствующими входу и выходу действия, относящегося к операции персонала.

Изучение свойств операции ManualSelectAssessor

Мы изменим операцию персонала, созданную Modeler. Пока мы просто изучим некоторые специальные характеристики данной операции.

Реализация

Выделите операцию ManualSelectAssessor и откройте закладку Implementation (Реализация) редактора свойств. Можно видеть, что с операцией связан тип порта ManualSelectAssessorPT, который определяется в файле RequestExternalReportsInterfac e.wsdl, сгенерированном Modeler. Мы будем изменять действия и сообщения, используемые операцией персонала ManualSelectAssessor и показанные на рис. 10.42.

увеличить изображение
Рис. 10.42. Типы портов и сообщения для ManualSelectAssessor, сгенерированные Modeler

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

Web-клиенты

Когда специалист по обработке претензий хочет выполнить какую-то часть работы, то переменная-запрос и ее содержимое передаются специалисту с помощью Web-клиента или клиента портала. Специалист принимает решение о том, какому оценщику следует направить запрос об оценке претензии, и Web-клиент возвращает ID оценщика в переменной-ответе.

Наиболее вероятный метод взаимодействия между специалистом по обработке претензии и его фрагментами работы – это Process Web Client. Предлагаемое приложение позволяет прошедшему авторизацию специалисту войти в систему и осуществлять взаимодействие с процессами RequestExternalReports. При этом данный экземпляр процесса становится недоступным для других специалистов по обработке претензий. Специалист отвечает за выполнение операции путем передачи экземпляру процесса значения assessorID, что позволяет экземпляру процесса продолжить работу.

Существует несколько вариантов Web-клиентов, которые можно написать или сконфигурировать в соответствии с нуждами бизнеса. Более полное объяснение приводится в разделе 9.2 книги серии Redbook "WebSphere Business Integration Server Foundation 5.1 Handbook", SG24-6318.

Откройте закладку Client (Клиент) окна свойств операции ManualSelectAssessor ( рис. 10.43). Данные определения для заданных по умолчанию Web-клиентов и клиентов портала извлекаются из файла ClientSet.xml, который находится в директории ...\install_root\IBM\WebSphere Studio\Application Developer IE\v5.1.1\runtimes\ee_v51\ ProcessChoreographer\client.

Мы можем изменять файл ClientSet.xml, задавая другой интерфейс клиента, или же можем изменять значения для JSP, предлагая другую реализацию заданных по умолчанию интерфейсов. Подробно об этом рассказывается в упомянутой выше книге серии Redbook. Мы будем использовать заданный по умолчанию Web-клиент и измененные входное и выходное сообщения.

Рис. 10.43. Закладка с определениями Web-клиента

Роли персонала

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

Откройте закладку Staff (Персонал) операции ManualSelectAssessor, и вы увидите, что специалист по обработке претензий (Claim Handler) уже определен в BPEL-модели, импортированной из Modeler ( рис. 10.44).

Рис. 10.44. Роли персонала, назначенные в операцию ManualSelectAssessor

Чтобы не иметь дело с конфигурацией системы безопасности в ходе тестирования, измените слово Staff на Everybody.

В период выполнения, когда процесс доходит до операции персонала, система WebSphere Process Choreographer создает элемент работы, который может быть обработан любым специалистом по обработке претензий. Контейнер WebSphere Process Choreographer связывает роль Claim Handler с реальным запросом к реализации менеджера сущностей, например пользовательскому реестру Windows или службе LDAP-директории. Этот механизм позволяет рабочей системе определить потенциального владельца, а затем обеспечить выполнение политики аутентификации.

Поскольку связывание роли Claim Handler происходит в период выполнения, определение связи можно поместить в описании размещения процесса на WebSphere Business Integration Server Foundation.

Истечение срока действия

Операция персонала во многом напоминает вызывающую операцию (invoke activity), и в ней есть параметр истечения срока (expiration), если специалист по обработке претензии не отвечает. Существуют разные способы указания этого срока. По достижении этого времени операция персонала переходит в состояние STATE_EXPIRED. Это значение можно проверять в управляющих ссылках (Control Links) выходного терминала операции персонала. В одной управляющей ссылке вы можете проверить состояние (возвращается значение true, если состояние операции STATE_EXPIRED). Это приведет к тому, что выполнение продолжится по данной управляющей ссылке.

Обычно действия на случай в модели, созданной бизнес-аналитиком, четко не прописываются, если специалист по обработке претензий становится владельцем претензии, но не выполняет операцию. ИТ-специалист должен проконсультироваться с бизнес-аналитиком и ИТ-архитектором, а не принимать решения по ситуации.

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

Конфигурирование операции ManualSelectAssessor

Для конфигурирования операции ManualSelectAssessor от нас потребуется:

1. Изменить тип порта, сгенерированный Modeler, с настройкой входящего и исходящего сообщений для ManualSelectAssessor.
2. Изменить конфигурацию операции ManualSelectAssessor, чтобы она использовала новый тип порта.
3. Изменить логику соединений операции while no committed assessment.

Изменения типа порта и действий для операции ManualSelectAssessor

Мы будем использовать следующий интерфейс операции ManualSelectAssessor:

• Вход: условие для операции While.

  Содержит строку с информацией либо о том, что оценщик не был выбран, либо о том, что выбранный оценщик отказался выполнять оценку.
• Выход: идентификатор оценщика, выбранного специалистом по обработке пре- тензий для выполнения оценки.

  Для этого понадобится новое сообщение – xsd:int. Web-клиент по умолчанию сконструирует форму из фрагментов выходного сообщения и выполнит конверсию типов, описанную в спецификации JAX-RPC.

1. Откройте файл RequestExternalReportsInterface.wsdl, как показано на рис. 10.42. ( рис. 10.45).
   • Удалите два существующих действия в ManualSelectAssessorPT.
   • Нажмите Add Child (Добавить потомок) Operation (Действие), введите requestAssessorID в поле имени, нажмите Add Child (Добавить потомок) Input (Вход) Add Child (Добавить потомок) Output (Выход).
   • Выберите элемент Input (Вход), нажмите Create a new message (Создать новое сообщение). Назовите сообщение ManuallyChosenAssessorInput.
   • Выберите элемент Output (Выход), нажмите Create a new message (Создать новое сообщение). Назовите сообщение ManuallyChosenAssessorOutput.
   • Выберите новое сообщение ManuallyChosenAssessorInput, нажмите Add Child (Добавить потомок) Part (Часть), назовите новую часть AssessorSelectionState. Оставьте заданный по умолчанию тип xsd:string.
   • Снова выберите сообщение ManuallyChosenAssessorInput, нажмите Add Child (Добавить потомок) Part (Часть), назовите новую часть claimID. Укажите тип xsd:int.
   • Выберите новое сообщение ManuallyChosenAssessorOutput, нажмите Add Child (Добавить потомка) Part (Часть), назовите новую часть AssessorID. Укажите тип xsd:int.
   

   
   Рис. 10.45. Входное и выходное сообщение для операции ManualSelectAssessor
   Для изменения конфигурации операции ManualSelectAssessor выполните следующие действия:
2. На закладке Implementation (Реализация) окна свойств операции Manual- SelectAssessor убедитесь, что в качестве переменных Request (Запрос) и Response (Ответ) установлены переменные ManualInputCriteriaVariable и ManualOutp utCriteriaVariable, которые уже должны существовать. Если они не существуют, создайте их.
3. Установите тип сообщения-запроса и сообщения-ответа, выделив переменные и открыв закладку Message (Сообщение) редактора свойств:
   • Для переменной ManualInputCriteriaVariable прокрутите список Message (Сообщение) до ManuallyChosenAssessorInput. Вам может понадобиться нажать кнопку Browse (Обзор) и найти файл RequestExternalReportsInput.wsdl, если сообщение не появляется. WSDL-файл кешируется.
   • Для переменной ManualOutputCriteriaVariable прокрутите список Message (Сообщение) до ManuallyChosenAssessorOutput.
4. Вернитесь в окно свойств операции ManualSelectAssessor, выберите только что созданное действие requestAssessorID в свойстве Operation (Действие) на закладке Implementation (Реализация).

Трансформации при переходе к ручной операции и от нее

Следующие этапы посвящены управлению данными, входящими в операцию ManualSelectAssessor и покидающими ее. Поток в конце концов будет выглядеть так, как показано на рис. 10.46.

Рис. 10.46. ManualSelectAssessorFlow

Создание агрегации и трансформации на входе в ManualSelectAssessor

Выполните следующие действия:

1. Создайте новую операцию трансформации и назовите ее ToManualSelectAssessor.
2. В качестве переменной-ответа (Response) укажите ManualInputCriteriaVariable.
3. Создайте агрегацию с именем AggregateManualSelectAssessor, которая будет объединять переменные InputCriterionVariable и AssessorAcknowledgement.
4. Создайте трансформирующую службу с именем TransformerManualSelect|Assessor:
   • добавьте сообщение AssessorAcknowledgement из файла RequestExternalReportsInterface.wsdl и сообщение RequestExternalReportsRequest из файла ExternalClaimsAssessorsInterface.wsdl в качестве входных сообщений трансформирующей службы;
   • выберите сообщение ManuallyChosenAssessorInput из файла RequestExternalReportsInterface. wsdl в качестве выходного сообщения;
   • соедините части claimID и Ack, как показано на рис. 10.47.

увеличить изображение
Рис. 10.47. Трансформация входа для ManuallyChosenAssessorInput

Создание агрегации и трансформации на выходе из ManualSelectAssessor

Создайте еще одну агрегирующую трансформацию, создав сначала новую операцию трансформации с именем ToAssessorURL, агрегацию с именем Aggregate-AssessorURl и трансформирующую службу TransformerAssessorURL:

1. Объедините AssessorID из сообщения ManuallyChosenAssessorOutput в файле RequestExternalReportsInterface.wsdl с ClaimID из сообщения RequestExternalReportsRequest в файле ExternalClaimsAssessorsInterface.wsdl (входящих сообщений). ( рис. 10.48).
2. Выберите сообщение SelectAssessorResponse из файла PreferredAssessor(5).wsdl в качестве исходящего сообщения.

увеличить изображение
Рис. 10.48. Выходные трансформации для ManuallyChosenAsssessorOutput

Изменение соединений операции While

Перетащите две трансформирующие службы в операцию While и измените соединения, как показано на рис. 10.46.