SAP SM59 RFC Destination Setup: Configuration, Testing, and Troubleshooting

SM59 is the central SAP GUI transaction for creating and maintaining RFC destinations. A destination stores the technical details that an ABAP program, integration process, or background job uses to reach another SAP system or an external service.

A reliable setup combines the correct destination type, reachable network endpoints, valid authentication, and a successful connection test. Keep the destination name, target client, technical user, and transport or change documentation together so that later troubleshooting has an auditable starting point.

01Plan the RFC destination

Before opening SM59, collect the target system details and decide which connection behavior the calling application requires. Confirm the target host, system number, client, logon language, user, authentication method, and whether the connection needs trusted authentication or SNC protection.

For an SAP-to-SAP connection, coordinate the settings with the target system administrator. The target system must accept the network connection and the target user must have the authorizations required by the remote-enabled function modules or business process.

Use SAP Basis system administration as the operational context for documenting ownership, changes, and monitoring responsibilities around the destination.

02Choose an SM59 destination type

The destination type determines the protocol and configuration fields available in SM59:

• ABAP Connection (type 3): Connects to an SAP ABAP system using its application server or message server details.
• HTTP Connection to External Server (type G): Sends HTTP or HTTPS requests to an external endpoint.
• TCP/IP Connection (type T): Connects to an external program through TCP/IP, commonly with a registered server or an SAP gateway configuration.
• Internal Connection (type I): Represents communication within the same SAP system.

Select the type that matches the interface design. A type 3 destination is appropriate for RFC communication with another ABAP system; an HTTP destination is appropriate when the receiving interface is an HTTP endpoint. The destination type cannot compensate for a protocol mismatch.

03Create the destination in SM59

1. Start transaction SM59 in SAP GUI.
2. Expand the relevant destination type in the navigation tree.
3. Choose Create and enter a unique destination name.
4. Maintain the Technical Settings tab.
5. Maintain the Logon & Security tab when the destination requires an SAP user, language, client, SNC, or another security setting.
6. Save the destination in the appropriate package or as a local object according to your change policy.
7. Record the owner, target system, purpose, and dependent interfaces.

For a type 3 destination, maintain the target application server and system number, or configure the message server and logon group when the design uses load balancing. Enter the target client and credentials on Logon & Security when the destination performs an authenticated logon.

Use a dedicated technical user with only the authorizations needed by the calling interface. Store credentials through the supported SAP configuration fields and protect access to SM59 because destination maintenance can expose connection and authentication details.

04Run the SAP RFC connection test

Open the saved destination and choose Connection Test. For a type 3 destination, the result confirms whether SAP can reach the target system and establish the RFC connection. Review the returned response time, target host, system number, and error text.

A successful connection test confirms transport-level communication and the destination's basic connection parameters. It does not prove that a particular remote-enabled function module will succeed with the calling user's authorization.

Run Remote Logon when you need to verify that the maintained credentials can log on to the target client. Run Authorization Test when you need to check the authorization behavior associated with the destination user. Use these tests only with an approved technical account and within the target system's security controls.

For an overview of RFC concepts and calling patterns, see Remote Function Call (RFC).

05Validate the complete interface path

Test the real application or interface after the SM59 connection test succeeds. A business process can still fail because of an unavailable remote-enabled function module, missing target-system authorization, invalid business data, a locked user, or an application-level exception.

Check the calling program's response and correlate its timestamp with the target system's logs. For scheduled interfaces, verify the background job step, variant, execution user, and destination name. For synchronous calls, capture the transaction, program, function module, and precise error message.

Keep separate evidence for the connection test, remote logon, authorization test, and application execution. This separates network and destination configuration issues from ABAP and business-process failures.

06Troubleshoot failed RFC connections

Start with the exact SM59 error text and the destination type. Then work through the following sequence:

1. Confirm that the destination name is spelled correctly in the calling program or job.
2. Verify the target host, system number, client, port, and logon group against the current target-system configuration.
3. Check network reachability and firewall rules between the source application server and the target endpoint.
4. Confirm that the target SAP instance and required gateway or message-server services are available.
5. Validate the technical user's password status, lock status, client assignment, and authorization.
6. Repeat the connection test after each controlled change.
7. Run the application again and compare the new timestamp with target-system logs and traces.

A timeout usually directs attention to routing, firewall, DNS, host, port, or service availability. A logon failure points to client, user, password, SNC, or security settings. An authorization error requires analysis of the target user's roles and the function module or business operation being called.

When an RFC call ends with an ABAP runtime error, inspect the relevant dump in ST22 and correlate it with the calling transaction or job. ABAP dump analysis in ST22 provides a focused way to review the dump context.

For system-wide events, inspect the system log in SM21 and compare the event time with the RFC failure. SAP system log monitoring with SM21 covers that operational check.

07Maintain RFC destinations safely

Treat SM59 destinations as production configuration. Restrict create, change, and display access according to operational roles, review destinations that contain stored credentials, and remove obsolete entries through the normal change process.

Use clear naming conventions that identify the target system and purpose without exposing passwords or other secrets. Avoid reusing a technical user across unrelated interfaces because shared credentials make ownership and incident analysis difficult.

After a password, certificate, SNC identity, host, system number, or message-server configuration changes, execute the relevant SM59 tests and the dependent business process. Record the result and the change reference.

Review destinations periodically for unused entries, obsolete hosts, expired certificates, and technical users that no longer have a valid owner. Coordinate deletions with interface owners before removing a destination used by jobs or integrations.

08Operational checklist

Use this checklist when handing over a new or changed RFC destination:

• Destination name and type documented
• Source system and calling application identified
• Target host, system number, client, and logon group verified
• Technical user and authorization owner recorded
• SNC, certificate, or secure transport requirements reviewed
• SM59 connection test completed
• Remote logon or authorization test completed when applicable
• End-to-end interface test completed
• Related job, program, or business process documented
• Monitoring and escalation contacts assigned
• Change record and rollback information stored

09Conclusion

An effective SAP SM59 RFC destination setup matches the destination type to the integration protocol, uses accurate target-system settings, applies controlled authentication, and validates both the technical connection and the complete business process. When a test fails, the destination type and exact error message provide the starting point for separating network, logon, authorization, and application problems.