SAP RFC Destination Setup Checklist (SM59)

0%

0 of 30 items complete

7 critical items still open - these are the highest-risk gaps.

Download checklist:

Plan the connection

Document source system, target system, client and business purpose of the destinationChoose the connection type: 3 for ABAP, H for HTTP to ABAP, G for HTTP to external, T for TCP/IP, I for internalAgree a naming convention such as SYSTEM_CLIENT_PURPOSE and record itConfirm network route, firewall rules and ports (for example 33NN for the gateway of instance NN)CRITICALDecide whether load balancing (message server) or a fixed application server is usedIdentify the interface owner and the change approval process

Create the destination in SM59

Create the entry with a clear description including owner and purposeEnter the target host or message server, instance number and logon group when load balancedSet the language and client explicitly instead of leaving them blankChoose the logon type: stored user, current user or trusted, based on the designCRITICALCheck the code page and Unicode setting match the target systemFor external programs, register the program ID and confirm the registered server is running

Secure it

Use a dedicated user of type System or Communication, never a dialog userCRITICALDo not store a password for a powerful dialog user, and rotate passwords on a scheduleCRITICALGive the target user only the authorizations the called function modules need, including S_RFCCRITICALEnable SNC where the landscape supports it and verify the SNC namesIf using trusted RFC, set up trust in SMT1 and S_ICF and S_RFCACL carefullyCRITICALCheck the gateway security files (secinfo and reginfo) allow only the intended programs and hostsRestrict who can maintain destinations with S_ADMI_FCD and authorization for SM59

Test

Run Connection Test in SM59 and confirm response time is reasonableRun Authorization Test where available and review the resultCall a known function module from the calling side with a small test inputCheck the SM21 system log and ST22 dumps on both sides if the test failsVerify the destination works after a restart or logon group changeTest the failure case, such as target down, and confirm the calling program handles it

Transport and operate

Decide whether the destination is transported or created per system, and avoid copying production passwordsCRITICALUse different destinations for DEV, QA and PROD with separate usersAdd the destination to your interface documentation and monitoringSchedule periodic review of unused destinations and delete obsolete onesMonitor failed calls through application logs or SM58 for transactional RFC

Items marked critical affect security or stability. Complete all of them before you use the destination in production. Version numbers, ports and transactions vary by SAP release and landscape, so confirm against your own system.

Want a second pair of eyes on your interfaces?

Ask for a light review of your RFC and interface inventory and where an on-prem assistant could reduce support effort.

Optional. The tool and every export work without this. No spam.

How to use the checklist

Tick items as you complete them and the progress bar updates. Treat the critical items as a gate: do not go live until they are done. Export the finished checklist to PDF and attach it to the change request or interface document as evidence that the destination was set up in a controlled way.

Connection types in practice

Type 3 connects to another ABAP system and is the most common. Type H and G cover HTTP connections, with G used for external services such as a cloud endpoint. Type T is for registered or started external programs. Each type has its own settings, but the user, trust and test steps apply to all of them.

Type 3 for ABAP to ABAP calls and BAPI access
Type H for HTTP to another ABAP system
Type G for HTTP to a non-ABAP server or cloud API
Type T for TCP/IP programs, registered or started

Authorization design

The calling system should reach the target with a technical user holding only the needed authorizations. S_RFC controls which function groups can be called, and S_RFCACL governs trusted logon. Avoid SAP_ALL on integration users, because a leaked destination then becomes a full system takeover path.

Common mistakes

Stored passwords of dialog users, shared users across environments, copying a production destination to test with the same password, and leaving test destinations active are the usual findings. Another is skipping the authorization test, so the connection works but the actual call fails with a missing authorization.

Frequently Asked Questions

Which user type should an RFC destination use?

Use a System or Communication user for technical connections, with only the authorizations the calls need. Avoid Dialog users because they are subject to password expiry and can be misused interactively, and avoid broad profiles such as SAP_ALL.

What is trusted RFC?

Trusted RFC lets a user logged on in one system call another without sending a password, based on a trust relationship set up in SMT1. It is convenient but needs strict S_RFCACL control, so use it only between systems with the same security level.

Why does the connection test pass but my call fails?

The connection test only checks that the logon works. The call can still fail because the user lacks S_RFC or application authorizations, or the function module does not exist in that release. Use the authorization test and review ST22 on the target.

Should RFC destinations be transported?

Usually not with passwords. Many teams create destinations per system and only transport the logical name used in code. If you do transport them, make sure no production credentials are carried into lower systems.

If your RFC and interface landscape has grown without documentation, Netray can help you map it and add private AI search over interface specs and logs.

Talk to an Expert Explore More Free Tools

Related Tools

SAP

More SAP tools

See all

SAP RFC Destination Setup Checklist