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

10.4.3 Конфигурирование ссылок на партнеров

Следующая задача – правильно назначить процессу и партнерам роли, относящиеся к ссылке на партнера, обеспечить правильный выбор типов портов и действий и выделение входных и выходных переменных для передачи входящих и исходящих сообщений для службы. На рис 10.16 показаны взаимосвязи между BPEL-процессом, интерфейсом Web-службы и EJB-реализацией.

Роли

При назначении процессу нужного количества ролей и ссылок на партнеров представляйте себе взаимосвязь между процессом и партнером как сеанс связи. Если в таком сеансе есть только один участник, то нужно выделять одну роль. Это относится и к взаимосвязи запрос/ответ, которая соответствует SOAP-сообщению типа запрос/ответ. С другой стороны, если существуют два участника сеанса связи, подобно обмену вопросами и ответами по голосовой почте, то используются два односторонних SOAP-сообщения, обмен которыми происходит асинхронно. Также возможна односторонняя связь, которая похожа на ситуацию, когда на голосовой почте оставляется сообщение, а ответ не ожидается.

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

Когда мы решили, что для каждого типа ссылки на партнера выделяется одна роль, следующий вопрос, будет ли роль принадлежать процессу или партнеру. Определить принадлежность данной роли можно простым вопросом: кто (что) осуществляет обслуживание? Если обслуживание осуществляет процесс, то роль относится к процессу. Если обслуживание выполняет партнер, то роль принадлежит партнеру.

Конфигурирование ссылок

Легче всего сделать это при помощи представления Outline (Общий обзор). Нажимайте по очереди на ссылки на партнеров в верхней части представления.

Для каждой ссылки, соответствующей ситуации, когда процесс играет роль сервера, убедитесь, что в поле Partners Role Name (Имя роли партнера) указано -- None -- (Нет) на закладке Implementation (Реализация) редактора свойств (рис 10.17). Существует четыре ссылки, которым нужно назначить имя роли процесса (Process Role Name).(рис 10.17) Конфигурирование процесса RequestExternalReports

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

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

Раскройте категорию Flow (Поток) в представлении Outline (Общий обзор) и выделяйте по очереди каждую операцию.

Для каждой операции на закладке Implementation (Реализация) проверьте правильность типа порта, операции, выбранные входные и выходные переменные и создайте все пропущенные переменные.

Повторите эти шаги для операции AssessorAvailabilityReceive.

Добавьте выходную переменную OutputCriteraVariable в операцию RequestExternalReports Reply.

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

10.4.5 Конфигурирование типов входных и выходных переменных

Следующий этап – это связывание определений сообщений с переменными запроса и ответа, относящимися к операциям. В табл. 10.3 перечислены сообщения, которые нужно связать с переменными. Чтобы связать сообщения с переменными, выделяйте переменные в представлении Outline (Общий обзор) и переходите на закладку Message (Сообщение) редактора свойств. Находите нужный WSDL-файл и выбирайте нужное сообщение, как показано на рис 10.19.

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

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

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

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

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

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

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

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

Удалите операцию Fork и две операции назначения, находящиеся между операцией RequestExternalReports Receive и операциями IdentifyAssessors и ResponseTimeBasedOnPolicy.

Создайте новую трансформирующую службу. Нажмите на соответствующий значок на панели действий или выберите пункт меню ).(рис 10.21) Создание трансформирующей службы

Нажмите Next (Далее), введите имя IdentifyAssessorsTransformer, нажмите Next (Далее), введите в поле Operation Name (Имя действия) toIdentifyAssessors, нажмите Add (Добавить) $$\to$$ Browse (Обзор), найдите файл ExternalClaimsAssessor.wsd, а в нем – входящее сообщение RequestExternalReports_RequestAssessorsMessage, нажмите Browse (Обзор), найдите исходящее сообщение RequestListAssessorsRequest:requestListAssessors.

Раскройте сообщения в редакторе трансформации и перетащите три поля входящего сообщения в соответствующие три поля исходящего сообщения. Результат показан на рис 10.22.(рис 10.22) Связывание полей во входящем сообщении операции IdentifyAssessors

Повторите эти шаги для операции ResponseTimeBasedOnPolicy. Назовите службу ResponseTimeBasedOnPolicyTransformer.

Перетащите два 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.

Убедитесь, что операции IdentifyAssessors, ResponseTimePolicy и RequestAvailability полностью соединены, как показано на рис 10.24.(рис 10.24) Добавление операции трансформации ToRequestAvailability

Перетащите в поток новую операцию трансформации, присвоив ей имя ToRequestAvailability и подключив ее непосредственно перед операцией RequestAvailability, как показано в правой части рис 10.24.

Откройте операцию ToRequestAvailability и задайте для ее переменной Response значение (рис 10.25) Переменные, заданные в операции трансформации ToRequestAvailability

Нажмите кнопку Aggregate (Агрегация) и выберите входные переменные, которые должны быть агрегированы:

InputCriteriaVariable,

IdentifyAssessorsOutputCriteriaVariable,

ResponseTimePolicyOutputCriterionVariable.

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

Мы решили назвать WSDL-файлы трансформирующих и агрегирующих служб так, чтобы они при сортировке в Service Navigator расположились по категориям "трансформация" и "агрегация". Альтернативным подходом является сохранение всех WSDL-файлов в пакете служб, присвоив им суффиксы Transformer или Aggregation, чтобы они сортировались в порядке сходства с исходной службой. Важно с самого начала продумать схему имен, а затем правильно применять ее. Единство схемы имен уменьшает вероятность трудноустранимых ошибок, вызванных путаницей в именах.

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

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

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

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

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

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

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

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

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

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

Корреляция AssessorID и AssessorURL в системе работы c процессом

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

Добавьте Java-фрагмент, называющийся AssessorURL.

Вставьте фрагмент AssessorURL в поток RequestExternalReports, как показано на рис 10.29.(рис 10.29) Вставка Java-фрагмента AssessorURL в поток

Создайте глобальную переменную с именем SelectedAssessor.

Создайте WSDL-сообщение SelectedAssessor, состоящее из двух частей:

AssessorID,

AssessorURL.

Выполните приведенные ниже инструкции, чтобы добавить AssessorID и AssessorURL в файл RequestExternalReportsInterface.wsdl (можно также создать новый WSDL-файл).

Откройте файл RequestExternalReportsInterface.wsdl в графическом WSDL-редакторе.

В области Messages (Сообщения) щелкните правой кнопкой мыши и выберите пункт меню Add Child (Добавить потомок) $$\to$$ Message (Сообщение). Введите имя SelectedAssessor.

Щелкните правой кнопкой мыши по SelectedAssessor и выберите пункт меню Add Child (Добавить потомок) $$\to$$ Part (Часть). Укажите имя AssessorID и введите xsd:int.

Аналогичным образом добавьте часть AssessorURL с содержимым xsd:String.

(Задачи пп. 5, 6 описываются в последующих разделах более подробно.)

Добавление сообщения SelectedAssessor в службу TransformerRequestAssessment

Теперь, когда у нас есть assessorURL для выбранного оценщика, нам нужно связать его с полем assessorURL в сообщении-запросе, посылаемом в операцию RequestAssessment. Нам нужно создать трансформирующую агрегирующую службу, подобную ToRequestAvailability.

На этом создание связей должно быть завершено. Теперь вам нужно задать значение AssessorURL в Java-фрагменте.

Создание Java-фрагмента AssessorURL

В этом фрагменте Java нам нужно получить список подходящих оценщиков, проверенных системой бизнес-правил, и идентифицировать оценщика, которого выбрала система правил. В этом списке оценщики представлены структурой данных, в которую входит assessorURL. Обнаружив выбранного оценщика, мы создаем глобальную переменную SelectAssessor для передачи assessorURL этого оценщика в трансформирующую службу ToRequestAssessor, которая вводит assessorURL в сообщение actionAssessment Request. Готовый фрагмент Java показан в примере 10.4. Мы рассмотрим этапы создания этого фрагмента с помощью функции автозаполнения в WebSphere Studio Application Development Integration Edition.

SelectedAssessorMessage SelectedAssessor = getSelectedAssessor(true);
java.lang.String assessorURL = SelectedAssessor.getAssessorURL();
<focus>
SelectedAssessor.setAssessorURL(assessorURL);

Assessor assessorList [] =
getIdentifyAssessorsOutputCriteriaVariable().getParameters().
getRequestListAssessorsReturn().getAssessors();

Integer selectedAssessorID

= getSelectAssessorOutputCriteriaVariable().getParameters()
.getSelectAssessorReturn().getAssessorID();

for (int i = 0; i < assessorList.length; i++) {
           Assessor assessor = assessorList[i];
<focus>
}

if (условие) { }

assessor.getAssessorID() == selectedAssessorID

assessorURL = assessor.getAssessorURL();

getSelectedAssessor(true).setAssessorURL(<focus>);

Готовый фрагмент Java должен сохраниться без ошибок. Полный исходный код показан в примере 10.4.

// мы будем обновлять глобальную переменную SelectedAssessor assessorURL
SelectedAssessorMessage SelectedAssessor = getSelectedAssessor(true);
java.lang.String assessorURL = SelectedAssessor.getAssessorURL();
// Получить список оценщиков, согласившихся на выполнение оценки
Assessor assessorList[] =
     getIdentifyAssessorsOutputCriteriaVariable()
          .getParameters()
          .getRequestListAssessorsReturn()
          .getAssessors();
// Получить assessorID выбранного оценщика
Integer selectedAssessorID =
     getSelectAssessorOutputCriteriaVariable()
          .getParameters()
          .getSelectAssessorReturn()
          .getAssessorID();
// Перебор списка согласившихся оценщиков, чтобы найти выбранного
for (int i = 0; i < assessorList.length; i++) {
SelectedAssessor.setAssessorURL(assessorList[i].getAssessorURL());
SelectedAssessor.setAssessorID((assessorList[i].getAssessorID()).intValue());
     if (assessorList[i].getAssessorID() == selectedAssessorID) {
        break; // выйти из цикла на нужном оценщике или на последнем в
списке
}/
/ Обновить сообщение SelectedAssessor в глобальном контейнере
setSelectedAssessor(SelectedAssessor);

Добавление SelectedAssessor в RequestAssessmentTransformer

Теперь, когда у нас есть assessorURL для выбранного оценщика, нам нужно связать его с полем assessorURL в сообщении-запросе, посылаемом в операцию RequestAssessment.

Чтобы пока завершить создание связей, свяжите поле makeOfCar с полями makeOfCar и registration, чтобы все поля были с чем-то связаны.

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

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

RequestExternalReport Reply

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

Заключение

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

10.4.7 Конфигурирование потока для ожидания ответа от оценщиков

Существует три задачи, которые ожидают ответа от оценщиков. Нам нужно настроить процесс на ожидание этих сообщенийВ общем дизайне взаимодействий предусмотрены множество последовательно запускаемых процессов, которые, как мы предполагаем, ведут взаимодействие способом, определенным бизнес-аналитиком. Это допущение является критическим для работоспособности нашей системы. Если сообщения для экземпляра процесса могли бы приходить в ином порядке, нам пришлось бы иметь дело с непоследовательными сообщениями. При такой реализации, вероятно, более подходящей была бы BPEL-операция Pick, а не Receive., и обеспечить прием сообщений, посылаемых в Automated Assessor, нужным экземпляром процесса.

В Business Process Choreographer есть механизм сохранения идентификационной информации в так называемом корреляционном наборе (correlation set). В корреляционных наборах хранятся псевдонимы, необходимые для связывания полей из разных сообщений с переменными, используемыми для корреляции. Этот механизм более гибок, чем тот, который требует, чтобы все сообщения имели одинаковое поле ключа. Последний вариант непрактичен, если представить, что формат сообщений может определять бизнес-партнер в другой организации или что есть сообщения, форматы которых определяются множеством различных стандартов.

Если работа длительно функционирующего экземпляра процесса приостанавливается, то Process Choreographer сохраняет данные о состоянии этого экземпляра в долговременном хранилище. Когда от WebSphere BI Message Broker приходит сообщение-ответ, Process Choreographer проверяет корреляционные наборы и снова запускает нужный экземпляр процесса.

Для добавления корреляционных наборов выполните следующие шаги:

Нажмите на значок + на панели Correlation Sets (Корреляционные наборы) (рис 10.33), чтобы добавить новый корреляционный набор. Назовите новый корреляционный набор Claims.(рис 10.33) Добавление нового корреляционного набора

Выделите набор Claims и перейдите на закладку Properties (Свойства) окна Detail (Подробно). Нажмите кнопку New (Новое). Откроется окно Create message property (Создание свойства сообщения).

Введите в поле имени свойства значение claimID, а в раскрывающемся списке выберите тип xsd:int.

Нажмите кнопку New (Новый) в верхней части списка псевдонимов. Нажмите кнопку Browse (Обзор) в окне Create property alias (Создание псевдонима свойства) и выберите элемент ITSOLGI $$\to$$ services (службы) $$\to$$ ITSOLGI Architecture $$\to$$ WSDL $$\to$$ Proxy(1).wsdl. Выберите сообщение RequestExternalReports_requestAssessorMessage, нажмите OK. Раскройте элемент Part: Container: $$\to$$ MessageContainer: requestAssessor $$\to$$ claimID : Int $$\to$$ OK.

Повторяйте шаг 4, чтобы добавить псевдонимы, приведенные в табл. 10.4.

Псевдонимы для корреляционного набора

Имя операции	Имя WSDL-файла	Сообщение	Часть
RequestExternal Reports Receive	Proxy(1)	RequestExternal Reports_request AssessorMessage	MessageContainer: requestAssessor: claimID
Assessor Availability Receive	Assessor AvailabilityLis(3a)t.wsdl	listAvailable Assessors	parameters -> claimID:int
AllocateAssessor Repsonse	AllocateAssessor Response(6a).wsdl	Assessor Confirmation Request	claimID:int
AssessorSend Report	AssessorReport(9).wsdl	receiveAssessor ReportRequest	claimID:int

Далее мы свяжем корреляционный набор с каждой из принимающих операций.

Щелкните по операции RequestExternalReports Receive в редакторе BPEL и перейдите на закладку Correlation (корреляция) в окне Detail (Подробно).

Нажмите кнопку ).

Повторите шаги с 1 по 7, чтобы присвоить корреляционные наборы принимающим операциям, указанным в табл. 10.5.

10.5 Контроль пути через процесс

Следующие этапы конфигурирования посвящены логике контроля пути через процесс. Эта задача делится на две части:

10.5.1 Проверка результатов, полученных от RequestAvailability

Партнерская ссылка RequestAvailability отвечает синхронным ответом, проходящим через корпоративную сервисную шину. Этот ответ представляет собой простое подтверждение того, что запрос о готовности, направляемый оценщикам, был получен шиной. Поскольку этот ответ не является частью бизнес-логики, мы игнорируем ответ в этом потоке. Он выходит за рамки нашего сценария. (Вспомните раздел 1.1.2, "Область сценария".)

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

Тем не менее нас интересует получение от оценщиков предложений по проведению оценки. Первый этап – это анализ ответов и проверка, все ли ответы получены. ESB ожидает ответов оценщиков в течение согласованного периода времени, а затем собирает предложения в единый список. ESB отправляет ответ обратно, используя автоматизированный процесс для работы с оценщиками. Автоматизированный процесс работы с оценщиками ждет, пока операция AssessorAvailability Receive передаст список системе бизнес-правил для автоматического выбора оценщика.

Мы должны проверить, были ли вообще получены предложения. Если предложения отсутствуют, мы передаем проблему специалисту по обработке претензий, чтобы он решил ее вручную. Если предложения были получены, то управление передается в автоматизированную операцию SelectAssessor, которая вызывает службу Business Rules для выбора наилучшего оценщика из списка.

Как можно сказать, были ли получены предложения? Единственный способ – это проверить, есть ли элементы в массиве assessorEstimationArray (рис 10.35).

Результаты этой проверки используются для того, чтобы задать значение для ссылок А и В на рис. 10.38. Для каждой ссылки мы можем открыть закладку свойств и задать условие, которое должно быть выполнено для перехода по ссылке. Для определения данного условия мы планируем использовать либо простой редактор выражений, либо визуальный редактор выражений. Однако казалось, что ни тот, ни другой редактор выражений не может обрабатывать выражения достаточно сложные, чтобы можно было проверить существование массива AssessorEstimationArray. Вместо использования редакторов мы напишем немного Java-кода для установки глобальной переменной. Затем каждая ссылка в простом выражении сможет проверять эту переменную, чтобы можно было установить для ссылки условие истинности.

Общий план реализации следующий:

Создание глобальной переменной EstimationArrayLength

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

Создание Java-фрагмента "Any Assessors?" для установки значения lengthValue

Чтобы создать Java-фрагмент "Any Assessors?", выполните следующие действия:

Измените пустую операцию "Any Assessors?" на Java-фрагмент, как показано на рис 10.38. В этом Java-фрагменте мы установим значение lengthValue в глобальной переменной EstimationArrayLength, чтобы его можно было проверять с помощью простых выражений, связанных со ссылками А и В.(рис 10.38) Проверка результатов в RequestAvailability

В Java-фрагменте мы должны установить доступ для обновления к глобальной переменной Estimation-ArrayLength:

Выделите Java-фрагмент Any Assessors? и откройте закладку Implementation (Реализация) в редакторе свойств.

Щелкните ). При этом будут созданы три инструкции.(рис 10.39) Результаты работы мастера обновления переменной

Первая инструкция создает в JVM $$\text{\texttrademark}$$ новый экземпляр EstimationArrayLengthMessage (поскольку параметр getEstimationArrayLength установлен в true). Это показывает, что Java-фрагменту требуется доступ по обновлению к глобальной переменной EstimationArrayLength.

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

Третья инструкция использует новое целочисленное значение lengthValue для установки нового значения глобальной переменной. Это также дает побочный эффект – разблокирование переменной, поскольку для обновления она больше не нужна.

Мастер обновления оставляет редактор готовым к заданию значения новой целочисленной переменной lengthValue. (рис 10.40).

Получите длину массива, хранящего ответы оценщиков. На этот раз мы используем встроенное автозаполнение, чтобы получить значение переменной AssessorEstimationArray. К сожалению, с помощью меню мы не можем добраться до нужной нам части сообщения. Используя Ctrl+Пробел для автозаполнения каждого элемента, мы в итоге получим следующую инструкциюВ нашем коде есть опечатка. Проверьте, чтобы в вашем коде ее не было!:

lengthValue = getListOfAvailableAssessrs()1.getParameters().
getResultAssessorCollection().getAssessorEstimations().length;

Полный код Java-фрагмента приведен в примере 10.5.

EstimationArrayLengthMessage EstimationArrayLength =
   getEstimationArrayLength(true);
int lengthValue =
   getListOfAvailableAssessors()
     .getParameters()
     .getResultAssessorCollection()
     .getAssessorEstimations()
     .length;
EstimationArrayLength.setLengthValue(lengthValue);

Проверка значения lengthValue в ссылках А и В

Последний этап процесса – это добавление визуальных выражений к двум ссылкам, идущим от Java-фрагмента "AddAssessors?", чтобы вызывалась операция ManualSelectAssessor или автоматическая операция SelectAssessor, но не обе сразу.

EstimationArrayLength.lengthValue == 0

EstimationArrayLength.lengthValue ¬= 0

10.5.2 Создание операции While для проверки согласования оценки

Служба RequestAssessment посылает запрос выбранному оценщику на выполнение оценки претензии для LGI. В конечном счете запрос приводит к возврату трех потоков сообщений обратно в процесс RequestExternalReports:

Как и в случае запроса готовности оценщиков, мы игнорируем ответ от ESB. Он нужен только для мониторинга и не выходит за рамки данного сценария. Окончательный ответ, содержащий отчет, обрабатывается операцией AssessorSendReport. В этом разделе мы изучим обработку подтверждения, получаемого от оценщика, которое принимается операцией AllocateAssessorResponse.

Выбор дизайна

Если оценщик отклоняет запрос, такой вариант является необычным и вместо автоматического выбора второго по рейтингу оценщика система передает задание по поиску другого оценщика специалисту по обработке претензий.

С точки зрения бизнеса важно, чтобы в случае возникновения в процессе необычной ситуации ответственность за принятие решения передавалась специалисту по обработке претензий. Хотя существуют технические возможности использования средств автоматизации для помощи специалисту по обработке претензий в выборе оценщика и в нетипичной ситуации, бизнес-спецификация, как она зафиксирована в BPEL-модели, созданной в WebSphere Business Integration Modeler, указывает на то, чтобы контроль над выбором осуществлял специалист. Эту спецификацию следует учитывать в исполняемом BPEL-коде, который генерирует ИТ-специалист. Однако достижение этой бизнес-цели возможно несколькими путями. Должна ли в процессе использоваться одна или несколько выполняемых вручную операций? Как следует формировать запросы ко второму, а возможно, и к последующим оценщикам? Эти вопросы не учитываются в бизнес-спецификации, и решение по ним должен принимать ИТ-специалист.

Использование существующей ручной операции или добавление новой ручной операции?

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

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

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

Проектирование управляющего цикла в BPEL

Нам нужно создать в BPEL-процессе управляющий цикл для передачи управления в ручную операцию, если оценщик отказывается создавать отчет об оценке. Простой возврат управления в предыдущую точку потока путем соединения потока с циклом в BPEL недопустим. Можно использовать две альтернативы:

Компенсация (Compensation) – это способ возврата при ошибке в операции. В своей простейшей форме каждая операция содержит такие две службы, как:

За дополнительной информацией о компенсационных службах обращайтесь к следующим источникам:

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

Операция While предоставляет необходимые нам возможности. На рис 10.41 показано, какие операции были перенесены в операцию While и в каком месте всего процесса данная операция располагается.

Создание операции While

Error BPED0211E: Link 'Linknn' does not link immediate children of flow
'RequestExternalReport' of process model 'RequestExternalReports'.
RequestExternalReports.bpelITSOWorkshop/Claim/TOBE/RequestExternalReports

<while condition="DefinedByJavaCode" name="Whilenocommittedassessment"
wpc:displayName="While no committed assessment" wpc:id="37">
              <wpc:condition>
<wpc:javaCode><![CDATA[//@generated
//
//AssessorAcknowledgement.Ack.equals("YES")
return getAssessorAcknowledgement().getAck().equals
"YES";]]></wpc:javaCode>
              </wpc:condition>
              <target linkName="Link27"/>
              <source linkName="Link5"/>
              <flow name="Flow" wpc:displayName="Flow" wpc:id="38">
         <links>
<link name="Link14"/>
              <link name="Link15"/>
              <link name="Link4"/>
              <link name="Link16"/>
              <link
name="ManualSelectAssessorOutput_to_RequestAssessmentInput2"/>
              <link name="Link19"/>
              <link name="Link18"/>
              <link name="Link17"/>
              <link name="Link3"/>
              <link name="Link25"/>
         </links>

AssessorAcknowledgement.Ack.equals("YES")!=true

Java имеет свои хитрости. Вы должны проверить, чтобы значение объекта не представляло собой тот же самый объект.

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

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

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

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

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

Реализация

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

Сообщения и действия будут управлять обменом информацией с 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-клиент и измененные входное и выходное сообщения.

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

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

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

Чтобы не иметь дело с конфигурацией системы безопасности в ходе тестирования, измените слово 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 от нас потребуется:

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

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

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

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

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

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

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

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

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

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

10.7 Компоновка

На этом этапе после сохранения процесса у нас должно остаться только одно предупреждение – The deployment code for this process needs to be generated (нужно сгенерировать код размещения для данного процесса).

Чтобы BPEL-процесс мог выполняться на сервере, нужен код размещения. Мы можем сгенерировать код для размещения процесса в WebSphere Studio Application Developer Integration Edition после того, как исправлены все ошибки. Система WebSphere Studio Application Developer Integration Edition генерирует EAR-модуль, который включает в себя EJB-модуль, созданный по определениям бизнес-процесса. Мы можем выполнять бизнес-процесс, разместив этот EAR-модуль на сервере.

Чтобы подготовить процесс, прошедший тестирование на тестовом сервере, к размещению и использованию базы DB/2 в рабочей системе, нужно выполнить еще один дополнительный компоновочный этап (см. раздел "Компоновка для рабочего сервера"). Мы используем для хранения объектов на тестовом сервере базу Cloudscape $$\text{\texttrademark}$$, а в рабочей системе мы используем DB/2.

10.7.1 Компоновка бизнес-процесса

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

Убедитесь, что в бизнес-процессе отсутствуют ошибки, сохранив все рабочее пространство.

Мы не хотим, чтобы экземпляр процесса автоматически удалялся по завершении работы, потому что мы хотим просмотреть результаты. По умолчанию экземпляр процесса по завершении работы удаляется. Чтобы изменить данное поведение, перейдите к всплывающему меню операции RequestExternalReports в верхней части потока и измените свойства сервера, как показано на рис 10.49.(рис 10.49) Сохранение экземпляра процесса после завершения

Чтобы сгенерировать код размещения, щелкните правой кнопкой мыши по процессу RequestExternalReport s, выберите пункт меню Enterprise Services (Корпоративные службы) $$\to$$ Generate Deploy Code (Сгенерировать код размещения). Откроется окно параметров генерации кода (рис 10.50).(рис 10.50) Генерация кода размещения BPEL

Выберите транспортные привязки процесса и его партнеров, где процесс будет выполнять роль сервера:

Оставьте JMS в качестве протокола вызова процесса.

Для трех других интерфейсов укажите привязки SOAP/http с использованием IBM Web service, как показано на рис 10.50.

Для каждого из трех интерфейсов определите стиль SOAP, как показано на рис 10.51. Файлы WSDL создавались совместимыми с WS-I и использующими интерфейс Document Literal (Документ литерал). За дополнительной информацией о совместимости SOAP и WS-I обращайтесь к книге серии Redbooks "WebSphere and .Net interoperability using Web services", SG24-6395.

10.7.2 Компоновка для рабочего сервера

При создании модулей для рабочего сервера мы можем упростить конфигурацию рабочего сервера, удалив ссылку на базу данных Cloudscape, которая используется в тестовой среде. Таким образом, когда EAR-файл процесса будет размещаться на рабочем сервере, этот файл будет сконфигурирован на автоматическое использование базы данных, указанной для рабочего сервера.

Перейдите в представление J2EE Hierarchy и удалите карту и схему из ресурса Cloudscape. (рис 10.52).(рис 10.52) Удаление связей с Cloudscape

Экспортируйте файл ITSOLGI.ear.

10.8 Тестирование и отладка процесса

В WebSphere Studio Application Development Integration Edition предлагается тестовая серверная среда, которая содержит тот же серверный компонент, что и WebSphere Business Integration Server Foundation. Это означает, что вы можете тестировать бизнес-процессы без инсталляции и конфигурирования тестового сервера за пределами среды разработки. Также предлагаются функции для отладки, например для установки точек останова, пошагового выполнения бизнес-процессов и мониторинга данных в ходе выполнения.

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

10.8.1 Подготовка к тестированию

Для подготовки к тестированию выполните следующие шаги:

Создайте новый тестовый сервер. Откройте представление Server Configuration (Конфигурация сервера). Его можно найти в нижней части перспективы Services (Службы) или с помощью главного меню: пункт Window (Окно) $$\to$$ Show view (Показать представление) $$\to$$ Server Configuration (Конфигурация сервера). Щелкните правой кнопкой мыши и выберите пункт меню New (Новый) $$\to$$ Server and Server Configuration (Сервер и конфигурация сервера) (рис 10.53).(рис 10.53) Создание сервера и конфигурации сервера

Введите TestServer в качестве имени нового сервера и убедитесь, чтобы в поле Server Type (Тип сервера) был указан вариант Integration Test Environment (Среда для тестирования интеграции). Нажмите OK, чтобы создать новый сервер.

Новый сервер, TestServer, будет добавлен в папку servers в представлении Server Configuration (Конфигурация сервера). Щелкните правой кнопкой мыши по серверу TestServer и выберите пункт меню Add and remove projects (Добавление и удаление проектов).

Нажмите кнопку ), чтобы добавить созданный нами модуль ITSOLGIEAR EAR. Нажмите (рис 10.54) Добавление модуля ITSOLGIEAR на сервер TestServer

Снова щелкните правой кнопкой мыши по серверу TestServer и выберите пункт меню Create tables and data sources (Создать таблицы и источники данных). Для выполнения процесса RequestExternalReports нам понадобится база данных, поскольку это длительно выполняемый процесс и необходимо сохранять в базе данных сведения об экземплярах процесса.

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

10.8.2 Публикация бизнес-процесса на тестовом сервере

Чтобы опубликовать тестовый сервер, выполните следующие действия. Щелкните правой кнопкой мыши по серверу TestServer и выберите пункт меню Publish (Публикация).

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

Project ITSOLGIEJB deployment failed.
     BPEA0010E: Unexpected exception during execution.
java.lang.reflect.InvocationTargetException:
com.ibm.bpe.api.UnexpectedFailureException: BPEA0010E: Unexpected exception
during execution.
com.ibm.bpe.util.ProcessAssertionError: Assertion violation !(param-
Value !=
null  paramValue.length() != 0) in method >>at
com.ibm.bpe.staff.StaffPluginUtil.deployStaffVerb(StaffP

Данная ошибка вызвана отсутствием реализации роли Claim Handler. В данном сценарии можно обойти эту ошибку, указав в поле staff операции ManualSelectAssessor вариант Everybody.

Project ITSOWorkshopEJB deployment failed.
BPED0203I: Validated process model 'RequestExternalReports' with
findings ( 0 information, 0 warnings, 1 errors ):
BPED0267E: Syntactical error found in BPEL file
'Claim/TOBE/RequestExternalReports/RequestExternalReports.bpel' (row: 223,
column: 73). Detail message: cvc-complex-type.2.4.b: The content of
element
'wpc:webClientSettings' is not complete. One of
'("http://www.ibm.com/xmlns/prod/websphere/business-process/v5.1/":customSe
tting,
"http://www.ibm.com/xmlns/prod/websphere/business-process/v5.1/":jsp)' is
expected.
java.lang.reflect.InvocationTargetException:
com.ibm.bpe.plugins.DeploymentBPELProcessValidationException: BPED0203I:
Validated process model 'RequestExternalReports' with findings ( 0
information, 0 warnings, 1 errors ):
BPED0267E: Syntactical error found in BPEL file
'Claim/TOBE/RequestExternalReports/RequestExternalReports.bpel' (row:
223,
column: 73). Detail message: cvc-complex-type.2.4.b: The content of
element
'wpc:webClientSettings' is not complete. One of

Если вы встретитесь со второй ошибкой, удалите строку <wpc:webClientSettings clientType="Web Client"/> из файла RequestExternalReports.bpel.

10.8.3 Создание среды для тестирования

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

Существует два варианта систем оценщиков, которые можно использовать:

Выбор зависит от того, какая версия системы управления оценщиками инсталлирована в WebSphere Application Server. Таблица оценщиков и их URL жестко прописаны в системе управления оценщиками. Одна версия указывает на WebSphere Application Server, а другая – на WebSphere Business Integration Message Broker.

Выбор системы оценщика

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

Проверьте, какая система установлена в данный момент:

Откройте браузер и откройте административную консоль WebSphere Application Server на машине SAH414A, введя адрес http://sah414a:9090/admin/.

Откройте раздел установленных приложений, поставьте галочку напротив ).(рис 10.56) Административная консоль WebSphere Application Server

Скачайте файл AssessorManagementService.ear.

Вы можете просматривать EAR-файл, используя утилиту распаковки, например WinZip, или же можете импортировать этот файл в WebSphere Studio Application Development Integration Edition в виде нового EAR-проекта, как мы описываем здесь.

Выберите пункт меню File (Файл) $$\to$$ Import (Импорт) $$\to$$ EAR file (EAR-файл) $$\to$$ Next (Далее). Найдите файл AssessorManagementService.ear, нажмите Finish (Готово).

Откройте перспективу J2EE и представление J2EE Hierarchy (Иерархия J2EE), выберите элемент EJB Modules (EJB-модули) $$\to$$ AssessorManagementServiceEJB $$\to$$ Session Beans (Сеансовые компоненты) $$\to$$ AssessorManagement. Двойным щелчком откройте компонент AssessorManagementBean, откройте представление Outline (Общий обзор) в окне ниже, сделайте двойной щелчок мышью по удаленному интерфейсу requestListAssessors и изучите код, приведенный в примере 10.10.

//Создание жестко прописанного массива оценщиков и нового списка
АssessorList
Assessor stubAssessor = new Assessor();
stubAssessor.setAssessorID( new Integer(9999));
stubAssessor.setAssessorURL( "http://SAH414A:7080/Availability");
Assessor anotherStubAssessor = new Assessor();
// оценщик только один, просто две записи с одним пунктом назначения
anotherStubAssessor.setAssessorID(new Integer(5555));
anotherStubAssessor.setAssessorURL("http://SAH414A:7080/Availability");
Assessor [] assArray = new Assessor[2];
assArray[0] = stubAssessor;
assArray[1] = anotherStubAssessor;
AssessorList stubAssList = new AssessorList();
stubAssList.setAssessors( assArray);
stubAssList.setClaimId( claimID);

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

Чтобы использовать альтернативного оценщика ( примерПросим прощения за опечатку в URL – эта опечатка "верная". 10.11), найдите директорию .\SG24-6636\WAS\Flow2 и разместите файл Flow2_AssessorManagementService_SOURCE.ear в WebSphere Application Server. Версия для брокера находится в поддиректории Broker Assessor.

stubAssessor.setAssessorURL(
"http://SAH414A:9080/AssessorAvailaibilityApplicationsEJBRouter/services/
Availa
bility");
Assessor anotherStubAssessor = new Assessor();
// оценщик только один, просто две записи с одним пунктом назначения
anotherStubAssessor.setAssessorID(new Integer(5555));
anotherStubAssessor.setAssessorURL("http://SAH414A:9080/AssessorAvailaibilityAp
plicationsEJBRouter/services/Availability");

Вызов служб оркестровки

Как вы помните, система proxyAssessorSystem вызывает три односторонние SOAP-службы, принадлежащие к потоку RequestExternalReports. Как нам узнать, какой URL нужно записать в узлы HTTPRequest системы proxyAssessorSystem в брокере для этих служб?

На этапе генерации кода размещения в разделе "Компоновка бизнес-процесса" вы указали адрес маршрутизации для каждой из трех служб - "http://localhost:9080/". Можно ли записать этот путь в ESB для узлов Http Request, которые отвечают Process Choreographer? Оказывается, нельзя.

URL Web-службы, который вы должны указывать в брокере для вызова сервера за- просов о готовности в Choreographer, должен быть таким:

http://SAH414:9080/ITSOLGIWeb/services/RequestExternalReportsAssessor
AvailabilityListHTTPServicePort

Откуда берется такой путь?

В WebSphere Studio Application Development Integration Edition откройте проект ITSOLGIWeb в папке Deployable services (Размещаемые службы).

Найдите файл web.xml (дескриптор размещения в Web) и откройте его.

Вы можете видеть, что в проекте определены три сервлета и JSP. Именно эти службы вызывает брокер.(рис 10.57) Web-службы, размещаемые в RequestExternalReports.bpelНажмите кнопку Details (Подробно) и изучите связи URL. Путь для службы AssessorAvailabilitylist будет выглядеть так:

services/RequestExternalReportsAssessorAvailabilityListHTTPServicePort

Добавьте этот путь к адресу маршрутизатора в URL, и вы получите полный путь к Web-службе, и его эквивалент для двух других служб:

ITSOLGIWeb/services/RequestExternalReportsAssessorAvailabilityListHTTP
ServicePort

Нам нужно изменить URL-адреса в брокере, поскольку они не совпадают с адресами Web-служб в новом процессе, который был нами создан. Сделать это можно без прямого редактирования потока в брокере сообщений. Это одноразовая модификация. После повторного размещения значение этого параметра в потоке снова будет восстановлено. Поэтому лучше будет изменить параметр в потоке:

Откройте в брокере административную перспективу, найдите папку Deployables (Размещаемые компоненты) в директории Broker Archives и откройте элемент LGIAvailability.

Выберите узел HTTP Request в потоке Output3a и замените URL Web-службы на URL RequestExternalReportsAssessorAvailabilityListHTTPService из модуля ITSOWorkshopWeb.

http://SAH414:9080/services/RequestExternalReportsAssessorAvailability
ListHTTPServicePort

Повторите процедуру для двух других Web-служб.

Снова разместите модули LGIReport и LGIAvailability.

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

10.8.4 Тестирование и отладка бизнес-процесса

Прежде чем начинать тестирование Process Choreographer, убедитесь, что все необходимые службы, функционирующие в WebSphere Application Server и WebSphere Business Integration Message Broker, работоспособны. Используйте для этого инструмент Web Services Explorer из WebSphere Studio Application Development Integration Edition.

10.8.5 Тестирование и отладка бизнес-процесса

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

Выберите в меню в левой части окна элемент my template (Мой шаблон). Вы увидите, что процесс RequestExternalReports готов (рис 10.58).(рис 10.58) Запущенный клиент Process Choreographer с выбранным элементом My Templates

Щелкните по полю RequestExternalReports $$\to$$ Start instance (Запустить экземпляр). Появится панель, отображающая входное сообщение (рис 10.59).(рис 10.59) Входное сообщение процесса

Если все в порядке, процесс отобразит список выполненных задач и будет ожидать ввода. На рис 10.60 показан пример, в котором процесс ждет ответа от выбранного оценщика.(рис 10.60) Ожидание ответа от proxyAssessorSystem

Отладка процесса

Если процесс не работает так, как ожидалось, у вас есть несколько возможностей для отладки:

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

Добавьте точку останова для проверки этапов выполнения. Щелкните правой кнопкой мыши по операции в BPEL-редакторе и выберите пункт меню Add Entry/Exit break point (Добавить элемент/точка останова для выхода).

Запустите сервер TestServer в режиме отладки. Щелкните правой кнопкой мыши по ) и выберите пункт Debug (Отладка). Откроется перспектива Debug (Отладка).(рис 10.61) Перспектива Debug (Отладка)

Выполняйте процесс пошагово, нажимая кнопки step over (Пропуск блока) или step in (Вход в блок) в представлении Debug (Отладка). В представлении Variables (Переменные) в правой части перспективы отображаются значения переменных.

В качестве примера на рис 10.62 показан процесс, приостановленный на входе во Java-фрагмент, агрегирующий результаты запроса о том, какие оценщики являются потенциальными кандидатами для проведения оценки и каково значение ResponseTimePolicy для данного клиента.

(рис 10.62) Процесс, приостановленный на входе во Java-фрагмент

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

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

Возможно, в данном случае список оценщиков не установлен и причина ошибки в proxyAssessorSystem :ESB.

10.9 Размещение процесса на сервере

Бизнес-процессы, которые разработаны в WebSphere Studio Application Development Integration Edition, размещаются в WebSphere Business Integration Server Foundation в формате EAR-файла и выполняются в контейнере бизнес-процесса, который предоставляет WebSphere Business Integration Server Foundation.

WebSphere Business Integration Server Foundation предлагает систему работы с процессом, основанную на Java 2 Enterprise Edition, которая поддерживает следующие возможности:

В системе работы с процессами, входящей в WebSphere Business Integration Server Foundation, есть несколько компонентов.

10.9.1 Инсталляция приложения бизнес-процесса

10.9.2 Проверка приложения

Запустите Web-клиент контейнера бизнес-процесса, указав в браузере URL http://sah414b:9080/bpe/webclient.

Измените конфигурацию брокера для вызова принимающих операций на рабо- чем сервере, расположенном на машине SAH414B. Делается это без изменения потока сообщений, из административной перспективы инструментария брокера. Например, на рис 10.64 показан поток Output6a.(рис 10.64) Изменение имени хоста на SAH414B для потока Output6a

Запустите проверочный тест. Если вы хотите протестировать операцию, выполняемую персоналом, измените ответ в подтверждении оценщика на NO.

10.10 Заключение

В этой лекции описано, как ИТ-специалист по процессам изменяет бизнес-процесс, предоставленный бизнес-аналитиком, с целью реализации интерфейсов, предложенных ИТ-архитектором, а затем тестирует и размещает процесс в WebSphere Business Integration Server Foundation.

Последний этап в нашем решении – это интеграция рабочего потока обработки претензий, работающего на сервере WebSphere MQ Workflow с бизнес-процессом с применением интеграционного вспомогательного пакета (supportpac) WA0D.