NexTool Solutions

Les règles métier sont le moteur d'automatisation natif de GLPI : sans une seule ligne de code, elles classent, affectent et appliquent des SLA à chaque ticket. Ce que la documentation explique rarement - et ce qui génère le plus de tickets de support lorsqu'on maintient des parcs GLPI de clients - n'est pas comment créer une règle, mais le modèle d'évaluation qui décide quelle règle l'emporte quand deux se croisent. Ce guide commence là où la plupart des tutoriels s'arrêtent : l'ordre, la condition de déclenchement et le chaînage.

Le modèle d'évaluation que presque personne ne lit avant sa première règle

Toute règle métier de ticket est du sous-type RuleTicket et réside dans la table glpi_rules. Trois colonnes gouvernent le comportement :

• ranking - l'ordre d'évaluation. Le moteur lit en ordre croissant, du plus petit au plus grand. L'écran les affiche de haut en bas, mais c'est le numéro qui commande.
• condition - quand la règle se déclenche : 1 à la création, 2 à la mise à jour, 3 aux deux. Une règle créée pour 1 seulement ne se réévalue jamais quand le ticket est modifié ensuite.
• match - la logique entre critères : AND (tous doivent correspondre) ou OR (n'importe lequel).

Le détail qui piège la plupart des gens : les règles de ticket ne s'arrêtent pas à la première correspondance. Contrairement aux règles du collecteur de courriel et de l'import d'inventaire, le moteur de RuleTicket parcourt TOUTES les règles actives dans l'ordre de ranking et utilise la sortie de l'une comme entrée de la suivante. Autrement dit, une règle générique avec un ranking plus élevé (évaluée plus tard) peut écraser l'affectation d'une règle spécifique qui avait déjà correspondu avant.

L'anatomie réelle : critères, actions et opérateurs

Chaque règle a trois blocs. Les critères sont dans glpi_rulecriterias, les actions dans glpi_ruleactions :

• Critère = criteria (le champ) + condition (l'opérateur, numérique) + pattern (la valeur attendue).
• Action = action_type (assign, regex_result, append, fromuser, fromitem) + field (le champ à modifier) + value.

L'opérateur est un code numérique, pas du texte - et choisir le mauvais est l'échec silencieux le plus courant. Les valeurs dans GLPI 11 :

0  = est (correspondance exacte)
1  = n'est pas
2  = contient
3  = ne contient pas
4  = commence par
5  = termine par
6  = expression régulière (regex)
7  = regex non satisfaite
8  = existe
9  = n'existe pas
11 = sous (arbre d'entité/catégorie)
12 = pas sous

Champs réels que vous utilisez le plus en action : _groups_id_assign (groupe technique), _users_id_assign (technicien), slas_id_ttr (SLA de résolution), itilcategories_id (catégorie) et urgency. En critère, _mailgate identifie le ticket entré par un collecteur de courriel spécifique et _x-priority lit l'en-tête de priorité du courriel.

Liste de contrôle : une règle qui se déclenche du premier coup

1. Définissez le déclencheur. Reclasser à la création ? Utilisez ONADD (condition 1). Besoin de réagir à un changement de catégorie fait ensuite ? Cochez aussi la mise à jour (condition 3).
2. Choisissez le bon opérateur. « Est » (0) exige un titre identique ; pour correspondre par fragment, utilisez « contient » (2) ou regex (6). La plupart des règles de titre qui « n'attrapent pas » ont utilisé « est » là où il fallait « contient ».
3. Positionnez le ranking. Spécifique d'abord, générique ensuite - mais rappelez-vous que la générique postérieure écrase. Si la générique ne doit pas toucher ce qui est déjà décidé, restreignez son critère.
4. Vérifiez l'entité. Une règle créée dans une entité fille sans l'indicateur « récursive » ne s'applique qu'aux tickets de cette entité - et disparaît pour le reste du parc.
5. Testez en préproduction avant d'activer en production.
6. Validez avec Rule Inspector dans un ticket réel : il montre quelles règles ont été évaluées, quels critères sont passés et lesquels ont échoué.

SQL de diagnostic : ce que nous lançons quand « la règle ne fonctionne pas »

Avant de toucher à l'interface, NexTool exporte l'ensemble complet des règles de ticket dans l'ordre d'évaluation. En quelques secondes, le ranking raconte l'histoire - c'est presque toujours l'ordre ou la condition, pas un critère erroné. Lancez-le sur une réplique de lecture ou avec prudence sur la base de production :

SELECT r.ranking,
       r.name,
       IF(r.is_active, 'active', 'INACTIVE') AS etat,
       r.match AS logique,
       CASE r.condition WHEN 1 THEN 'creation'
                        WHEN 2 THEN 'mise_a_jour'
                        WHEN 3 THEN 'creation+mise_a_jour'
       END AS declenche_quand,
       (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 criteres,
       (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;

Lisez de haut en bas : deux lignes qui écrivent _groups_id_assign signifient que celle au ranking le plus élevé l'emporte. Une ligne avec etat = INACTIVE explique la « disparition » de la règle. declenche_quand = creation explique pourquoi modifier le ticket ne le réachemine pas.

Matrice de décision : quelle collection de règles utiliser

GLPI possède plusieurs collections de règles, et chacune se comporte différemment. Les confondre est la racine de nombreux « pourquoi cette règle s'exécute-t-elle deux fois ? » :

Pour un ticket qui arrive par courriel, notez que deux moteurs s'exécutent en séquence : d'abord celui du collecteur (s'arrête à la première correspondance), puis celui du métier sur le ticket déjà créé (les exécute toutes).

L'erreur de terrain la plus courante

En maintenance, le ticket que nous ouvrons le plus au sujet des règles est toujours le même : « j'ai créé la règle et elle n'attrape pas ». Dans l'immense majorité, ce n'est pas le critère - c'est le modèle d'évaluation. Cas numéro un : deux règles écrivent _groups_id_assign, la spécifique au ranking plus bas correspond en premier, et une règle générique au ranking plus élevé, créée des mois plus tard « juste pour garantir un groupe par défaut », écrase tout parce que le moteur chaîne la sortie. Cas deux : la règle a été créée avec condition = 1 uniquement (à la création), donc lorsque l'agent change la catégorie ensuite, rien n'est réacheminé. C'est pourquoi nous avons fait une norme d'exploitation de toujours lancer le SQL d'audit ci-dessus AVANT de toucher à l'interface : la colonne ranking révèle le conflit en quelques secondes, alors que cliquer règle par règle à l'écran masque l'ordre réel d'exécution. C'est le genre de chose qui ne devient évident que lorsqu'on exploite des dizaines d'environnements et qu'on voit le même schéma se répéter.

Besoin d'un GLPI dont l'automatisation se comporte de façon prévisible, sans règles qui se marchent dessus ? La maintenance NexTool audite et réorganise votre jeu de règles, et le plugin Rule Inspector montre, dans chaque ticket, exactement quelle règle a décidé quoi.

Révisé par l'équipe NexTool Solutions.