El retiro de una integración no consiste en detener el iFlow y borrar el paquete. Una interface forma parte de una cadena: recibe mensajes, consulta sistemas, escribe datos, usa credenciales, dispara alertas y deja evidencia que puede ser necesaria después. El decommissioning debe cerrar esa cadena en un orden verificable.
El objetivo no es conservar componentes indefinidamente. Es demostrar que el flujo ya no tiene demanda legítima, que los mensajes pendientes se resolvieron y que existe una ventana prudente para observar el cambio antes de eliminar activos.
1) Confirmar la decisión y el alcance
Antes de tocar el tenant, documenta por qué se retira la interface y qué la reemplaza. Un cambio de ERP, una consolidación de iFlows o el cierre de un proveedor pueden afectar más rutas de las visibles en el paquete.
- Owner funcional: confirma que el proceso ya no requiere la interface anterior.
- Owner técnico: identifica artefactos, dependencias y secuencia de retiro.
- Owner operativo: define ventana, observación, alertas y escalamiento.
- Criterio de éxito: establece qué evidencia demuestra que el retiro fue seguro.
2) Construir un mapa de dependencias reales
El nombre del iFlow rara vez describe toda la superficie afectada. Revisa emisores, receptores, ProcessDirect, colas, Data Store, Value Mapping, APIs, certificados, aliases, schedulers y scripts externos. Incluye también automatizaciones n8n o jobs que invoquen el endpoint aunque no vivan en SAP BTP.
| Componente | Pregunta de control | Evidencia de cierre |
|---|---|---|
| Productor | ¿Dejará de enviar antes de detener el iFlow? | Cambio desplegado o job deshabilitado. |
| Mensajes | ¿Hay mensajes en proceso, fallidos o pendientes? | Conciliación y decisión por cada pendiente. |
| Consumidor | ¿Recibirá datos por otra ruta? | Validación funcional de la ruta sustituta. |
| Seguridad | ¿Qué credenciales o certificados son exclusivos? | Revocación sin afectar integraciones compartidas. |
3) Cerrar los datos en tránsito
Detener el productor primero reduce carreras. Después conviene observar el flujo, clasificar mensajes fallidos y conciliar con el sistema destino. Reprocesar todo de forma indiscriminada puede duplicar operaciones; descartar todo puede perder eventos de negocio.
4) Retirar por fases y conservar rollback
- Congelar cambios no relacionados y respaldar versión, configuración y dependencias.
- Detener productores o schedulers de entrada.
- Drenar y conciliar mensajes pendientes.
- Desactivar el iFlow durante una ventana de observación.
- Eliminar rutas, accesos y alertas exclusivas solo después de validar estabilidad.
El tiempo de observación depende de la frecuencia del proceso. Una interface mensual no puede darse por validada con veinticuatro horas sin mensajes.
5) Limpiar seguridad y observabilidad sin daño colateral
Un alias, certificado o usuario técnico puede ser compartido. Verifica consumidores antes de revocarlo. También actualiza dashboards, alertas, runbooks, inventario y rutas de escalamiento; de otro modo, la interface retirada seguirá produciendo falsos positivos y confusión.
Este control no reemplaza SAP Cloud ALM, SAP Transport Management ni el monitoreo runtime. Usa esas capacidades como fuentes de evidencia y ejecución dentro de un proceso de ciclo de vida con responsables claros.
6) Conservar la evidencia correcta
- Decisión aprobada, owners y fecha efectiva.
- Inventario de artefactos retirados y activos compartidos conservados.
- Resultado de conciliación y tratamiento de mensajes pendientes.
- Versión exportada, configuración y condiciones de rollback.
- Validación funcional posterior y cierre de la ventana de observación.
Señales de una integración zombie
- El iFlow está desplegado, pero nadie conoce su consumidor.
- Una alerta sigue activa para un proceso que negocio considera retirado.
- Existen endpoints o usuarios técnicos sin owner confirmado.
- El reemplazo productivo convive indefinidamente con la ruta anterior.
- Eliminar el paquete parece riesgoso porque no hay mapa de dependencias.
El retiro controlado también es gobierno. El Picasso CPI Governance Assessment puede ayudar a detectar artefactos sin owner, dependencias invisibles y controles de ciclo de vida incompletos antes de una consolidación o limpieza del tenant.