NexTool Solutions

Bidirektionale Integration zwischen Systemen, ohne individuelles Skript und ohne externe Middleware. Das Modul Automations von NexTool macht GLPI zu einem Hub, der Ereignisse aus beliebigen Systemen empfangen und autonom darauf reagieren kann – der Webhook kommt an, die Daten werden gemappt und eine Aktion wird ausgelöst, alles innerhalb der eigenen Umgebung.

Das Problem

Teams, die mehrere Werkzeuge betreiben – Monitoring, ITSM, E-Commerce, ERP, Observability-Plattformen –, leben mit der Lücke zwischen den Systemen. Wenn in Zabbix ein Alarm ausgelöst wird oder im E-Commerce eine Bestellung eingeht, muss jemand das Ticket in GLPI erstellen, Felder ausfüllen und einen Verantwortlichen zuweisen. Jeder manuelle Eingriff ist eine Fehlerquelle und eine Ursache für Verzögerungen.

Generische Lösungen wie Zapier oder Make lösen einfache Fälle, erfordern aber ein externes Konto, rechnen pro Vorgang ab und liegen außerhalb der Kontrolle des Teams. Für Betriebe, die Nachvollziehbarkeit, Sicherheit und eine tiefe Integration mit GLPI brauchen, muss die Lösung in der eigenen Umgebung liegen – und genau das liefert das Modul Automations.

So funktioniert Automations

Das Modul arbeitet mit drei verketteten Säulen:

• Eingang (Trigger) – ein zustandsloser Webhook-Endpunkt empfängt POST-Anfragen aus beliebigen Systemen. Jeder Flow hat ein eindeutiges Token und eine HMAC-SHA-256-Authentifizierung, sodass nur autorisierte Quellen Aktionen auslösen.
• Verarbeitung (PayloadMapper) – das empfangene JSON-Payload wird mit JSONPath gemappt. Transformationen wie map_priority, resolve_user_by_email und resolve_category_by_name wandeln externe Daten ohne Code in native GLPI-Felder um.
• Ausgang (ActionRunner) – zwei Aktionstypen: ein Ticket in GLPI erstellen (mit Session Impersonation, um den richtigen Anforderer zuzuweisen) oder eine HTTP-Anfrage an ein externes System über einen hinterlegten Connector senden.

Ein Visual Flow Wizard ermöglicht es, Flows in einer Oberfläche mit drei verbundenen Karten zu erstellen und zu bearbeiten: Trigger, Mapping und Aktion. JSON muss nicht von Hand bearbeitet werden. Flows lassen sich im Dashboard aktivieren, deaktivieren und überwachen. Das Modul verwaltet außerdem Connectoren – Dutzende nach Kategorie geordnete Anbieter, mit verschiedenen Authentifizierungsarten (API Key, Bearer, Basic, OAuth2, HMAC) und mit AES-256-GCM verschlüsselt gespeicherten Zugangsdaten. So führt eine Flow-Aktion authentifizierte Aufrufe an externe APIs wie Microsoft 365, Jira, Slack oder jeden Dienst mit REST-API aus.

Ein echter Flow, vom Payload zur Aktion

Das häufigste Beispiel, das wir aufbauen, ist die Umwandlung eines Monitoring-Alarms in ein Ticket. Das externe System sendet einen mit HMAC SHA-256 signierten POST an den Endpunkt des Flows:

# 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]"
    }
  }'

In der Mapping-Karte wird jeder JSONPath-Pfad zu einem nativen Feld des Tickets. Die Transformationen übersetzen die Werte – „High“ wird zu Dringlichkeit 4, die E-Mail-Adresse wird zum anfordernden Benutzer:

$.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)

Das Detail, das nur kennt, wer Integrationen betreibt

Im Betrieb ist der klassische Fehler, dass das externe System die E-Mail-Adresse des Anfragenden sendet, diese aber nicht als Benutzer in GLPI existiert. Ohne ein resolve_user_by_email mit Plan B entsteht das Ticket verwaist, oder die Aktion schlägt stillschweigend fehl – und niemand bemerkt es, bis Historie fehlt. Wir haben einen technischen Fallback-Anforderer standardisiert (etwa „auto-integration“), damit nie ein Ereignis verloren geht, und lassen die ursprüngliche E-Mail-Adresse zur Nachverfolgung im Text des Tickets. Das zweite Detail ist die HMAC-Signatur: Beide Seiten müssen den Hash über exakt denselben Rohinhalt berechnen. Ein Proxy, der das JSON unterwegs neu serialisiert, ändert ein Leerzeichen, bricht die Signatur, und der Webhook wird mit 401 abgelehnt – deshalb erfolgt die Validierung über den Raw Body, nicht über das bereits neu geparste JSON. Wer das nicht weiß, verliert Stunden mit der Annahme, der Schlüssel sei falsch.

Nativer Eingang vs. was das Modul ergänzt

So aktivieren Sie es

1. Installieren Sie das NexTool-Plugin in GLPI.
2. Öffnen Sie Einrichtung > NexTool > Module.
3. Suchen Sie die Karte Automations und klicken Sie auf Installieren, danach auf Aktivieren.
4. Erstellen Sie einen Flow mit dem Visual Flow Wizard und kopieren Sie die erzeugte Webhook-URL.
5. Konfigurieren Sie das externe System so, dass es die Ereignisse an diese URL sendet, mit dem Token und der HMAC-Signatur.

Für wen es geeignet ist (und wann nicht)

Es eignet sich für Betriebe mit mehreren integrierten Werkzeugen: Monitoring (Zabbix, Grafana, Nagios), E-Commerce, ERP, HR oder jeden Dienst, der Webhooks auslösen kann. Besonders wertvoll ist es, wenn der Betrieb Nachvollziehbarkeit und Audit verlangt – jede Ausführung wird mit Input, Output, Dauer und Status protokolliert. Es ist nicht dafür gedacht, etwas zu automatisieren, das nicht konzipiert ist: Hat Ihr Prozess zur Ticketerstellung noch keine festgelegte Kategorie, Dringlichkeit und Zuständigkeit, beschleunigt die Automatisierung nur das Chaos. Definieren Sie zuerst den manuellen Ablauf, automatisieren Sie danach.

Kompatibilität

• GLPI: 11.0+
• Plan: Auf Anfrage
• Plugin: NexTool 6.9.1 oder höher

Nächster Schritt

Das Modul Automations ist Teil von NexTool. Bereit, die manuellen Eingriffe zwischen Ihren Systemen abzuschaffen? Sprechen Sie mit dem Team, und wir konzipieren den ersten Flow gemeinsam mit Ihnen.

Geprüft vom Team von NexTool Solutions.