NexTool Solutions

Geschäftsregeln sind die native Automatisierungs-Engine von GLPI: Ohne eine Zeile Code klassifizieren sie jedes Ticket, weisen es zu und wenden einen SLA an. Was die Dokumentation selten erklärt und was im Betrieb von GLPI-Installationen bei Kunden die meisten Support-Tickets erzeugt, ist nicht, wie man eine Regel anlegt, sondern welches Auswertungsmodell entscheidet, welche Regel gewinnt, wenn sich zwei überschneiden. Dieser Leitfaden beginnt dort, wo die meisten Tutorials aufhören: bei Reihenfolge, Auslösebedingung und Verkettung.

Ein Auswertungsmodell, welches kaum jemand vor der ersten Regel liest

Jede Geschäftsregel für Tickets ist vom Untertyp RuleTicket und liegt in der Tabelle glpi_rules. Drei Spalten steuern ihr Verhalten:

• ranking - die Reihenfolge der Auswertung. Die Engine liest in aufsteigender Reihenfolge, vom kleinsten zum größten Wert. Die Oberfläche zeigt sie von oben nach unten, aber maßgeblich ist die Zahl.
• condition - wann die Regel auslöst: 1 beim Erstellen, 2 beim Aktualisieren, 3 bei beidem. Eine nur für 1 angelegte Regel wird nie neu ausgewertet, wenn ein Ticket später bearbeitet wird.
• match - die Logik zwischen den Kriterien: AND (alle müssen zutreffen) oder OR (eines genügt).

Ein Detail, an welchem die meisten scheitern: Ticketregeln stoppen nicht beim ersten Treffer. Anders als die Regeln des E-Mail-Empfängers und des Inventarimports durchläuft die Engine von RuleTicket ALLE aktiven Regeln in der Reihenfolge des Rankings und verwendet die Ausgabe einer Regel als Eingabe der nächsten. Eine allgemeine Regel mit höherem Ranking (später ausgewertet) kann also die Zuweisung einer spezifischen Regel überschreiben, die zuvor bereits zugetroffen hatte.

Tatsächlicher Aufbau: Kriterien, Aktionen und Operatoren

Jede Regel hat drei Blöcke. Die Kriterien liegen in glpi_rulecriterias, die Aktionen in glpi_ruleactions:

• Kriterium = criteria (Feld) + condition (Operator, numerisch) + pattern (erwarteter Wert).
• Aktion = action_type (assign, regex_result, append, fromuser, fromitem) + field (zu änderndes Feld) + value.

Der Operator ist ein numerischer Code, kein Text, und die Wahl des falschen ist der häufigste stille Fehler. Die Werte in GLPI 11:

0  = is (exact match)
1  = is not
2  = contains
3  = does not contain
4  = begins with
5  = ends with
6  = regular expression (regex)
7  = regex does not match
8  = exists
9  = does not exist
11 = under (entity/category tree)
12 = not under

Tatsächliche Felder, die Sie in Aktionen am häufigsten verwenden: _groups_id_assign (Technikergruppe), _users_id_assign (Techniker), slas_id_ttr (SLA für die Lösung), itilcategories_id (Kategorie) und urgency. In Kriterien identifiziert _mailgate ein Ticket, welches über einen bestimmten E-Mail-Empfänger eingegangen ist, und _x-priority liest den Prioritäts-Header der E-Mail.

Checkliste: eine Regel, die auf Anhieb auslöst

1. Legen Sie den Auslöser fest. Soll beim Erstellen neu klassifiziert werden? Verwenden Sie ONADD (Bedingung 1). Muss auf eine spätere Änderung der Kategorie reagiert werden? Markieren Sie zusätzlich die Aktualisierung (Bedingung 3).
2. Wählen Sie den richtigen Operator. „ist“ (0) verlangt einen identischen Titel; für Treffer auf Teilstücke verwenden Sie „enthält“ (2) oder Regex (6). Die meisten Titelregeln, die „nicht greifen“, verwenden „ist“, wo „enthält“ nötig gewesen wäre.
3. Setzen Sie ein passendes Ranking. Spezifische zuerst, allgemeine danach, aber denken Sie daran, dass die spätere allgemeine überschreibt. Wenn die allgemeine nicht an bereits Entschiedenem rühren soll, schränken Sie ihr Kriterium ein.
4. Prüfen Sie die Einheit. Eine in einer untergeordneten Einheit angelegte Regel ohne die Option „rekursiv“ gilt nur für die Tickets jener Einheit und fehlt für den Rest der Installation.
5. Testen Sie in einer Testumgebung, bevor Sie in Produktion aktivieren.
6. Validieren Sie mit Rule Inspector innerhalb eines echten Tickets: Er zeigt, welche Regeln ausgewertet wurden, welche Kriterien zutrafen und welche nicht.

Diagnose-SQL: was wir ausführen, wenn „die Regel nicht funktioniert“

Bevor wir die Oberfläche anfassen, gibt NexTool den gesamten Satz an Ticketregeln in der Reihenfolge der Auswertung aus. In Sekunden erzählt ranking die Geschichte: Fast immer liegt es an Reihenfolge oder Bedingung, nicht an einem falschen Kriterium. Führen Sie es auf einem Lese-Replikat oder mit Vorsicht auf der Produktionsdatenbank aus:

SELECT r.ranking,
       r.name,
       IF(r.is_active, 'active', 'INACTIVE') AS state,
       r.match AS logic,
       CASE r.condition WHEN 1 THEN 'on_create'
                        WHEN 2 THEN 'on_update'
                        WHEN 3 THEN 'create+update'
       END AS fires_when,
       (SELECT GROUP_CONCAT(
                 CONCAT(c.criteria, ' [op ', c.condition, '] ', c.pattern)
                 ORDER BY c.id SEPARATOR ' | ')
          FROM glpi_rulecriterias c WHERE c.rules_id = r.id) AS criteria,
       (SELECT GROUP_CONCAT(
                 CONCAT(a.action_type, ':', a.field, '=', a.value)
                 ORDER BY a.id SEPARATOR ' | ')
          FROM glpi_ruleactions a WHERE a.rules_id = r.id) AS actions
FROM glpi_rules r
WHERE r.sub_type = 'RuleTicket'
ORDER BY r.ranking;

Lesen Sie von oben nach unten: Zwei Zeilen, die _groups_id_assign schreiben, bedeuten, dass jene mit höherem ranking gewinnt. Eine Zeile mit state = INACTIVE erklärt das „Verschwinden“ der Regel. fires_when = on_create erklärt, warum die Bearbeitung eines Tickets es nicht neu routet.

Entscheidungsmatrix: welche Regelsammlung Sie verwenden sollten

GLPI hat mehrere Regelsammlungen, und jede verhält sich anders. Sie zu verwechseln, ist die Wurzel vieler Fragen wie „Warum läuft diese Regel zweimal?“:

Beachten Sie bei einem Ticket, welches per E-Mail eingeht, dass zwei Engines nacheinander laufen: zuerst die des Empfängers (stoppt beim ersten Treffer), danach die Geschäftsregeln auf dem bereits erstellten Ticket (führt alle aus).

Der häufige Praxisfehler

Im Betrieb ist ein Ticket zu Regeln immer dasselbe: „Ich habe die Regel angelegt, und sie greift nicht.“ In der überwältigenden Mehrheit liegt es nicht am Kriterium, sondern am Auswertungsmodell. Fall Nummer eins: Es gibt zwei Regeln, die _groups_id_assign schreiben; die spezifische mit kleinerem Ranking trifft zuerst zu, und eine allgemeine Regel mit höherem Ranking, Monate später angelegt, „nur um eine Standardgruppe sicherzustellen“, überschreibt alles, weil die Engine die Ausgabe verkettet. Fall zwei: Die Regel wurde nur mit condition = 1 (nur beim Erstellen) angelegt, sodass nichts neu geroutet wird, wenn der Bearbeiter später die Kategorie ändert. Deshalb haben wir als Betriebsstandard festgelegt, immer zuerst obiges Audit-SQL auszuführen, BEVOR wir die Oberfläche anfassen: Die Spalte ranking zeigt den Konflikt in Sekunden, während Klicken von Regel zu Regel auf dem Bildschirm die tatsächliche Ausführungsreihenfolge verbirgt. Solche Dinge werden erst offensichtlich, wenn man Dutzende Umgebungen betreibt und dasselbe Muster sich wiederholen sieht.

Brauchen Sie ein GLPI, dessen Automatisierung sich vorhersehbar verhält, ohne Regeln, die sich gegenseitig überfahren? Der Betriebsservice von NexTool prüft und ordnet Ihren Regelsatz neu, und Plugin Rule Inspector zeigt in jedem Ticket genau, welche Regel was entschieden hat.

Geprüft vom Team von NexTool Solutions.