Send IDoc from SAP Cloud Integration to On-Premise SAP S/4HANA

This post flips the direction of the Medium article I published about receiving IDocs from on-premise S/4HANA into SAP Cloud Integration, so you can keep both flows side by side. Receive IDoc from SAP S/4 to SAP Cloud Integration

Architecture overview

An IDoc receiver channel in CPI calls SAP Cloud Connector’s reverse proxy, which tunnels the HTTPS /sap/bc/srt/idoc request down to the on-premise S/4HANA system. This setup keeps the backend hidden behind the virtual host/port that Cloud Connector publishes, and the adapter’s Location ID is how CPI chooses the correct connector tunnel when multiple connectors exist for the same subaccount. See the SAP Cloud Connector documentation for the supporting architecture and Location ID behavior.

Prerequisites

• SAP Integration Suite: an active tenant with the IDoc receiver adapter deployed, a credentials artifact for the technical user or OAuth client that will post XML to S/4HANA, and the appropriate roles so CPI can call an on-premise HTTP service. The SAP Cloud Integration documentation describes how to secure receiver adapters and store credentials.
• SAP Cloud Connector: installed in the same network as S/4HANA, registered to your Integration Suite subaccount, and configured with a virtual host/port mapping plus a Location ID for the backend. The connector’s access control list must expose /sap/bc/srt/idoc via HTTPS so only IDoc traffic is allowed.
• On-premise SAP S/4HANA: activate /sap/bc/srt/idoc in SICF/SRTIDOC, and configure an inbound partner profile (WE20) that contains the logical system, message type/basic type, and HTTP receiver port so the posted IDoc is processed by the right application. Refer to the SAP S/4HANA documentation for guidance on SRTIDOC services and partner profiles.

Step 1 — map the on-premise system in Cloud Connector

1. Under Cloud to On-Premise, add the Integration Suite subaccount record so the connector knows your tenant and records the Location ID that CPI will later select on the adapter.
2. Create a system mapping where the Internal Host/port point to the real S/4HANA server and the Virtual Host/port are what CPI should call instead of the backend host.
3. In the access control list add /sap/bc/srt/idoc as an HTTPS resource and set the access policy to “Path and All Sub Paths” so only the IDoc inbound service is reachable. The connector documentation lists these settings in its “Access Control” section.
4. Save the mapping and keep the Location ID handy; CPI uses it whenever more than one connector is registered to the subaccount.

Step 2 — build the iFlow that pushes IDocs

1. End your flow with the IDoc receiver adapter — pick the message type/basic type you intend to deliver so CPI can generate the XML payload automatically.
2. Point the adapter Address to https://<virtual-host>:<virtual-port>/sap/bc/srt/idoc, turn on the On-Premise switch, and keep the protocol as HTTPS because Cloud Connector only exposes secure tunnels.
3. Supply the credentials artifact that stores the technical user (or OAuth client) used for S/4 authentication before the request enters Cloud Connector.
4. Enter the Location ID recorded in Step 1 so CPI picks the correct connector when multiple proxies exist.

Step 3 — prepare the S/4HANA inbound plumbing

1. Activate the /sap/bc/srt/idoc service in SICF and register the runtime via SRTIDOC so the HTTP entry is reachable and bound to an inbound handler.
2. Define the inbound partner profile in WE20 (partner type LS) with the matching logical system, message type/basic type (for example, MATMAS05), and the HTTP receiver port.
3. Make sure the technical user has the authorization objects that allow HTTP calls to post IDocs; these requirements are described in the Integration Suite and S/4HANA docs.
4. If your scenario uses partner functions, queue names, or processing codes, enable them in the profile so the IDoc is routed to the correct application module.

Step 4 — validate and monitor

1. Use WE19 to create a test IDoc, populate the required segments, set the receiver port to the HTTP entry, and execute Standard Outbound Processing. This proves the format and partner setup before CPI sends production data.
2. Monitor the IDoc lifecycle in WE05/WE02 — the status codes progress from 03 (data passed to port) to 53 (application document posted), and the transactions expose dumps when the inbound processing fails (the Medium article linked above runs through these same status codes).
3. Open the Integration Suite Message Operations view to review CPI’s message log, inspect the IDoc adapter response, and rerun or replay the message if necessary. See the SAP Integration Suite documentation for the monitor’s capabilities.
4. If CPI never reaches the backend, check the Cloud Connector log files (default log/scc directory) to confirm the Location ID and virtual host mapping handled the HTTP call.

Troubleshooting highlights

• SRTIDOC registration errors: re-register the HTTP service in SRTIDOC and ensure the ICF node is active; missing runtime entries raise the familiar “service name is not registered” message.
• Receiver adapter returns 403/404: double-check the /sap/bc/srt/idoc ACL entry, use “Path and All Sub Paths,” and confirm the technical user credentials so Cloud Connector forwards the HTTPS call.
• IDocs stuck in status 51 or 29: these typically indicate inbound partner profile misconfigurations — review the logical system, message type, and receiving function module in WE20/WE57 so the IDoc arrives at the right application logic.

Where to go next

Once the CPI-to-S/4HANA flow is stable, revisit the reverse-direction article (Receive IDoc from SAP S/4 to SAP Cloud Integration) so you can document the full bidirectional architecture.