SAP CPI (Cloud Integration)

El CMS llama a los iFlows de SAP Cloud Integration (Integration Suite) por el endpoint del adaptador de entrada: HTTPS en /http/... y SOAP en /cxf/.... Es el camino cuando la integración con SAP ya pasa por el CPI — el iFlow hace el mapeo y habla con S/4HANA, y el CMS solo le entrega.

Como el SAP Gateway, es HTTP puro: no usa el SDK ni microservicio. Vale para los tres ambientes: Cloud Foundry, Neo y Edge Integration Cell.

Ver SAP para comparar con RFC/BAPI, IDoc y Gateway.

Cómo se arma

• La Conexión Externa es el tenant. Tiene dos partes, con credenciales separadas en el BTP:
  • el runtime, donde corren los iFlows — ahí van las Recolecciones y las Entregas;
  • la API de gestión (opcional), que el CMS solo lee: endpoints implementados y cómo terminó el procesamiento de cada mensaje.
• La Aplicación es del tipo SAP CPI y aparece en el grupo SAP en todas las pantallas. Su URL viene de la conexión y queda bloqueada.
• La ruta del iFlow va en cada Recolección (Ruta de la Recolección) y en cada Entrega (URI).

Ejemplo: runtime https://mitenant.it-cpi018-rt.cfapps.us10-001.hana.ondemand.com, Entrega con la ruta /http/pp/confirmacion. La llamada sale a https://mitenant.it-cpi018-rt.cfapps.us10-001.hana.ondemand.com/http/pp/confirmacion.

El sentido contrario — el iFlow llamando al CMS — no necesita esta conexión: el iFlow usa la Entrada HTTP o la API dinámica de Recolección, con un API Token, como cualquier sistema.

Qué preparar en el BTP

En Cloud Foundry, las credenciales salen de instancias del servicio SAP Process Integration Runtime, en Services › Instances and Subscriptions de la subcuenta (vale también para el trial):

En las dos, el Grant type es Client Credentials. Después de crear la instancia, cree una Service Key en ella: es el JSON que lee el CMS.

{
  "oauth": {
    "clientid": "sb-xxxx!b123|it-rt-mitenant!b456",
    "clientsecret": "....",
    "url": "https://mitenant.it-cpi018-rt.cfapps.us10-001.hana.ondemand.com",
    "tokenurl": "https://misubcuenta.authentication.us10.hana.ondemand.com/oauth/token"
  }
}

El url de la service key del runtime tiene -rt en el host; el de la API de gestión, no.

En Neo y en Edge Integration Cell lo habitual es usuario y contraseña de un usuario con el rol ESBMessaging.send.

Configurar la conexión

En Conexiones Externas, tipo SAP CPI (Cloud Integration), en el grupo SAP.

Pegar service key

Al lado de la URL del runtime y de la URL de la API de gestión está el enlace Pegar service key. Pegue el JSON entero y haga clic en Completar: se completan la URL, la URL del token, el client id y el client secret (en la service key de certificado, el certificado y la clave privada). El JSON no se guarda — solo los campos siguen en el Guardar, con los secretos cifrados.

Las dos service keys tienen el mismo formato, y pegar una en lugar de la otra es el error más común. Si la URL pegada en el runtime no tiene -rt (o la de la API de gestión la tiene), la pantalla avisa.

Runtime

Contraseña, client secret, clave privada y la contraseña de la clave quedan cifrados y nunca vuelven a la pantalla: al editar, dejarlos en blanco mantiene el actual.

API de gestión (opcional)

Complete la URL de la API de gestión — el url de la service key del plan api — y su credencial (OAuth 2.0 o Basic). En blanco, la conexión funciona normalmente; solo quedan desactivados el catálogo de iFlows y el estado en el SAP CPI.

La prueba de conexión

El runtime del CPI no tiene un “ping”, y un GET en un endpoint ejecuta el iFlow. Por eso, con el iFlow de prueba en blanco, Probar Conexión y el Keep Alive no llaman a ningún iFlow: obtienen el token (lo que prueba client id y secret) y verifican que el runtime responde. Un 401 o 403 ahí es credencial rechazada — en Cloud Foundry, casi siempre falta el rol ESBMessaging.send en la instancia.

Complete el iFlow de prueba solo con un iFlow de ping, sin efecto en SAP. Entonces la prueba pasa a ser un GET en él.

El botón Probar Conexión prueba también la API de gestión, cuando está configurada, y solo sale bien con las dos en línea. El Keep Alive prueba solo el runtime: la API de gestión caída no impide la Entrega, y no tumba la Aplicación.

La Aplicación

En el registro de Aplicaciones, elija el tipo SAP CPI y la conexión en el campo de Keep Alive. La URL de la Aplicación aparece bloqueada, con la URL del runtime, y cambia sola si la conexión cambia — junto con el destino de sus Entregas. La autenticación y los certificados no quedan en la Aplicación.

Recolecciones y Entregas

La ruta empieza en /http/ o /cxf/: el host viene de la conexión. Para una prueba de lectura, la Recolección HTTP_GET no necesita estar activa — el botón Probar del formulario abre el Banco de Pruebas y ejecuta la lectura.

Elegir el iFlow en la lista

Con la API de gestión configurada, el campo de ruta de la Recolección y de la Entrega gana el botón iFlows: la lista de los endpoints implementados en el tenant, con el nombre y la versión del iFlow, el tipo (HTTP o SOAP) y el estado del artefacto — STARTED en ejecución, ERROR implementado con error. Hacer clic en + completa la ruta.

• En la Recolección, solo se pueden elegir endpoints HTTP.
• En la Entrega, elegir un endpoint SOAP cambia el tipo a HTTP_SOAP, y elegir uno HTTP lo saca de ahí.
• Un endpoint en otro host no sale por esta conexión y queda deshabilitado.

Token CSRF

El adaptador HTTPS de entrada viene con CSRF Protected activado y rechaza POST, PUT, PATCH y DELETE sin un token válido. El CMS lo resuelve solo:

1. antes de la primera escritura en un endpoint /http/, hace un HEAD en el propio endpoint con X-CSRF-Token: Fetch y guarda el token y las cookies de la sesión;
2. las escrituras siguientes en el mismo endpoint reutilizan el token (renovado cada 20 minutos);
3. si el CPI rechaza el token (403 con x-csrf-token: Required), el CMS pide otro y reintenta una vez.

En el CPI el token es del iFlow: el de un endpoint no sirve para otro, así que cada endpoint tiene el suyo. El adaptador SOAP (/cxf/) no usa CSRF, y el CMS nunca pide token para él. Desactive la opción solo si los iFlows tienen la protección desactivada.

Otro usuario en una Recolección o Entrega

La credencial del runtime es la predeterminada. Cuando un iFlow exige otro usuario, elija una Credencial de la Aplicación en el campo Credencial de la Recolección o de la Entrega — la primera opción, De la Conexión SAP CPI, es la predeterminada. Solo cambia la autenticación; el token CSRF sigue viniendo de la conexión, guardado por usuario.

Estado en el SAP CPI

El CPI responde a la Entrega apenas la recibe. En un iFlow asíncrono — con cola JMS, o que llama a S/4HANA después de responder — la falla llega después, dentro del tenant, y el CMS mostraría “Procesado” sin saber nada.

Toda respuesta del CPI trae el id del log de procesamiento (SAP_MessageProcessingLogID). El CMS guarda ese id en cada intento de Entrega y de Recolección, con éxito o con falla, y lo usa de dos maneras:

En el detalle del mensaje, el panel Estado en el SAP CPI consulta la API de gestión y muestra, por intento: el estado en el tenant (COMPLETED, FAILED, PROCESSING, RETRY, ESCALATED…), el iFlow, cuándo terminó, el texto del error y el enlace Abrir en el Monitor del CPI. El tenant guarda los logs unos 30 días; más antiguo que eso, el panel dice que no lo encontró.

Por la alerta Falla en el iFlow (SAP CPI): el programador de sistema Check-sap-cpi-processamento revisa, cada minuto, las Entregas de las últimas 24 horas que el CPI aceptó y que todavía no tienen estado final. Cuando el iFlow termina en FAILED, ESCALATED o ABANDONED, dispara la alerta — una vez por intento.

La alerta nace pre-registrada, desactivada y sin destinatarios, al crear una Entrega para una Aplicación SAP CPI, junto al Error de Entrega. Para recibirla, actívela en Alertas y elija los destinatarios. Sin API de gestión en la conexión, el barrido no hace ninguna llamada.

Cuando falla

La falla de una Recolección o Entrega trae el texto que devolvió el iFlow, después del estado.