WE21 — Port Definition for IDoc Interfaces

WE21 creates and maintains ports, the technical definition of where an IDoc goes physically once it leaves ALE processing, or where it is expected to arrive from. A port has a type (transactional RFC, file, ABAP-PI, Internet/XML) and, depending on type, a target RFC destination or a file directory and naming convention. The structural fact that causes most confusion: a port is purely a transport-layer definition. It does not know which message type, partner, or direction it serves. That binding happens in the partner profile (WE20), which points at a port by name. Consultants who edit a port expecting to change routing for a specific interface are often editing something shared by several unrelated partner profiles, and the fix intended for one interface silently breaks another.

WE21 is reached during initial ALE or EDI setup, when a new outbound or inbound IDoc interface is being wired to a target system, a third party via file exchange, or a middleware layer such as PI/PO acting as the tRFC or XML endpoint. It sits upstream of WE20: the port must exist before a partner profile can reference it. Consultants reach for WE21 specifically when an interface fails with a port-related error, when a new environment (QA, a new partner, a new middleware instance) needs its own destination, or when a file-based interface changes its drop directory. For interfaces built through SAP Cloud Integration or an API-based connection rather than classic IDoc/ALE, WE21 is irrelevant; it belongs to the IDoc transport layer, not to proxy or REST-based integration.

Start in SE16 on EDIPORT filtered by the port name in question; confirm the port type and, for file ports, the exact outbound and inbound path strings including trailing separators. If the port is tRFC or ABAP-PI, take the RFC destination name from that record into SM59 and confirm the destination is active, points at the intended target host, and authenticates successfully. To confirm which interfaces use a given port, filter EDIDC (the IDoc control table) by the port name field and status, and check whether stuck IDocs cluster on one port versus many, which indicates a port-level problem rather than a data problem.

WE21 is unchanged on S/4HANA; it remains part of the classic ALE/IDoc configuration layer and has no Fiori equivalent, because it is infrastructure configuration rather than a business transaction. What has changed is how often it gets used: newer integration scenarios built on SAP Cloud Integration or API-based connections bypass ports entirely, but WE21 remains relevant wherever an S/4HANA system still exchanges IDocs with a middleware layer, a legacy partner, or a file-based interface, including hybrid landscapes that bridge classic IDoc traffic into cloud integration flows.

Ownership splits by port type. File port directories and Basis-level connectivity belong to Basis; the RFC destination's technical health (SM59) is also Basis, though its business meaning belongs to the integration consultant. The functional or integration consultant owns which port a partner profile should reference and why. A clean handover names the exact port, its type, the RFC destination or file path it resolves to, and which partner profile and message type depend on it, so Basis is not left guessing which of several ports is safe to change.

WE20 is the natural next stop, since it is the object that actually binds a port to a partner and message type; most WE21 investigations start or end there. WE19 is useful for reproducing a failing IDoc against a known-good port configuration in a test run. WE41 covers outbound process codes, which determine what happens to an IDoc after it successfully leaves through a port, relevant when the port works but downstream processing still fails. SXMB_MONI is the next step when the port in question is an ABAP-PI or XML type feeding a PI/PO or middleware layer, to see whether the message even arrived on the other side.