суббота, 16 июня 2012 г.

Координация родительских и дочерних BPEL-процессов. Сигналы

Продолжаем серию уроков по BPEL. Сегодня мы рассмотрим специфическое для Oracle SOA Suite средство организации взаимодействия между экземплярами BPEL-процессов - сигналы.

Постановка задачи координации родительских и дочерних процессов


При моделировании бизнес-процессов иногда требуется вынести некоторую логику в отдельные подпроцессы. Данная необходимость может объясняться желанием повторно использовать данную логику или распараллелить выполнение подпроцессов с целью увеличения производительности. Основной процесс в терминологии Oracle называется "мастером" или "родительским", а подпроцесс - "детальным" или "дочерним" процессом.

Взаимодействие с BPEL-процессами реализуется точно так же, как и с другими сервисами. При этом существует три основных паттерна взаимодействия родительского и дочерних процессов:
  1. Родительскому процессу интересен только факт запуска экземпляров дочерних процессов. Данный паттерн так же называется "Вызови и забудь" (fire and forget). Родительский процесс создает один или несколько экземпляров дочернего процесса, при этом его не интересует их последующее исполнение.
  2. Родительскому процессу интересна информация, возвращаемая дочерними. В таком случае родительскому процессу необходимо ожидать ответ от каждого из них. В случае синхронного взаимодействия ответ и так подразумевается, а в случае асинхронного - родительский процесс продолжает работу после получения ответа от дочернего, а для связывания запроса и ответа используется механизм корреляции или WS-Addressing.
  3. Родительскому процессу интересен факт завершения выполнения некоторых действий дочерним процессом, но не результаты этого выполнения. Т.е. родительский процесс нуждается не в сообщении от дочернего, а в некотором сигнале.

Действия Signal и Receive Signal - Oracle'овое расширение языка BPEL - позволяют реализовать третий паттерн взаимодействия процессов.

Запуск дочерних процессов


Прежде чем подробно рассмотреть особенности настройки и применения действий Signal и Receive Signal необходимо разобраться с тем, как создать дочерний процесс. Запуск дочернего процесса производится аналогично запуску любого другого BPEL-процесса: посредством вызова сервиса, представляющего собой запускаемый процесс, с помощью действия Invoke. При этом у данного действия необходимо отметить флаг Invoke as Detail. Если этого не сделать, до между процессами не будет установлена связь "Родительский" - "Дочерний" и координация посредством сигналов будет невозможна.





При запуске дочернего процесса с ним можно связать метку. Значение метки задается в поле Detail Label действия Invoke. Если в родительском процессе предполагается использование нескольких действий Receive Signal (т.е. предполагается координация выполнения с несколькими группами дочерних процессов), то у каждого действия Invoke, посредством которого запускаются дочерние процессы, должно быть указано значение поля Detail Label. В противном случае будет сгенерирована ошибка компиляции.





С помощью одного действия Invoke можно запустить несколько экземпляров дочерних процессов, вызвав это действие в цикле. Несколько действий Invoke могут использовать одну и ту же метку Detail Label.



Координация процессов посредством сигналов


Как было сказано выше, координация процессов осуществляется с помощью действий Signal и Receive Signal. Действие Receive Signal блокирует исполнение процесса до получения сигнала, отправленного действием Signal. Для отделения сигналов друг от друга используются метки. Метка задается в качестве значения параметра Label. Действие Signal и соответствующее ему действие Receive Signal должны использовать одинаковые метки.



Направление отправки или получения сигнала задается в качестве значения параметров To/From действий Signal/Receive Signal, соответственно. Данные параметры могут принимать одно из двух возможных значений: master - сигнал посылается родительскому процессу или ожидается от родительского процесса и details - сигнал посылается всем дочерних процессам и, соответственно, ожидается от всех дочерних процессов, созданных с помощью действия Invoke, метка Detail Label которого совпадает с меткой Label.

Действие Signal:







Действие Receive Signal:







Уместно отметить преимущество координации с помощью сигналов перед координацией с помощью сообщений. Данное преимущество проявляется при координации одного родительского процесса с несколькими экземплярами дочернего. При использовании сигналов достаточно пары действий Signal/Receive Signal независимо от числа экземпляров одного дочернего процесса. При использовании координации с помощью отправки/приема сообщений, необходимо организовывать цикл с числом итераций равным числу дочерних процессов, при этом аккуратно организовывая корреляцию сообщений.

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



В данном процессе можно выделить цикл создания трех экземпляров дочернего процесса (цикл While3), запуск дочерних процессов (действие SignalStarted), ожидание завершения работы всех дочерних процессов (действие ReceiveSignalFinish) и обработку результатов (действия ProcessResult и др.)

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



В дочернем процессе можно выделить ожидание разрешения на запуск (действие ReceiveStarted), выполнение некоторых операций (действие DoSomething) и уведомление родительского процесса о завершении работы (действие SignalFinish).

Пример использования координации процессов с помощью сигналов


Рассмотрим следующий пример координации процессов с помощью сигналов. Предположим, что мы разрабатываем бизнес-процесс интеграции трех систем: Автоматизированной Системы Расчетов (АСР, биллинг), CRM и MDM (Нормативно-Справочная Информация (НСИ)). Из системы биллинга в систему CRM передаются абоненты. У каждого абонента есть набор полей, представляющих собой ссылки на справочники (справочник адресов, справочник типов абонентов, справочник типов юридических лиц и т.д.) Справочники ведутся в системе MDM и периодически передаются в систему CRM. При этом, в системе CRM нельзя создавать абонента до тех пор, пока с данной системой не будут синхронизированы все необходимые справочники. Отслеживание факта синхронизации справочников возлагается на интеграционное решение, т.е. на разрабатываемый нами бизнес-процесс.

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

Родительский процесс:



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

Действие InvokeCheckAbonentTypeCode настраивается следующим образом:



Действие ReceiveAbonentType настраивается следующим образом:



Действия InvokeCheckAddress и receiveAddress настраиваются аналогично.

Дочерний процесс (на примере типа абонента):



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

Действие SignalAbonentType настраивается следующим образом:



На этом рассмотрение примера можно закончить. Подпроцесс проверки адреса строится аналогично только что рассмотренному подпроцессу проверки типа абонента.

Ресурсы



Заключение


Помимо сигналов Oracle SOA Suite предлагает ряд других действий, расширяющих возможности языка BPEL. В JDeveloper данные действия расположены на вкладке Oracle Extensions палитры Component Palette. Если уважаемым читателям будет интересно, то в следующих статьях расскажу еще про какое-либо из данных действий. Оставайтесь на связи!

Понравилось сообщение - подпишитесь на блог и Twitter

2 комментария:

badinside комментирует...

Громадное спасибо за статью. Подскажите, приходилось ли использовать на просторах интеграции AIA Foundation Pack, смотрю на него как баран на новые ворота и не понимаю с какого конца начинать его грызть.

Pavel Samolisov комментирует...

Здравствуйте.
В реальных проектах пока не использовал, но грызу для себя. Можете попробовать начать с книжки
Oracle Application Integration Architecture (AIA) Foundation Pack 11gR1: Essentials

Отправить комментарий

Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!