SAP RFC Destinations and SM59 Connection Types

An RFC destination contains technical endpoint, connection type, logon/authentication, gateway/router, language/client and performance/security options appropriate to the protocol. Type 3 ABAP connections are common for SAP-to-SAP RFC; Type T TCP/IP destinations connect registered/started external RFC programs; HTTP destination types cover web endpoints. Destinations are reusable infrastructure references consumed by CALL FUNCTION DESTINATION, IDoc ports, qRFC/bgRFC, trusted RFC and other frameworks. Password-based technical users, trusted systems and SNC/security options each create different risk and operational behavior.

Use SM59 when a supported SAP interface requires RFC/HTTP destination-based connectivity. Test the network/logon separately from the business call: connection test proves reachability at one level, authorization test/logon proves credentials/permissions, and the actual function call proves application authorization/data. Avoid storing broad high-privilege technical users because 'it fixes the connection'. For BTP/cloud scenarios, SAP BTP Destinations and Cloud Connector may replace or complement SM59.

RFC destinations sit under BAPI/RFC calls, IDoc tRFC ports, qRFC queues and some workflow/application integrations. WE21 can reference an RFC destination through a port. SM58 may show tRFC failures that ultimately use SM59 connectivity. Trusted RFC and principal propagation change identity flow; SNC/TLS/router settings change transport security. Monitoring requires identifying whether the incident is name resolution/network, gateway, authentication, authorization, or remote application logic.

An IDoc tRFC destination passes SM59 Connection Test but outbound calls fail with RFC_NO_AUTHORITY. Network and logon are working; the technical user lacks permission for the called function/application. Increasing timeouts or changing host would not help. The Security team adjusts the least-privilege role, then a function-level test succeeds. In a different incident, 'program not registered' on a Type T destination points to external RFC server registration/gateway, not ABAP authorization.

SM59 remains fundamental in S/4HANA on-premise/private cloud for RFC-based integration. BTP side-by-side designs increasingly use Destination service/Cloud Connector and released HTTP APIs instead. Clean-core principles affect which remote functions should be called, not merely whether the RFC route can reach them.

Basis owns destination/network/gateway configuration; Security owns users/trust/SNC/auth; integration teams own interface mapping and endpoint lifecycle; application teams own business-call errors after connectivity is proven.

SM59 has a detailed TCode page. RFC-vs-BAPI and RFC-types explain how destinations are consumed. WE21 connects IDoc ports to technical communication; SM58/SMQ* monitor reliable RFC layers.

Production verification: Capture destination or caller and target system, RFC user or propagated identity, function or BAPI name, business key, complete RETURN or message set, transaction and commit state, and any SM59, SM58 or SMQ evidence. Separate communication success from application authorization and from durable business posting.

Operational readiness: For production readiness of SAP RFC Destinations and SM59 Connection Types, add an operational runbook that names the source owner, integration or platform owner, and target application owner; defines correlation, retry or replay and duplicate handling; and states where a support engineer can prove the last successful handoff. Test authentication expiry, receiver outage, malformed or business-invalid payloads, and ambiguous timeouts—not only the happy path. If the interface is asynchronous, document queue, retention and order behavior and how a corrected message is reprocessed without duplicating a business transaction.

Review checkpoint: Review checkpoint for SAP RFC Destinations and SM59 Connection Types: document one successful message and one intentionally failed message from source to target, including the correlation key visible in every participating monitor. Record whether the operation is synchronous, queued, retried or event-driven and what constitutes final business success. Verify secret and certificate ownership, expiry monitoring, destination or endpoint promotion between environments, timeout behavior, and the exact manual replay procedure. A support engineer should be able to determine within minutes whether the failure belongs to source data, BTP connectivity or security, middleware processing, target API validation, or downstream business posting.