SAP Integration Suite: decisiones y compromisos en producción

SAP Integration Suite es la plataforma de integración de SAP en SAP BTP: Cloud Integration (el antiguo CPI) más API Management, Event Mesh, Integration Advisor, Open Connectors y herramientas para migrar desde PI/PO. Es el middleware por defecto de los programas de S/4HANA en la nube y la vía de salida de PI/PO, cuyo mantenimiento estándar termina en 2027. Los retrasos en las interfaces rara vez vienen de la tecnología. Vienen de responsabilidades poco claras, de suposiciones sin comprobar sobre los sistemas heredados y de pruebas diseñadas para aprobar en lugar de para encontrar fallos. Esta guía es para responsables de integración, arquitectos y directores de programa. Explica para qué sirve cada componente, el contenido estándar frente al desarrollo a medida, la migración desde PI/PO, los riesgos de los sistemas heredados y de las pruebas, y la gobernanza posterior al go-live.

PI/PO tiene fecha límite. SAP Process Integration y Process Orchestration 7.5 están en mantenimiento estándar hasta finales de 2027. El mantenimiento ampliado opcional llega hasta finales de 2030, y después termina el soporte de SAP. La arquitectura de referencia de migración de SAP describe la ruta. Integration Suite incluye una aplicación Migration Assessment que dimensiona cada escenario de PI/PO, y Cloud Integration trae herramientas de migración guiadas por asistentes. Migre por oleadas: primero los flujos de SAP a SAP de bajo riesgo, en medio B2B y EDI, y al final los flujos de pedidos de gran volumen. Un cambio forzado bajo la presión de la fecha límite lleva más tiempo y cuesta más.

1. Oleada 1Flujos de SAP a SAP de bajo riesgoDimensione primero cada escenario con Migration Assessment
2. Oleada 2B2B y EDI
3. Oleada 3Flujos de pedidos de gran volumen
4. 2027Termina el mantenimiento estándar de PI/PO 7.5Fin de año. Planifique las oleadas para terminar antes de esta fecha
5. 2030Termina el mantenimiento ampliado opcionalFin de año. Después termina el soporte de SAP

Fuente: Fechas de mantenimiento de SAP y arquitectura de referencia de migración, comprobadas en octubre de 2026

Compruebe qué cubre su contrato en la nube. Los contratos de RISE y GROW suelen incluir créditos de SAP BTP con los que se puede pagar Integration Suite. Confirme qué edición y qué volúmenes de mensajes cubre su derecho de uso antes de comparar Integration Suite con MuleSoft o Boomi solo por funcionalidades. La economía de una plataforma ya incluida cambia la comparación.

La IA llega por etapas. Cloud Integration ofrece generación de flujos con IA generativa en su edición Premium desde mediados de 2024. Produce la estructura de un iFlow (pasos, canales, subproceso de excepción), no los mapeos ni los scripts. La edición mejorada de SAP, lanzada en marzo de 2026, añade generación de flujos a partir de texto y optimización de scripts, y SAP tenía previsto que Joule en Integration Suite estuviera disponible con carácter general en el tercer trimestre de 2026. Es útil para flujos estándar. La orquestación compleja con lógica de negocio profunda sigue necesitando arquitectos senior.

Integration Suite es un conjunto de servicios. Usar el adecuado para cada tarea marca la diferencia en lo bien que resiste el panorama de sistemas.

Componente	Función	Qué falla cuando se usa mal
Cloud Integration (CPI)	Flujos de mensajes, enrutamiento y transformación; la opción por defecto para la mayoría de los iFlows	Meterlo todo en CPI, incluidas las API y los eventos, lo vuelve difícil de soportar y de probar
API Management	Gobierna la exposición de las API: seguridad, límites de tasa, analítica	Si se omite, se multiplican las llamadas punto a punto; la gobernanza es difícil de añadir después
Event Mesh	Mensajería asíncrona para disparadores desacoplados	Las colas sin seguimiento crecen en silencio sin avisar a nadie
Integration Advisor	Propuestas de mapeo para formatos B2B como EDIFACT, X12 e IDoc	Los equipos dan por hecha una cobertura alta; uno esperaba el 80 % y obtuvo cerca del 40 %
Open Connectors	Conectores predefinidos para aplicaciones en la nube de terceros	Los cambios en las API externas rompen los conectores en silencio si nadie los supervisa
Migration Assessment y herramientas de migración	Dimensionan y migran escenarios de PI/PO	Se trata como una estimación puntual en lugar de como un plan de migración operativo

Los equipos que tratan Integration Suite como «CPI con extras» suelen ignorar API Management y Event Mesh. Funciona hasta que la complejidad los alcanza. Mi guía de SAP CPI profundiza en el propio Cloud Integration.

El contenido de integración prediseñado de SAP es realmente útil cuando el proceso es estándar. Conectar S/4HANA con SAP Ariba o SuccessFactors con procesos estándar suele encajar sin fricciones. Los procesos reales rara vez se quedan dentro de las líneas de referencia de SAP.

Elija contenido estándar cuando:

1. El escenario es de SAP a SAP y se parece mucho al proceso de referencia de SAP
2. El flujo es sencillo y casi siempre unidireccional
3. Puede convivir con el mapeo de SAP y extenderlo solo mediante las salidas previstas

Opte por un desarrollo a medida cuando:

1. Años de decisiones internas han alejado el proceso del modelo de SAP
2. Intervienen enrutamiento condicional, lógica de varios pasos o rarezas de los sistemas heredados
3. Una modificación profunda rompería la alineación con el soporte de SAP para el paquete estándar

Tome la decisión en la fase de blueprint. Cuando se toma tarde, los equipos descubren a mitad del proyecto que un iFlow «estándar» se ha modificado tanto que perdió la alineación con el soporte, y lo reconstruyen bajo la presión del go-live. He visto proyectos perder semanas porque los equipos dieron por hecho que el contenido estándar absorbería a la vez estructuras de datos maestros a medida, campos adicionales y autenticación heredada. No lo hizo. El análisis que correspondía al diseño se hizo durante la UAT.

En los programas SAP grandes, la integración suele ser lo primero que se cae entre los frentes de trabajo. Las interfaces cruzan los límites entre equipos, pero nadie es responsable de la coordinación. He visto a dos equipos de proyecto construir integraciones independientes para el mismo socio comercial, apuntando al mismo endpoint, sin saber el uno del otro. Ninguno lo descubrió hasta la UAT. Es un fallo estructural, no técnico.

Establezca pronto una gobernanza central de la integración:

1. Un backlog de integración compartido y visible para todos los frentes de trabajo
2. Un responsable con nombre para cada interfaz, con seguimiento durante toda la entrega
3. Puntos de coordinación entre los frentes de trabajo antes de cada despliegue importante
4. Una revisión de las dependencias entre interfaces antes de cualquier compromiso de go-live, con los endpoints y las colas compartidos secuenciados en el plan de cutover
5. Despliegue automatizado entre entornos, con las credenciales documentadas para cada panorama de sistemas

Los problemas de integración más difíciles rara vez están en las plataformas modernas. Están en los sistemas más antiguos que ocupan el centro de procesos críticos.

Los ERP heredados a menudo no pueden gestionar llamadas síncronas concurrentes. Envíe cinco llamadas API en paralelo y el servidor se ralentiza, se bloquea o pierde datos en silencio. La integración asíncrona ayuda solo si el sistema receptor puede procesar una cola, y muchos no pueden.

Los desajustes de protocolo son habituales y se descubren tarde. Usted diseña con OAuth2 y REST; el sistema heredado habla SOAP con un timeout fijo de 30 segundos y gestiona mal la renovación de tokens.

En un caso de cliente, un flujo de middleware fallaba todos los viernes porque el token emitido por un sistema de nómina de un tercero caducaba cada semana. Nadie lo notó hasta el segundo ciclo de UAT. Rarezas así son frecuentes y se comen los plazos.

La tabla recoge los riesgos que conviene revisar antes de la congelación del diseño.

Riesgo	Problema habitual	Qué hacer en el diseño
Límites síncronos	El sistema heredado se bloquea con llamadas en paralelo	Use mensajería asíncrona; escalone las llamadas mediante Event Mesh o Cloud Integration
Desajuste de protocolo	El sistema heredado rechaza REST u OAuth, o agota el tiempo de espera en SOAP	Confirme los protocolos y los timeouts antes de empezar el diseño
Límites de tasa de las API	Los procesos por lotes superan la limitación de terceros	Limite el ritmo en API Management; añada lógica de espera en el iFlow
Caducidad de tokens	Los flujos fallan en silencio en las ventanas de poca actividad	Programe los ciclos de renovación y supervise la caducidad
Formatos rígidos	Las cargas dinámicas rompen el análisis sintáctico del sistema heredado	Valide con muestras reales de producción
Sin plan alternativo	Las transferencias de archivos fallan sin reintento y los datos quedan atascados	Use un búfer en el middleware; incorpore reintentos y alertas en los iFlows

Para la versión entre nubes de estos problemas, vea mi artículo sobre por qué falla la integración de ERP con Salesforce.

La integración no se rompe como lo comprueban las pruebas funcionales. Falla bajo presión de tiempos, cuando se solapan los trabajos en segundo plano y cuando las entradas llegan en volumen en lugar de una a una. Una prueba funcional demuestra que una transacción se contabiliza y que un mensaje aparece en el log. No demuestra qué ocurre cuando la primera ejecución de nómina envía un aluvión de IDocs. En un proyecto, un IDoc que parecía limpio en las pruebas de integración de sistemas bloqueó la cola cuando llegaron los volúmenes reales de nómina. Solo las pruebas de carga lo detectaron.

Las pruebas de interfaces deben cubrir:

1. Volúmenes de datos realistas con usuarios concurrentes
2. Interrupciones del servicio y comportamiento de recuperación
3. Timeouts y reintentos en el middleware y en los sistemas back-end
4. Procesos por lotes que se ejecutan junto con llamadas en tiempo real
5. Cierres de mes y otros periodos de máxima carga

Los entornos de desarrollo están limpios. Los bloqueos mutuos, las condiciones de carrera y la limitación aparecen en la UAT y en preproducción, donde los demás sistemas y las ventanas de procesos por lotes están activos, así que haga allí las pruebas de carga. Reparta con claridad la responsabilidad: los equipos funcionales validan los resultados de negocio en todo el flujo, los equipos de integración se encargan de los logs, los reintentos y los flujos de excepción, y los responsables de proyecto confirman la cobertura. Mi guía sobre las pruebas de rendimiento en SAP trata la parte de carga.

Integration Advisor propone mapeos para formatos B2B estructurados. Con socios que siguen convenciones estrictas, ahorra mucho tiempo de configuración. En integraciones empresariales con sistemas heredados, campos a medida, lógica condicional y reglas sin documentar, es un punto de partida.

Un equipo con el que trabajé esperaba una cobertura de mapeo del 80 %. La cobertura real rondó el 40 %. El resto hubo que personalizarlo, validarlo con el negocio y probarlo a mano.

No resuelve la lógica de negocio que se acumuló de manera informal durante años (condiciones de pago, categorías de precios, convenciones de unidades), las reglas condicionales basadas en el contexto del negocio ni las excepciones fuera del formato estándar. Eso necesita aportación funcional. Sin ella, las interfaces quedan bien mapeadas desde el punto de vista técnico y erróneas desde el lógico en casos concretos.

La integración se deteriora tras el go-live cuando la documentación se queda atrás y la responsabilidad no es formal. Una documentación útil recoge los mapeos de campos y la lógica de transformación, así como los detalles de autenticación: endpoints, renovación de tokens y rotación de credenciales. También cubre el tratamiento de errores, las reglas de contingencia y los volúmenes esperados en ventanas críticas como el cierre de mes y la nómina. La prueba: ¿podría alguien que se incorpore la semana próxima al equipo de soporte diagnosticar una interfaz que falla solo con la documentación?

Cada interfaz, incluso la de bajo volumen, necesita un responsable con nombre para la supervisión, la escalada y los cambios del ciclo de vida. Sin él, los fallos rebotan entre Basis, el middleware y los equipos funcionales mientras el negocio espera. Tras el hypercare, la supervisión tiende a diluirse. Establezca revisiones periódicas de los logs de errores, un traspaso formal del proyecto a soporte y niveles de servicio acordados entre el negocio y TI. La integración desatendida está detrás de muchas de las contabilizaciones retrasadas, las facturas perdidas y los informes financieros desalineados que afloran semanas después del go-live.

¿Qué es SAP Integration Suite y en qué se diferencia de CPI?

Cloud Integration, antes SAP Cloud Platform Integration (CPI), es una capacidad más dentro de Integration Suite. La suite añade API Management para la exposición gobernada de las API y Event Mesh para la mensajería asíncrona. Incluye además Integration Advisor para propuestas de mapeo B2B, Open Connectors para aplicaciones en la nube de terceros y herramientas de evaluación y migración para PI/PO. Los equipos que la tratan como CPI con otro nombre suelen saltarse API Management y Event Mesh, y lo pagan después con vacíos de gobernanza.

¿Cuándo termina el soporte de SAP PI/PO?

SAP Process Integration y Process Orchestration 7.5 están en mantenimiento estándar hasta finales de 2027. Los clientes pueden contratar un mantenimiento ampliado opcional hasta finales de 2030, y después termina el soporte de SAP. Integration Suite incluye una aplicación Migration Assessment para dimensionar cada escenario y herramientas de migración para trasladar los artefactos de forma semiautomática. Empiece con un plan por oleadas en lugar de esperar a la fecha límite.

¿Cuándo conviene usar contenido estándar y cuándo desarrollo a medida en la integración con SAP?

Use contenido estándar cuando el escenario sea de SAP a SAP, esté cerca del proceso de referencia de SAP y sea relativamente sencillo. Desarrolle a medida cuando el proceso se haya alejado del modelo de SAP, cuando las rarezas de los sistemas heredados requieran un tratamiento específico o cuando la lógica condicional y de varios pasos obligue a cambios profundos en el paquete estándar. Decídalo en la fase de blueprint; reconstruir un flujo estándar modificado en exceso bajo la presión del go-live cuesta más que un desarrollo a medida limpio.

¿Qué causa los fallos de integración en SAP en programas complejos?

Sobre todo causas estructurales. Ningún responsable con nombre para la supervisión y la resolución de errores, de modo que los fallos rebotan entre equipos. Dos frentes de trabajo que construyen integraciones que comparten un endpoint o una cola sin saberlo. Sistemas heredados que no admiten llamadas concurrentes, algo que solo se descubre bajo carga. Y pruebas que salen limpias de forma aislada pero que nunca simulan el solapamiento de procesos por lotes ni el volumen máximo.

¿Cómo deben estructurarse las pruebas de integración para SAP Integration Suite?

Además de las pruebas funcionales, cubra volúmenes realistas, como el primer cierre de mes o la primera ejecución de nómina. Pruebe los procesos por lotes que se ejecutan junto con interfaces en tiempo real, la recuperación cuando un sistema posterior no está disponible y los límites de tasa de terceros durante los trabajos masivos. Haga las pruebas de carga y de rendimiento en entornos que se parezcan a producción, porque los sistemas de desarrollo limpios ocultan los problemas.

¿Cómo debe gobernarse la integración con SAP después del go-live?

Dé a cada interfaz un responsable con nombre para la supervisión, la escalada y los cambios. Mantenga la documentación al día: mapeos, autenticación y rotación de credenciales, tratamiento de errores y volúmenes esperados. Y construya un modelo de soporte a largo plazo con revisiones periódicas de los logs de errores, un traspaso formal del proyecto a soporte y niveles de servicio acordados. La integración que se vuelve invisible acaba descuidada.