Тук-тук 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

Сервисна шина предприятия WSO2 ESB

Попробуем использовать шину для опосредования веб-сервисов. За основу возьмём урок, опубликованный на официальном сайте.

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

Наша задача отправить запрос на веб-сервис из пользовательского веб-интерфейса через шину ESB:

В настройках ESB мы создадим прокси-сервис. Он будет выполнять роль точки подключения веб-интерфейса. На сайте WSO2 находим такое определение прокси-сервиса:

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

Концевая точка (Endpoint) описывается такими словами:

Концевая точка содержит параметры внешнего пункта назначения для исходящего из шины сообщения.

Откроем в браузере панель администрирования сервисной шины предприятия и перейдём в пункт меню Manage -> Services -> Add -> Proxy Service:

Из перечисленных с правой стороны вариантов выберем "WSDL Based Proxy". Система создаст для нас и прокси-сервис, и концевую точку. При желании можно выбрать одну из концевых точек из реестра артефактов, но мы не будем этого делать. Заполним поля формы:

Данные берём из WSDL бизнес-процесса:

Получаем сообщение о том, что прокси-сервис успешно создан:

Находим наш сервис в списке и сразу переходим в Source View:

Чтобы избежать возникновения ошибки  "The endpoint reference (EPR) for the Operation not found" Добавляем параметр disableOperationValidation сразу после открывающего тэга <proxy>:






<parameter name="disableOperationValidation" locked="false">true</parameter>
 

(Читать про ошибку на Stackoverflow)



Сейчас мы перенаправим наш скрипт Jaggery с веб-сервиса BPS на его прокси в шине ESB. Берём ссылку из дэшборда созданного только что прокси-сервиса:

И вставляем его в код Jaggery:

<%

var x = request.getParameter("x");
var y = request.getParameter("y");
//var sum = parseInt(x) + parseInt(y);
var sum = add(parseInt(x), parseInt(y));

response.content = {
    success: true,
    data: {
        result: sum
    }
};

function add(x, y) {

    var ws = require("ws");

    var stub = new ws.WSStub("http://02-128:8280/services/BpmAdderProcessProxy?wsdl");

    var process = stub.services["BpmAdderProcessProxy"].operations["process"];

    var payloadTemplate = process.payloadXML();

    var payload = replaceQuestionMarks(payloadTemplate, arguments);

    var resultXml = process.request(payload);

    var resultValue = resultXml.children().text();

    return parseInt(resultValue);

}

function replaceQuestionMarks(template, values) {

    var i = 0;

    return template.replace(
        /\?/g,
        function() {
            return values[i++];
        }
    );

}

%>

Убеждаемся, что всё работает:

Итак, WSO2 ESB предоставляет удобный инструмент для быстрого проксирования веб-сервисов. Концевая точка создаётся автоматически. Главное, не забывать вклюключить определение вызываемого метода веб-сервиса по телу SOAP-запроса, как показано выше. Кстати в Design View этот параметр выглядит так: