Muchas operaciones de SAP CPI / Integration Suite fallan en el momento menos conveniente no por falta de monitoreo, sino porque el equipo no tiene una forma consistente de interpretar la alerta. El mensaje de error existe, el payload existe, el MPL existe, pero la decisión queda en manos de la persona que conoce el flujo de memoria.
Un runbook operativo resuelve una parte concreta del problema: convierte conocimiento disperso en pasos verificables. No reemplaza SAP Cloud ALM, SAP Transport Management, alertas runtime ni criterio de arquitectura. Sirve como capa de respuesta para que soporte actúe con contexto, límites y evidencia.
1) Empezar por escenarios, no por pantallas
Un runbook útil no describe cada botón de la consola. Describe escenarios que realmente ocurren y qué se debe comprobar en cada uno.
- Falla técnica: timeout, autenticación, certificado, conectividad o recurso no disponible.
- Falla funcional: dato inválido, regla de negocio, estructura inesperada o catálogo incompleto.
- Riesgo operativo: duplicado potencial, reproceso parcial, backlog acumulado o dependencia externa lenta.
- Excepción controlada: pausa temporal, ventana de mantenimiento, endpoint alterno o cambio autorizado.
La diferencia importa porque cada clase de evento tiene owner, severidad y acción distinta. Tratar todo como error genérico produce reprocesos inseguros y escalaciones pobres.
2) Definir severidad con impacto de negocio
La severidad no debería depender solo del color de la alerta. Debe conectar el estado técnico con el impacto operativo.
| Severidad | Criterio práctico | Decisión esperada |
|---|---|---|
| P1 | Proceso crítico detenido o riesgo alto de duplicados financieros, logísticos o de nómina. | Escalar de inmediato con owner funcional y técnico. |
| P2 | Backlog creciente, SLA en riesgo o dependencia externa intermitente. | Diagnosticar, contener y acordar ventana de recuperación. |
| P3 | Error individual sin impacto sistémico y con reproceso controlable. | Corregir dato, reprocesar con evidencia y registrar causa. |
3) Documentar diagnóstico mínimo
Cada runbook debe decir dónde mirar y qué capturar. Para SAP CPI normalmente conviene incluir Message Processing Log, Correlation ID, nombre del iFlow, tenant, ambiente, timestamp, endpoint llamado, payload permitido para soporte y respuesta del sistema receptor cuando sea posible.
4) Separar acciones seguras de acciones restringidas
El runbook debe marcar claramente qué puede ejecutar L1/L2 y qué requiere aprobación de arquitectura, seguridad o dueño funcional.
- Acciones seguras: confirmar estado, recolectar evidencia, validar duplicidad, revisar backlog y notificar al owner.
- Acciones condicionadas: reprocesar mensajes, pausar scheduler, cambiar parámetros externalizados o activar una ruta temporal.
- Acciones restringidas: modificar certificados, credenciales, endpoints productivos, mapeos o lógica del iFlow.
Esta separación reduce improvisación y evita que una corrección rápida cree una deuda operativa mayor.
5) Incluir criterios de reproceso e idempotencia
En integraciones SAP, reprocesar sin criterio puede ser peor que no reprocesar. El runbook debe indicar si el flujo es idempotente, cómo detectar duplicados, qué clave de negocio se usa y cuándo se requiere conciliación manual antes de enviar de nuevo.
- Identificar mensaje y clave de negocio.
- Confirmar si el receptor ya procesó parcial o totalmente.
- Validar si existe mecanismo idempotente o bloqueo de duplicados.
- Registrar evidencia antes y después del reproceso.
- Escalar si el estado final no puede comprobarse.
6) Mantener el runbook como activo vivo
Un runbook caduca cuando cambia el endpoint, el owner, el SLA, el certificado, el esquema de datos o el patrón de error. Por eso debe tener fecha de revisión, responsable y relación con cambios recientes. Una sección de deuda conocida también ayuda: excepciones aceptadas, gaps de observabilidad y decisiones pendientes.
En una revisión de gobierno, los runbooks muestran si el landscape de integración puede operar sin depender de conocimiento tribal. El Picasso CPI Governance Assessment suele revisar runbooks, ownership, reintentos, trazabilidad, evidencias y límites operativos como parte de una fotografía técnica del tenant.