NexTool Solutions

Le regole di business sono il motore di automazione nativo di GLPI: senza una sola riga di codice, classificano, assegnano e applicano gli SLA a ogni ticket. Ciò che la documentazione spiega raramente - e ciò che genera più ticket di supporto quando si mantengono parchi GLPI di clienti - non è come creare una regola, ma il modello di valutazione che decide quale regola vince quando due si incrociano. Questa guida parte da dove la maggior parte dei tutorial si ferma: l'ordine, la condizione di attivazione e il concatenamento.

Il modello di valutazione che quasi nessuno legge prima della prima regola

Ogni regola di business dei ticket è del sottotipo RuleTicket e risiede nella tabella glpi_rules. Tre colonne governano il comportamento:

• ranking - l'ordine di valutazione. Il motore legge in ordine crescente, dal minore al maggiore. La schermata le mostra dall'alto verso il basso, ma è il numero a comandare.
• condition - quando la regola scatta: 1 alla creazione, 2 all'aggiornamento, 3 a entrambi. Una regola creata solo per 1 non si rivaluta mai quando il ticket viene modificato in seguito.
• match - la logica tra i criteri: AND (tutti devono corrispondere) o OR (uno qualsiasi).

Il dettaglio che frega la maggior parte: le regole dei ticket non si fermano alla prima corrispondenza. A differenza delle regole del collettore di posta e dell'importazione dell'inventario, il motore di RuleTicket percorre TUTTE le regole attive in ordine di ranking e usa l'uscita di una come ingresso della successiva. In altre parole, una regola generica con ranking più alto (valutata dopo) può sovrascrivere l'assegnazione di una regola specifica che aveva già corrisposto prima.

L'anatomia reale: criteri, azioni e operatori

Ogni regola ha tre blocchi. I criteri stanno in glpi_rulecriterias, le azioni in glpi_ruleactions:

• Criterio = criteria (il campo) + condition (l'operatore, numerico) + pattern (il valore atteso).
• Azione = action_type (assign, regex_result, append, fromuser, fromitem) + field (il campo da modificare) + value.

L'operatore è un codice numerico, non testo - e sceglierne uno sbagliato è il guasto silenzioso più comune. I valori in GLPI 11:

0  = è (corrispondenza esatta)
1  = non è
2  = contiene
3  = non contiene
4  = inizia con
5  = finisce con
6  = espressione regolare (regex)
7  = regex negata
8  = esiste
9  = non esiste
11 = sotto (albero di entità/categoria)
12 = non sotto

Campi reali che usi di più nell'azione: _groups_id_assign (gruppo tecnico), _users_id_assign (tecnico), slas_id_ttr (SLA di risoluzione), itilcategories_id (categoria) e urgency. Nel criterio, _mailgate identifica il ticket entrato tramite un collettore di posta specifico e _x-priority legge l'intestazione di priorità dell'email.

Checklist: una regola che scatta al primo tentativo

1. Definisci l'attivatore. Riclassificare alla creazione? Usa ONADD (condizione 1). Devi reagire a un cambio di categoria fatto dopo? Segna anche l'aggiornamento (condizione 3).
2. Scegli l'operatore giusto. "È" (0) richiede un titolo identico; per corrispondere a un frammento usa "contiene" (2) o regex (6). La maggior parte delle regole di titolo che "non prendono" ha usato "è" dove serviva "contiene".
3. Posiziona il ranking. Specifica prima, generica dopo - ma ricorda che la generica successiva sovrascrive. Se la generica non deve toccare ciò che è già stato deciso, restringi il suo criterio.
4. Controlla l'entità. Una regola creata in un'entità figlia senza il flag "ricorsiva" si applica solo ai ticket di quell'entità - e sparisce per il resto del parco.
5. Testa in preproduzione prima di attivare in produzione.
6. Convalida con Rule Inspector dentro un ticket reale: mostra quali regole sono state valutate, quali criteri sono passati e quali sono falliti.

SQL di diagnostica: cosa eseguiamo quando "la regola non funziona"

Prima di toccare l'interfaccia, NexTool scarica l'intero insieme di regole dei ticket in ordine di valutazione. In pochi secondi il ranking racconta la storia - quasi sempre è l'ordine o la condizione, non un criterio sbagliato. Eseguilo su una replica di lettura o con cautela sul database di produzione:

SELECT r.ranking,
       r.name,
       IF(r.is_active, 'attiva', 'INATTIVA') AS stato,
       r.match AS logica,
       CASE r.condition WHEN 1 THEN 'creazione'
                        WHEN 2 THEN 'aggiornamento'
                        WHEN 3 THEN 'creazione+aggiornamento'
       END AS scatta_quando,
       (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 criteri,
       (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 azioni
FROM glpi_rules r
WHERE r.sub_type = 'RuleTicket'
ORDER BY r.ranking;

Leggi dall'alto verso il basso: due righe che scrivono _groups_id_assign significano che vince quella con ranking più alto. Una riga con stato = INATTIVA spiega la "sparizione" della regola. scatta_quando = creazione spiega perché modificare il ticket non lo reinstrada.

Matrice decisionale: quale collezione di regole usare

GLPI ha diverse collezioni di regole, e ognuna si comporta in modo diverso. Confonderne una con l'altra è la radice di molti "perché questa regola gira due volte?":

Per un ticket che arriva via email, nota che due motori girano in sequenza: prima quello del collettore (si ferma alla prima corrispondenza), poi quello di business sul ticket già creato (le esegue tutte).

L'errore sul campo più comune

In manutenzione, il ticket che apriamo di più sulle regole è sempre lo stesso: "ho creato la regola e non prende". Nella stragrande maggioranza non è il criterio - è il modello di valutazione. Caso numero uno: due regole scrivono _groups_id_assign, quella specifica con ranking più basso corrisponde per prima, e una regola generica con ranking più alto, creata mesi dopo "solo per garantire un gruppo predefinito", sovrascrive tutto perché il motore concatena l'uscita. Caso due: la regola è stata creata solo con condition = 1 (solo alla creazione), quindi quando l'operatore cambia la categoria dopo, nulla viene reinstradato. Per questo abbiamo reso uno standard operativo eseguire sempre l'SQL di audit qui sopra PRIMA di toccare l'interfaccia: la colonna ranking rivela il conflitto in pochi secondi, mentre cliccare regola per regola sullo schermo nasconde il vero ordine di esecuzione. È il tipo di cosa che diventa ovvia solo quando gestisci decine di ambienti e vedi ripetersi lo stesso schema.

Ti serve un GLPI la cui automazione si comporta in modo prevedibile, senza regole che si pestano i piedi? La manutenzione NexTool verifica e riorganizza il tuo insieme di regole, e il plugin Rule Inspector mostra, dentro ogni ticket, esattamente quale regola ha deciso cosa.

Revisionato dal team NexTool Solutions.