Integração bidirecional entre sistemas, sem script customizado nem middleware externo. O módulo Automações do NexTool transforma o GLPI num hub capaz de receber eventos de qualquer sistema e reagir a eles 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
Equipes que operam várias ferramentas - monitoramento, ITSM, e-commerce, ERP, plataformas de observabilidade - convivem com a lacuna entre sistemas. Quando um alerta dispara no Zabbix ou um pedido cai no e-commerce, alguém precisa abrir o chamado no GLPI, preencher campos e atribuir responsável. Cada intervenção manual é ponto de falha e 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 controle da equipe. Para operações que precisam de rastreabilidade, segurança e integração profunda com o GLPI, a resposta tem que morar dentro do próprio ambiente - e é isso que o módulo Automações entrega.
Como o Automações funciona
O módulo opera em três pilares encadeados:
- Entrada (Trigger) - um endpoint webhook stateless recebe requisições POST de qualquer sistema. Cada fluxo tem um token único e autenticação HMAC SHA-256, garantindo que só fontes autorizadas disparem 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 chamado no GLPI (com session impersonation para atribuir o requerente correto) ou disparar uma requisição HTTP para um sistema externo via conector cadastrado.
Um Visual Flow Wizard permite montar e editar fluxos numa interface com três cards conectados: Trigger, Mapeamento e Ação. Não é preciso editar JSON à mão. Fluxos podem ser ativados, desativados e monitorados no painel. O módulo ainda gerencia Conectores - dezenas de provedores mapeados por categoria, com vários tipos de autenticação (API Key, Bearer, Basic, OAuth2, HMAC) e credenciais armazenadas com criptografia 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 exemplo mais comum que montamos é transformar alerta de monitoramento em chamado. 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": "monitoramento@suaempresa.com"
}
}'No card de mapeamento, cada caminho JSONPath vira um campo nativo do chamado. As transformações fazem a tradução de valor - "High" vira urgência 4, o e-mail vira o usuário requerente:
$.event.trigger -> name (titulo do chamado)
$.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 mandar o e-mail do solicitante, mas esse e-mail não existir como usuário no GLPI. Sem um resolve_user_by_email com plano B, o chamado nasce órfão ou a ação falha em silêncio - e ninguém percebe até faltar histórico. Nós padronizamos um requerente técnico de fallback (algo como "integracao-automatica") para nunca perder o evento, deixando o e-mail original no corpo do chamado para rastreio. O segundo detalhe é a assinatura HMAC: os dois lados precisam calcular o hash sobre exatamente o mesmo corpo bruto. Um proxy que reserializa o JSON no 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á reparseado. Quem não sabe disso perde horas achando que a chave está errada.
Entrada nativa vs. o que o módulo adiciona
| 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 chamado 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 status por execução |
Como ativar
- Instale o plugin NexTool no GLPI.
- Acesse Configuração > NexTool > Módulos.
- Localize o card Automações e clique em Instalar, depois em Ativar.
- Crie um fluxo pelo Visual Flow Wizard e copie a URL do webhook gerada.
- Configure o sistema externo para enviar os eventos para essa 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: monitoramento (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 registrada com input, output, duração e status. Não é para automatizar o que não está desenhado: se o seu processo de abertura de chamado ainda não tem categoria, urgência e responsável definidos, a automação só vai acelerar a bagunça. Defina o fluxo manual primeiro, 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 as intervenções manuais entre os seus sistemas? Fale com a equipe e desenhamos o primeiro fluxo com você.
Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe NexTool Solutions.
