Итак, установили мы замечательный 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 :)
P.S. по поводу того, что при поиске отдавалось не более 500 сообщений помогло увеличение параметра «GenericInterface::Operation::TicketSearch###SearchLimit».
Спасибо eisaev за помощь.
Комментарии (6)
eisaev
16.01.2017 00:16+1По запросу TicketSearch отдает не более 500 ID-шников. Так что если вам должно прийти более 500, то все равно вы получите только 500. Не нашел, как это можно обойти.
Думаю поможет увеличение параметра «GenericInterface::Operation::TicketSearch###SearchLimit»
brestows
16.01.2017 00:17У меня через web service настроена интеграция с Redmine а у redmine написан плагин для интеграции с OTRS. Очень удобное средство для интеграции, в особенности если знаешь Perl
alprk
16.01.2017 10:56а не могли бы поделиться, какую именно задачу у вас решает интеграция с redmine?
brestows
16.01.2017 12:03Простая интеграция, я как админ написал это для того что бы не ходить в OTRS, т.е. приходит заявка в OTRS, ей выставляется некий сервис, если сервис относится к сисадминам, то webservis OTRS используя API создает задачу в Redmie выставляет все необходимые поля, номер задачи, заказчика (кто автор запроса в отрс) компанию на которую работает заказчик и т.п., а так же на основании сервиса отправляет задачу в определенном проекте. Таким образом админ видит задачу в Redmine и если он в ней отвечает то плагин redmine уже отправляет комментарий в OTRS. OTRS в свою очередь обновляет задачу в Redmine если в OTRS кто-то что-то написал. Идет полноценная двухсторонняя синхронизация задачи в OTRS и в Redmie. Делали именно так, потому что интеграция на уровне почты не устраивает тем что все задачи валятся в один проект, потом их надо переносить и т.п. У меня принцип, что если что-то надо делать в ручну, то в группе более 2 — 3 людей это делаться не будет, поэтому и костылил вот таким образом
azomorth
Собирался сегодня разобраться — почему отваливается прием заявок по почте, а тут такая хорошая статья.
спасибо, буду сегодня еще и с вебсервисами разбираться.
хотелось бы увидеть еще материалы на эту тему.