SAP CPI: trazabilidad end-to-end con Correlation ID (sin soporte arqueológico)

Un Correlation ID bien diseñado convierte un incidente de “buscar en 5 sistemas” a “seguir un hilo”. La clave es tratarlo como parte del contrato operativo de la integración: se genera, se propaga, se registra y se usa para soporte.

1) Define qué correlacionas (y qué no)

Antes de escoger un header, define el alcance:

• Unidad de correlación: ¿pedido, empleado, factura, transferencia, ticket?
• Cardinalidad: ¿un ID por mensaje, por transacción o por lote?
• Privacidad: evita IDs que expongan datos personales; usa identificadores técnicos o tokens.

2) Estándar mínimo: un header estable + un identificador de plataforma

Para soporte, ayuda separar:

• Correlation ID (negocio): el que viaja entre sistemas y une saltos (ej. X-Correlation-ID).
• ID de ejecución (plataforma): el que te da el runtime (por ejemplo, IDs de mensajes y logs) para llegar a detalles técnicos.

El error común es usar solo el ID de plataforma: sirve para mirar un salto, pero no para unir el recorrido completo cuando hay reintentos, reproceso o rutas paralelas.

3) Propagación: cada salto debe preservar el hilo

Si tu integración hace HTTP, SOAP, OData o colas, el patrón es el mismo: el Correlation ID entra o se genera, luego se copia a cada request saliente.

• Inbound: si llega un ID válido, respétalo; si no llega, genera uno.
• Outbound: reinyecta el mismo ID en el header del request (y, si aplica, en el response).
• Batch: para lotes, define si el ID es por lote (para soporte) y agrega un sub-ID por ítem si necesitas granularidad.

4) Implementación en SAP CPI / Integration Suite (patrón operativo)

Sin entrar a un iFlow específico, el patrón típico queda así:

1. Validar/normalizar el Correlation ID al inicio (longitud, charset, formato).
2. Persistir en propiedades para reutilizarlo en todo el flujo (y evitar que se pierda en mapeos).
3. Inyectar en outbound (HTTP headers, SOAP headers o adapters equivalentes).
4. Log mínimo: cuando haya error o retries, registra el Correlation ID + el contrato (qué entidad, qué operación, qué destino).

Un enfoque sano es que cada iFlow tenga una sección explícita de “observabilidad”: qué se registra, qué no se registra, y cómo se busca un caso desde soporte.

5) Evidencia mínima para soporte (sin convertir logs en dumping)

“Más logs” no es una estrategia. Lo mínimo útil suele ser:

• Correlation ID + timestamp + ambiente.
• Contrato: entidad/operación/destino.
• Fingerprint: hash del payload o una firma estable sin datos sensibles.
• Resultado: éxito/falla + clase de error (transitorio vs funcional).

Esto no reemplaza herramientas SAP de lifecycle, transport management o monitoreo runtime. Es gobernanza de middleware enfocada en trazabilidad operable.

6) Gobierno: cómo evitar “cada iFlow a su manera”

Cuando el estándar no existe, la trazabilidad se rompe en el primer cambio. Define reglas simples:

• Nombres: un header canónico y su formato (ej. UUID o token seguro).
• Obligatoriedad: qué integraciones deben incluirlo siempre (casi todas las que cruzan sistemas).
• Runbook: “cómo trazar un caso” desde el ticket hasta el salto que falló.
• Pruebas: un smoke test que valide que el Correlation ID se conserva en el recorrido.

Checklist rápido (para partners SAP)