The building blocks of an SAP EDI setup

When Great Lakes Fleet Services sends an 850 and SAP S/4HANA creates sales order 1000457, five pieces of configuration did their job without anyone noticing. When one of them is wrong, the IDoc stops with a status code and someone asks the EDI consultant why. This course teaches those five pieces in the order the system uses them, with Contoso Motor Co.'s real setup as the example: the conversion landscape CMD, CMQ and CMP, and SAP Process Orchestration 7.5 in XD1, XQ1 and XP1, which carries the EDI flows until after hypercare.

How they fit together

On the way out, an application such as sales decides to send output (course sap-edi-202 covers how). The IDoc interface reads the partner profile for the receiving partner and message type, uses its process code to call the function module that fills the IDoc, and hands the IDoc to the port named in the profile. The port uses an RFC destination to reach the middleware. On the way in, the middleware calls SAP, the IDoc is saved, and the IDoc interface looks up the inbound partner profile for the sender and message type to find the process code that posts it.

Logical systems

A logical system is a name for a client of a system, maintained in transaction BD54 and assigned to the client in SCC4. SAP uses it as the system's own identity in IDoc control records (sender or receiver partner of type LS) and in documents created by distributed processes. Contoso follows the common convention of system ID, "CLNT" and client: CMDCLNT300, CMQCLNT100 and CMPCLNT100. Logical system definitions are client-independent, so every client in the system sees the same list; the assignment to a client is per client.

Do EDI partners need logical systems? Usually not. Great Lakes is not an SAP system; it is a customer, so it appears in partner profiles as partner type KU with its customer number. Lakeside Components is a supplier, partner type LI. You define a logical system for a partner only when you exchange IDocs with another system as a system, partner type LS, which is typical for ALE scenarios such as master data distribution between SAP systems. But your own client always needs one, and after every system copy the logical system name inside the copied data must be converted with BDLS so CMQ stops calling itself CMP.

RFC destinations

An RFC destination (SM59) is the technical address. For SAP Process Orchestration 7.5, which is a Java-only system at Contoso, the IDoc adapter (the Advanced Adapter Engine version, IDoc_AAE) listens as a registered server program at a gateway, so the S/4HANA side uses a TCP/IP destination (type T) with the registered program ID that the PO team configured. To another ABAP system you would use an ABAP connection (type 3). For XML over HTTP you use an HTTP destination (type G or H). Contoso names its destinations after their target: XQ1_IDOC_AAE from CMQ and XP1_IDOC_AAE from CMP.

The development-side objects

Configuration consultants rarely create message types or basic types, but they must know where they live, because an error often points to them. WE81 lists message types; WE82 assigns basic types (and extensions) to message types per release; WE30 and WE31 develop IDoc types and segments; WE57 links inbound function modules to message and basic types; WE41 and WE42 maintain outbound and inbound process codes; WE60 shows IDoc type documentation. For daily operations you use WE02 and WE05 to display IDocs, BD87 to monitor and reprocess, and WE19 to test.