Создание динамических BPEL-процессов

Источник: Oracle Magazine

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

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

Web-сервисы и сервис-ориентированная архитектура (SOA) позволяют легко расширять бизнес-процессы через взаимодействия с другими бизнес-процессами и приложениями. BPEL-процессы реализуют такие взаимодействия через партнерские связи (partner links), которые определяют интерфейс (сообщения и операции), транспортный протокол и, что важнее всего, местоположение каждого сервиса, который предполагается использовать.

В большинстве разработок основных процессов партнерские связи являются статическими; они обращаются к единственному внешнему процессу, выбранному разработчиком во время проектирования. Этот подход вполне адекватен для узкоцелевых или ограниченных систем. Однако в более крупных системах бизнес-процессы являются более сложными. Они взаимодействуют с большим числом внешних сервисов и определяют множество партнерских связей, и некоторые из этих партнерских связей могут быть еще неизвестны во время проектирования. В результате все потенциальные сноски (callouts) и логика для решения о том, какие партнерские взаимоотношенияследует использовать, должны быть встроены в бизнес- процесс, что излишне усложняет его. Более того, по мере добавления дополнительных партнерских связей получающийся процесс становится все более громоздким, поскольку при любых изменениях партнерских связей требуется модификация всего бизнес-процесса. К счастью, язык BPEL поддерживает концепцию динамического связывания партнерских связей. Динамическое связывание позволяет разработчику добавлять новые сервисы с помощью конфигурирования или данных, вводимых во время выполнения. Этот подход устраняет потребность предугадывать и управлять всеми отношениями типа "родитель-потомок" во время проектирования.

В этом выпуске Поваренной книги BPEL я постараюсь обрисовать эффективную стратегию экранирования BPEL- процессов от изменений отношений с партнерами, которая позволяет системе динамически управлять партнерскими связями на стадии исполнения. Я также объясню, как динамически (последовательно или параллельно) вызывать несколько BPEL-процессов. Краткий обзор динамического связывания Подобно объектно-ориентированному анализу и проектированию в мире традиционного программирования, динамическое связывание партнерских взаимоотношений учитывает модуляризацию (разбивку на модули) кода и связывание между собой процессов во время исполнения. Преимущества такого подхода включают:

• Поддержку ориентированной на команду разработки, благодаря разделению функциональных компонентов на индивидуальные единицы работы

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

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

• Изменения и усовершенствования в подпроцессах автоматически становятся доступными для родительских процессов

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

Построение динамических BPEL-процессов

Как я уже сказал ранее, партнерские связи описывают интерфейсы к бизнес-процессам или другим сервисам. BPEL-процессы вызывают эти внешние сервисы, используя информацию, хранимую партнерскими связями. Партнерская связь определяет типы операций и сообщений, из которых состоит интерфейс с сервисом, используя portTypes (типы портов) языка WSDL. Как показано на рис. 1, portTypes также косвенно определяет транспорт, используемый для общения с сервисом (связывания), и местоположение сервиса (сервисов).

Рисунок 1. portTypes в действии

В статическом BPEL-процессе информация о партнерских связях определяется во время проектирования. Однако есть сценарии, где вся информация о партнерских связях неизвестна разработчику или может изменяться во время выполнения, чтобы приспособиться к данным или к другим динамическим требованиям. Рассмотрим пример сценария обработки ссуды, в котором вы хотите выбрать провайдера ссуды, базируясь на таких переменных данных, как географический регион, размер займа или кредитная история. Эти данные неизвестны до запуска. Поэтому, если привлекается много возможных провайдеров ссуд, то моделирование процесса для управления всеми статически доступными сервисами может оказаться весьма трудным делом. Динамический выбор провайдеров устраняет эту проблему. В стандарте WS-Addressing предлагается механизм, получивший название "конечные ссылки (endpoint references), который позволяет вам выбирать один из доступных сервисов в WSDL или даже определять новые сервисы во время выполнения. Бизнес-процесс статически зависит от информации интерфейса, определенной в portType, тогда как конечная ссылка (которая отображает связывание с сервисом) позволяет вам динамически переопределять местоположение сервиса. В основном, конечная ссылка является динамической альтернативой статическому элементу сервиса, определенному в WSDL. Во многих случаях проектировщик процесса может оставаться изолированным от решения о том, какие сервисы следует вызывать, до тех пор, пока все эти сервисы соответствуют стандартному интерфейсу. Хорошей отправной точкой для понимания этой темы является пример с DynamicPartner-Link, поставляемый вместе с Oracle BPEL Process Manager.

Давайте шаг за шагом исследуем этот пример; в результате, вы узнаете, как "с нуля" строить динамический процесс.

(Примечание: я рекомендую, чтобы перед работой с этим примером вы познакомились со стандартной обучающей программой LoanFlow.)

Понимание примера DynamicPartnerLink

Пример DynamicPartnerLink - это прекрасный ресурс для понимания основных концепций партнерских взаимоотношений и конечных ссылок. Он позволяет вам определить одного из трех поставщиков услуг ссуды (компании United, Star или American) и производит динамический вызов соответствующего сервиса, базируясь на входных данных процесса.

Для этого мы используем пример, предложенный в выпуске GA Oracle BPEL Process Manager 10.1.2; вы

найдете его в каталоге [BPEL_HOME]\samples\references\ DynamicPartnerLink. Обсуждаемый здесь код я разработал и проверил для версии 10.1.2 с пакетом исправлений 1.

Заметьте: когда вы в первый раз загружаете и развертываете пример Dynamic Partner Link (динамические связи с партнерами), не следует делать никаких модификаций в коде визуального проектировщика Oracle JDeveloper - просто разверните его "как есть". Если же вам необходимо внести и сохранить какие-то изменения, JDeveloper должен переформатировать BPEL-код, основанный на стандартной компоновке XML, вводя в него символы новой строки.

Утилита JDeveloper изменяет тэги <Address> и <ServiceName> внутри данных <EndpointReference>, добавляя символ новой строки перед тэгами закрытия (</Address> и </ServiceName>). Символ новой строки, добавленный к данным внутри этих элементов, разрушает связывание.В случае необходимости вы можете исправить проблему, удалив символ новой строки перед закрытием тэгов адреса и сервиса. Позже я представлю альтернативный метод для заполнения конечной ссылки, на который не оказывает влияния форматирование, применяемое в JDeveloper.

Когда вы запускаете пример с консоли, наряду с полем "provider" вам будет задан вопрос о данных для стандартной прикладной программы ссуды для демонстрационной версии программы Loan Flow (SSN, адрес электронной почты и так далее). Определите в строке провайдера одно из следующих значений: united, star или american.

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

Чтобы понять, как работает этот динамический процесс, сначала необходимо проанализировать файл DynamicPartnerLink.bpel. Первой объектом, который может заинтересовать нас в этом файле, является партнерская связь с сервисом ссуды:

<partnerLink name="LoanService" partnerLinkType="services:

LoanService"

myRole="LoanServiceRequester" partnerRole="LoanServicePro

vider"/>

Вместо того чтобы определять конкретный сервис ссуды (наподобие UnitedLoan), здесь определяется родовое имя и тип сервиса ссуды (services:LoanService). Партнерская связь LoanService определена в файле LoanService.wsdl; этот файл импортируется путем добавления его к файлу bpel.xml в раздел <partnerLinkBindings>, как показано ниже:

<property name="wsdlLocation">LoanService.wsdl</property>

</partnerLinkBinding>

Нетрудно заметить, как показано ниже в файле LoanService.

wsdl, что каждый из доступных провайдеров ссуды

определен как <service> в пределах этого единого файла

WSDL.

<soap:address location="http://localhost:9700/orabpel/default/

StarLoan"/>

</port>

</service>

<soap:address location="http://localhost:9700/orabpel/default/

UnitedLoan"/>

</port>

</service>

<soap:address location="http://localhost:9700/orabpel/default/

AmericanLoan"/>

</port>

</service>

Важно понять, что на самом деле нет никакого "реального" сервиса, который назывался бы "LoanService." Скорее, имя LoanService является шаблоном, из которого вы выбираете один из реальных сервисов ссуд-провайдера (UnitedLoan, AmericanLoan, StarLoan). Этот подход работает до тех пор, пока все реальные сервисы поддерживают один и тот же интерфейс (те же самые типы данных, сообщения, роли, порты и типы партнерских связей), что и для сервисов, определенных в шаблоне WSDL. Важно тщательно определить этот интерфейс шаблона, потому что сделанное здесь изменение может затронуть много процессов сверху донизу.

В файле LoanService.wsdl определяются все опции сервиса, которые родительский процесс может выбрать для динамического вызова. Такая модель требует повторного развертывания файла WSDL при добавлении каждого нового сервиса. Этот подход представляет поразительное усовершенствование по сравнению с изменением родительского процесса для включения новых партнерских связей и логики маршрутизации для каждого нового сервиса. (Позже вы увидите, как отсоединить конечные точки сервиса и от файла WSDL.)

Возвращаясь к файлу DynamicPartnerlink.bpel, следующей характеристикой, которую мы хотим рассмотреть, является переменная partnerReference:

Эта переменная имеет тип EndpointReference. Она принадлежит пространству имен wsa:, определенному поверх файла BPEL следующим образом

xmlns:wsa=http://schemas.xmlsoap.org/ws/2003/03/addressing

Стандарт WS-Addressing предлагает схему для типа EndpointReference. Вы можете <assign> (назначить) переменные этого типа партнерскому взаимоотношению, чтобы изменить информацию об адресе и информацию о сервисе, обеспечивая, таким образом, возможность изменения партнерских взаимоотношений во время выполнения.

Процесс DynamicPartnerLink в основном состоит из переключателя (switch). Он просматривает строку "provider", передаваемую в него вызывающей программой. Затем он присваивает структуру данных xml EndpointReference переменной partnerReference, содержащей информацию, релевантную запрашиваемому вами сервису. После переключения переменная partnerReference назначается партнерскому взаимоотношению LoanService и вызывается партнерское взаимоотношение.

Ниже показывается, как выполнить эту задачу, когда входная строка (провайдер услуг) имеет значение "united":

<copy>

<from>

<EndpointReference xmlns="http://schemas.xmlsoap.org/

ws/2003/03/addressing">

<Address>http://localhost:9700/orabpel/default/UnitedLoan</Address>

<ServiceName

xmlns:ns1="http://services.otn.com">ns1:UnitedLoan</ServiceName>

</EndpointReference>

</from>

</copy>

</assign>

Все находящееся между тэгами <from> и </from> - это XML-литерал, который вы присваиваете переменной partnerReference. Эти данные перекрывают адрес и сервис, определенные в партнерском взаимоотношении LoanService, когда вы присваиваете ссылке переменную partner-Reference. Теперь, когда вы исследовали использование партнерского взаимоотношения LoanService и файла LoanService.wsdl для вызова сервисов, выбранных во время выполнения, вы можете перейти к построению динамического процесса.

Создание динамического процесса BPEL

Теперь давайте создадим динамический BPEL-процесс "на пустом месте" (с нуля).

1. Создайте новый проект BPEL.

Создайте в JDeveloper новый проект асинхронного BPEL-процесса и назовите его "MyDL".

2. Импортируйте файл LoanService.wsdl из примера

DynamicPartnerLink.

Скопируйте файл LoanService.wsdl из примера DynamicPartnerLink в рабочий каталог проекта MyDL (по умолчанию, это [BPEL_HOME] \integration\jdev\jdev\ mywork\Workspace1\MyDL). (Такой подход сэкономит вам время и избавит от проблем, связанных с созданием собственных сервисов динамического WSDL и подпроцесса.) Затем кликните правой кнопкой мыши по проекту MyDL в Applications Navigator и выберите Add to Project... Выберите из каталога файл LoanService.wsdl и кликните по OK.

В этот момент файл LoanService.wsdl еще не добавлен к файлу bpel.xml. Вам не следует делать этого до того момента (намного позже в процессе), когда будет введена в действие переменная EndpointReference.

3. Создайте для сервиса ссуды шаблон партнерского взаимоотношения.

Кликните правой кнопкой мыши по одной из "линий поплавка" (визуально разделенные полосы внутри диаграммы процесса) и выберите Create Partner Link....

Заполните диалог, как показано на рис. 2. Чтобы заполнить поле WSDL File, вы будете должны использовать кнопку Browse WSDL Files from Local File System (слева от иконки с фонариком) и выберите файл LoanService.wsdl из каталога вашего проекта MyDL. Кликните по OK, чтобы создать партнерскую связь.

Рисунок 2. Окно диалога "Create Partner Link"

4. Создайте действия invoke (вызвать) и receive (получить) для вызова партнерского взаимоотношения DynamicLoanService.

Перетащите каждое из действий invoke и receive из палитры компонентов в ваш процесс (между действиями receiveInput и callbackClient). Перетащите одну из стрелок от invoke до партнерского взаимоотношения DynamicLoanService и создайте входную переменную. Сделайте то же самое для receive. Переменные нужно назвать loanInput и loanOutput.

5. Конфигурирование входных данных loanInput.

Обычно для получения от пользователя входных данных о ссуде вам требуется изменить файл MyDL.wsdl. Ради простоты здесь вы будете просто жестко кодировать присваивание, чтобы заполнить переменную loanInput. Поместите присваивание после действия receiveInput и создайте правило копирования, которое помещает значение "123456789" (имейте в виду, что это строка, а не число, так что не забывайте заключить ее в кавычки) в элемент SSN переменной loanInput следующим образом:

<copy>

<to variable="loanInput" part="payload" query="/ns2:loanApplication/

ns2:SSN"/>

</copy>

</assign>

6. Создайте переменную partnerReference.

В окне Structure раскройте дерево Variables, затем Process и выберите элемент Variables (см. рис. 3).

Рисунок 3 Раскрытие дерева "Variables"

Кликните правой кнопкой мыши по Variables и выберите Create Variable.... Установите имя вашей переменной на "partnerReference" и установите ее тип на "Element". Кликните по фонарику рядом с полем элемента, чтобы "поднять" селектор типа. Найдите тип "EndpointReference", двигаясь по следующему пути: Project WSDL Files→ LoanService.wsdl → Inline Schemas → schema (см. рис.4).

Рисунок 4 Выбор "EndpointReference"

7. Установка переменной partnerReference.

Перед тем как вызвать DynamicLoanService, создайте еще один элемент assign. Используйте его для установки переменной partnerReference. Первоначально вы должны жестко закодировать ее в сервисе UnitedLoan, но в следующем разделе вы сможете сделать ее динамической.

Здесь будет показано, как можно при переформатировании данных xml EndpointReference избежать проблемы, с которой пришлось столкнуться в примере DynamicPartnerLink,. Создайте правило копирования, которое заполняет переменную partnerReference этим пустым значением EndpointReference:

<EndpointReference xmlns="http://schemas.xmlsoap.org/

ws/2003/03/addressing"

xmlns:ns1="http://services.otn.com">

</EndpointReference>

В блоке "from" правила копирования убедитесь, что перед вводом приведенной выше информации выбрали тип "XML Fragment". Вы должны сделать эту копию, чтобы установить информацию о пространстве имен для partnerReference, потому что переменная partnerReference рассматривается как отдельный документ XML, когда она копируется в партнерское взаимоотношение DynamicLoanService. В противном случае вы получите исключительную ситуацию "пустой указатель", когда попробуете присвоить партнерскому взаимоотношению переменную partnerReference.

Теперь вы можете заполнить элементы ServiceName и Assign переменной partnerReference с помощью стандартных правил копирования. Убедитесь, что определили для сервиса то же самое пространство имен (ns1), что определено в вашей пустой конечной ссылке. Элемент

<Assign> должен выглядеть следующим образом:

<copy>

<from>

<EndpointReference

xmlns="http://schemas.xmlsoap.org/ws/2003/03/addressing"

xmlns:ns1="http://services.otn.com">

</EndpointReference>

</from>

</copy>

<copy>

<to variable="partnerReference" query="/ns3:EndpointReference/

ns3:ServiceName"/>

</copy>

<copy>

<to variable="partnerReference" query="/ns3:EndpointReference/

ns3:Address"/>

</copy>

</assign>

Также отметьте, что только в этой точке вы получаете возможность использовать переменную partnerReference, которую файл LoanService.wsdl добавил к вашему файлуxml.bpel (так что теперь можно обратиться к схеме EndpointReference).

8. Скопируйте переменную partnerReference в партнерское

взаимоотношение DynamicLoanService. Создайте новый элемент <assign> между действием SetupPartnerlink и <invoke> для DynamicLoanService.

Создайте новое правило копирования и настройте его, какпоказано на рис. 5.

Рисунок 5 Создание нового правила копирования

После того, как эти шаги будут закончены, динамический BPEL-процесс считается созданным. В теле процесса содержатся жестко закодированные присваивания адресов. Вы можете исправить эту ситуацию, заменив в Шаге 7 последние два правила копирования на информацию, собранную во время выполнения. Диаграмма процесса BPEL показана на рис. 6.

Рисунок 6 Новый процесс BPEL

Увеличение эффективности динамических процессов

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

Устранение зависимости адреса во время выполнения. Адреса сервисов часто могут изменяться, но во время выполнения вы можете оградить динамические процессы от этих изменений. Если вы назначаете только имя сервиса, но не его адрес, то адрес сервиса будет, вместо этого, найден в WSDL. Для демонстрации удалите заглушку адреса (<Address/>) из фрагмента XML в шаблоне правила копирования. Прежде, чем сделать это, создайте резервную копию файла MyDL.bpel, поскольку вскоре вам снова потребуется информация об адресе. Также удалите правило копирования, которое манипулирует адресом из оператора <assign> вашего SetupPartnerLink. Теперь элемент <assign> из SetupPartnerlink должен выглядеть следующим образом:

<copy>

<from>

<EndpointReference xmlns="http://schemas.xmlsoap.org/

ws/2003/03/addressing"

xmlns:ns1="http://services.otn.com">

</EndpointReference>

</from>

</copy>

<copy>

<to variable="partnerReference" query="/ns3:EndpointReference/

ns3:ServiceName"/>

</copy>

</assign>

Теперь снова разверните и выполните процесс MyDL. Несмотря на отсутствие адреса, он все еще делает успешный вызов подпроцесса UnitedLoan. Это действие может быть подтверждено, если взглянуть на представление дерева процесса на BPEL-консоли. Результат состоит в том, что можно изменить поведение динамических процессов, просто развертывая новый WSDL, в котором будет содержаться измененная информация об адресе сервиса. Альтернатива заключается в том, что для добавления новых сервисов потребуется изменить и повторно развернуть WSDL.

Независимые от WSDL сервисы.

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

Вернемся к предыдущей версии файла MyDL.bpel, в который имелись правила копирования для манипулирования адресами. Вместо того, чтобы удалять информацию об адресах, удалите информацию о сервисе как из фрагмента XML шаблона, так и из правила копирования ServiceName. Теперь элемент <assign> должен выглядеть следующим образом:

<copy>

<from>

<EndpointReference xmlns="http://schemas.xmlsoap.org/

ws/2003/03/addressing"

xmlns:ns1="http://services.otn.com">

</EndpointReference>

</from>

</copy>

<copy>

<to variable="partnerReference" query="/ns3:EndpointReference/

ns3:Address"/>

</copy>

</assign>

Когда Вы выполняете экземпляр процесса, он делает правильный вызов сервиса UnitedLoan, даже при том, что имя сервиса не определено. Вы можете создать WSDL DynamicPartnerLink только с одним фиктивным сервисом, затем вызывать другие сервисы, не перечисленные в WSDL, по мере того как во время выполнения будут становиться известными адреса этих сервисов. Если вы по каким- то причинам не определили адрес, то будет использован адрес сервиса в WSDL по умолчанию. Поэтому может оказаться хорошей идеей сделать так, чтобы в этом сервисе был указатель на реальный BPEL-процесс, возможно, на процесс регистрации ошибки или посылки уведомления.

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

Вызов многочисленных динамических процессов.

В некоторых случаях возникает ситуация, когда один набор данных следует передать нескольким подпроцессам - последовательно или параллельно. Для того чтобы осуществить такой тип поведения, вы можете использовать один или более циклов while. Давайте рассмотрим краткий пример. Доступность ссуд- провайдера может определяться в зависимости от дня недели. Эта информация хранится в базе данных. Запрос на ссуду поступает в понедельник, и когда делается запрос к базе данных, он возвращает список доступных ссуд- провайдеров (Loan Service Providers) - United и Star. Для обработки ссуды должны быть вызваны подпроцессы United или Star - последовательно или параллельно. Запрос к базе данных возвращает следующий результат:

<part xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

name="responseheaders">

null</part>

<part xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

name="DynamiclinksCollection">

<n:DynamiclinksCollection

xmlns:n=http://xmlns.oracle.com/pcbpel/adapter/db/top/MyDynamicLink

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<address>http://localhost:9700/orabpel/default/UnitedLoan</address>

<day>monday</day>

</Dynamiclinks>

<address>http://localhost:9700/orabpel/default/StarLoan</address>

<day>united</day>

</Dynamiclinks>

</n:DynamiclinksCollection>

</part>

</dbOutput>

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

<copy>

</copy>

</assign>

<while name="LoanLoop" condition="bpws:getVariableData("i")

count(bpws:getVariableData("dbOutput","DynamiclinksCollecti

on",

"/ns3:Dynamiclin ksCollection/Dynamiclinks"))">

<copy>

<from>

<EndpointReference

xmlns="http://schemas.xmlsoap.org/ws/2003/03/addressing"

xmlns:ns1="http://services.otn.com">

</EndpointReference>

</from>

</copy>

</assign>

<!-- set the address in the endpoint variable

based on the current node -->

<copy>

<from variable="dbOutput" part="DynamiclinksCollection"

query="/ns3:DynamiclinksCollection/Dynamiclinks

[number(bpws:getVariableData("i"))]/address"/>

<to variable="partnerReference"

query="/wsa:EndpointReference/wsa:Address"/>

</copy>

</assign>

<copy>

</copy>

</assign>

<invoke name="Invoke_2" partnerLink="LoanService"

portType="ns2:LoanService" operation="initiate"

inputVariable="loanInput"/>

<!-- be sure to increment your counter or you have an infinite loop

-->

<copy>

</copy>

</assign>

</sequence>

</while>

В приведенном выше примере вы вызываете асинхронные сервисы. Их можно вызывать параллельно, если удалить <receive> из цикла while <invoke> и создать для него собственный цикл while. Отклики от каждого из исходящих (callout) процессов будут стоять в очереди вплоть до запуска <receive>, чтобы захватить их. Задача receive соберет ответы в том порядке, в котором они возвращаются. При таком подходе выходные данные быстро выполняющейся задачи не будут поставлены в очередь позади выходных данных долго выполняющейся задачи. Не рекомендуется выходить из цикла while <receive>, пока не будут собраны все асинхронные ответы.

Заключение

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

Об авторе: Шон Кэри является разработчиком структуры систем программного обеспечения в компании SPS Commerce - лидера в области хостинга EDI. За плечами у Шона более семи лет работы со стратегически важными реализациями систем электронной коммерции и 15 лет практического опыта в области проектировании программного обеспечения.

Ссылки по теме