SM59 — RFC Destination Maintenance
SM59 maintains RFC destinations, the stored connection parameters (target host, system, client, logon data) that let one SAP system call another system, an external program, or an HTTP service. A green connection test proves the network path and stored credentials work; it does not prove the actual interface call, which may use a different destination, user, or timeout, will succeed.
This page covers RFC destination maintenance in SM59, the transaction Basis teams use to diagnose failed interface, batch and callout connections. It focuses on the diagnostic sequence for connection failures rather than the screen layout, since most incidents come down to a mismatch between what was tested and what the failing program actually calls.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,120 words
Purpose
SM59 is where RFC destinations are created and maintained: named entries that bundle a connection type (ABAP system, TCP/IP program, HTTP server), a target address, and logon data, so that ABAP code can call out to another system without hardcoding any of it. The structural fact that causes most confusion is that a destination is purely client-side configuration tested in isolation. Pressing Connection Test only proves that this system can reach the target host with the stored credentials at that moment. It says nothing about whether the actual failing program is even using that destination, whether it runs under a different user or client, whether the remote function module exists with the expected interface, or whether authorizations differ for the calling context versus a manual test.
When it is used
Reached for whenever an interface, background job, IDoc, or web service callout reports a connection or RFC-level error rather than a data or business-logic error: 'connection closed', 'user has no authorization to logon', 'destination not found', or timeouts on remote calls. It sits underneath every ALE/IDoc scenario, batch RFC, and system-to-system callout, and underneath many older HTTP integrations that still route through an RFC destination of type G or H. It is not the first stop for pure Fiori/OData failures reaching the front end (that starts in SICF and the gateway) but it is the right stop the moment an error message names a destination or references RFC.
How to use it in practice
- Open SM59 and locate the destination under the relevant connection type group (ABAP connections, HTTP connections to external server, TCP/IP connections)
- Check Technical Settings: target host, system number or instance, and whether it points to a specific application server or a load-balanced logon group
- Check Logon & Security: client, user, authentication method (password, current user, trusted system, SNC), and whether the password is stored or entered at runtime
- Run Connection Test to confirm basic network reachability and logon
- For type 3 destinations, run Remote Logon to confirm the stored user can actually log on interactively, which surfaces authorization or password issues the connection test can miss
- Save only after confirming the change matches what the calling program or interface configuration actually expects
Key data objects
- RFCDES - the destination header: destination name, connection type, target host or program ID, load balancing settings, and pointers to the logon data used at runtime
- RFCDOC - short descriptive text maintained against each destination, used for documentation rather than logic
- secure storage (not a plain transparent table) - holds the encrypted password when a destination is configured with stored logon credentials rather than current-user or trusted-system logon
How to prove it in the data
Run SE16 on RFCDES filtered on the destination name in RFCDEST and compare RFCTYPE, RFCHOST, RFCSYSID, RFCCLIENT and the stored user against what the interface configuration or job variant actually references, since a common cause of confusion is two similarly named destinations. Cross-check the timestamp of the failure against SM21 system log entries for RFC or communication errors on both source and target, and against ST22 for short dumps naming CALL_FUNCTION or CALL_FUNCTION_REMOTE_ERROR with the destination name in the dump context.
ECC vs S/4HANA
SM59 itself is unchanged on S/4HANA and remains the place to maintain classical RFC destinations for ABAP-to-ABAP and TCP/IP callouts. Newer outbound scenarios, particularly OAuth-based cloud integrations, are increasingly modeled through communication arrangements and communication systems in the Fiori administration apps, which generate or reference destinations under the covers rather than replacing SM59 outright. For interfaces still built on classic RFC or IDoc, diagnosis in SM59 works exactly as it did in ECC.
Common pitfalls and how to diagnose them
- Test passes but interface still fails: the interface configuration, IDoc port, or program may reference a different destination name than the one manually tested, or call it under a different user via a background job. Confirm the exact destination name and user context the failing program uses before touching SM59 at all.
- Authorization failure at the target, not the network: connection test succeeds because it only opens a session, but the actual remote function call fails with an authorization error. Check S_RFC and, where relevant, S_RFCACL on the target system for the function group actually being called, not just logon authority.
- Load-balanced destination pointing at a dead or overloaded group: destinations that use a logon group rather than a specific instance can fail intermittently if one or more application servers in that group are down. Confirm instance health with the app server list before assuming the destination definition itself is wrong.
- Locked or expired background user: a shared RFC user hitting password expiry or account lock causes a sudden burst of failures across every interface that shares the destination, and the error text can look like a network problem. Check the user's lock and password status before touching connection parameters.
- Timeout set too short: raising the timeout value is the reflex fix, but a short timeout is usually a symptom of a genuinely slow remote call. Raising it without checking the remote side's performance just delays the failure and hides the real bottleneck.
- Broken trust or SNC after a system copy or refresh: trusted-system relationships and SNC certificates are tied to system identity and can silently break after a refresh, landscape rename, or certificate rotation, producing logon failures that look identical to a bad password.
Whose problem this is
Basis owns creation, security settings, and trust configuration of RFC destinations. Functional and interface teams identify which destination an interface uses and describe the failing behavior. A useful handover names the exact destination, the calling program or job, the client and user involved, the error text with timestamp, and whether a manual connection test was already run and with what result.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/sm59ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.