Покрокова налагодження веб-сервісів в OTRS 5

В цій статті розповім, як налаштувати веб-сервіс до OTRS 5, де і що вписати і як через SoapUI перевірити працездатність сервісу. Будемо налаштовувати SOAP, а не REST. Налаштовуємо OTRS як провайдера, тобто система буде за запитом віддавати дані. Якщо зацікавило, то прошу під кат.

<habracut/>

Отже, ми встановили чудовий 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 :).
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.