Двусторонняя интеграция между системами без собственных скриптов и внешнего middleware. Модуль Automations от NexTool превращает GLPI в хаб, способный принимать события от любой системы и автономно на них реагировать: приходит вебхук, данные сопоставляются, запускается действие — и всё это внутри вашей среды.
Проблема
Команды, работающие с множеством инструментов — мониторингом, ITSM, интернет-магазином, ERP, платформами наблюдаемости, — живут с разрывом между системами. Когда в Zabbix срабатывает алерт или в интернет-магазин приходит заказ, кто-то должен создать заявку в GLPI, заполнить поля и назначить ответственного. Каждое ручное вмешательство — точка отказа и источник задержек.
Универсальные решения вроде Zapier или Make справляются с простыми случаями, но требуют внешней учётной записи, берут плату за каждую операцию и находятся вне контроля команды. Для процессов, где нужны прослеживаемость, безопасность и глубокая интеграция с GLPI, решение должно жить внутри самой среды — и именно это даёт модуль Automations.
Как работает Automations
Модуль построен на трёх последовательных опорах:
- Вход (Trigger) — stateless-endpoint вебхука принимает POST-запросы от любой системы. У каждого сценария есть уникальный токен и аутентификация HMAC SHA-256, так что запускать действия могут только авторизованные источники.
- Обработка (PayloadMapper) — полученный JSON-payload сопоставляется через JSONPath. Преобразования вроде map_priority, resolve_user_by_email и resolve_category_by_name превращают внешние данные в нативные поля GLPI без кода.
- Выход (ActionRunner) — два типа действий: создать заявку в GLPI (с session impersonation, чтобы назначить правильного инициатора) или отправить HTTP-запрос во внешнюю систему через зарегистрированный коннектор.
Visual Flow Wizard позволяет собирать и редактировать сценарии в интерфейсе из трёх связанных карточек: Trigger, Сопоставление и Действие. Редактировать JSON вручную не нужно. Сценарии можно включать, выключать и отслеживать на панели. Модуль также управляет Коннекторами — десятки провайдеров, распределённых по категориям, с разными типами аутентификации (API Key, Bearer, Basic, OAuth2, HMAC) и учётными данными, хранящимися с шифрованием AES-256-GCM. Благодаря этому действие сценария выполняет аутентифицированные вызовы внешних API, таких как Microsoft 365, Jira, Slack или любой сервис с REST API.
Реальный сценарий: от payload до действия
Самый частый пример, который мы собираем, — превращение алерта мониторинга в заявку. Внешняя система отправляет POST, подписанный HMAC SHA-256, на endpoint сценария:
# Zabbix (or any system) fires a signed POST to the flow endpoint
curl -X POST 'https://glpi.yourcompany.com/plugins/nextool/automations/webhook/...token...' \
-H 'Content-Type: application/json' \
-d '{
"event": {
"host": "srv-db-01",
"severity": "High",
"trigger": "Disk space < 10%",
"requester": "[email protected]"
}
}'В карточке сопоставления каждый путь JSONPath становится нативным полем заявки. Преобразования переводят значения: «High» становится срочностью 4, e-mail — пользователем-инициатором:
$.event.trigger -> name (ticket title)
$.event.host -> content (description)
$.event.severity -> urgency (map_priority: High=4, Disaster=5)
$.event.requester -> _users_id_requester (resolve_user_by_email)Деталь, которую знают только те, кто эксплуатирует интеграции
В сопровождении классическая ошибка — внешняя система передаёт e-mail заявителя, но такого пользователя в GLPI нет. Без resolve_user_by_email с запасным вариантом заявка рождается «сиротой» или действие молча падает — и никто этого не замечает, пока не обнаружится пробел в истории. Мы стандартизировали технического инициатора по умолчанию (что-то вроде «integracao-automatica»), чтобы никогда не терять событие, а исходный e-mail оставляем в тексте заявки для отслеживания. Вторая деталь — подпись HMAC: обе стороны должны вычислять хеш строго от одного и того же сырого тела запроса. Прокси, который по пути пересериализует JSON, меняет один пробел, ломает подпись, и вебхук отклоняется с 401 — поэтому проверка выполняется по raw body, а не по уже повторно разобранному JSON. Кто этого не знает, часами ищет ошибку в ключе.
Нативный вход и что добавляет модуль
| Возможность | Нативный вебхук GLPI 11 | Модуль Automations от NexTool |
|---|---|---|
| Направление | Только исходящие (outbound) | Входящие и исходящие |
| Аутентификация входящих | Не применимо | Уникальный токен на сценарий + HMAC SHA-256 |
| Сопоставление payload | Не применимо | JSONPath + готовые преобразования |
| Создание заявки от имени правильного инициатора | Не применимо | Session impersonation |
| Аудит выполнения | Ограниченный | Input, output, длительность и статус по каждому запуску |
Как включить
- Установите плагин NexTool в GLPI.
- Откройте Настройки > NexTool > Модули.
- Найдите карточку Automations и нажмите Установить, затем Включить.
- Создайте сценарий в Visual Flow Wizard и скопируйте сгенерированный URL вебхука.
- Настройте внешнюю систему на отправку событий на этот URL с использованием токена и подписи HMAC.
Кому подходит (и когда нет)
Модуль подходит тем, кто работает в средах с множеством интегрированных инструментов: мониторингом (Zabbix, Grafana, Nagios), интернет-магазином, ERP, HR или любым сервисом, способным отправлять вебхуки. Особенно он ценен, когда процессы требуют прослеживаемости и аудита — каждый запуск фиксируется с input, output, длительностью и статусом. Он не предназначен для автоматизации того, что не спроектировано: если в вашем процессе создания заявок ещё не определены категория, срочность и ответственный, автоматизация лишь ускорит беспорядок. Сначала определите ручной процесс, затем автоматизируйте.
Совместимость
- GLPI: 11.0+
- Тариф: По запросу
- Плагин: NexTool 6.9.1 или новее
Следующий шаг
Модуль Automations входит в NexTool. Готовы избавиться от ручных вмешательств между вашими системами? Свяжитесь с командой, и мы спроектируем первый сценарий вместе с вами.
Проверено командой NexTool Solutions.
