Покрокова настройка веб-сервісів в OTRS 5 +10
- такий же як Forbes, тільки краще.
У цій статті розповім, як налаштувати веб-сервіс в OTRS 5, де і що вписати і як через SoapUI перевірити працездатність сервісу. Налаштовувати будемо SOAP, а не REST. Налаштовуємо OTRS як провайдера, тобто система буде за запитом передавати інформацію. Якщо зацікавило, то прошу під кат.
Отже, встановили ми чудовий OTRS, почали в ньому працювати. І тут керівництву потрібна звітність. І не якась, а вельми складна. Замість того, щоб глибоко пиляти внутрішні звіти, вирішили просто з системи по веб-сервісу забирати дані і в окремій програмі будувати звіти.
Отже, переходимо в адміністрування> веб-сервіси.
Створюємо новий веб сервіс:
1) Вписуємо назва інтерфейсу
2) Вибираємо мережевий транспорт HTTP :: SOAP
3) Тиснемо "Зберегти".
Після збереження є можливість вибрати Operations.
Нам потрібні були всього три для роботи з тікетами:
SessionCreate - дозволяє створити сесію і надалі використовувати її ID, а не передавати логін-пароль кожного разу.
TicketSearch - дозволяє знайти тікети за заданими критеріями (в нашому випадку відкриті і закриті за певний період). Повертає список ID тікетів (причому саме ID, а не номерів).
TicketGet - дозволяє по ID тікета отримати конкретний тікет (або кілька).
При створенні Operation ви вказуєте ім'я, по якому надалі будете її викликати.
І останній штрих - йдете в конфігурацію мережевого транспорту і задаєте простір імен і довжину повідомлення. Довжина 1000 нас цілком влаштувала.
Простір імен являє собою наступне посилання:
Де example.com - ваш домен, InterfaceName - ім'я вашого інтерфейсу. В разі встановлення шифрування, то https, а не http.
Все, з боку OTRS всі налаштування зроблені. Тепер як звернутися до сервісу зовні? Для цього ставимо SoapUI, беремо wsdl схему і віддаємо її в SoapUI.
В інтернеті багато хто скаржився, що OTRS сам не віддає WSDL схему, і це, насправді, проблема.
Спасибі добрим людям, які її виклали в загальний доступ.
Так що трошки переробляємо запропонований ними файл під нас.
В заголовки файлу GenericTicketConnectorSOAP.wsdl міняємо definitions name на ім'я вашого веб сервісу.
Далі у всіх soap: operation в soapAction міняєте http: //www.otrs.org/TicketConnector на ваш NameSpace.
І в самому кінці документа в wsdl: port вказуєте ваш NameSpace в location.
Запускаєте Soap UI, створюєте новий SOAPProject, вказуєте файл зі схемою.
В результаті має вийти щось на зразок такого. Базові запити SoapUI нагенерірует автоматично.
І фінальний акорд - перевірка працездатності сервісу. Сервіс повернув нам SessionID, який вже можна використовувати в інших запитах, не передаючи кожен раз логін і пароль.
1) Як вже говорилося, OTRS не віддає WSDL схему, що дуже незручно.
2) За запитом TicketSearch віддає не більше 500 ID-шників. Так що якщо вам повинно прийти понад 500, то все одно ви отримаєте тільки 500. Чи не знайшов, як це можна обійти.
3) Щоб в TicketGet віддавав SolutionDiffInMin (на скільки час вирішення заявки відрізняється від цільового по SLA), потрібно в запиті передати в Extended що-небудь.
P.S. з приводу того, що при пошуку віддавалася не більше 500 повідомлень допомогло збільшення параметра «GenericInterface :: Operation :: TicketSearch ### SearchLimit».
Спасибі eisaev за допомогу.