Продолжаем серию уроков по BPEL. Сегодня мы рассмотрим специфическое для Oracle SOA Suite средство организации взаимодействия между экземплярами BPEL-процессов - сигналы.
При моделировании бизнес-процессов иногда требуется вынести некоторую логику в отдельные подпроцессы. Данная необходимость может объясняться желанием повторно использовать данную логику или распараллелить выполнение подпроцессов с целью увеличения производительности. Основной процесс в терминологии Oracle называется "мастером" или "родительским", а подпроцесс - "детальным" или "дочерним" процессом.
Взаимодействие с BPEL-процессами реализуется точно так же, как и с другими сервисами. При этом существует три основных паттерна взаимодействия родительского и дочерних процессов:
Действия 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
Постановка задачи координации родительских и дочерних процессов
При моделировании бизнес-процессов иногда требуется вынести некоторую логику в отдельные подпроцессы. Данная необходимость может объясняться желанием повторно использовать данную логику или распараллелить выполнение подпроцессов с целью увеличения производительности. Основной процесс в терминологии Oracle называется "мастером" или "родительским", а подпроцесс - "детальным" или "дочерним" процессом.
Взаимодействие с BPEL-процессами реализуется точно так же, как и с другими сервисами. При этом существует три основных паттерна взаимодействия родительского и дочерних процессов:
- Родительскому процессу интересен только факт запуска экземпляров дочерних процессов. Данный паттерн так же называется "Вызови и забудь" (fire and forget). Родительский процесс создает один или несколько экземпляров дочернего процесса, при этом его не интересует их последующее исполнение.
- Родительскому процессу интересна информация, возвращаемая дочерними. В таком случае родительскому процессу необходимо ожидать ответ от каждого из них. В случае синхронного взаимодействия ответ и так подразумевается, а в случае асинхронного - родительский процесс продолжает работу после получения ответа от дочернего, а для связывания запроса и ответа используется механизм корреляции или WS-Addressing.
- Родительскому процессу интересен факт завершения выполнения некоторых действий дочерним процессом, но не результаты этого выполнения. Т.е. родительский процесс нуждается не в сообщении от дочернего, а в некотором сигнале.
Действия 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 настраивается следующим образом:
На этом рассмотрение примера можно закончить. Подпроцесс проверки адреса строится аналогично только что рассмотренному подпроцессу проверки типа абонента.
Ресурсы
- Coordinating Master and Detail Processes;
- SOA Suite 11g – Oracle BPEL Master and Detail process coordination using signals.
Заключение
Помимо сигналов Oracle SOA Suite предлагает ряд других действий, расширяющих возможности языка BPEL. В JDeveloper данные действия расположены на вкладке Oracle Extensions палитры Component Palette. Если уважаемым читателям будет интересно, то в следующих статьях расскажу еще про какое-либо из данных действий. Оставайтесь на связи!
Понравилось сообщение - подпишитесь на блог и Twitter
2 комментария:
Громадное спасибо за статью. Подскажите, приходилось ли использовать на просторах интеграции AIA Foundation Pack, смотрю на него как баран на новые ворота и не понимаю с какого конца начинать его грызть.
Здравствуйте.
В реальных проектах пока не использовал, но грызу для себя. Можете попробовать начать с книжки
Oracle Application Integration Architecture (AIA) Foundation Pack 11gR1: Essentials
Отправить комментарий
Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!