Integraciones
Cuando la integración deja de funcionar
Cómo enterarse antes que el usuario, y qué mirar primero.
Una integración rota casi nunca avisa. Sigue todo verde hasta que alguien pregunta por qué un proveedor no aparece en el ERP, y para entonces lleva dos semanas fallando.
Las cuatro causas, por frecuencia
| Causa | Cómo se reconoce | Arreglo |
|---|---|---|
| Clave revocada o caducada | Todo falla de golpe, con error de autenticación | Rotar la clave y actualizarla |
| Vuestro endpoint devuelve error | Los avisos se reintentan y se acumulan | Mirar vuestros logs, no los nuestros |
| Un campo cambió de forma | Falla solo un tipo de operación | Revisar qué se envía frente a lo que se espera |
| Nadie mira los fallidos | Todo parece bien y falta la mitad | Poner una alerta sobre la cola de fallidos |
Importante
La cuarta es la que más daño hace y la única que no da error: si nadie mira los avisos fallidos, la integración parece funcionar mientras pierde la mitad de los eventos. Poned una alerta sobre esa cola antes que sobre nada más.
Lo mínimo para enterarse a tiempo
Ojo con esto
No reintentéis en bucle sin límite. Un endpoint que responde error a todo y un emisor que reintenta indefinidamente generan ruido durante días y esconden el fallo real.
›¿Se pueden reenviar los eventos perdidos?
Los reintentos tienen un plazo. Pasado, hay que reconciliar consultando por la API.
›¿Cómo pruebo sin tocar producción?
Contra el entorno de pruebas, con su propia clave.
›¿Conviene alertar de cada fallo?
No: alertad del patrón, no del evento suelto, o dejaréis de mirar las alertas.
Un caso real
La situación
Un ERP lleva dos semanas sin recibir avisos y nadie se ha dado cuenta.
Qué haces
- Descubre que su endpoint devolvía error desde un despliegue
- Añade una alerta sobre la cola de fallidos
Qué consigues
El siguiente fallo se detecta en horas en vez de en semanas.
La situación
La integración lleva cinco días caída y se descubre porque falta un expediente.
Qué haces
- Configura un aviso si deja de llegar actividad
- Revisa el registro de llamadas cada semana
Qué consigues
El corte se detecta en horas y no cuando alguien echa algo en falta.
La situación
Falla y nadie sabe si el problema es de un lado o del otro.
Qué haces
- Consulta el registro de llamadas con su código de error
Qué consigues
El diagnóstico empieza donde hay que mirar.
La situación
Se reintenta a mano y se duplican expedientes.
Qué haces
- Comprueba qué llegó antes de reprocesar
Qué consigues
El reintento no crea lo que ya existía.
La situación
La clave caducó y nadie lo sabía.
Qué haces
- Registra el vencimiento de las claves con aviso
Qué consigues
La rotación se hace antes de que corte el servicio.
La situación
Se arregla y no queda constancia de qué pasó.
Qué haces
- Registra la causa y lo actuado
Qué consigues
La siguiente vez se resuelve en minutos.
Este artículo responde a
- la integración ha dejado de funcionar
- los webhooks no llegan
- errores de la api en producción
- monitorizar una integración