# SAP RFC Destination Setup Checklist

> Source: https://netray.co/tools/sap-rfc-destination-setup-checklist
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Work through every step of creating and securing an RFC destination in SM59, from connection type to authorization and testing.

## Category

sap

## Erp

SAP ECC / S/4HANA

## Audience

- SAP basis administrator
- SAP integration developer
- SAP security consultant

## Tool

**Kind:** checklist

**Groups:**

#### Plan the connection

**Items:**

Document source system, target system, client and business purpose of the destination

Choose the connection type: 3 for ABAP, H for HTTP to ABAP, G for HTTP to external, T for TCP/IP, I for internal

Agree a naming convention such as SYSTEM_CLIENT_PURPOSE and record it

**Text:** Confirm network route, firewall rules and ports (for example 33NN for the gateway of instance NN)

**Critical:** true

Decide whether load balancing (message server) or a fixed application server is used

Identify the interface owner and the change approval process

#### Create the destination in SM59

**Items:**

Create the entry with a clear description including owner and purpose

Enter the target host or message server, instance number and logon group when load balanced

Set the language and client explicitly instead of leaving them blank

**Text:** Choose the logon type: stored user, current user or trusted, based on the design

**Critical:** true

Check the code page and Unicode setting match the target system

For external programs, register the program ID and confirm the registered server is running

#### Secure it

**Items:**

**Text:** Use a dedicated user of type System or Communication, never a dialog user

**Critical:** true

**Text:** Do not store a password for a powerful dialog user, and rotate passwords on a schedule

**Critical:** true

**Text:** Give the target user only the authorizations the called function modules need, including S_RFC

**Critical:** true

Enable SNC where the landscape supports it and verify the SNC names

**Text:** If using trusted RFC, set up trust in SMT1 and S_ICF and S_RFCACL carefully

**Critical:** true

Check the gateway security files (secinfo and reginfo) allow only the intended programs and hosts

Restrict who can maintain destinations with S_ADMI_FCD and authorization for SM59

#### Test

**Items:**

Run Connection Test in SM59 and confirm response time is reasonable

Run Authorization Test where available and review the result

Call a known function module from the calling side with a small test input

Check the SM21 system log and ST22 dumps on both sides if the test fails

Verify the destination works after a restart or logon group change

Test the failure case, such as target down, and confirm the calling program handles it

#### Transport and operate

**Items:**

**Text:** Decide whether the destination is transported or created per system, and avoid copying production passwords

**Critical:** true

Use different destinations for DEV, QA and PROD with separate users

Add the destination to your interface documentation and monitoring

Schedule periodic review of unused destinations and delete obsolete ones

Monitor failed calls through application logs or SM58 for transactional RFC

**Scoring Note:** 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.

## Content

**Intro:** A badly configured RFC destination is one of the quietest security and stability risks in an SAP landscape. This checklist walks through planning, creating, securing and testing a destination in SM59 so that the next interface does not become an audit finding.

**Sections:**

#### How to use the checklist

**Body:** 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

**Body:** 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.

**Bullets:**

- 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

**Body:** 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

**Body:** 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.

**Cta:** 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.

**Faq:**

#### Which user type should an RFC destination use?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

sap rfc destination setup, sm59 create rfc destination, sap rfc connection type 3, sap trusted rfc setup, sm59 connection test failed, sap rfc security checklist, sap rfc user type system, sap snc rfc

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json