NexTool Solutions

As regras de negócio são o motor de automação nativo do GLPI: sem uma linha de código, elas classificam, atribuem e aplicam SLA em cada chamado. O que a documentação raramente explica - e o que mais gera chamado de suporte na sustentação de parques GLPI de clientes - não é como criar uma regra, e sim 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 regra de negócio de chamado é do subtipo RuleTicket e vive na tabela glpi_rules. Três colunas comandam o comportamento:

• ranking - a ordem de avaliação. O motor lê em ordem crescente, da menor para a maior. A tela 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 só para 1 nunca reavalia quando o chamado é editado depois.
• match - a lógica entre critérios: AND (todos precisam bater) ou OR (qualquer um).

O detalhe que derruba a maioria: as regras de chamado não param no primeiro acerto. Diferente das regras de coletor de e-mail e de importação de inventário, o motor de RuleTicket percorre TODAS as regras ativas na ordem de ranking e usa a saída de uma como entrada da próxima. Ou seja, uma regra genérica com ranking maior (avaliada depois) pode sobrescrever a atribuição de uma regra específica que já tinha acertado antes.

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 você mais usa em 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. Em critério, _mailgate identifica o chamado que entrou por um coletor de e-mail específico e _x-priority lê o cabeçalho de prioridade do e-mail.

Checklist: uma regra que dispara de primeira

1. Defina o gatilho. Vai reclassificar na criação? Use ONADD (condição 1). Precisa 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 casar por trecho use "contém" (2) ou regex (6). A maioria das regras de título que "não pegam" usou "é" onde precisava de "contém".
3. Posicione o ranking. Específica antes, genérica depois - mas lembre que a genérica depois sobrescreve. Se a genérica não deve mexer no que já foi decidido, restrinja o critério dela.
4. Confira a entidade. Regra criada numa entidade-filha sem o flag "recursiva" só vale para os chamados daquela entidade - e some para o resto do parque.
5. Teste em homologação antes de ativar em produção.
6. Valide com o Rule Inspector dentro de um chamado real: ele mostra quais regras foram avaliadas, quais critérios passaram e quais falharam.

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

Antes de mexer na interface, a NexTool despeja o conjunto inteiro de regras de chamado em ordem de avaliação. Em segundos o ranking conta a história - quase sempre é ordem ou condição, não critério errado. Rode em réplica de leitura ou com cautela no banco 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 "sumiço" da regra. quando = criacao explica por que editar o chamado não o reroteia.

Matriz de decisão: qual coleção de regra usar

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

Para um chamado que chega por e-mail, note que dois motores rodam em sequência: primeiro o do coletor (para no primeiro acerto), depois o de negócio no chamado já criado (roda todas).

O erro comum de campo

Na sustentação, o chamado que mais abre sobre regras é sempre o mesmo: "criei a regra e ela não pega". Na esmagadora maioria não é o critério - é o modelo de avaliação. O caso número um: existem duas regras gravando _groups_id_assign, a específica com ranking menor acerta primeiro e uma regra genérica de ranking maior, criada meses depois "só para garantir um grupo padrão", sobrescreve tudo porque o motor encadeia a saída. O segundo caso: a regra foi criada apenas com condition = 1 (só na criação), então quando o atendente troca a categoria depois, nada reroteia. Por isso decidimos, como padrão de operação, sempre rodar o SQL de auditoria acima ANTES de tocar na interface: a coluna ranking revela o conflito em segundos, enquanto clicar regra por regra na tela esconde a ordem real de execução. É o tipo de coisa que só fica óbvia quando você opera dezenas de ambientes e vê o mesmo padrão se repetir.

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 qual regra decidiu o quê.

Revisado pela equipe NexTool Solutions.