Integração bidirecional entre sistemas, sem script personalizado nem middleware externo. O módulo Automações do NexTool transforma o GLPI num hub capaz de receber eventos de qualquer sistema e reagir de forma autónoma - o webhook chega, os dados são mapeados e uma ação dispara, tudo dentro do próprio ambiente.
O problema
As equipas que operam várias ferramentas - monitorização, ITSM, e-commerce, ERP, plataformas de observabilidade - convivem com a lacuna entre sistemas. Quando um alerta dispara no Zabbix ou um pedido entra no e-commerce, alguém tem de abrir o pedido no GLPI, preencher campos e atribuir responsável. Cada passo manual é um ponto de falha e uma fonte de atraso.
Soluções genéricas como Zapier ou Make resolvem casos simples, mas exigem conta externa, cobram por operação e vivem fora do controlo da equipa. Para operações que precisam de rastreabilidade, segurança e integração profunda com o GLPI, a resposta tem de viver dentro do próprio ambiente - e é isso que o módulo Automações entrega.
Como funciona o Automações
O módulo opera em três pilares encadeados:
- Entrada (Trigger) - um endpoint webhook stateless recebe pedidos POST de qualquer sistema. Cada fluxo tem um token único e autenticação HMAC SHA-256, garantindo que só fontes autorizadas disparam ações.
- Processamento (PayloadMapper) - o payload JSON recebido é mapeado com JSONPath. Transformações como map_priority, resolve_user_by_email e resolve_category_by_name convertem dados externos em campos nativos do GLPI sem código.
- Saída (ActionRunner) - dois tipos de ação: criar um pedido no GLPI (com session impersonation para atribuir o requerente correto) ou disparar um pedido HTTP para um sistema externo através de um conector registado.
Um Visual Flow Wizard permite montar e editar fluxos numa interface com três cartões ligados: Trigger, Mapeamento e Ação. Não é preciso editar JSON à mão. Os fluxos podem ser ativados, desativados e monitorizados no painel. O módulo ainda gere Conectores - dezenas de fornecedores mapeados por categoria, com vários tipos de autenticação (API Key, Bearer, Basic, OAuth2, HMAC) e credenciais guardadas com cifra AES-256-GCM. Assim, uma ação de fluxo faz chamadas autenticadas para APIs externas como Microsoft 365, Jira, Slack ou qualquer serviço com API REST.
Um fluxo real, do payload à ação
O fluxo mais comum que montamos transforma um alerta de monitorização num pedido. O sistema externo faz um POST assinado no endpoint do fluxo:
# O Zabbix (ou qualquer sistema) dispara um POST assinado no endpoint do fluxo
curl -X POST 'https://glpi.suaempresa.com/plugins/nextool/automations/webhook/...token...' \
-H 'Content-Type: application/json' \
-H 'X-Signature: sha256=...assinatura-hmac...' \
-d '{
"event": {
"host": "srv-db-01",
"severity": "High",
"trigger": "Espaco em disco < 10%",
"requester": "monitorizacao@suaempresa.com"
}
}'No cartão de mapeamento, cada JSONPath torna-se um campo nativo do pedido. As transformações traduzem o valor - "High" passa a urgência 4, o e-mail passa ao utilizador requerente:
$.event.trigger -> name (titulo do pedido)
$.event.host -> content (descricao)
$.event.severity -> urgency (map_priority: High=4, Disaster=5)
$.event.requester -> _users_id_requester (resolve_user_by_email)O detalhe que só quem opera integração conhece
Na sustentação, o erro clássico é o sistema externo enviar o e-mail do solicitante, mas esse e-mail não existir como utilizador no GLPI. Sem um resolve_user_by_email com plano B, o pedido nasce órfão ou a ação falha em silêncio - e ninguém repara até faltar o histórico. Padronizamos um requerente técnico de recurso (algo como "integracao-automatica") para nunca perder o evento, deixando o e-mail original no corpo do pedido para rastreio. O segundo detalhe é a assinatura HMAC: os dois lados têm de calcular o hash sobre exatamente o mesmo corpo em bruto (raw body). Um proxy que reserializa o JSON pelo caminho muda um espaço, quebra a assinatura e o webhook é rejeitado com 401 - por isso a validação é feita sobre o raw body, não sobre o JSON já reprocessado. Quem não sabe disto perde horas a pensar que a chave está errada.
Entrada nativa vs. o que o módulo acrescenta
| Recurso | Webhook nativo do GLPI 11 | Módulo Automações NexTool |
|---|---|---|
| Direção | Só saída (outbound) | Entrada e saída |
| Autenticação de entrada | Não se aplica | Token único por fluxo + HMAC SHA-256 |
| Mapeamento de payload | Não se aplica | JSONPath + transformações prontas |
| Criar pedido como o requerente certo | Não se aplica | Session impersonation |
| GLPI 10 | Não suportado | Suportado |
| Auditoria de execução | Limitada | Input, output, duração e estado por execução |
Como ativar
- Instale o plugin NexTool no GLPI.
- Aceda a Configuração > NexTool > Módulos.
- Localize o cartão Automações e clique em Instalar e depois em Ativar.
- Crie um fluxo pelo Visual Flow Wizard e copie o URL do webhook gerado.
- Configure o sistema externo para enviar os eventos para esse URL, usando o token e a assinatura HMAC.
Para quem é indicado (e quando não)
É indicado para quem opera ambientes com várias ferramentas integradas: monitorização (Zabbix, Grafana, Nagios), e-commerce, ERP, RH ou qualquer serviço capaz de disparar webhooks. É especialmente valioso quando a operação exige rastreabilidade e auditoria - cada execução fica registada com input, output, duração e estado. Não serve para automatizar o que não está desenhado: se o seu processo de abertura de pedido ainda não tem categoria, urgência e responsável definidos, a automação só vai acelerar a confusão. Defina primeiro o fluxo manual, depois automatize.
Compatibilidade
- GLPI: 10.0+ e 11.0+
- Plano: Enterprise
- Plugin: NexTool 3.x ou superior
Próximo passo
O módulo Automações faz parte do NexTool. Pronto para eliminar os passos manuais entre os seus sistemas? Fale com a equipa e desenhamos o primeiro fluxo consigo.
Este conteúdo foi produzido com auxílio de inteligência artificial e revisto pela equipa NexTool Solutions.
