NexTool Solutions

As regras de negócio são o motor de automação nativo do GLPI: sem uma linha de código, classificam, atribuem e aplicam SLA a cada chamado. O que a documentação raramente explica - e o que mais gera pedidos de suporte na sustentação de parques GLPI de clientes - não é como criar uma regra, mas o modelo de avaliação que decide qual regra vence quando duas se cruzam. Este guia começa onde a maioria dos tutoriais para: a ordem, a condição de disparo e o encadeamento.

O modelo de avaliação que quase ninguém lê antes da primeira regra

Toda a regra de negócio de chamado é do subtipo RuleTicket e reside na tabela glpi_rules. Três colunas comandam o comportamento:

• ranking - a ordem de avaliação. O motor lê por ordem crescente, do menor para o maior. O ecrã mostra de cima para baixo, mas quem manda é o número.
• condition - quando a regra dispara: 1 na criação, 2 na atualização, 3 em ambas. Uma regra criada apenas para 1 nunca reavalia quando o chamado é editado mais tarde.
• match - a lógica entre critérios: AND (todos têm de bater) ou OR (qualquer um).

O detalhe que apanha a maioria: as regras de chamado não param na primeira correspondência. Ao contrário das regras do coletor de correio e da importação de inventário, o motor de RuleTicket percorre TODAS as regras ativas por ordem de ranking e usa a saída de uma como entrada da seguinte. Ou seja, uma regra genérica com ranking maior (avaliada depois) pode sobrepor-se à atribuição de uma regra específica que já tinha correspondido antes.

A anatomia real: critérios, ações e operadores

Cada regra tem três blocos. Os critérios ficam em glpi_rulecriterias, as ações em glpi_ruleactions:

• Critério = criteria (o campo) + condition (o operador, numérico) + pattern (o valor esperado).
• Ação = action_type (assign, regex_result, append, fromuser, fromitem) + field (o campo a alterar) + value.

O operador é um código numérico, não texto - e escolher o errado é a falha silenciosa mais comum. Os valores no GLPI 11:

0  = é (igualdade exata)
1  = não é
2  = contém
3  = não contém
4  = começa por
5  = termina por
6  = expressão regular (regex)
7  = regex negada
8  = existe
9  = não existe
11 = sob (árvore de entidade/categoria)
12 = não sob

Campos reais que mais usa na ação: _groups_id_assign (grupo técnico), _users_id_assign (técnico), slas_id_ttr (SLA de resolução), itilcategories_id (categoria) e urgency. No critério, _mailgate identifica o chamado que entrou por um coletor de correio específico e _x-priority lê o cabeçalho de prioridade do correio.

Lista de verificação: uma regra que dispara à primeira

1. Defina o gatilho. Vai reclassificar na criação? Use ONADD (condição 1). Precisa de reagir a uma mudança de categoria feita depois? Marque também a atualização (condição 3).
2. Escolha o operador certo. "É" (0) exige o título idêntico; para corresponder por excerto use "contém" (2) ou regex (6). A maioria das regras de título que "não apanham" usou "é" onde precisava de "contém".
3. Posicione o ranking. Específica primeiro, genérica depois - mas lembre-se de que a genérica posterior sobrepõe-se. Se a genérica não deve mexer no que já foi decidido, restrinja o seu critério.
4. Confirme a entidade. Uma regra criada numa entidade-filha sem a marca "recursiva" só se aplica aos chamados dessa entidade - e desaparece para o resto do parque.
5. Teste em pré-produção antes de ativar em produção.
6. Valide com o Rule Inspector dentro de um chamado real: mostra que regras foram avaliadas, que critérios passaram e quais falharam.

SQL de diagnóstico: o que corremos quando "a regra não funciona"

Antes de mexer na interface, a NexTool exporta o conjunto inteiro de regras de chamado por ordem de avaliação. Em segundos o ranking conta a história - quase sempre é ordem ou condição, não um critério errado. Corra numa réplica de leitura ou com cuidado na base de dados de produção:

SELECT r.ranking,
       r.name,
       IF(r.is_active, 'ativa', 'INATIVA') AS estado,
       r.match AS logica,
       CASE r.condition WHEN 1 THEN 'criacao'
                        WHEN 2 THEN 'atualizacao'
                        WHEN 3 THEN 'criacao+atualizacao'
       END AS 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 criterios,
       (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 acoes
FROM glpi_rules r
WHERE r.sub_type = 'RuleTicket'
ORDER BY r.ranking;

Leia de cima para baixo: duas linhas que gravam _groups_id_assign significam que a de ranking maior vence. Uma linha com estado = INATIVA explica o "desaparecimento" da regra. quando = criacao explica porque editar o chamado não o reencaminha.

Matriz de decisão: que coleção de regras usar

O GLPI tem várias coleções de regras, e cada uma comporta-se de forma diferente. Confundir uma com a outra é a raiz de muitos "porque é que esta regra corre duas vezes?":

Para um chamado que chega por correio, note que dois motores correm em sequência: primeiro o do coletor (para na primeira correspondência), depois o de negócio no chamado já criado (corre todas).

O erro de campo mais comum

Na sustentação, o pedido que mais abrimos sobre regras é sempre o mesmo: "criei a regra e não apanha". Na esmagadora maioria não é o critério - é o modelo de avaliação. Caso número um: existem duas regras a gravar _groups_id_assign, a específica com ranking menor corresponde primeiro, e uma regra genérica de ranking maior, criada meses depois "só para garantir um grupo por omissão", sobrepõe-se a tudo porque o motor encadeia a saída. Caso dois: a regra foi criada apenas com condition = 1 (só na criação), pelo que quando o técnico troca a categoria depois, nada é reencaminhado. Por isso tornámos padrão de operação correr sempre o SQL de auditoria acima ANTES de tocar na interface: a coluna ranking revela o conflito em segundos, enquanto clicar regra a regra no ecrã esconde a ordem real de execução. É o tipo de coisa que só se torna óbvia quando se opera dezenas de ambientes e se vê o mesmo padrão repetir-se.

Precisa de um GLPI cuja automação se comporta de forma previsível, sem regras que se atropelam? A sustentação NexTool audita e reorganiza o seu conjunto de regras, e o plugin Rule Inspector mostra, dentro de cada chamado, exatamente que regra decidiu o quê.

Revisto pela equipa NexTool Solutions.