Lesson 2 of 6
Ports: file, tRFC and XML HTTP
9 min
Listen to this lesson
A port answers one question: how does an IDoc physically leave this system, and how does it come in? SAP's IDoc documentation is blunt that at least one port must exist for each external system. You maintain ports in WE21, where they are grouped by port type in a tree on the left. Port definitions are client-independent.
| Port type | How IDocs move | Typical use |
|---|---|---|
| Transactional RFC (tRFC) | Each IDoc or packet is sent by tRFC to an RFC destination; the receiver confirms each transaction ID | Middleware with an IDoc adapter such as PO 7.5; ALE between SAP systems |
| File | IDocs are written as flat files in a directory; inbound files are read from a directory | EDI subsystems and translators that exchange files on a shared file system |
| XML file | IDocs are written as IDoc-XML files to a directory | Data transfers and tools that read XML files |
| XML HTTP | IDoc-XML is posted over HTTP to an RFC destination of type HTTP | HTTP-based receivers; SOAP-based IDoc receivers such as Cloud Integration's IDoc sender adapter |
| ABAP-PI (programming interface) | The IDoc is handed to a function module you write instead of an external system | Special custom processing |
| CPI-C | Legacy link to R/2 systems | Historic; not used in new designs |
The port types in WE21 and where each fits.
Transactional RFC ports
A tRFC port is the workhorse for middleware. You create it under Transactional RFC in WE21, either with a system-generated number or a name of your own, and enter the RFC destination. You also choose the IDoc record types version, which for any current receiver is "SAP Release 4.x". When the IDoc interface passes an IDoc to the port, it gets status 03 (data passed to port OK). Because tRFC guarantees exactly-once delivery by transaction ID, a temporary network problem leaves the call in the tRFC queue (SM58) to be retried instead of losing the IDoc; status 12 (dispatch OK) is set only when report RBDMOIND (transaction BD75) later confirms that the tRFC call reached the receiver; SAP does not set it by itself.
File ports
A file port writes IDocs to a directory and reads them from one. You define the outbound directory and a file name, usually through a function module such as EDI_PATH_CREATE_CLIENT_DOCNUM that builds a unique name per client and IDoc number, and optionally an outbound trigger that starts the subsystem by command. For inbound, the subsystem places a file and starts processing, typically through the startrfc program calling the IDoc inbound function, or a job reads the directory. File ports suit traditional EDI translators that run on the same network and exchange flat files. Their weakness is control: a file can sit unread in a directory, and neither side knows unless someone monitors the folder.
XML HTTP ports
An XML HTTP port sends IDoc-XML to an HTTP destination. In WE21 you enter the RFC destination (type G or H) and the content type, text/xml or application/x-sap.idoc. SAP Cloud Integration's IDoc sender adapter receives IDocs as SOAP web service calls, so when Contoso moves its EDI flows to SAP Integration Suite after hypercare, Theo's team will most likely switch these partners from the tRFC port to an XML HTTP port that uses the SOAP protocol option; course sap-pim-205 covers that setup in detail.
- Does the receiver run an SAP IDoc adapter reached by RFC (PO, PI or another SAP system)?Yes → tRFC port with a type T or type 3 destination · No → next question
- Does the receiver accept IDoc-XML over HTTP or SOAP (for example Cloud Integration)?Yes → XML HTTP port with an HTTP destination · No → next question
- Does the receiver exchange files on a shared directory (classic EDI translator)?Yes → file port (flat IDoc) or XML file port (IDoc-XML) · No → next question
- Must a custom ABAP program take the IDoc instead of an external system?Yes → ABAP-PI port · No → revisit the architecture with the integration lead
One port, many partners
Ports are per receiving system, not per business partner. All of Contoso's EDI customers and suppliers go through Process Orchestration, so every outbound partner profile row in CMP names the same port, XP1_PO. PO decides from the IDoc control record (receiver partner type and number, message type) which trading partner gets the file. A VAN or second translator would get its own port. This is why changing a port is a high-impact change: it reroutes every partner that uses it.
| Port type | Delivery guarantee | Visibility of failures | Effort to operate |
|---|---|---|---|
| tRFC | Exactly once per transaction ID, with retry | Status 02 or entries in SM58 | Low; standard monitoring |
| File | Depends on the file handling around it | Files left in folders are invisible unless monitored | Medium; directory housekeeping and triggers |
| XML HTTP | HTTP response per call; retries depend on setup | Status 02 with the HTTP error | Low to medium; certificates and HTTP settings |
What would you do?
Outbound ORDRSP IDocs in CMQ stop with status 02 (error passing data to port) after a weekend. Nothing changed in the partner profiles. What should Sam, the Basis lead, check first?
- A port defines how IDocs leave and enter; at least one port is needed per external system, and ports are client-independent.
- tRFC ports suit middleware with an IDoc adapter (PO 7.5); file ports suit classic translators; XML HTTP suits HTTP and SOAP receivers.
- Status 03 means the IDoc was handed to the port; status 02 means passing it to the port failed.
- One port usually serves all partners behind the same middleware, so a port change reroutes every one of them.
Check your understanding · not graded
Lesson check
1. A supplier sends EDI 850s through middleware that calls SAP over RFC. Which WE21 port type fits the outbound response path?
2. What does outbound IDoc status 03 mean?
3. Which content types can an XML HTTP port send?