RFCDES table — RFC Destination Definitions Table

Each row in RFCDES is one RFC destination as seen in SM59: a named connection the local system can use to call out to another ABAP system, a non-SAP system over TCP/IP, an HTTP endpoint, or an internal loopback connection. The row carries the connection type, the target host and system identification, the logon method (fixed user, current user, trusted system, or SNC), and various technical flags such as whether tracing is switched on. It does not carry a live connection or a status; it is purely the configuration record that RFC, IDoc, and BAPI calls resolve at runtime to know where to send the request and how to authenticate. Load balancing entries, gateway destinations, and connections used by background jobs and interfaces all live here as well.

RFCDES is small and client-independent, so there is no client field to restrict on and no volume problem. Selection is always by RFCDEST, or by RFCTYPE when scanning for every HTTP or every ABAP-type destination in the system. Because the table is cross-client, a query run in a test client will return destinations that were actually created and are being used by a completely different client on the same system, which is a common source of confusion when comparing environments. Password and secured logon data are not visible in this table by direct read; they sit in a separate secure storage layer and are not something to go looking for here.

An interface is failing with a connection error and the team suspects the destination was pointed at the wrong host. Select RFCDES where RFCDEST equals the destination name quoted in the error, and read RFCHOST, RFCSYSID, RFCCLIENT, and RFCTYPE directly. Compare RFCHOST against the actual target system's address rather than trusting the destination's description text in SM59, which is free text and frequently stale or copied from a template destination.

RFCDES is unchanged in shape between ECC and S/4HANA on-premise; SM59 and the underlying table continue to work the same way. What changed is the broader connectivity landscape around it: cloud-to-cloud and cloud-to-on-premise scenarios increasingly route through the Cloud Connector and BTP destination configuration rather than a classical SM59 entry, so on an S/4HANA system integrated with BTP, some connections a consultant expects to find in RFCDES may instead be configured entirely outside the ABAP stack.

Basis owns RFCDES and SM59 as a technical connectivity object, including host names, load balancing, and secure storage of credentials. The interface or integration team supplies the business requirement for what needs to connect to what and which user or trust relationship should be used, but the actual destination configuration and any change to it goes through Basis, particularly in productive landscapes where a wrong host entry can silently redirect live traffic.

TBDLS holds logical system definitions that point back to an RFCDES entry for ALE distribution. EDP13 partner profiles reference a port that in turn resolves to an RFC destination for IDoc outbound processing. ARFCSSTATE and ARFCSDATA record the transactional RFC calls actually sent through a destination, useful when a destination is suspected of silently failing. TRFCQOUT and TRFCQIN hold queued RFC calls awaiting or blocked on delivery through a given destination. SM59 is the maintenance transaction for RFCDES itself.