Integración bidireccional entre sistemas, sin script a medida ni middleware externo. El módulo Automatizaciones de NexTool convierte GLPI en un hub capaz de recibir eventos de cualquier sistema y reaccionar de forma autónoma - llega el webhook, se mapean los datos y se dispara una acción, todo dentro de tu propio entorno.
El problema
Los equipos que operan varias herramientas - monitorización, ITSM, e-commerce, ERP, plataformas de observabilidad - conviven con la brecha entre sistemas. Cuando salta una alerta en Zabbix o entra un pedido en el e-commerce, alguien tiene que abrir el ticket en GLPI, rellenar campos y asignar responsable. Cada paso manual es un punto de fallo y una fuente de retraso.
Soluciones genéricas como Zapier o Make resuelven casos simples, pero exigen cuenta externa, cobran por operación y viven fuera del control del equipo. Para operaciones que necesitan trazabilidad, seguridad e integración profunda con GLPI, la respuesta tiene que vivir dentro del propio entorno - y eso es lo que entrega el módulo Automatizaciones.
Cómo funciona Automatizaciones
El módulo opera en tres pilares encadenados:
- Entrada (Trigger) - un endpoint webhook stateless recibe peticiones POST de cualquier sistema. Cada flujo tiene un token único y autenticación HMAC SHA-256, de modo que solo fuentes autorizadas disparan acciones.
- Procesamiento (PayloadMapper) - el payload JSON recibido se mapea con JSONPath. Transformaciones como map_priority, resolve_user_by_email y resolve_category_by_name convierten datos externos en campos nativos de GLPI sin código.
- Salida (ActionRunner) - dos tipos de acción: crear un ticket en GLPI (con session impersonation para asignar al solicitante correcto) o disparar una petición HTTP a un sistema externo mediante un conector registrado.
Un Visual Flow Wizard permite montar y editar flujos en una interfaz con tres tarjetas conectadas: Trigger, Mapeo y Acción. No hace falta editar JSON a mano. Los flujos se activan, desactivan y monitorizan en el panel. El módulo también gestiona Conectores - decenas de proveedores mapeados por categoría, con varios tipos de autenticación (API Key, Bearer, Basic, OAuth2, HMAC) y credenciales guardadas con cifrado AES-256-GCM. Así, una acción de flujo hace llamadas autenticadas a APIs externas como Microsoft 365, Jira, Slack o cualquier servicio con API REST.
Un flujo real, del payload a la acción
El flujo más común que montamos convierte una alerta de monitorización en un ticket. El sistema externo hace un POST firmado al endpoint del flujo:
# Zabbix (o cualquier sistema) dispara un POST firmado al endpoint del flujo
curl -X POST 'https://glpi.tuempresa.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": "Espacio en disco < 10%",
"requester": "monitorizacion@tuempresa.com"
}
}'En la tarjeta de mapeo, cada JSONPath se convierte en un campo nativo del ticket. Las transformaciones traducen los valores - "High" pasa a urgencia 4, el e-mail pasa al usuario solicitante:
$.event.trigger -> name (titulo del ticket)
$.event.host -> content (descripcion)
$.event.severity -> urgency (map_priority: High=4, Disaster=5)
$.event.requester -> _users_id_requester (resolve_user_by_email)El detalle que solo conoce quien opera integraciones
En el mantenimiento, el error clásico es que el sistema externo envíe el e-mail del solicitante pero ese e-mail no exista como usuario en GLPI. Sin un resolve_user_by_email con plan B, el ticket nace huérfano o la acción falla en silencio - y nadie se da cuenta hasta que falta el historial. Estandarizamos un solicitante técnico de reserva (algo como "integracion-automatica") para no perder nunca el evento, dejando el e-mail original en el cuerpo del ticket para rastreo. El segundo detalle es la firma HMAC: ambos lados deben calcular el hash sobre exactamente el mismo cuerpo bruto (raw body). Un proxy que reserializa el JSON en el camino cambia un espacio, rompe la firma y el webhook se rechaza con 401 - por eso la validación se hace sobre el raw body, no sobre el JSON ya reparseado. Quien no lo sabe pierde horas creyendo que la clave está mal.
Entrada nativa vs. lo que añade el módulo
| Recurso | Webhook nativo de GLPI 11 | Módulo Automatizaciones NexTool |
|---|---|---|
| Dirección | Solo salida (outbound) | Entrada y salida |
| Autenticación de entrada | No aplica | Token único por flujo + HMAC SHA-256 |
| Mapeo de payload | No aplica | JSONPath + transformaciones listas |
| Crear ticket como el solicitante correcto | No aplica | Session impersonation |
| GLPI 10 | No soportado | Soportado |
| Auditoría de ejecución | Limitada | Input, output, duración y estado por ejecución |
Cómo activarlo
- Instala el plugin NexTool en GLPI.
- Accede a Configuración > NexTool > Módulos.
- Localiza la tarjeta Automatizaciones y pulsa Instalar y luego Activar.
- Crea un flujo con el Visual Flow Wizard y copia la URL del webhook generada.
- Configura el sistema externo para enviar los eventos a esa URL usando el token y la firma HMAC.
Para quién es (y cuándo no)
Es para quien opera entornos con varias herramientas integradas: monitorización (Zabbix, Grafana, Nagios), e-commerce, ERP, RRHH o cualquier servicio que dispare webhooks. Es especialmente valioso cuando la operación exige trazabilidad y auditoría - cada ejecución queda registrada con input, output, duración y estado. No sirve para automatizar lo que no está diseñado: si tu proceso de apertura de ticket aún no tiene categoría, urgencia y responsable definidos, la automatización solo acelerará el desorden. Define primero el flujo manual y luego automatiza.
Compatibilidad
- GLPI: 10.0+ y 11.0+
- Plan: Enterprise
- Plugin: NexTool 3.x o superior
Siguiente paso
El módulo Automatizaciones forma parte de NexTool. ¿Listo para eliminar los pasos manuales entre tus sistemas? Habla con el equipo y diseñamos el primer flujo contigo.
Este contenido fue producido con ayuda de inteligencia artificial y revisado por el equipo de NexTool Solutions.
