ABAP Developmentintermediate

IDoc Part 5: Partner Profile, Port and RFC Configuration

Key takeaway

Configure the IDoc communication chain: logical systems (BD54, SCC4), RFC destinations (SM59), ports (WE21: tRFC, file, XML HTTP), partner profiles (WE20) with inbound and outbound parameters, and the typical configuration errors behind status 56, 29 and 02.

Explanation

📌 KEY POINTS
✅ Chain: logical system (BD54, client assignment in SCC4) → RFC destination (SM59) → port (WE21) → partner profile (WE20).
✅ Partner profiles are defined per partner number and type: LS (logical system), KU (customer), LI (vendor), with inbound and outbound parameters per message type.
✅ Most "configuration" IDoc errors are: no partner profile (status 56), port/RFC problems (status 02), wrong basic type or process code.
⚠️ System copies (e.g. production to QA) copy partner profiles and ports — check them immediately after the copy to avoid sending test data to real partners.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 3–4 used partner profiles. Now we set up the chain ourselves.

━━━━━━━━━━━━━━━━━━━━
▶ 1. LOGICAL SYSTEMS

BD54: define logical system names (e.g. ERPCLNT100, EXTWMS).
SCC4: assign the own logical system to the client.
Used as sender/receiver in ALE and in partner type LS.

━━━━━━━━━━━━━━━━━━━━
▶ 2. RFC DESTINATION (SM59)

Type 3 (ABAP connection) for SAP systems, type G/H for HTTP.
Test connection and authorization; user should be a system/communication user with IDoc authorizations.

━━━━━━━━━━━━━━━━━━━━
▶ 3. PORT (WE21)

Transactional RFC port: points to the RFC destination (most common for SAP-SAP and middleware).
File port: IDocs written to/read from a directory (legacy EDI converters).
XML HTTP port: IDoc XML via HTTP.

━━━━━━━━━━━━━━━━━━━━
▶ 4. PARTNER PROFILE (WE20)

Partner number + type (LS/KU/LI) + general data (agent for errors).
Outbound parameters per message type: receiver port, output mode, basic type (+ extension), message control (for output-based IDocs).
Inbound parameters per message type: process code, processing mode, (optional) message code/function.
For KU/LI partners: partner function (e.g. SP, AG) can be part of the key.

━━━━━━━━━━━━━━━━━━━━
▶ 5. TYPICAL ERRORS

56 — no inbound partner profile for sender/message type.
29 — error in ALE service (e.g. distribution model / filtering).
02 — error passing data to port (RFC destination, logon, receiver down) — see SM58.
37 — IDoc added incorrectly (control record errors).

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

SM59: test an ABAP connection used by an IDoc port.
WE21: display the tRFC port and its destination.
WE20: create a test partner profile for a customer with inbound ORDERS (process code ORDE).

✅ CHECKPOINT: you can set up and troubleshoot the IDoc communication chain.

Code example

ABAP Code

* ===== Configuration checklist for a new IDoc interface =====* Logical systems*   BD54  : define ERPCLNT100 (own) and EXTWMS (partner)*   SCC4  : client 100 -> logical system ERPCLNT100* RFC*   SM59  : destination EXTWMS_RFC, type 3 (or HTTP type G/H), test connection* Port*   WE21  : transactional RFC port EXTWMS_PORT -> RFC destination EXTWMS_RFC* Partner profile*   WE20  : partner EXTWMS, type LS*           outbound: message type WMMBXY, port EXTWMS_PORT, basic type, transfer immediately*           inbound : message type SHPCON, process code, background processing* ALE model (if ALE)*   BD64  : model view ERP -> EXTWMS with message types, distribute, generate partner profiles * ===== Quick report: partner profile inbound parameters (table EDP21) =====REPORT zidoc_partner_check. PARAMETERS p_sndprn TYPE edi_sndprn DEFAULT 'EXTWMS'. DATA: lt_edp21 TYPE STANDARD TABLE OF edp21,      ls_edp21 TYPE edp21. START-OF-SELECTION.  SELECT * FROM edp21 INTO TABLE lt_edp21 WHERE sndprn = p_sndprn.  IF sy-subrc <> 0.    WRITE: / 'No inbound parameters - IDocs would get status 56'.  ENDIF.  LOOP AT lt_edp21 INTO ls_edp21.    WRITE: / ls_edp21-sndprt, ls_edp21-mestyp, ls_edp21-evcode.   " EVCODE = process code  ENDLOOP.* Outbound parameters are stored in EDP13.

Real project scenario

After a production-to-QA system copy, QA sent real order confirmations to customers because the copied partner profiles still pointed to the production EDI middleware port.
The basis team added post-copy steps: change RFC destinations and ports to QA middleware, lock external partners, and check SCC4/BD54 logical systems (BDLS conversion). No further test messages reached customers.

Common mistakes

Missing inbound partner profile (status 56).
Wrong RFC user or password in SM59 (status 02).
Wrong logical system after system copy (BDLS not run).
Basic type in partner profile not matching the receiver.
No agent for error notifications.

Best practices

Document the full chain per interface.
Use dedicated communication users.
Post-copy checklist for ports and destinations.
Assign error agents in partner profiles.
Test connections before go-live.

Interview angle

Questions: "Which configuration is needed for IDocs?", "What is a partner profile?", "What does status 56 mean?"
Strong answer: logical systems (BD54/SCC4), RFC destination (SM59), port (WE21), partner profile (WE20: partner number/type LS/KU/LI, outbound: port, basic type, mode; inbound: process code, processing mode), BD64 for ALE; status 56 = no partner profile, 02 = port/RFC error (SM58), 29 = ALE service error; check after system copies.

Practice this lesson

Quick check

1. Outbound IDocs end in status 02. Where do you look first?

2. What is a key functional difference between transactional RFC (tRFC) and queued RFC (qRFC) when used for IDoc transfer between systems?

3. IDocs are delivered via:

Interview questions

1. What is a partner profile?

Answer it in your own words first, then compare.

2. Outbound IDocs were created but remain with communication errors to a new partner system. How do you check the configuration chain?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.