Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 5

Configuration: logical systems, ports and partner profiles

10 min

Listen to this lesson

0:00 / 7:11

An IDoc only moves if the system knows who the partner is, how to reach it and what to do with each message type. Four configuration objects answer those questions. Testers do not usually maintain them, but they need to read them, because many integration test failures are configuration gaps that look like application errors.

Logical systemA name for a system that exchanges IDocs, for example the middleware or a partner SAP system (maintained through SALE / BD54)
RFC destinationThe technical connection: host, credentials, protocol (maintained in SM59)
PortThe channel IDocs use: transactional RFC, file or XML over HTTP; a tRFC port points to an RFC destination (WE21)
Partner profilePer partner and message type: direction, port, IDoc type, processing mode and process code (WE20)
The configuration objects behind an IDoc interface, from the system name down to per-message rules.
The Sign-Off Table · thesignofftable.com/academy/sap-int-201

Partner profiles

The partner profile (WE20) is the heart of IDoc configuration. SAP defines it in parts: a general profile for each partner, then separate outbound parameters and inbound parameters for each message type the partner exchanges. A partner is identified by a partner number and a partner type, for example LS for a logical system, KU for a customer or LI for a supplier.

SettingOutbound parametersInbound parameters
KeyPartner, partner type, message type (plus partner function and variants where used)Partner, partner type, message type
Where to send / how to processReceiver port and IDoc type (basic type and any extension)Process code that names the function that posts the IDoc
TimingTransfer IDoc immediately, or collect IDocs and send them in a batch jobTrigger immediately, or trigger by background program
Error handlingPermitted agent who receives work items when output failsPermitted agent who receives work items for errors
Output linkMessage control: application, output type and process code for output-driven IDocsNot applicable

Main settings in a partner profile. Exact field names vary slightly by release.

A partner profile has one general part and then separate outbound and inbound parameters per message type, which point on to a port or a process code.
The Sign-Off Table · thesignofftable.com/academy/sap-int-201

SAP's documentation notes two practical points. First, partner profiles are maintained per system and are generally not transported: they are created in each system, often in production after the master data exists. That makes them a classic cutover task and a classic cause of "it worked in CMQ but not in CMP". Second, SAP offers a fast-entry option that copies default values from Customizing (WE24 for outbound, WE27 for inbound), which keeps profiles consistent across many partners.

Process codes

A process code links an IDoc to the program logic that creates or posts it. On the inbound side it points to the function module that reads the IDoc and posts the business document, for example the standard function for inbound orders. On the outbound side, for output-driven IDocs, it points to the function that fills the segments from the application document. Process codes are maintained in WE42 (inbound) and WE41 (outbound).

What triggers an outbound IDoc

Outbound IDocs are created in one of three ways: by output control when a document is saved (a purchase order output with EDI as the medium), by ALE distribution of master data according to the distribution model (BD64), or by a program or job. In SAP S/4HANA, many documents use SAP S/4HANA output control rather than the older message control; check for each document type which framework your system uses, because the configuration and the monitoring differ.

Three different triggers create outbound IDocs, and the partner profile's output mode decides whether the IDoc leaves at once or waits in status 30 for a job.
The Sign-Off Table · thesignofftable.com/academy/sap-int-201
  1. Buyer saves POPurchase order 4500002210 for Lakeside Components (supplier 17300001): 500 pc CMC-RTR-200 at $42.00, value $21,000
  2. Output determinedEDI output is determined for the supplier and scheduled
  3. Partner profile readOutbound parameters for partner 17300001 (type LI) and message type ORDERS: port, ORDERS05, transfer immediately
  4. IDoc createdStatus 01 created, then 30 ready for dispatch, then 03 passed to port
  5. Middleware deliversThe platform maps the IDoc to the supplier's EDI format and sends it
Outbound IDoc path for a Contoso purchase order. The $21,000 PO is under the $25,000 approval threshold, so it needs no approval and is output at once.
The Sign-Off Table · thesignofftable.com/academy/sap-int-201

What would you do?

After the first mock conversion, inbound orders from Great Lakes Fleet Services fail in the converted copy with "partner profile not available". In CMQ they worked yesterday. What is the most likely cause?

Key points
  • Logical system, RFC destination, port and partner profile together define how IDocs move.
  • Partner profiles hold outbound and inbound parameters per partner and message type.
  • Process codes link IDocs to the function that creates or posts them.
  • Partner profiles are not transported; plan them as cutover tasks and compare them after go-live.

Check your understanding · not graded

Lesson check

  1. 1. Which transaction maintains partner profiles?

  2. 2. In inbound parameters, what does the process code determine?

  3. 3. An outbound IDoc sits in status 30 after the PO is saved. What should you check before raising a defect?

  4. 4. Why are partner profiles a cutover task?