О динамической настройке адаптеров Oracle SOA Suite

В общем случае среда, в которой тестируется приложение, отличается от среды, в котором оно будет работать. Банальный пример: при тестировании может использоваться другая база данных нежели при промышленной эксплуатации. Так же зачастую бывает необходимо развернуть на одном сервере несколько экземпляров приложения, но настроенных по-разному, например, для ускорения обработки сообщений в SOA-среде может потребоваться пустить поток сообщений через несколько JMS-очередей, обрабатываемых несколькими экземплярами композитного приложения, построенного на платформе Oracle SOA Suite. В данной статье мы рассмотрим как с помощью SOA Suite динамически изменять JNDI-имя используемой очереди сообщений при разворачивании и во время работы композитного приложения.

Управление конфигурацией при разворачивании приложения

Для управления конфигурацией во время разворачивания приложения существует такое понятие, как конфигурационный план (Config Plan). В случае SOA Suite конфигурационный план представляет собой XML-файл с корневым тегом SOAConfigPlan, пространство имен которого определено по адресу: http://schemas.oracle.com/soa/configplan.

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

Для разработки будем использовать Oracle JDeveloper. Прежде всего необходимо настроить подключение к серверу приложений. Подключение создается из пункта меню New.... В появившемся диалоговом окне нужно выбрать General -> Connections -> Application Server Connection.



На первом шаге мастера задается название нового подключения и его тип - в нашем случае WebLogic 10.3:



Затем требуется задать логин и пароль администратора сервера:



А так же настройки подключения: расположение сервера, порт и название домена. У меня SOA Suite установлен на локальной машине, используется стандартный порт 7001, а сам домен называется soasuite.



После задания основных параметров конфигурации можно протестировать соединение. Если все указано правильно, то по завершении процесса тестирования на экран будет выдана строчка 9 of 9 tests successful..



На последнем шаге мастера нас проинформируют как открыть созданное соединение:



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

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



Сразу после перетягивания откроется мастер подключения адаптера. На первом шаге мастера необходимо задать имя экземпляра адаптера в системе:



После чего - выбрать JMS Provider. В качестве провайдера можно использовать как встроенный в WebLogic, так и провайдеры сторонних производителей. Выберем провайдер Oracle WebLogic JMS:



После выбора провайдера необходимо выбрать подключение к серверу приложений из созданных ранее:



На следующем шаге нам предложат либо выбрать существующую операцию, либо задать ее позже. Выберем задать позже и нажмем Next. После этого появится окно создания операции, в котором необходимо выбрать тип операции: Consume Message - подписаться на сообщения из очереди, Produce Message - записать сообщение в очередь и Request/Reply - произвести синхронную операцию через очередь. Выберем Produce Message:



Теперь нужно задать параметры созданной на предыдущем шаге операции. Прежде всего, с помощью кнопки Browse... выбрать очередь сообщений из присутствующих на сервере. Так же необходимо задать параметры сообщения: тип тела сообщения (текстовое, бинарное или т.н. Map message), тип доставки (с сохранением при доставки или без него), приоритет и время жизни. Особое внимание следует обратить на параметр JNDI Name - в нем указывается JNDI имя фабрики соединений с очередью. В поставку Oracle SOA Suite входит широкий набор фабрик соединений, в составе которого есть например фабрики соединений с WebLogic JMS, Websphere MQ, Sun MQ, JBoss MQ и конечно же Active MQ. Впрочем, данный список далеко неполон.



После настройки сообщения необходимо задать формат его содержимого.



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



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



На последнем шаге нам сообщат, что мы создали экземпляр адаптера и о том, какие файлы будут созданы после щелчка на Finish



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



В принципе у нас уже готово композитное приложение, использующее очередь jms/Queue/DemoQueue, выбранную на 7-м шаге мастера. Однако, мы не хотим использовать данную очередь, а хотим указывать очередь непосредственно при разворачивании приложения на сервере. Для этого необходимо вернуться к понятию конфигурационного плана и познакомиться с ним поближе.

Прежде всего конфигурационный план нужно сгенерировать. Для этого необходимо правой кнопкой мыши щелкнуть на файле композита, расположенному в дереве файлов проекта, и выбрать пункт меню Generate Config Plan:



Появится диалоговое окно Composite Configuration Plan Generator в котором можно задать название файла с планом и отметить нужно ли перезатирать существующие файлы с таким названием.



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



Теперь то значение JNDI-имени очереди, которое было указано при создании адаптера, будет игнорироваться, а вместо него будет использоваться jms/sourceQueue_100.

Рассмотрим процесс разворачивания приложения на сервере. Для разворачивания из среды JDeveloper существует пункт меню Deploy:



При выборе данного пункта запустится мастер разворачивания, на первом шаге которого необходимо выбрать куда именно будет разворачиваться приложение: на сервер или в SAR-файл.



Чтобы при разворачивании приложения были применены изменения, указанные в конфигурационном плане, необходимо на следующем шаге мастера отметить пункт Use the following SOA cofiguration plan for all composites: и указать путь к файлу с планом. Так же можно отметить пукт Overwrite any existing components with the same revision ID, что позволит переразворачивать приложение, не обновляя его версию (удобно при разработке).



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



Если сервер приложений запущен и с ним установлена связь, то на следующем шаге мастера будет отображена информация о статусе и параметрах данного сервера:



Если нажать Next... то отобразится сводная информация по приложению и по серверу, на котором оно будет развернуто.



При нажатии кнопки Finish мастер запустит процесс разворачивания композитного приложения на выбранном сервере.



Протестируем созданное и развернутое приложение. Для этого откроем Enterprise Console и перейдем в Dasboard приложения: Farm_soasuite -> SOA -> soa-infra -> default -> deploymentdemo:



В нижней части страницы расположен блок Services and References, состоящий из двух элементов: bpelprocess1_client_ep и OutJMSAdapter:



Если нажать на OutJMSAdapter и перейти на вкладку Properties, то можно увидеть свойства адаптера, в том числе и DestinationName: jms/sourceQueue_100, т.е. значение, указанное в конфигурационном плане:



Для тестирования приложения необходимо нажать кнопку Test. Откроется страница тестирования, на которой можно увидеть путь к WSDL файлу сервиса (сервис выставляет клиент к BPEL-процессу. Т.е. в качестве веб-сервиса выступает непосредственно BPEL-процесс), параметры сервиса и, самое главное, разобранный массив входных параметров, по которому сгенерирована форма. Данная форма находится в блоке Input arguments. Если заполнить поля данной формы и нажать на кнопку Test Web Service, то на веб-сервис отправится запрос, содержащий указанные параметры.



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



По возвращении на страницу Dashboard мы сможем увидеть, что вызов сервиса действительно завершен успешно.



В административной консоли WebLogic, по адресу Services -> Messaging -> JMS Modules -> Module -> Queue -> Monitoring можно посмотреть содержимое сообщений, отправленных в очередь:

Управление конфигурацией во время исполнения приложения

Oracle SOA Suite позволяет гибко изменять конфигурацию адаптеров не только во время разворачивания приложения, но и во время его работы. В отличие от других, в том числе и снабженных открытыми исходными кодами, движков BPEL, SOA Suite позволяет передавать в контекст вызова (элемент Invoke) широкую номенклатуру свойств.

Для того, чтобы изменить используемое JMS-адаптером JNDI-имя очереди сообщений, достаточно установить свойство jca.jms.JMSDestinationName. Данное свойство может принимать в качестве значения либо переменную, либо выражение. Рассмотрим вариант с переменной.

Добавим в BPEL-процесс глобальную переменную queueName типа xsd:string:



В BPEL-процессе перед оператором Invoke разместим оператор Assign, в котором будем присваивать константу MyDemoQueue в качестве значения переменной queueName.



Настроим оператор Invoke. Откроем вкладку Properties, найдем свойство jca.jms.JMSDestinationName и нажмем на ... в столбце Value:



Появится диалоговое окно установки значения свойства Adapter Property Value.



Как уже было замечено выше, в качестве значения свойства можно использовать переменную (Variable) или XPath-выражение (Expression). Если нажать на значок лупы, то можно указать переменную либо ее часть:



Выбранная переменная будет отображена в поле ввода диалогового окна



и в качестве значения свойства jca.jms.JMSDestinationName.



Развернем на сервере новый вариант приложения и протестируем его как было описано выше. Так как на сервере WebLogic не создано очереди MyDemoQueue, то тест завершится неудачно:



Чтобы получить более подробную информацию о причинах ошибки, необходимо кликнуть на идентификатор экземпляра приложения (Composite Instance ID). Откроется окно, содержащее подробные сведения о конкретном экземпляре, в частности - поток исполнения с указанными на нем ошибками. Видно, что оператор writeToJMS завершен неуспешно. Если открыть узел payload, то будет отображена подробная информация об ошибке:



Видно, что заданное название очереди MyDemoQueue не является допустимым - такой очереди попросту нет.

Мы рассмотрели вопросы динамической настройки адаптеров Oracle SOA Suite в режиме развертывания и в режиме исполнения. В принципе, применение конфигурационного плана не ограничивается только настройкой адаптеров, это - довольно гибкий механизм, позволяющий в частности и передавать значения тех или иных параметров в BPEL-процессы. Сама BPEL-машина Oracle гораздо мощнее тех, с которыми мне приходилось до этого работать, в частности - Active BPEL. Причем, данная BPEL машина позиционируется Oracle не как средство описания бизнес процессов (для этого существует Oracle BPM с BPMN), а как часть интеграционного решения, т.е. BPEL используется по своему прямому назначению - обеспечивать оркестровку сервисов.

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