Lesson 1 of 6
Connecting IDocs to Cloud Integration
8 min
Listen to this lesson
After hypercare, Theo's team moves Contoso's IDoc interfaces, about 25 of the 64 integrated configurations on SAP Process Orchestration (XP1), to Integration Suite. Two of them carry this course: purchase orders to Lakeside Components, an ORDERS05 IDoc that becomes an X12 850 file on Lakeside's SFTP server, and orders from Great Lakes Fleet Services, X12 850s received over AS2 that become sales orders. This course follows that work, from the connection to the regression pack.
In Cloud Integration, IDocs travel as SOAP over HTTP, not over RFC. S/4HANA sends IDoc XML to an endpoint of the IDoc sender adapter, and Cloud Integration posts IDoc XML to S/4HANA's IDoc SOAP service with the IDoc receiver adapter. Both directions need configuration on the S/4HANA side and in the flow.
Outbound: S/4HANA to Cloud Integration
| Object | Transaction | Contoso setting |
|---|---|---|
| HTTP destination | SM59, connection type G (HTTP connection to external server) | Target host: the tenant's runtime host; port 443; path prefix /cxf/ plus the IDoc sender adapter's address; SSL active |
| Port | WE21, port type XML HTTP | The destination above, content type Text/XML, SOAP Protocol selected |
| Partner profile | WE20 | Supplier Lakeside Components (partner type LI): outbound message type ORDERS, basic type ORDERS05, the XML HTTP port as receiver port |
| Output | NAST output for purchase orders | Output type NEU, medium 6 (EDI) for Lakeside, so saving PO 4500002210 creates the IDoc |
Outbound objects in S/4HANA. The same pattern serves every outbound IDoc interface; only the partner profile and output differ.
On the Cloud Integration side, the IDoc sender adapter's Address is a relative path such as /cmc/orders05/lakeside, so the full endpoint is https://<runtime host>/cxf/cmc/orders05/lakeside. SAP warns about prefix overlap: a sender calling /path/test may reach a flow deployed on /path, so give every interface its own distinct address. Access is controlled by the role required in the sender's authorization, by default ESBMessaging.send, or by a client certificate.
The adapter supports Exactly Once and Exactly Once In Order; which applies depends on how the sending system is configured. For in-order delivery it sets the headers SapPlainSoapQoS and SapPlainSoapQueueId from the IDoc's ARCKEY, and SAP asks you to apply SAP Note 3519275 in the sending system so the sequence holds when a message fails. It also sets headers you'll use constantly: SapIDocType, SapIDocTransferId (the sender's DOCNUM), SapIDocDbId, SapIDocContentType and SapMessageId.
Inbound: Cloud Integration to S/4HANA
S/4HANA receives IDocs over SOAP through the IDoc service registered with transaction SRTIDOC. SAP's setup guides use the values: URI SOAP application urn:sap-com:soap:runtime:application:idoc, web service definition GENERIC, call address (ICF path) /sap/bc/srt/idoc. Contoso's S/4HANA runs in the RISE data center, so the flow reaches it through SAP Cloud Connector.
| IDoc receiver adapter field | Contoso setting | Why |
|---|---|---|
| Address | http://<virtual host>:<port>/sap/bc/srt/idoc?sap-client=100 | SAP says to use HTTP with the virtual host configured in Cloud Connector |
| Proxy Type | On-Premise | The call goes through Cloud Connector |
| Authentication | Basic (User Credentials artifact) or Principal Propagation | Client Certificate isn't supported with On-Premise |
| IDoc Content Type | Application/x-sap.idoc | One IDoc per request, sequencing and Exactly-Once |
| SAP Message ID Determination | Reuse, or Map from a source ID | Keeps the message ID stable across retries (sap-pim-204) |
IDoc receiver adapter settings for an on-premise S/4HANA client 100 (CMQ).
The content type choice matters. Application/x-sap.idoc sends a single IDoc per request and enables message sequencing and Exactly-Once processing; the adapter uses the header SapMessageId, so keep it stable on retries. Text/XML allows several IDocs per request (composite messages, for example built with an Aggregator) but doesn't support Exactly-Once. For bulk messages, the response headers SapIDocTransferId and SapIDocDbId hold the first IDoc only; read SapIDocAssignMap or the response payload for the rest.
Tracing one IDoc across both systems
Support needs to get from an IDoc in WE02 to the message in Cloud Integration's monitor and back. Contoso's flows copy SapIDocTransferId (the S/4HANA IDoc number) into the header SAP_ApplicationID, which monitoring shows as the Application Message ID and lets you search. Inbound, the IDoc receiver's response gives the new IDoc number in SapIDocDbId, which the flow writes to the log as a custom header property. With both in place, Maria can give support a sales order, support finds the IDoc, and the IDoc leads to the message in seconds.
- IDocs reach Cloud Integration over SOAP: SM59 type G with path prefix /cxf/<address> and a WE21 XML HTTP port.
- The IDoc sender adapter sets SapIDocType, SapIDocTransferId, SapIDocDbId and SapMessageId; in-order delivery uses ARCKEY.
- Inbound uses SRTIDOC (/sap/bc/srt/idoc) and the IDoc receiver adapter, through Cloud Connector for on-premise systems.
- Application/x-sap.idoc: one IDoc, Exactly-Once; Text/XML: composite messages, no Exactly-Once.
Check your understanding · not graded
Lesson check
1. Which path prefix does the SM59 destination use to reach an IDoc sender adapter with address /cmc/orders05/lakeside?
2. Which WE21 port type sends IDocs from S/4HANA to Cloud Integration?
3. Which IDoc content type supports Exactly-Once processing in the IDoc receiver adapter?
4. A bulk response from the IDoc receiver contains five IDocs. Where do you find all five IDoc numbers?