Ранее я писал как можно настроить OTRS в роли провайдера. Это когда любая система может обратиться к OTRS и запросить данные.
Сейчас же я опишу, как произвести настройку OTRS в роли запрашивающего (requester). Когда в OTRS происходит какое-то событие и после этого идет обращение к внешней системе. А так же проблемы, с которыми столкнулся. Если заинтересовало, то прошу под кат.
Итак, установили мы замечательный OTRS, начали в нем работать. Но захотелось от системы большего. В нашем случае — интеграции с телеграм ботом. Кейс следующий: если приходит тикет от ВИП пользователя, то бот должен сразу проинформировать об этом ответственных лиц.
А для этого надо, чтобы система сама могла с ним общаться и сообщать о приходе таких тикетов.
В самом начале нам надо включить invoker. По умолчанию их всего два, и как сделать больше, я не разбирался. Для задачи и одного вполне хватает.
Для этого заходим в “Конфигурация системы” и далее ищем.
Edit Config Settings in GenericInterface -> GenericInterface::Invoker::ModuleRegistration
Просто включаем, ничего менять не надо.
Далее переходим в администрирование — > веб-сервисы.
Создаем новый веб сервис.
Вписываем название интерфейса
Выбираем сетевой транспорт HTTP::REST в блоке «OTRS как запрашивающий».
Жмем “Сохранить”.
После сохранения есть возможность выбрать Invoker и настроить транспорт.
Invoker у нас один, его и выбираем.
После добавления invoker вам сразу предложат его настроить.
Имя — тут все понятно
Дальше две мапы параметров. Я не уверен, что они в принципе работают, поэтому просто настроил пробрасывать как есть.
Триггер события — я выбрал по созданию тикета. Важно — не забудьте нажать плюсик. Только после этого ваш триггер добавится. Я минут 5 разбирался, почему после перезахода в настройки не видел своего триггера.
Триггер может быть синхронным и асинхронным. Если синхронный, то пока OTRS не получит ответ, вы не сможете дальше работать с тикетом. Асинхронный — OTRS отправит запрос в фоне.
Пример проблемы синхронных вызовов:
Настроили триггер на смену сервиса в тикете.
Открываем в тикете окно смены сервиса, меняем сервис.
Пока внешняя система не даст ответ, окно не закроется. Хотя должно закрываться сразу.
Далее настраиваем транспорт
Указываете адрес принимающей системы с портом. В следующей строке имя сервлета и TicketID. Согласно инструкции можно передавать еще и другие параметры от тикета, но у меня это не получилось. Поэтому все что мы имеем — номер тикета. Об этом чуть ниже.
На этом настройки закончены. При наступлении события наша внешняя система получила запрос.
За время настройки всплыло 2 момента:
Если у кого-то есть интересные замечания, комментарии — welcome :)
Сейчас же я опишу, как произвести настройку OTRS в роли запрашивающего (requester). Когда в OTRS происходит какое-то событие и после этого идет обращение к внешней системе. А так же проблемы, с которыми столкнулся. Если заинтересовало, то прошу под кат.
Итак, установили мы замечательный OTRS, начали в нем работать. Но захотелось от системы большего. В нашем случае — интеграции с телеграм ботом. Кейс следующий: если приходит тикет от ВИП пользователя, то бот должен сразу проинформировать об этом ответственных лиц.
А для этого надо, чтобы система сама могла с ним общаться и сообщать о приходе таких тикетов.
В самом начале нам надо включить invoker. По умолчанию их всего два, и как сделать больше, я не разбирался. Для задачи и одного вполне хватает.
Для этого заходим в “Конфигурация системы” и далее ищем.
Edit Config Settings in GenericInterface -> GenericInterface::Invoker::ModuleRegistration
Просто включаем, ничего менять не надо.
Далее переходим в администрирование — > веб-сервисы.
Создаем новый веб сервис.
Вписываем название интерфейса
Выбираем сетевой транспорт HTTP::REST в блоке «OTRS как запрашивающий».
Жмем “Сохранить”.
После сохранения есть возможность выбрать Invoker и настроить транспорт.
Invoker у нас один, его и выбираем.
После добавления invoker вам сразу предложат его настроить.
Имя — тут все понятно
Дальше две мапы параметров. Я не уверен, что они в принципе работают, поэтому просто настроил пробрасывать как есть.
Триггер события — я выбрал по созданию тикета. Важно — не забудьте нажать плюсик. Только после этого ваш триггер добавится. Я минут 5 разбирался, почему после перезахода в настройки не видел своего триггера.
Триггер может быть синхронным и асинхронным. Если синхронный, то пока OTRS не получит ответ, вы не сможете дальше работать с тикетом. Асинхронный — OTRS отправит запрос в фоне.
Пример проблемы синхронных вызовов:
Настроили триггер на смену сервиса в тикете.
Открываем в тикете окно смены сервиса, меняем сервис.
Пока внешняя система не даст ответ, окно не закроется. Хотя должно закрываться сразу.
Далее настраиваем транспорт
Указываете адрес принимающей системы с портом. В следующей строке имя сервлета и TicketID. Согласно инструкции можно передавать еще и другие параметры от тикета, но у меня это не получилось. Поэтому все что мы имеем — номер тикета. Об этом чуть ниже.
На этом настройки закончены. При наступлении события наша внешняя система получила запрос.
За время настройки всплыло 2 момента:
- Если у вас не отправляются запросы и в логах “Got no TicketNumber”, то вам нужно на сервере найти файл Test.pm и везде поменять “TicketNumber” на “TicketID”. В моем случае он лежал тут — /opt/otrs/Kernel/GenericInterface/Invoker/Test.
Спасибо этим ребятам за совет. - OTRS по наступлению события отправляет только id тикета. Заявлено, что можно передавать и другие параметры. Однако это так и не удалось. В результате при наступлении события внешняя система получает TicketID, и по нему сама обращается в OTRS за полной информацией. Ребята с форума приблизительно так же и поступили.Это плодит дополнительные обращения, но в нашем случае не критично.
Если у кого-то есть интересные замечания, комментарии — welcome :)
eisaev
Если посмотрите на функцию PrepareRequest в Test.pm, то можете увидеть какие именно параметры для запроса подготавливаются (по-умолчанию Ticket
NumberID, Action и SystemTime). Их можно использовать для запроса или дописать данную функцию для передачи нужным вам параметров.victor_2004 Автор
Ребята с форума пробовали
$ReturnData{Owner} = $Param{Data}=>{Owner};
Я пробовал
$ReturnData{CustomerID} = $Param{Data}=>{CustomerID};
Увы не помогло ни мне, ни им.
OTRS начал понимать, что CustomerID это переменная, но во внешнюю систему приходит пустое значение.
eisaev
Да. Судя по отладчику, invoker'у в принципе поступает только:
eisaev
В общем список полей для определённого события захардкожен. Например для событий по тикетам в Kernel/System/Ticket.pm. Вот например кусок для события TicketCreate:
И здесь действительно только TicketID. А вот например для события TicketStateUpdate:
И здесь действительно уже кроме TicketID передаётся ещё и объект OldTicketData: