NexTool Solutions

Manche Prozesse erzeugen immer ein Folgeticket – und jedes Mal, wenn dieser Schritt vergessen wird, scheitert der Prozess lautlos. Ticket Flow von NexTool macht aus dieser Verkettung eine Automatisierung: Erfüllt ein Ticket ein Kriterium, erstellt es ein Folgeticket auf Basis einer nativen GLPI-Vorlage, ohne menschliches Eingreifen.

Ausgangslage

Viele Ticketkategorien folgen immer demselben Ablauf. Wird ein Ticket „Beauftragung einer Dienstleistung“ erstellt, sollte automatisch ein Ticket „Finanzielle Genehmigung“ entstehen. Wird ein Ticket „Wartung“ gelöst, sollte eine „Qualitätsumfrage“ folgen. Im Standard-GLPI geschieht diese Orchestrierung im Gedächtnis des Technikers – wenn er daran denkt. Ergebnis ist bekannt: übersprungene Schritte, unvollständige Prozesse und unmögliche Audits, weil es keinen Nachweis über Teilprozesse gibt, die hätten eröffnet werden sollen.

Seien wir ehrlich, was GLPI bereits kann. Geschäftsregeln für Tickets (RuleTicket) eignen sich hervorragend zum Routen, Zuweisen und Kategorisieren – aber sie wirken auf ein Ticket, welches gerade erstellt oder aktualisiert wird. Keine native Regel erstellt aus einem Ticket ein neues. Genau diese Lücke schließt Ticket Flow.

So funktioniert Ticket Flow

Ticket Flow erlaubt es, Abläufe zu konfigurieren, die die Erstellung eines neuen Tickets auslösen, wenn ein ursprüngliches Ticket ein Kriterium erfüllt. Jeder Ablauf ist an eine ITIL-Kategorie und ein auslösendes Ereignis gebunden und verwendet native Ticketvorlagen von GLPI, um ein Folgeticket zu erzeugen:

• 3 konfigurierbare Auslöser – Ticket erstellt, Ticket gelöst und Ticket geschlossen. Eine Kategorie kann mehrere Abläufe haben, auch für denselben Auslöser, ausgeführt in der jeweils festgelegten Reihenfolge.
• Integration mit TicketTemplate – ein Kind-Ticket entsteht aus einer nativen GLPI-Vorlage und übernimmt Kategorie, Titel, Beschreibung, Gruppen und Priorität, die in der Vorlage bereits konfiguriert sind.
• Ausführung über native Hooks – die Ausführung erfolgt automatisch über die Hooks item_add und item_update von Ticket, ohne Cron und ohne manuelle Aktion.
• Schleifenschutz – ein interner Mechanismus verhindert, dass ein erzeugtes Ticket in derselben Operation einen weiteren Ablauf auslöst, und beseitigt so ein Risiko endloser Rekursion.
• Ausführungslog – jede Auslösung wird mit Link zum ursprünglichen und zum erzeugten Ticket protokolliert, für vollständige Nachvollziehbarkeit.
• Testreiter – Sie können direkt in der Konfigurationsansicht ein Testticket aus einer Vorlage erstellen, bevor Sie einen Ablauf für die Produktion freigeben. Achtung: Der Test erstellt ein echtes Ticket und erfordert eine eigene Berechtigung.

Warum die Ticketvorlage das Herzstück eines Ablaufs ist

Da ein Kind-Ticket aus einem TicketTemplate erzeugt wird, hängt die Qualität eines Ablaufs vollständig davon ab, wie die Vorlage ausgefüllt ist. Bevor Sie einen Ablauf produktiv setzen, lohnt es sich, die vordefinierten Felder Ihrer Vorlagen zu prüfen. Die folgende Abfrage listet Ticketvorlagen und ihre vordefinierten Felder – ist ein Gruppen- oder Zuständigkeitsfeld leer, entsteht ein verwaistes Kind-Ticket:

-- Modelos de chamado e seus campos predefinidos.
-- O Ticket Flow copia esses valores no chamado filho.
-- Campo essencial em branco (grupo/responsavel) = filho orfao.
SELECT tt.id            AS modelo_id,
       tt.name          AS modelo,
       tp.num           AS campo_num,
       tp.value         AS valor_predefinido
FROM glpi_tickettemplates tt
LEFT JOIN glpi_tickettemplatepredefinedfields tp
       ON tp.tickettemplates_id = tt.id
ORDER BY tt.name, tp.num;

Jede Zeile ist ein vordefiniertes Feld der Vorlage. Der Wert von num ist eine Suchoption von GLPI (Titel, Kategorie, Anforderergruppe, zugewiesene Gruppe, Priorität). Eine Vorlage ohne zugewiesene Gruppe erzeugt ein Kind-Ticket, welches niemand in seiner Warteschlange sieht – und ein Prozess stockt genau dort, wo er weitergehen sollte.

Ticket Flow vs. native Funktionen von GLPI

So aktivieren Sie es

1. Installieren Sie ein NexTool-Plugin in Ihrem GLPI.
2. Öffnen Sie Einstellungen > NexTool > Module.
3. Aktivieren Sie Ticket Flow und klicken Sie auf Konfigurieren.
4. Erstellen Sie im Reiter Abläufe einen Ablauf, indem Sie Kategorie, Auslöser und Vorlage für ein Kind-Ticket wählen.
5. Validieren Sie die Vorlage im Testreiter, bevor Sie einen Ablauf aktiv lassen: Es gibt keinen separaten Schalter für die Ausführung, und bei aktivem Modul läuft jeder aktive Ablauf bereits.

Für wen es geeignet ist – und wann nicht

Ticket Flow ist für Teams mit strukturierten Prozessen gedacht, in denen die Erstellung eines Tickets Voraussetzung für den Beginn eines anderen ist: Änderungsmanagement, Beauftragungen, Projekte und Qualitätsprozesse, bei denen ein vergessener Schritt echte Auswirkungen auf Betrieb und Audit hat.

Nicht geeignet ist es, wenn Sie Aufgaben innerhalb desselben Tickets verketten müssen (dafür gibt es Abläufe für Unteraufgaben), oder wenn es lediglich darum geht, ein Ticket selbst zuzuweisen oder zu kategorisieren – dies lösen native Geschäftsregeln bereits. Ticket Flow gewinnt gerade dann an Wert, wenn ein Prozess ein weiteres Ticket mit eigenem Verantwortlichen und eigener Frist erzeugen muss.

Was wir im Betrieb gelernt haben

Im Betrieb liegt der häufigste Fehler bei Ticket Flow nie in der Ausführung, sondern in einer Vorlage für Kind-Tickets ohne zugewiesene Gruppe – ein Kind-Ticket entsteht ohne Verantwortlichen und verschwindet aus der Warteschlange. Der zweite war die alte Regel von einem aktiven Ablauf pro Kategorie, durch die zwei Prozesse derselben Kategorie um denselben Platz konkurrierten; seit Version 2.0 akzeptiert eine Kategorie mehrere Abläufe, ausgeführt in der jeweils festgelegten Reihenfolge. Der dritte ist der tückischste: Der Auslöser „geschlossen“ greift auch, wenn GLPI ein Ticket von selbst schließt, durch die Routine zur automatischen Schließung bei Inaktivität (Cron autoclose). Wir haben erlebt, dass ein Kunde morgens eine Reihe nachts erstellter Kind-Tickets vorfand, weil ein Stapel alter Tickets durch diese Routine geschlossen wurde und jede Schließung einen Ablauf auslöste. Unsere standardisierte Empfehlung: Reservieren Sie den Auslöser „geschlossen“ für Prozesse, die wirklich beim Abschluss laufen sollen, bevorzugen Sie „gelöst“, wenn Sie auf die Lösung reagieren wollen, und validieren Sie eine Vorlage für Kind-Tickets immer im Testreiter, bevor Sie einen Ablauf aktivieren.

Kompatibilität

• GLPI: 11
• Plan: PAID
• Plugin: NexTool-Basis 6.11.0 oder höher

Ticket Flow ist Teil von NexTool, einem Ökosystem von Modulen, um GLPI ohne Code-Anpassungen zu erweitern. Sprechen Sie mit unserem Team für eine Demonstration.

Geprüft vom Team der NexTool Solutions.