SAP
El CMS integra con SAP ECC y S/4HANA por tres protocolos — RFC/BAPI, IDoc y OData (SAP Gateway) —, por el SAP CPI (Cloud Integration), cuando la integración ya pasa por Integration Suite, y por los packs listos sobre RFC. No compiten entre sí: resuelven problemas distintos. Esta página dice cuál usar; las páginas siguientes detallan cada uno.
Qué camino usar
| RFC / BAPI | IDoc | SAP Gateway (OData) | SAP CPI | Packs SAP | |
|---|---|---|---|---|---|
| Quién inicia | El CMS llama a SAP | SAP llama al CMS | El CMS llama a SAP | El CMS llama al iFlow | — |
| Naturaleza | Síncrono, request/response | Asíncrono, orientado a documento | HTTP, request/response | HTTP y SOAP, request/response | Configuración lista sobre RFC |
| Sirve para | Leer y grabar datos puntuales | Recibir documentos de negocio en volumen | Consumir servicios OData ya publicados (apps Fiori, APIs de S/4HANA) | Entregar a iFlows que ya hacen el mapeo hacia SAP | Escenarios clásicos de planta |
| Ejemplo | Notificar producción, leer la orden 60003285 | Recibir ORDERS, MATMAS, DELVRY | Leer puestos de trabajo, notificar una operación por el servicio Fiori | Enviar la notificación a un iFlow /http/pp/confirmacion | “Notificación de producción por tiempo” |
| Microservicio | cms-sap-connector | cms-idoc-connector | Ninguno: HTTP directo, sin SDK | Ninguno: HTTP directo, sin SDK | Usa el de RFC |
| Página | SAP RFC / BAPI | SAP IDoc | SAP Gateway (OData) | SAP CPI | Packs SAP |
En la práctica, una implantación típica usa RFC para el flujo operativo (el MES notifica producción, lee la cartera de órdenes) e IDoc para el maestro y el documento de negocio (material, orden de venta, entrega) — que es como el propio SAP separa las dos cosas.
Los packs no son un cuarto camino: son RFC/BAPI ya configurado, con los nombres de campo de negocio en lugar de los técnicos y los errores de SAP traducidos. Quien empieza por ellos evita descubrir a los golpes qué BAPI llamar.
El SAP Gateway (OData) es el camino cuando el servicio ya existe del lado de SAP — las apps Fiori y las APIs de S/4HANA son OData —, o cuando el equipo SAP prefiere publicar OData antes que liberar RFC. Es HTTP puro: no usa el SDK ni microservicio, y una conexión atiende a todos los servicios del servidor.
El SAP CPI es el camino cuando el cliente ya integra por Integration Suite: el iFlow hace el mapeo y habla con SAP, y el CMS le entrega (o lee de él). También es HTTP puro, y la conexión es el tenant — con la API de gestión opcional para elegir el iFlow en una lista y saber cómo terminó cada mensaje allá adentro.
La arquitectura, y por qué es así
Ninguno de los dos lados RFC corre dentro de cms-api. Los dos viven en microservicios separados,
porque el SAP NetWeaver RFC SDK es código nativo en C: un crash de addon derribaría la API, el
programador y los workers junto. En un proceso separado, derriba únicamente la integración SAP.
Y son dos microservicios, no uno, porque un RFC Server es un listener de larga duración registrado en el gateway SAP — naturaleza completamente distinta de una llamada request/response. Una falla o reinicio del listener no puede afectar al cliente RFC ni a la API.
Los dos servicios quedan solo en la red interna del docker-compose, sin puerto publicado y sin
pasar por nginx. Los endpoints, excepto /health, exigen el header X-Internal-Token cuando el token
correspondiente está configurado.
El prerrequisito común: el SDK
RFC/BAPI, IDoc y los packs dependen del SAP NetWeaver RFC SDK oficial (el SAP Gateway y el SAP CPI, no), usado a través de node-rfc. No hay
emulación ni traducción intermedia: la llamada sale del connector directo al gateway RFC de su SAP,
con el mismo protocolo de un programa ABAP remoto.
El SDK está licenciado por SAP y no puede redistribuirse, por eso no viene embebido en la imagen — se instala en la implantación, con la licencia del cliente. El paso a paso está en SAP RFC / BAPI.
La variante del SDK debe coincidir con la plataforma del contenedor (Linux x86_64), no con la
del servidor SAP (AIX, por ejemplo). Descargar la variante equivocada es la causa más común de falla
en la compilación de node-rfc.
Una conexión, dos bloques de configuración
La Conexión Externa de tipo SAP guarda la configuración de los dos lados, en bloques separados:
- RFC client — cómo el CMS llega a SAP: application server o message server (con grupo de logon), mandante, usuario, contraseña, idioma, SAProuter, tamaño del pool y la función usada en la prueba de conexión.
- RFC server (IDoc) — cómo SAP llega al CMS: gateway host y servicio, Program ID y el logon usado para cargar los metadatos de los segmentos.
Los dos bloques pueden apuntar a sistemas distintos, y el de IDoc solo se completa cuando hay recepción de IDoc.
El idioma de la conexión (sapLang) determina el idioma de los mensajes de error que SAP
devuelve — y los Errores de Negocio coinciden por texto. Cambiar el idioma después de configurar
exige revisar las reglas.
Seguridad: qué no deja llamar el CMS
El nombre de la función configurada en una Recolección o Entrega pasa por una validación antes de guardarse y antes de ejecutarse:
- debe tener formato de identificador ABAP válido;
- no puede estar en la lista fija de funciones bloqueadas:
RFC_ABAP_INSTALL_AND_RUN,RFC_START_PROGRAM,SXPG_COMMAND_EXECUTE,SXPG_STEP_COMMAND_EXECUTE,RFC_GET_TABLE_ENTRIES,BAPI_TRANSACTION_COMMITyBAPI_TRANSACTION_ROLLBACK; - no puede tener prefijo de gestión de usuarios (
SUSR_).
BAPI_TRANSACTION_COMMIT está bloqueada como configuración porque el commit tiene lugar propio: la
opción commit después de la llamada en la Definición de Entrega. RFC_PING siempre está permitida
— es lo que usan la prueba de conexión y el keep-alive.
Esto es defensa en profundidad, no la protección principal. La protección real es el rol S_RFC del usuario de servicio en SAP, restringido a los function groups estrictamente necesarios. Un CMS bien configurado con un usuario SAP mal configurado sigue siendo un problema.