Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
Showing results for 
Search instead for 
Did you mean: 


Former Member
0 Kudos

Hi All,

Could any one send me an example for RFC FM and a Doc.

Thanks for the kindfull help.



Active Contributor
0 Kudos

RFC_READ_TEXT is an example:

all bapis are rfcs. So, go to se37 and search using bapi* and f4.

Read this also:



Former Member
0 Kudos


Detailed explanation about RFC FM exists in SAP Help itself. Just go to ABAPDOCU, in keyword input <b>RFC</b>.

We get information about Synchronous RFC, Asynchronous RFC and Transaction RFC. An example of Asynchronous RFC also exists in the help.



Former Member
0 Kudos

Hai Aima Sufi

Go through the following Example & Document

Sending system side(SEND--800)


Create function module by using Tcode SE37 or SE80

goto attributes select remote function


Receiving system side(RECE--000)


goto Tcode SM59

here select the R/3 Connections-->click on Create Button

give RFC Desstination : TESTRFC

Connection Type : 3 for Connecting two systems

Description : Some meaningful Description

Press enter

give Target system Name : SEND

Language : EN

Client : 800

user Name : sapuser

Password : xxxxxx

save this connections & click on test connections(f8)

& Remote logon(f7)---> it will open a session

with client 800 that is your sending system

then only your RFC is correct

create a report in SE38 Tcode

data : c1 type i.

data : itab like mara occurs 0 with header line.

call function 'ZRFCFM' destination 'TESTRFC' --->Function Module 'ZRFCFM' your just create at Sending system




Here are the steps.

SM59 Transaction is used for Connection Establishment with Destination.

When you establish a connection to a client through a destination, the HTTP connection must first be entered in transaction SM59.

There are two types of HTTP connection in transaction SM59: Call transaction SM59 to display the different RFC destinations.

The HTTP connection to the external server (connection type G) and the HTTP connection to the R/3 system (connection type H) are different only in their logon procedures. Their technical settings are the same. To display the technical settings, double-click a connection.

You can choose from three tabs. Under Technical Settings, you can specify the following:

E Target Host: The host to which you want to connect.

Note that if you are using HTTPS as a protocol, you have to specify the full host name (with domain).

E Service No.: Here, you specify the port. The destination host must of course be configured in such a way that the specified port gunderstandsh the corresponding protocol (HTTP or HTTPS). See Parameterizing the ICM and the ICM Server Cache.

E Path Prefix: At the time when the connection to this destination is initiated, the system inserts this sub-path before ~request_uri.

E HTTP Proxy Options: Here, you can configure a proxy for HTTP connections: You can determine the proxy host and service, as well as users and passwords for the HTTP connection.

The tab page Logon/Security will be different depending on whether you have selected a HTTP connection to an external server (connection type G) or a HTTP connection to an R/3 system (connection type H).

HTTP Connection to an External Server (Connection Type G)

Choose the connection you want to use. You can choose from the following logon procedures:

E No Logon: The server program does not request a user or password.

E Basic Authentication: The server program requests a user and password. Basic Authentication is a standard HTTP method for authenticating users. When a user logs on to the target system, he or she provides a user ID and password as authentication. This information is then sent in a header variable as a Base 64-encoded string to the server, through the HTTP connection.

E SSL Client Certificate: If you use client certificates for authentication, the client authentication is performed through the Secure Sockets Layer (SSL) protocol. In this case, you must also select the SSL Client PSE of the SAP Web AS that contains the relevant certificate for the authentication. The target system must handle the issuer of the SAP Web AS client certificate as a trusted system.

Under Logon/Security, you can also activate SSL to ensure that HTTPS is the protocol used (if you select SSL, make sure that the correct port is entered under Technical Settings). In the security transaction STRUST you can determine which type of SSL client is used. (Getting Started with the Trust Manager, Trust Manager).

The field Authorization for Destination has been implemented as an additional level of protection. We recommend that you specify a user and password for the RFC destination.

HTTP Connection to an R/3 System (Connection Type H)

Here, you can specify more settings for authentication in the target system.

The settings under Technical Settings and Special Options are the same as for connection type G. Under Logon/Security, the connection type H has additional logon procedures. As with external servers, you can activate and deactivate SSL and specify an authorization.

Because the target system is an SAP system, you can set the client and language for the logon as well as the user name and password. If you check Current User, you have to specify the password.

The following authentication procedures are available: Basic Authentication, SAP Standard, and SAP Trusted System, and SSL Client Certificate.

E HTTP Basic Authentication: Logon with user and password

E SAP Standard: This procedure uses an RFC logon procedure. The RFC Single Sign-On (SSO) procedure is valid within the one system. The same SAP user (client, language, and user name) is used for logon.

E SAP Trusted System: Trusted RFC logon to a different SAP system (see Trusted System: Maintaining Trust Relationships Between SAP Systems)).

E SSL Client Certificate: The SSL protocol enables you to use client certificates for the logon.

Type G/H (SM59)


When sending a HTTP request, you can use this parameter to specify the maximum response time for the connection.

HTTP Setting:

You can use the HTTP version to specify the protocol version of the HTTP request (HTTP 1.0 or 1.1).


You can use this option to activate the gzip compression for the request body. This can only be activated in HTTP Version 1.1.

Compressed Response:

In the standard setting, the SAP Web Application Server sends the Accept Encoding field as a header field with the value gzip, if the application server can handle this compression. This notifies the partner that the caller can handle gzip decompression, and that the partner can send compressed data. If you want to prevent a compressed response being sent, choose the option No.

HTTP Cookie:

You can use this option to control the way received cookies are handled.

You can specify the following for cookies:

E Accept them automatically

E Reject them automatically

E Accept or reject them in a prompt

E Use a handler for the event IF_HTTP_CLIENT~EVENTKIND_HANDLE_COOKIE to process the cookies in the program.

E In the next section, you can read about the parallelization of requests.

Check this thread

RFC:RFCs are requests that an SAP component sends to invoke functions on remote systems, or calls that remote systems initiate to invoke functions on an SAP component.A process that can accept RFCs from SAP components. This allows SAP components to access functions in external systems. In SAP BC terminology, the process is called a Listener. Listeners are one or more threads on SAP Business Connector that wait for incoming requests from SAP components. Listeners are named and register with an SAP gateway to indicate that they are ready to accept requests. Listeners can accept RFC or tRFC requests.

TRFC:Protocol for ensuring that an RFC is executed successfully and executed only once on the target system. SAP Business Connector can handle both inbound and outbound tRFCs.Communications method that an SAP component uses to asynchronously invoke a function on a remote system and that a remote system uses to asynchronously invoke a function on an SAP component. The tRFC protocol ensures that an RFC is executed successfully and only once.

                • Detailed Description **********

Transactional RFC(tRFC):-Transactional RFC uses resource checking only. It does not use parallel RFCs.

The required ABAP language element is:


This ABAP command flags the function module remote function for asynchronous processing. The module is not executed immediately. The data transferred with EXPORTING or TABLES is placed in a database table. A COMMIT WORK then triggers the function module. There are various cases:

E The data is updated. In this case the function module is executed within the update following the V1 phase, usually even on a different server.

E The data is not updated. In this case the function module is executed in the same work process.

If an error occurs during a synchronous remote function call, the system cannot tell at what point the error occurred (most crucially, whether the function module was actually processed in R/3 before the operation failed). Restarting a failed call is therefore a dangerous thing to do, since you risk duplicating a completed function call.

To alleviate this problem, you can use transactional RFC, which guarantees that each function call you issue will only be executed once, even if you submit it repeatedly to the R/3 System. The system implements this safeguard by assigning a unique transaction ID (TID) to each transaction that you submit. When you attempt to process the transaction, the system checks whether that TID has already been processed. If it has, the transaction is ignored.


Communication between an MTS component and the R/3 System uses Remote Function Call (RFC). Since there is considerable overhead involved in establishing these connections, the MTS does not release a connection as soon as an object has finished with it. Instead, it keeps it in a connection pool. From here, it can be reused by another object. If after a certain period the object has still not been used, the system will release it.

Each RFC connection is characterized by the following properties:

Target system


User name



A pooled resource can only be reused by an object with the same properties. Thus resource pooling is of considerable importance in Web scenarios, where several users share a single R/3 user, because there will be many requests using the same connection parameters. If the MTS can allocate an existing connection to these requests, the performance of the application will be improved, because you no longer have the overhead associated with creating new RFC connections.

for more info: