В этой статье расскажу, как настроить веб-сервис в 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 :)

P.S. по поводу того, что при поиске отдавалось не более 500 сообщений помогло увеличение параметра «GenericInterface::Operation::TicketSearch###SearchLimit».
Спасибо eisaev за помощь.
Поделиться с друзьями
-->

Комментарии (6)


  1. azomorth
    16.01.2017 00:14

    Собирался сегодня разобраться — почему отваливается прием заявок по почте, а тут такая хорошая статья.
    спасибо, буду сегодня еще и с вебсервисами разбираться.
    хотелось бы увидеть еще материалы на эту тему.


  1. eisaev
    16.01.2017 00:16
    +1

    По запросу TicketSearch отдает не более 500 ID-шников. Так что если вам должно прийти более 500, то все равно вы получите только 500. Не нашел, как это можно обойти.

    Думаю поможет увеличение параметра «GenericInterface::Operation::TicketSearch###SearchLimit»


    1. victor_2004
      16.01.2017 00:17

      Действительно помогло.
      Спасибо огроменное :)


  1. brestows
    16.01.2017 00:17

    У меня через web service настроена интеграция с Redmine а у redmine написан плагин для интеграции с OTRS. Очень удобное средство для интеграции, в особенности если знаешь Perl


    1. alprk
      16.01.2017 10:56

      а не могли бы поделиться, какую именно задачу у вас решает интеграция с redmine?


      1. brestows
        16.01.2017 12:03

        Простая интеграция, я как админ написал это для того что бы не ходить в OTRS, т.е. приходит заявка в OTRS, ей выставляется некий сервис, если сервис относится к сисадминам, то webservis OTRS используя API создает задачу в Redmie выставляет все необходимые поля, номер задачи, заказчика (кто автор запроса в отрс) компанию на которую работает заказчик и т.п., а так же на основании сервиса отправляет задачу в определенном проекте. Таким образом админ видит задачу в Redmine и если он в ней отвечает то плагин redmine уже отправляет комментарий в OTRS. OTRS в свою очередь обновляет задачу в Redmine если в OTRS кто-то что-то написал. Идет полноценная двухсторонняя синхронизация задачи в OTRS и в Redmie. Делали именно так, потому что интеграция на уровне почты не устраивает тем что все задачи валятся в один проект, потом их надо переносить и т.п. У меня принцип, что если что-то надо делать в ручну, то в группе более 2 — 3 людей это делаться не будет, поэтому и костылил вот таким образом