Создаём точку входа API в WSO2 ESB

WSO2 ESB настраивается без программирования. Предоставляется графический интерфейс для создания конфигураций. Готовая конфигурация представляет собой XML-текст.

Ниже показаны все шаги по созданию простого REST API. Переданный в ссылке ID пользователя записывается в лог.

Создаём новое API

Указываем названиеAPI, путь от корня сайта и создаём первый ресурс

Будем отправлять параметры в адресной строке (GET), задаём шаблон и переходим к созданию последовательности медиаторов для обработки поступающих на ресурс запросов.

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

 

Начинаем определение параметра, значения которого будут попадать в лог

 

Используем выражение get-property('uri.var.userId') для извлечения значения из URL и сохраняем медиатор

Сохраняем последовательность и возвращаемся к редактированию API

Сохраняем ресурс

Сохраняем API

Закрываем сообщение об успешном создании API

Находим адрес API в списке

Обращаемся к созданному ресурсу ESB по адресу
http://192.168.4.163:8280/userapi/users/100500

Убеждаемся, что ID пользователя отобразилось в логе

Посмотрим XML-конфигурацию для созданного API

Видим следующее:

<api xmlns="http://ws.apache.org/ns/synapse" name="userapi" context="/userapi">
   <resource methods="GET" uri-template="/users/{userId}">
      <inSequence>
         <log>
            <property name="userId" expression="get-property('uri.var.userId')"></property>
         </log>
      </inSequence>
   </resource>
</api>

Дополнительную информацию вы найдёте в документации к сервисной шине.

Вызываем Java из Jaggery.js

Зачем переписывать на JavaScript код, который уже есть в Java? Jaggery.js позволяет делать прямые вызовы. Смотрите с 55-ой минуты вэбинара:

http://wso2.com/library/webinars/2014/09/javascript-from-browser-to-server/

Оформить обращение к Java в виде отдельной функции в коде JavaScript.
Начинать путь к классу Java со слова Packages.
Перед тем как вернуть результат, преобразовать его в тип JavaScript.

Ниже приведён пример функции для изменения формата строки.

<%
function encodeBase64(str) {

    var bytes = new Packages.java.lang.String(str).getBytes();
    var converted = Packages.org.apache.commons.codec.binary.Base64.encodeBase64(bytes);
    return String(new Packages.java.lang.String(converted));

}
%>

MoscowJS 15

Приглашаю на доклад "Jaggery.js — сладкие корпоративные решения", который пройдёт в рамках 15-го митапа MoscowJS 25 сентября 2014 года в офисе Mail.ru.

В программе знакомство с фреймворком от WSO2 и демонстрация подключения веб-сервиса.

Материалы к докладу

сайт Jaggery.js

сайт WSO2 User Engagement Server

слайды презентации

"Jaggery.js — сладкие корпоративные решения", Александр Новиков, MoscowJS 15 from MoscowJS

виртуальная машина VirtualBox (2,3Гб):
Яндекс диск
Google диск

Пользователь: jaggery
Пароль: jaggery

Запустить в терминале скрипты, указанные в файле README на рабочем столе:

Открыть браузер во весь экран и перейти к нужной закладке:

Дополнительно

как установить Jaggery.js на Ubuntu

Общие принципы установки:

1. Установить Java
2. Создать переменную JAVA_HOME
3. Добавить JAVA_HOME/bin к PATH
4. Загрузить и распаковать Jaggery.js
5. Запустить bin/server.sh или bin/server.bat

Короткая ссылка на эту страницу: bit.do/jaggery

Устанавливаем Jagggery.js на Ubuntu 14 x32

Самое главное правильно настроить путь к Java.

Потом всё просто:

1. скачиваем архив
2. распаковываем
3. запускаем Jaggery.js

В итоге имеем доступ через браузер к

1. простенькой панели администирования, 
2. документации и примерам,
3. нашим сайтам, созданным в директории apps

sudo apt-get update
sudo apt-get upgrade

# Java 7
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get clean
sudo apt-get update
sudo apt-get install oracle-java7-installer
# check Java installation
java -version
# get path to Java
sudo update-alternatives --config java
    /usr/lib/jvm/java-7-oracle/jre/bin/java
# define JAVA_HOME and add the binary directory to PATH
sudo nano /etc/environment
    JAVA_HOME="/usr/lib/jvm/java-7-oracle/jre"
    PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:$JAVA_HOME/bin"
# apply changes
sudo reboot


# WSO2 directory
cd ~
mkdir wso2
cd wso2

# Jaggery.js
wget -U Mozilla/5.0 http://dist.wso2.org/products/jaggery/dl/jaggery-0.9.0-SNAPSHOT_ALPHA3.zip
unzip jaggery-0.9.0-SNAPSHOT_ALPHA3.zip -d ./
sh ./jaggery-0.9.0-SNAPSHOT/bin/server.sh &

# see examples and docs at http://localhost:9763/
# enter user admin and password admin at https://10.0.2.15:9443/admin/carbon/
# create a directory for your site inside /home/jaggery/wso2/jaggery-0.9.0-SNAPSHOT/apps

Тук-тук ESB API

Для отладки последовательностей медиаторов нужен инструмент, который бы позволял "дёргать" WSO2 ESB в ручном режиме. Создадим простой API в сервисной шине предприятия, чтобы можно было отправлять запросы из адресной строки браузера.

Сначала создаём последовательность для поступающих в шину запросов. Последовательность - это своего рода контейнер для медиаторов.

Назовём создаваемую последовательность tuktukInSequence и сохраним её кнопкой Save.

Теперь поместим последовательность в реестр, чтобы впоследствии подключить нашу последовательность к ресурсу в API. Мы сможем работать с последовательностью отдельно, в отличие от встроенных (inline) в ресурс последовательностей. После настройки у нас будет возможность переподключить tuktukInSequence к какому-нибудь прокси-сервису или другому API.

Теперь наша последовательность tuktukInSequence присутствует и в реестре и в списке последовательностей. Причём в списке последовательностей она повторяется дважды. Важно понимать, что это два независимых экземпляра. Та, что нам нужна, начинается с conf:/

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

Называем наш API tuktuk. Задаём контекст /tuktuk. Все ссылки на этот путь URI будут отправляться в API tuktuk. Оттуда в ресурс add, а из ресурса в последовательность tuktukInSequence. Но мы забежали уже вперёд. Создадим прежде ресурс add.

Прокручиваем страницу вниз и видим форму настройки нового ресурса. Наш ресурс будет обрабатывать только GET-запросы. Адрес ресурса будет содержать два параметра, поэтому выбираем тип URL "URI-Template". Шаблон выглядит так:
/add/{xval}/{yval}/
Как я уже писал однобуквенное название параметра x приводило к нарушению работы пользовательского интерфейса, поэтому пишите больше букв. В медиаторах значение параметра извлекается выражением (expression):
get-property('uri.var.xval')

Теперь назначим последовательность для обработки входящих запросов. Возьмём tuktukInSequence из реестра.

Важно сначала нажать на кнопку Update для сохранения ресурса.

А только потом на кнопку Save для сохранения последовательности.

Ну вот всё готово! Можно пользоваться.

Для проверки работоспособности добавим в последовательность tuktukInSequence логирующий медиатор. В списке последовательностей находим tuktukInSequence и жмём на Edit:

Добавляем в последовательность медиатор Log.

Прокручиваем страницу вниз. Добавляем свойство xval.
 

Для простого теста работоспособности можно ограничится такими значениями полей: lalala, Value, uhuhuhu. Нажимаем на кнопку Update.

Затем сохраняем изменения последовательности кнопкой Save&Close.

Обращаемся к API из браузера:
http://192.168.4.67:8280/tuktuk/add/881/2888/

Видим сообщение в логе.

Значит, медиатор Log запускается.

Фасад пустоты и API вуду

С чего начать, если ничего нет? Конечно, со строительства фасада.

Строим фасад за которым ничего не стоит. Фасад пустоты.

Знаю два способа:

1. прокси-сервис (WSDL)
2. API (REST)

Чтобы сделать прокси-сервис, нужно

открыть Eclipse

создать проект Java

 

создать открытый класс

 

наполнить его методами, не заботясь о деталях реализации

экспортировать пакет в jar-файл

 

 

превратить JAR в WSDL в админке ESB

 

 

(в FireFox можно нажать Ctrl+u, чтобы без проблем скопировать этот XML)

 создать прокси-сервис по WSDL

 

 

на этом шаге создать входящую последовательность действий "In Sequence" или вставлить подготовленную заранее из реестра. Последовательность просто должна быть. Наполнить её медиаторами можно потом.

дойти до конца помощника, ничего больше не меняя

Теперь можно вносить изменения и наблюдать через "Try this service" или медиатор log

Вот насколько всё просто! Поэтому мне больше нравится создавать REST API. Но они тоже не лишины своего вуду. Например, если указать в шаблоне URI параметр x, то веб-интерфейс начинает глючить. Если написать xval, то работает, словно ни в чём не бывало.Или ещё пример. Из документации прямо не понятно, что для ресурсов нужно указывать относительные пути. Если указать от корня сайта, то увидишь белый лист, а медиаторы log не будут срабатывать.

P.S.
Чтобы не было проблем при заполнении последовательностей, нужно добавить в определение сервиса 2 параметра:

   <parameter name="modifyUserWSDLPortAddress">true</parameter>
   <parameter name="useOriginalwsdl">true</parameter>

https://docs.wso2.com/display/ESB481/Working+with+Proxy+Services