Integrazione bidirezionale tra sistemi, senza script su misura né middleware esterno. Il modulo Automazioni di NexTool trasforma GLPI in un hub capace di ricevere eventi da qualsiasi sistema e reagire in modo autonomo - arriva il webhook, i dati vengono mappati e un'azione si attiva, tutto dentro il tuo ambiente.
Il problema
I team che gestiscono più strumenti - monitoraggio, ITSM, e-commerce, ERP, piattaforme di osservabilità - convivono con il divario tra i sistemi. Quando scatta un alert in Zabbix o arriva un ordine nell'e-commerce, qualcuno deve aprire il ticket in GLPI, compilare i campi e assegnare un responsabile. Ogni passaggio manuale è un punto di guasto e una fonte di ritardo.
Le soluzioni generiche come Zapier o Make risolvono i casi semplici, ma richiedono un account esterno, addebitano per operazione e vivono fuori dal controllo del team. Per operazioni che richiedono tracciabilità, sicurezza e integrazione profonda con GLPI, la risposta deve vivere dentro l'ambiente stesso - ed è ciò che offre il modulo Automazioni.
Come funziona Automazioni
Il modulo opera in tre pilastri concatenati:
- Ingresso (Trigger) - un endpoint webhook stateless riceve richieste POST da qualsiasi sistema. Ogni flusso ha un token univoco e autenticazione HMAC SHA-256, così solo le fonti autorizzate attivano azioni.
- Elaborazione (PayloadMapper) - il payload JSON ricevuto viene mappato con JSONPath. Trasformazioni come map_priority, resolve_user_by_email e resolve_category_by_name convertono i dati esterni in campi nativi di GLPI senza codice.
- Uscita (ActionRunner) - due tipi di azione: creare un ticket in GLPI (con session impersonation per assegnare il richiedente corretto) o attivare una richiesta HTTP verso un sistema esterno tramite un connettore registrato.
Un Visual Flow Wizard permette di costruire e modificare flussi in un'interfaccia con tre card collegate: Trigger, Mappatura e Azione. Non serve modificare il JSON a mano. I flussi si attivano, disattivano e monitorano nel pannello. Il modulo gestisce anche i Connettori - decine di provider mappati per categoria, con vari tipi di autenticazione (API Key, Bearer, Basic, OAuth2, HMAC) e credenziali salvate con cifratura AES-256-GCM. Così un'azione di flusso effettua chiamate autenticate verso API esterne come Microsoft 365, Jira, Slack o qualsiasi servizio con API REST.
Un flusso reale, dal payload all'azione
Il flusso più comune che costruiamo trasforma un alert di monitoraggio in un ticket. Il sistema esterno fa un POST firmato sull'endpoint del flusso:
# Zabbix (o qualsiasi sistema) attiva un POST firmato sull'endpoint del flusso
curl -X POST 'https://glpi.tuaazienda.com/plugins/nextool/automations/webhook/...token...' \
-H 'Content-Type: application/json' \
-H 'X-Signature: sha256=...firma-hmac...' \
-d '{
"event": {
"host": "srv-db-01",
"severity": "High",
"trigger": "Spazio su disco < 10%",
"requester": "monitoraggio@tuaazienda.com"
}
}'Nella card di mappatura, ogni JSONPath diventa un campo nativo del ticket. Le trasformazioni traducono i valori - "High" diventa urgenza 4, l'e-mail diventa l'utente richiedente:
$.event.trigger -> name (titolo del ticket)
$.event.host -> content (descrizione)
$.event.severity -> urgency (map_priority: High=4, Disaster=5)
$.event.requester -> _users_id_requester (resolve_user_by_email)Il dettaglio che conosce solo chi gestisce integrazioni
In manutenzione, l'errore classico è che il sistema esterno invii l'e-mail del richiedente ma quell'e-mail non esista come utente in GLPI. Senza un resolve_user_by_email con un piano B, il ticket nasce orfano o l'azione fallisce in silenzio - e nessuno se ne accorge finché non manca lo storico. Standardizziamo un richiedente tecnico di riserva (qualcosa come "integrazione-automatica") per non perdere mai l'evento, lasciando l'e-mail originale nel corpo del ticket per la tracciabilità. Il secondo dettaglio è la firma HMAC: entrambi i lati devono calcolare l'hash sullo stesso identico corpo grezzo (raw body). Un proxy che riserializza il JSON per strada cambia uno spazio, rompe la firma e il webhook viene rifiutato con 401 - per questo la validazione avviene sul raw body, non sul JSON riparseato. Chi non lo sa perde ore convinto che la chiave sia sbagliata.
Ingresso nativo vs. ciò che aggiunge il modulo
| Funzione | Webhook nativo GLPI 11 | Modulo Automazioni NexTool |
|---|---|---|
| Direzione | Solo uscita (outbound) | Ingresso e uscita |
| Autenticazione in ingresso | Non applicabile | Token univoco per flusso + HMAC SHA-256 |
| Mappatura del payload | Non applicabile | JSONPath + trasformazioni pronte |
| Creare il ticket con il richiedente giusto | Non applicabile | Session impersonation |
| GLPI 10 | Non supportato | Supportato |
| Audit di esecuzione | Limitato | Input, output, durata e stato per esecuzione |
Come attivarlo
- Installa il plugin NexTool su GLPI.
- Vai su Configurazione > NexTool > Moduli.
- Individua la card Automazioni e clicca su Installa e poi su Attiva.
- Crea un flusso con il Visual Flow Wizard e copia l'URL del webhook generato.
- Configura il sistema esterno per inviare gli eventi a quell'URL, usando il token e la firma HMAC.
Per chi è (e quando no)
È per chi gestisce ambienti con più strumenti integrati: monitoraggio (Zabbix, Grafana, Nagios), e-commerce, ERP, HR o qualsiasi servizio in grado di attivare webhook. È particolarmente prezioso quando l'operazione richiede tracciabilità e audit - ogni esecuzione è registrata con input, output, durata e stato. Non serve ad automatizzare ciò che non è progettato: se il tuo processo di apertura ticket non ha ancora categoria, urgenza e responsabile definiti, l'automazione accelererà solo il disordine. Definisci prima il flusso manuale, poi automatizza.
Compatibilità
- GLPI: 10.0+ e 11.0+
- Piano: Enterprise
- Plugin: NexTool 3.x o superiore
Prossimo passo
Il modulo Automazioni fa parte di NexTool. Pronto a eliminare i passaggi manuali tra i tuoi sistemi? Parla con il team e progettiamo il primo flusso insieme a te.
Questo contenuto è stato prodotto con l'aiuto dell'intelligenza artificiale e revisionato dal team di NexTool Solutions.
