SAP CPI: qué es, su arquitectura y el paso desde PI/PO

SAP CPI (Cloud Platform Integration) es el middleware en la nube de SAP para conectar sistemas SAP y no SAP. Hoy se llama Cloud Integration, la capacidad central de SAP Integration Suite en SAP Business Technology Platform (SAP BTP).

Mueve mensajes entre aplicaciones, transforma su formato y los enruta al destino correcto. Si todavía usa SAP PI/PO, el calendario importa: el mantenimiento estándar de SAP NetWeaver 7.5, que incluye PI/PO, termina a finales de 2027.

Esta guía explica qué hace CPI, cómo funciona su arquitectura, cómo se compara con PI/PO y cómo planificar el cambio. Está escrita para responsables de integración y CIO, no solo para desarrolladores.

He visto equipos pasar meses construyendo scripts personalizados frágiles para conectar sistemas SAP y no SAP. Al principio algo funciona. Luego una actualización del sistema cambia el nombre de un campo, o sale una nueva versión de una API, o el tráfico se duplica.

El script falla en silencio. Nadie se entera hasta que un informe extrae datos obsoletos o un pedido se queda sin procesar durante tres días.

CPI sustituye eso por flujos de integración gestionados y reutilizables. No porque sea más sencillo (a menudo no lo es), sino porque la arquitectura está pensada para monitorizarse y mantenerse. Las pequeñas decisiones que se toman al principio del diseño en CPI se acumulan como deuda técnica más rápido de lo que la mayoría de los equipos espera.

Mi consejo a cualquier empresa que siga en SAP PI/PO es pasar a SAP Integration Suite. El fallo de integración más común que veo es no dedicar suficiente tiempo a la integración.

La guía de migración de SAP describe Cloud Integration como la capacidad para diseñar y ejecutar flujos de integración en entornos cloud, on-premise e híbridos. Cubre escenarios de aplicación a aplicación (A2A), de empresa a empresa (B2B) y de empresa a administración pública (B2G). La mayoría de los consultores aún lo llaman «CPI» o «SAP CI», y no pasa nada.

SAP Integration Suite agrupa Cloud Integration con otras capacidades. Las principales son API Management, Event Mesh, Integration Advisor, Trading Partner Management, Open Connectors y Migration Assessment.

Qué hace CPI: mueve datos entre sistemas, transforma formatos de mensaje, enruta al destino correcto y gestiona errores y reintentos. Conecta sistemas SAP (S/4HANA, SuccessFactors, Ariba) y plataformas no SAP (Salesforce, Workday, ServiceNow) mediante adaptadores estándar.

Qué no hace: almacenar datos a largo plazo, sustituir un ERP o servir como herramienta ETL para la migración masiva de datos. Está hecho para mensajes en tiempo real o casi real. Usarlo como data warehouse o como herramienta de migración causa problemas de arquitectura más adelante.

CPI frente a SAP BTP: BTP es la plataforma completa: desarrollo de aplicaciones, datos, IA, analítica e integración. CPI es un servicio dentro de ella. Un arquitecto de BTP diseña entre servicios; un especialista en CPI es responsable de flujos, adaptadores, mapeos y conectividad.

El diagrama siguiente muestra los escenarios de integración para los que está hecho CPI. Nube a nube, on-premise a nube, empresa a empresa (B2B), empresa a administración pública (B2G) y conexiones con usuarios y dispositivos.

Entender la arquitectura de CPI no es solo cosa de desarrolladores. Según mi experiencia, los equipos que comprenden cómo gestiona CPI la integración a nivel estructural suelen tomar mejores decisiones de diseño desde el principio.

CPI funciona como un servicio en la nube multitenant en SAP BTP. SAP opera la plataforma, así que usted no mantiene sus propios servidores de integración. Cuando un flujo debe ejecutarse dentro de su propia red, Edge Integration Cell es un runtime híbrido opcional: diseña y monitoriza en la nube y ejecuta el flujo en su propia red.

El flujo de mensajes en la práctica

En el centro está el iFlow (flujo de integración). Cada integración en CPI se modela como uno, y cada iFlow lleva un mensaje de un origen a un destino en tres etapas:

1. Adaptador emisor. Recibe el mensaje del sistema de origen por SOAP, REST, OData, IDoc, SFTP, JMS, AS2 u otro protocolo.
2. Pasos de procesamiento. Mapeo, conversión de formato (de JSON a XML, por ejemplo), enrutamiento basado en contenido, llamadas a otros sistemas, cifrado y gestión de errores.
3. Adaptador receptor. Envía el mensaje procesado a su destino.

Los flujos se ejecutan de forma síncrona o asíncrona, según el caso de uso. No siempre es evidente cuál elegir, así que pruebe ambos con volúmenes reales.

La monitorización tiene un papel importante. Dispone de logs de procesamiento de mensajes, trazas y mensajes persistidos, cada uno con un propósito distinto. Durante las pruebas o la depuración, suelo alternar entre la traza y la persistencia según la profundidad que necesite.

Componentes de la arquitectura de SAP CPI

La tabla relaciona cada componente con su función en la arquitectura.

Componente	Qué hace	Papel en la arquitectura
Runtime de flujos de integración	Ejecuta los iFlows	Gestiona enrutamiento, mapeo, transformación y seguridad en tiempo de ejecución
Diseñador web	Editor gráfico para construir, configurar y desplegar iFlows	Donde los desarrolladores modelan los flujos; la lógica compleja sigue necesitando Groovy o JavaScript
Adaptadores	SOAP, REST, OData, IDoc, JDBC, SFTP, JMS, AS2 y adaptadores específicos de SaaS	Conectan sistemas en la nube y on-premise
Seguridad	OAuth 2.0, SAML, TLS, gestión de certificados y claves	Protege credenciales y mensajes en tránsito
Monitorización y operaciones	Logs de mensajes, detalle de errores, reintentos, alertas	Permite a los equipos de soporte encontrar y corregir fallos
Contenido preempaquetado	Paquetes de integración entregados por SAP en SAP Business Accelerator Hub	Acelera los escenarios estándar con contenido probado
SAP Cloud Connector	Túnel seguro desde su red hasta SAP BTP	Llega a los sistemas on-premise sin exponerlos a internet
Edge Integration Cell	Runtime opcional en su propio centro de datos o nube privada	Para flujos que deben permanecer on-premise

Los scripts Groovy resuelven la lógica que los pasos gráficos no pueden. Suelo recomendar que sean ligeros, porque demasiado scripting genera problemas de mantenimiento después. Los paquetes están versionados, así que ningún cambio llega a producción fuera de un paquete desplegado.

Tres fechas condicionan ahora casi cualquier plan de integración.

1. 2027Termina el mantenimiento estándar de PI/POFinal de año, para SAP NetWeaver 7.5
2. 2028Se retira Cloud Integration en Neo31 de diciembre. Los tenants de Neo pasan a Cloud Foundry
3. 2030Termina el mantenimiento ampliado de PI/POFinal de año. La última parada para cualquier sistema PI/PO

Fuente: Nota SAP 1648480 y artículo de la base de conocimientos de SAP 3355661

1. A PI/PO se le acaba el camino. La nota SAP 1648480 fija el mantenimiento estándar de SAP NetWeaver 7.5, que incluye PI/PO, hasta finales de 2027, con mantenimiento ampliado hasta finales de 2030. El sistema no se detiene el 1 de enero de 2028, pero cada año posterior cuesta más mantenerlo.
2. Neo cierra. El artículo de la base de conocimientos de SAP 3355661 confirma que Cloud Integration en el entorno Neo de SAP BTP se retira el 31 de diciembre de 2028. Los tenants de CPI más antiguos en Neo deben pasar al entorno multicloud (Cloud Foundry), y ese cambio es un pequeño proyecto en sí mismo.
3. Lo híbrido tiene respuesta. Edge Integration Cell ejecuta flujos de Integration Suite dentro de su propia red. Eso elimina el motivo más habitual que daban los equipos para quedarse en PI/PO.

En lo comercial: si está en RISE with SAP, compruebe qué derecho de uso de SAP BTP incluye ya su contrato antes de comprar capacidad de Integration Suite por separado.

PI (Process Integration) y PO (Process Orchestration) son el middleware on-premise de SAP. Así se comparan con CPI.

Factor	SAP PI/PO	SAP CPI (Integration Suite)
Despliegue	On-premise, en sus servidores	Nube en SAP BTP; Edge Integration Cell para un runtime on-premise
Carga de mantenimiento	Alta: parches, actualizaciones, gestión de servidores	Menor: SAP opera la plataforma
Extensibilidad	Personalización profunda; más difícil de actualizar	Modular; actualizaciones más rápidas; menos control de bajo nivel
Licencias	Licencia más su propia infraestructura	Suscripción en SAP BTP, por edición
Dirección de la inversión	Solo mantenimiento, sin funciones nuevas	Desarrollo activo
Fin del mantenimiento estándar	Finales de 2027 (ampliado hasta finales de 2030)	No aplica (servicio en la nube)

La guía de migración de SAP trata Cloud Integration como el sustituto principal porque cubre la mayor parte de lo que hace PI/PO. Pregunte a SAP cómo se mide su edición y luego modélelo con sus volúmenes reales de mensajes antes de migrar. Algunas empresas descubren que su tráfico de integración es mayor de lo que creían.

La migración no es una conversión automática. El comportamiento de los adaptadores difiere entre PI y CPI, y una gestión de errores que funcionaba en PI puede comportarse de otra manera en CPI. Algunos flujos hay que reconstruirlos; otros pasan con pequeños cambios.

SAP ofrece dos herramientas oficiales:

1. Migration Assessment. Una capacidad de Integration Suite que se conecta a su sistema PO, extrae los escenarios de integración y estima el esfuerzo de trasladarlos. El tutorial de SAP explica la configuración.
2. Migration Tooling. Una función de Cloud Integration que semiautomatiza la migración de los objetos de configuración integrada (ICO) de PO a iFlows. Solo los escenarios evaluados como «Ready to migrate» o «Adjustment required» pueden migrarse con ella.

SAP Learning deja claro que ninguna vía de migración sirve para todos los clientes, y muchos ejecutan PI/PO e Integration Suite en paralelo durante el cambio. Las herramientas reducen el trabajo mecánico. No toman las decisiones sobre qué reconstruir y qué retirar.

Este es el plan por oleadas que uso como punto de partida. Ajuste las oleadas a su propio inventario.

Oleada	Qué se traslada	Por qué en este orden	Responsable	Criterios de salida
0. Inventario	Cada interfaz de PI: frecuencia, volumen, adaptador, criticidad, responsable	No se puede planificar lo que no se ha contado	Responsable de integración	Inventario aprobado por los responsables de negocio
1. Bajo riesgo	Flujos SAP a SAP con contenido estándar	Demuestra el modelo operativo y la monitorización	Responsable de integración	Dos semanas estable en producción, ruta de PI retirada
2. Socios	Flujos B2B y EDI con socios comerciales clave	Requiere ventanas de prueba con los socios y un cutover coordinado	Responsable de integración con compras y ventas	Cada socio lo confirma por escrito
3. Alto riesgo	Flujos de gran volumen, regulados o críticos para los ingresos	Se trasladan al final, con más ensayos	Arquitecto de integración	Prueba de volumen superada; vuelta a PI ensayada
4. Retirada	Apagado de PI/PO	Deja de pagar por dos plataformas	CIO	Todos los flujos migrados o retirados; licencias finalizadas

Mantenga una ruta de vuelta a PI en cada oleada hasta que el nuevo flujo haya funcionado sin errores en producción. El orden importa: demuestre el modelo operativo con flujos de bajo riesgo antes de tocar las interfaces que generan ingresos.

Las pruebas de integración son donde desaparece el tiempo. Planifique pronto las pruebas de regresión con socios B2B y destinos no SAP, porque esos fallan en silencio. Mi guía de pruebas en SAP explica cómo estructurar los ciclos de integración y regresión.

Si el cambio de PI/PO forma parte de un programa de S/4HANA, alinee los dos planes. Mi guía de migración de ECC a S/4HANA cubre las vías y los plazos del lado del ERP.

Los escenarios que veo con más frecuencia:

1. S/4HANA a SuccessFactors. Datos organizativos, plantilla y cambios de compensación. El contenido de integración estándar de SAP cubre los escenarios comunes; los flujos personalizados se ocupan de las desviaciones.
2. Compras heredadas a SAP Ariba. Pedidos de compra de salida, confirmaciones y facturas de vuelta. Normalmente bidireccional.
3. Datos financieros a SAP Analytics Cloud. Traslado de datos desde ECC o sistemas no SAP a SAC.
4. Salesforce a SAP. Operaciones cerradas que llegan a SAP para su entrega, facturación y actualización de stock. Mi artículo sobre por qué fallan las integraciones entre Salesforce y el ERP explica los errores de diseño.

Si el trabajo de integración ya se está retrasando en su programa, los retrasos en la entrega de SAP Integration Suite explica las causas habituales. El resumen de plataformas de integración de SAP compara las opciones una junto a otra.

¿Qué es SAP CPI y cómo se llama ahora?

SAP CPI significa Cloud Platform Integration. Ahora es la capacidad Cloud Integration de SAP Integration Suite en SAP BTP, junto con API Management, Event Mesh y las herramientas de integración con socios. «CPI» sigue siendo el nombre habitual para la construcción de flujos de integración.

¿Qué es SAP CI?

SAP CI es la abreviatura de SAP Cloud Integration, el nombre actual de lo que antes era SAP CPI. Ambos términos se refieren a la misma capacidad dentro de SAP Integration Suite.

¿SAP CPI es un middleware?

Sí. CPI es un middleware en la nube: se sitúa entre sistemas, transforma y enruta mensajes, y gestiona errores y reintentos. Sustituye a middleware on-premise como SAP PI/PO, y no almacena datos de negocio a largo plazo.

¿En qué se diferencia SAP CPI de SAP PI/PO?

PI/PO es un middleware on-premise que usted instala, parchea y opera. CPI es un servicio en la nube en SAP BTP que SAP opera por usted, con nuevos adaptadores y contenido que llegan de forma centralizada. Edge Integration Cell cubre los flujos que deben permanecer on-premise.

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

El mantenimiento estándar de SAP NetWeaver 7.5, que incluye PI/PO, termina a finales de 2027. El mantenimiento ampliado está disponible hasta finales de 2030. SAP ofrece Migration Assessment y Migration Tooling para ayudar a trasladar los escenarios a Integration Suite.

¿SAP CPI es lo mismo que SAP BTP?

No. SAP BTP es la plataforma: desarrollo de aplicaciones, datos, analítica, IA e integración. CPI es el servicio de integración dentro de ella.

Al definir el alcance del trabajo, el presupuesto y las competencias difieren: un arquitecto de BTP trabaja entre servicios, un especialista en CPI es responsable de flujos, adaptadores y mapeos.

Si está planificando el paso desde PI/PO o diseñando la integración de un nuevo programa de S/4HANA, empiece por el inventario de interfaces. Si quiere una segunda opinión sobre el plan antes de comprometerse, póngase en contacto conmigo.