En SAP CPI / SAP Integration Suite, el manejo de errores no es un “detalle de implementación”. Es parte del diseño de arquitectura: define confiabilidad, costo operativo y el riesgo de que una integración impacte finanzas, inventario, nómina o master data.
La diferencia que casi siempre se ignora: reintento vs reproceso
Reintento es automático y ocurre sin que un humano valide el impacto. Reproceso es intencional: alguien decide volver a correr un mensaje con contexto (y con un plan para evitar duplicados).
Si el equipo no puede explicar esa diferencia por integración, el sistema no está listo para producción: está listo para “correr”, no para sostenerse.
Clasifica fallas antes de diseñar la solución
Una política de reintentos madura parte de una clasificación simple:
- Transitoria: timeouts, throttling, fallas momentáneas de red o capacidad.
- Funcional: datos inválidos, reglas de negocio, autorizaciones inexistentes, fechas fuera de rango.
- Dependencia: el sistema destino está degradado, en mantenimiento o con colas saturadas.
- Contrato: el payload no cumple el esquema, faltan campos obligatorios o cambió una API.
Solo la primera categoría suele ser candidata a reintentos automáticos. El resto requiere reproceso controlado o corrección de datos.
Idempotencia: la condición mínima para reintentar sin miedo
El reintento sin idempotencia no es resiliencia: es duplicación “en cámara lenta”. En integraciones SAP, un solo duplicado puede crear documentos repetidos, contabilizaciones dobles o inconsistencias de reconciliación.
La pregunta clave no es “¿podemos reintentar?”. Es “¿qué prueba tenemos de que un segundo intento no crea un segundo efecto?”
| Decisión | Evidencia mínima |
|---|---|
| Qué mensajes pueden reintentarse automáticamente | Listado por iFlow + condición explícita (HTTP status/código de error) + límite de intentos |
| Cómo evitamos duplicados | Clave idempotente (por negocio) + deduplicación en destino o control en integración |
| Qué se hace cuando falla definitivamente | Ruta de excepción + cola/buzón de pendientes + responsable y SLA operativo |
| Cómo se investiga y se coordina soporte | Correlation ID consistente + logs útiles + runbook de triage |
Checklist de governance (práctico, sin papel)
Para cada integración productiva, valida estos puntos:
- Contrato de reintentos: cuántos intentos, con qué backoff, y bajo qué errores.
- Contrato de reproceso: quién re-procesa, desde dónde, y cómo se evita el doble efecto.
- Runbook: pasos claros para diagnóstico, incluyendo “qué NO hacer” cuando hay presión.
- Observabilidad mínima: trazabilidad por correlación, contexto de error y evidencia de payload (sin exponer datos sensibles).
- Segregación: quién puede desplegar, quién puede re-procesar, y cómo se audita.
Esto no reemplaza herramientas de ciclo de vida SAP (ALM/Transport/monitoreo), pero reduce el caos operativo dentro del alcance real del middleware.
Cuándo esto se vuelve un problema “de arquitectura”
Si hoy el equipo “resuelve” incidentes reintentando a ciegas, el problema ya no es un iFlow. Es el diseño de integración y su gobernanza: idempotencia, ownership de datos, y un proceso de soporte que no está alineado con el riesgo.