SAP
The CMS integrates with SAP ECC and S/4HANA through three protocols — RFC/BAPI, IDoc and OData (SAP Gateway) —, through SAP CPI (Cloud Integration) when the integration already goes through Integration Suite, and through the ready-made packs on top of RFC. They do not compete with each other: they solve different problems. This page says which one to use; the following pages detail each.
Which path to use
| RFC / BAPI | IDoc | SAP Gateway (OData) | SAP CPI | SAP Packs | |
|---|---|---|---|---|---|
| Who starts | The CMS calls SAP | SAP calls the CMS | The CMS calls SAP | The CMS calls the iFlow | — |
| Nature | Synchronous, request/response | Asynchronous, document-oriented | HTTP, request/response | HTTP and SOAP, request/response | Ready configuration on top of RFC |
| Used for | Reading and writing individual data | Receiving business documents in volume | Consuming OData services already published (Fiori apps, S/4HANA APIs) | Delivering to iFlows that already do the mapping to SAP | Classic shop floor scenarios |
| Example | Confirm production, read order 60003285 | Receive ORDERS, MATMAS, DELVRY | Read work centers, confirm an operation through the Fiori service | Send the confirmation to an iFlow /http/pp/confirmation | “Production confirmation by time” |
| Microservice | cms-sap-connector | cms-idoc-connector | None: plain HTTP, no SDK | None: plain HTTP, no SDK | Uses the RFC one |
| Page | SAP RFC / BAPI | SAP IDoc | SAP Gateway (OData) | SAP CPI | SAP Packs |
In practice, a typical deployment uses RFC for the operational flow (the MES confirms production, reads the order backlog) and IDoc for master data and business documents (material, sales order, delivery) — which is how SAP itself separates the two.
The packs are not a fourth path: they are RFC/BAPI already configured, with business field names in place of technical ones and SAP errors translated. Starting there avoids the hard way of finding out which BAPI to call.
SAP Gateway (OData) is the path when the service already exists on the SAP side — Fiori apps and S/4HANA APIs are OData —, or when the SAP team prefers publishing OData to opening RFC. It is plain HTTP: no SDK and no microservice, and one connection serves every service on the server.
SAP CPI is the path when the customer already integrates through Integration Suite: the iFlow does the mapping and talks to SAP, and the CMS delivers to it (or reads from it). It is plain HTTP too, and the connection is the tenant — with the optional management API to pick the iFlow from a list and know how each message ended inside it.
The architecture, and why it looks like this
Neither RFC side runs inside cms-api. Both live in separate microservices, because the SAP
NetWeaver RFC SDK is native C code: an addon crash would take down the API, the scheduler and the
workers with it. In a separate process, it only takes down the SAP integration.
And there are two microservices, not one, because an RFC Server is a long-lived listener registered with the SAP gateway — a completely different nature from a request/response client. A failure or restart of the listener must not affect the RFC client or the API.
Both services stay on the internal docker-compose network only, with no published port and
without going through nginx. Their endpoints, except /health, require the X-Internal-Token header
when the matching token is configured.
The shared prerequisite: the SDK
RFC/BAPI, IDoc and the packs depend on the official SAP NetWeaver RFC SDK (SAP Gateway and SAP CPI do not), used through node-rfc. There is no
emulation and no intermediate translation: the call leaves the connector straight for your SAP’s RFC
gateway, with the same protocol as a remote ABAP program.
The SDK is licensed by SAP and cannot be redistributed, so it does not ship inside the image — it is installed at deployment time, with the customer’s licence. The step-by-step is in SAP RFC / BAPI.
The SDK variant must match the container’s platform (Linux x86_64), not the SAP server’s (AIX,
for instance). Downloading the wrong variant is the most common cause of node-rfc build failure.
One connection, two configuration blocks
The SAP External Connection holds the configuration of both sides, in separate blocks:
- RFC client — how the CMS reaches SAP: application server or message server (with logon group), client, user, password, language, SAProuter, pool size and the function used in the connection test.
- RFC server (IDoc) — how SAP reaches the CMS: gateway host and service, Program ID and the logon used to load segment metadata.
The two blocks may point at different systems, and the IDoc one is only filled in when IDocs are received.
The connection language (sapLang) determines the language of the error messages SAP returns —
and Business Errors match by text. Changing the language after configuring means revisiting the
rules.
Security: what the CMS will not let you call
The function name configured in a Collection or Delivery goes through validation before it is saved and before it runs:
- it must be a valid ABAP identifier;
- it must not be in the fixed list of blocked functions:
RFC_ABAP_INSTALL_AND_RUN,RFC_START_PROGRAM,SXPG_COMMAND_EXECUTE,SXPG_STEP_COMMAND_EXECUTE,RFC_GET_TABLE_ENTRIES,BAPI_TRANSACTION_COMMITandBAPI_TRANSACTION_ROLLBACK; - it must not carry the user-management prefix (
SUSR_).
BAPI_TRANSACTION_COMMIT is blocked as configuration because the commit has a place of its own: the
commit after call option on the Delivery Definition. RFC_PING is always allowed — it is what the
connection test and the keep-alive use.
This is defence in depth, not the main protection. The real protection is the S_RFC role of the service user in SAP, restricted to strictly necessary function groups. A well-configured CMS with a badly configured SAP user is still a problem.