В этой статье расскажу, как настроить веб-сервис в OTRS 5, где и что вписать и как через SoapUI проверить работоспособность сервиса. Настраивать будем SOAP, а не REST. Настраиваем OTRS как провайдера, т.е. система будет по запросу отдавать данные. Если заинтересовало, то прошу под кат.
Итак, установили мы замечательный OTRS, начали в нем работать. И тут руководству потребовалась отчетность. И не какая-то, а весьма сложная. Вместо того, чтобы глубоко пилить внутренние отчеты, решили просто с системы по веб-сервису забирать данные и в отдельной программе строить отчеты.
Итак, переходим в администрирование — > веб-сервисы.
Создаем новый веб сервис:
1) Вписываем название интерфейса
2) Выбираем сетевой транспорт HTTP::SOAP
3) Жмем “Сохранить”.
После сохранения есть возможность выбрать Operations.
Нам нужны были всего три для работы с тикетами:
SessionCreate — позволяет создать сессию и в дальнейшем использовать ее ID, а не передавать логин-пароль каждый раз.
TicketSearch — позволяет найти тикеты по заданным критериям (в нашем случае открытые и закрытые за определенный период). Возвращает список ID тикетов (причем именно ID, а не номеров).
TicketGet — позволяет по ID тикета получить конкретный тикет (либо несколько).
При создании Operation вы указываете имя, по которому в дальнейшем будете ее вызывать.
И последний штрих — идете в конфигурирование сетевого транспорта и задаете пространство имен и длину сообщения. Длина 1000 нас вполне устроила.
Пространство имен представляет собой следующую ссылку:
example.com/otrs/nph-genericinterface.pl/Webservice/InterfaceName
Где example.com — ваш домен, InterfaceName — имя вашего интерфейса.
Если настроено шифрование, то https, а не http.
Все, со стороны OTRS все настройки сделаны.
Теперь как обратиться к сервису снаружи? Для этого ставим SoapUI, берем wsdl схему и отдаем ее в SoapUI.
В интернете многие жаловались, что OTRS сам не отдает WSDL схему, и это, на самом деле, проблема.
Спасибо добрым людям, которые ее выложили в общий доступ.
github.com/OTRS/otrs/tree/master/development/webservices
Так что немножко переделываем предложенный ими файл под нас.
В заголовки файла GenericTicketConnectorSOAP.wsdl меняем definitions name на имя вашего веб сервиса.
<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions name="GenericTicketConnectorSOAP" targetNamespace="http://www.otrs.org/TicketConnector/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://www.otrs.org/TicketConnector/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"> <wsdl:documentation>Далее во всех soap:operation в soapAction меняете http: //www.otrs.org/TicketConnector на ваш NameSpace.
<soap:operation soapAction="http://www.otrs.org/TicketConnector/TicketCreate" />И в самом конце документа в wsdl:port указываете ваш NameSpace в location.
<wsdl:port name="GenericTicketConnector_Port" binding="tns:GenericTicketConnector_Binding">
<soap:address location="http://localhost/otrs/nph-genericinterface.pl/Webservice/GenericTicketConnectorSOAP" />
</wsdl:port>Запускаете Soap UI, создаете новый SOAPProject, указываете файл со схемой.
В результате должно получиться что-то вроде такого. Базовые запросы SoapUI нагенерирует автоматически.
И финальный аккорд — проверка работоспособности сервиса. Сервис вернул нам SessionID, который уже можно использовать в других запросах, не передавая каждый раз логин и пароль.
Некоторые нюансы:
1) Как уже говорилось, OTRS не отдает WSDL схему, что весьма неудобно.
2) По запросу TicketSearch отдает не более 500 ID-шников. Так что если вам должно прийти более 500, то все равно вы получите только 500. Не нашел, как это можно обойти.
3) Чтобы в TicketGet отдавал SolutionDiffInMin (на сколько время решения заявки отличается от целевого по SLA), нужно в запросе передать в Extended что-нибудь.
Если у кого-то есть интересные замечания, комментарии — welcome :).
Автор: victor_2004
