среда, 24 сентября 2014 г.

Из пустого в порожнее

Статья о том, как перекладывать файлы. По мотивам вебинара "SOA Pattern: File Gateway". Задача состоит в том, чтобы переложить пустой файл из одной директории в другую при помощи WSO2 ESB.

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

Открываем файл <ESB_HOME>/repository/conf/axis2/axis2.xml и раскомментируем две строчки. Первую  - в разделе входящих соединений "Transport Ins (Listeners)":

<transportReceiver name="vfs" class="org.apache.synapse.transport.vfs.VFSTransportListener"/>

Вторую - в разделе исходящих соединений "Transport Outs (Senders)":

<transportSender name="local" class="org.wso2.carbon.core.transports.local.CarbonLocalTransportSender"/>

Теперь при создании нового прокси-сервиса появляется опция vfs.



Будем добавлять параметры, чтобы настроить передачу файлов. Задаём интервал опроса файловой системы:
transport.PollInterval = 2000ms


Подобным образом добавляем следующие параметры.
Папка источник:
transport.vfs.FileURI = file://D:/q/in
Шаблон названия файла:
transport.vfs.FileNamePattern = .*\.txt
Тип содержимого файлов:
transport.vfs.ContentType = text/plain
Действие после обработки файла:
transport.vfs.ActionAfterProcess = MOVE
transport.vfs.MoveAfterProcess = file://D:/q/processed
Действие в случае ошибки при обработки файла:
transport.vfs.ActionAfterFailure = MOVE
transport.vfs.MoveAfterFailure = file://D:/q/failure 

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


Переходим к созданию последовательностей медиаторов.




 Ограничимся созданием встроенной входящеё последовательности.



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


Свойство OUT_ONLY = true  говорит шине о том, что не нужно ждать ответа от сервиса, которому отправлено сообщение.



 Добавим ещё один медиатор Property и запишем в него имя обрабатываемого файла.


 Извлекаем имя фала с помощью выражения:  
get-property('transport', 'FILE_NAME')
 


Создадим третий медиатор Property.
Передаём определяем имя конечного файла, который запишет VFS. Если не указать параметр transport.vfs.ReplyFileName, то будет создан файл с именем по умолчанию - response.xml.
Выполняемый трюк с перебросом имени файла описан в нескольких источниках:
 http://stackoverflow.com/questions/10492050/wso2-how-to-set-replyfilename-in-vfs

 

 Создадим теперь медиатор Send, который запишет обрабатываемый файл в новое место.


Конечная точка (Endpoint) будет у нас встроенной, чтобы сократить число шагов.


 Выбираем адресную конечную точку (Address Endpoint).


 В качестве адреса передаём путь к директории, в которую будем складывать файлы:
 vfs:file://D:\q\out
 Префиксы vfs: и file: означают, что мы будем работать с файловой системой через VFS.


 Запоминаем настройки медиатора Send, содержащего созданную только что конечную точку.


 Сохраняем последовательность.





 Завершаем определение прокси-сервиса.








 В итоге получилась такая конфигурация:

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="fileproxy"
       transports="vfs"
       statistics="disable"
       trace="disable"
       startOnLoad="true">
   <target>
      <inSequence>
         <property name="OUT_ONLY" value="true" scope="default" type="STRING"/>
         <property name="filename"
                   expression="get-property('transport', 'FILE_NAME')"
                   scope="default"
                   type="STRING"/>
         <property name="transport.vfs.ReplyFileName"
                   expression="get-property('filename')"
                   scope="transport"
                   type="STRING"/>
         <send>
            <endpoint>
               <address uri="vfs:file://D:\q\out"/>
            </endpoint>
         </send>
      </inSequence>
   </target>
   <parameter name="transport.vfs.ActionAfterProcess">MOVE</parameter>
   <parameter name="transport.PollInterval">2000ms</parameter>
   <parameter name="transport.vfs.MoveAfterProcess">file://D:/q/processed</parameter>
   <parameter name="transport.vfs.FileURI">file://D:/q/in</parameter>
   <parameter name="transport.vfs.MoveAfterFailure">file://D:/q/failure</parameter>
   <parameter name="transport.vfs.FileNamePattern">.*\.txt</parameter>
   <parameter name="transport.vfs.ContentType">text/plain</parameter>
   <parameter name="transport.vfs.ActionAfterFailure">MOVE</parameter>
   <description/>
</proxy>
                                

Ссылки на документацию:
https://docs.wso2.com/display/ESB481/VFS+Transport
https://docs.wso2.com/display/ESB481/Configuring+Transports

ESB или BPS

Посмотрел вебинар об интеграционных патернах, реализуемых при помощи WSO2 ESB и WSO2 BPS.

Освещён вопрос о том, в каком случае какому продукту отдавать предпочтение.

Enterprise Service Bus

- не нужно сохранять состояние взаимодействия
- небольшое количество интегрируемых сервисов (менее 10)
- не нужно долго ждать ответа сервиса
- нет опыта применения BPEL

Business Process Server

- требуется хранить состояние
- большое количество интегрируемых сервисо (более 10)
- нужно долго (часы, дни) ждать ответа некоторых сервисов
- сотрудники умеют пользоваться BPEL

Показаны 2 варианта совместного использования ESB и BPS. В одном из них шина используется, чтобы привести все соединения к единому формату (SOAP), а BPS выполняет оркестрирование сервисов.




вторник, 23 сентября 2014 г.

Подключаемся из ESB к Jira



Установить Jira на локальной машине


Описание доступно по ссылке:

https://developer.atlassian.com/display/DOCS/Set+up+the+Atlassian+Plugin+SDK+and+Build+a+Project

Описание на официальном сайте немного устарело. Ниже описан работающий на данный момент способ.

Java

Скачать JDK 1.7 с сайта Oracle и установить на компьютер.
Прописать путь в переменной окружения JAVA_HOME: C:\Program Files\Java\jdk1.7.0_51
Добавить путь к бинарникам в начало переменной окружения Path: %JAVA_HOME%\bin;
Проверить версию компилятора: javac -version

Plugin SDK

Скачать SDK: https://marketplace.atlassian.com/download/plugins/atlassian-plugin-sdk-windows
Создать директорию на жёстком диске.
Запустить установщик.

Maven
После установки Plugin SDK добавить переменную окружения M2_HOME так, чтобы использовать Maven, который идет в комплекте к SDK:
D:\atlassian-plugin-sdk\apache-maven-3.2.1
Создать переменную окружения M2:
%M2_HOME%\bin
Создать переменную MAVEN_OPTS:
-Xms768m -Xmx3072m -XX:MaxPermSize=1200m
Добавить путь к бинарникам к переменной окружения Path:
;%M2%
Вписать прокси-сервер в файл настроек:
D:\atlassian-plugin-sdk\apache-maven-3.2.1\conf\settings.xml

<proxies>
<proxy>
<id>tp-local</id>
<active>true</active>
<protocol>http</protocol>
<username>ваше имя в домене Winows</username>
<password>ваш пароль</password>
<host>free.tp-local.ru</host>
<port>3128</port>
<nonProxyHosts>localhost</nonProxyHosts>
</proxy>
</proxies>


Создать папку на локальном диске и записать путь к ней в файл настроек:
D:\atlassian-plugin-sdk\apache-maven-3.2.1\conf\settings.xml

<localRepository>D:\atlassian-maven-repository</localRepository>

Если этого не сделать, то репозиторий у меня окажется на другой машине в сети:  
\\srv09\UserFolders$\novikov\.m2\repository

Дополнительная информация на странице: http://maven.apache.org/download.cgi

Проверка
В командной строке запустить:  
atlas-version
Убедиться, что все пути правильные.

 Запустить экземпляр Jira

Создать на диске директорию для запуска Jira с произвольным именем:
D:/jira
Открыть командную строку и перейти в эту директорию.
Запустить команду
atlas-run-standalone --product jira 
Более подробно смотри Step 1. Install and configure the local JIRA instance и
https://developer.atlassian.com/display/DOCS/atlas-run-standalone
По окончании работы команды на экране появится подобное сообщение:


Скопировать в адресную строку браузера подчёркнутую часть.
Войти в Jira под пользователем admin с паролем admin.
Создать проект с названием TEST и задачу в нём с ключом TEST-1.



Настроить шину WSO2 ESB


Установить Jira Connector

Правила установки Jira Connector приведены в документации:
https://docs.wso2.com/display/ESB480/JIRA+Connector#JIRAConnector-createIssue

Нужно скачать архив с плагином.


 Загрузить плагин в шину через браузер.



 В списке коннекторов нажать на слово Disabled, чтобы сделать загруженный коннектер активным.


 Создать локальную запись jiraauth, которая потребуется позже в медиаторах для авторизации в Jira.
https://docs.wso2.com/display/ESB480/JIRA+Connector#JIRAConnector-ConnectingtoJIRA


 Вставить значение

<jira.init xmlns="http://ws.apache.org/ns/synapse">     
      <username>admin</username>     
      <password>admin</password>     
      <uri>http://02-128.tp-local.ru:2990/jira</uri>  
</jira.init>


URI взять то, что указано в командной строке после запуска Jira.





Создать 2 последовательности медиаторов jiratest и jiraerror для последующего использования в REST API.

Начать с последовательности jiraerror


 Последовательность содержит только медиатор для ведения лога.



Сохранить последовательность в реестр.




 После jiraerror создать последовательность jira для обработки входящих запросов.


 Указать название последовательности и прикрепить последовательность jiraerror, которая служит для обработки ошибок.




 Переключаемся в XML-представление, чтобы вставить медиатор для получения сведений о задаче в Jira.


Вставить определение медиатора, составленное по примеру в документации:
 https://docs.wso2.com/display/ESB480/JIRA+Connector#JIRAConnector-getIssue





<sequence xmlns="http://ws.apache.org/ns/synapse" name="jira" onError="conf:/jiraerror">
   <jira.getIssue configKey="jiraauth">     
      <issueIdOrKey>TEST-1</issueIdOrKey>  
   </jira.getIssue>

</sequence>


 Добавляем медиатор для записи параметров сообщения в лог.


 Определяем параметр id.


 По ссылке http://02-128.tp-local.ru:2990/jira/rest/api/2/issue/TEST-1 видно, что REST API Jira возвращает JSON.



Об этом также написано в документации:
https://docs.atlassian.com/jira/REST/latest/
https://docs.atlassian.com/jira/REST/latest/jira-rest-plugin.wadl

Как работать с JSON в WSO2 ESB описано здесь:
https://docs.wso2.com/display/ESB481/JSON+Support#JSONSupport-AccessingcontentfromJSONpayloads

Поэтому, чтобы извлечь значение id, пишем json-eval($.id)


Сохраняем последовательность jira в реестр.







Создать API для обращения к Jira.


Назвать API и задать контекст (начало URL). Перейти к созданию ресурса.


Определяем метод GET, стиль URL и определить путь, на который будет отзываться создаваемый ресурс. О маппинге написано в документации:
https://docs.wso2.com/display/ESB481/Creating+APIs#CreatingAPIs-URLmappings
Начать прикрепление последовательности медиаторов с именем jira. Для этого открыть реестр.


Выбрать последовательность из списка.


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


Выбрать последовательность из списка.


Сохранить ресурс.


Сохранить API.


Закрыть сообщение.


Создание API завершено.



Выполнить проверку. Открыть в браузере URL:
http://192.168.4.163:8280/jiratest/test

Убедиться, что id получен из Jira и занесён в лог.


 На этом пошаговая инструкция окончена.

Ссылки на материалы в документации

https://docs.wso2.com/display/ESB480/Managing+Connectors+in+Your+ESB+Instance
https://docs.wso2.com/display/ESB480/Using+a+Connector
https://docs.wso2.com/display/ESB480/JIRA+Connector

https://docs.wso2.com/display/ESB481/JSON+Support
https://docs.wso2.com/display/ESB481/Creating+APIs

https://developer.atlassian.com/display/JIRADEV/Creating+a+JIRA+SOAP+Client
https://docs.atlassian.com/jira/REST/latest/