RFC Basics

This section gives you an overview of the Remote Function Call (RFC) within an SAP system, that is:
How the RFC Interface works
The functionality that is provided by the RFC and
What technical requirements exist for the supported platforms when using RFCs with SAP and
external systems.
The following background topics are available:
The RFC Interface
RFC in SAP Systems
RFC Destination
RFC Performance Profile
RFC Context
RFC Exceptions
RFC System Fields
RFC Authorization
RFC Trusted/Trusting Systems
RFC Restrictions
Technical Prerequisites
The RFC Interface
A remote function call (RFC) is when a function module is called that runs in a different system to the
calling program. Although it is also possible to call a function module in the same system as an
RFC, RFCs are normally used when the caller and the called function module run in different
systems.
In the SAP system, these functions are provided by the RFC interface system. The RFC interface
system enables function calls between two SAP systems, or between an SAP system and an external
system.
The RFC- interface system is made up of the following interfaces:
calling interface for ABAP programs
Every ABAP program can call a remote function module using the command CALL
FUNCTION...DESTINATION. Parameter DESTINATION informs the SAP system that the called
function module is running in a different system to the calling system. RFC communication with
the remote system takes place as part of the CALL FUNCTION command.
RFC function modules in an SAP system must be proper function modules and must be registered in
the SAP system as remote.
If the calling program and the called program are both ABAP programs, the RFC interface provides
both communication partners. The calling program can be any ABAP program, while the called
program must be a function module that is registered as remote.

 For more detailed information on calling function modules that are registered as remote, see Calling
RFC Function Modules in ABAP.
For more information on writing function modules that you want to call remotely, see Writing RFC
Function Modules in ABAP.
Interfaces for calling non-ABAP programs
If either the calling program or the called partner is not an SAP program, this program must be
programmed in such a way that it can play the role of the other partner in RFC communication.
For help while implementing RFC partner programs in non-SAP systems, see: Components of SAP
Communication Technology
RFC-supported and GUI-supported interfaces can be used by external programs to call function
modules in SAP systems and to perform them in these systems. ABAP programs can also use these
interfaces to use functions supplied by external programs.
RFC in SAP Systems
In all SAP systems, CALL FUNCTION represents an integral part of the ABAP language. This
statement executes a function (a function module) in the same system.
REMOTE FUNCTION CALL (RFC) is an extension of CALL FUNCTION in a distributed
environment. Existing function modules can be executed using an RFC from a remote system. This
is done by adding a DESTINATION clause to the CALL FUNCTION statement:

The destination parameter displays an entry in the RFCDES table (which is defined with transaction
SM59). This entry contains all necessary parameters to connect to and log in the destination
system.
You can use RFC between two SAP systems.
By using the RFC Library (RFC API), you can also use the functions of the RFC between an SAP
system and a C program on different platforms. It is of no significance to the caller whether the
remote function is provided in an SAP System or in a C program.
RFC frees the ABAP programmer from having to program his own communications routines. When
you make an RFC call, the RFC interface takes care of:
Converting all parameter data to the representation needed in the remote system. This includes
character string conversions, and any hardware-dependent conversions needed (for example,
integer, floating point). All ABAP data types are supported.
Calling the communication routines needed to talk to the remote system.
Handling communications errors, and notifying the caller, if desired. (The caller requests notification
using the EXCEPTIONS parameter of the CALL FUNCTION statement.)
The RFC interface is effectively invisible to the ABAP programmer. Processing for calling remote
programs is built into the CALL FUNCTION statement. Processing for being called is generated
automatically (in the form of an RFC stub) for every function module registered as remote. This
stub serves as an interface between the calling program and the function module.
A distinction is made between an RFC client and RFC server. RFC client is the instance that calls up
the Remote Function Call to execute the function that is provided by an RFC server. In the
following, the functions that can be executed remotely will be called RFC functions and the
functions provided via RFC API will be called RFC calls.
All RFC functions available in a remote RFC server system, which are called by an RFC client, are
processed transactionally. This means that after execution of the first RFC function in the RFC
server system the complete context (all globally defined variables in the RFC server program or in
the main program of a function module) is available for further RFC functions. The RFC
connection is closed only
when the context of the calling ABAP program has ended or
explicitly by RfcAbort or RfcClose in the external program.
You can either assign an application server directly, or assign it through a message server, as part of a
load distribution. This applies to RFCs between two SAP systems and to RFCs between an SAP
system and an external system.
To make the execution of RFC functions reliable, safe and independent from the availability of the RFC
server or RFC server system, the transactional RFC (tRFC) is available for SAP systems. This
ensures that the called function module is executed only once in the RFC server system.
In transactional RFC calls, the data that belongs to an RFC function must first be stored temporarily on
the SAP database in the RFC client system. When processing is completed, this must be reported
back to the calling ABAP program. Everything else is handled by the tRFC component in the SAP
system.
Since a database is not always available on external systems, the link to the tRFC interfaces is
implemented such that the client or server programs based on RFC API must take on some
administrative functions to ensure that the respective function module is executed only once.
In an SAP system, other SAP systems can be defined as trusted systems. Trusted systems can access the
called system (the trusting system) without having to provide a password.
For more information, see Trusted System.

RFC Destination
When calling a function module using the RFC interface, the calling program must specify the
parameters of the connection in the form of a destination. This destination defines the type of
connection, the partner program, and the target system. You can manage it using transaction SM59,
and it distinguishes between a variety of connections, such as TCP/IP or SAP connections. For a
synchronous RFC, the destination must be specified explicitly. For asynchronous and transactional
RFCs, a destination can be specified. If no destination has been specified the function module is
called using the RFC interface in the same system. Depending on the type of execution, the
following conditions apply:
For synchronous and asynchronous calls, the values of the call parameters are transferred to the
function module directly, whereas in the case of transactional calls, these are stored in the database
temporarily until execution.
For asynchronous calls, no connection to external systems is possible (TCP/IP connections in
transaction SM59).
For synchronous calls, the results of the called function are copied directly. For asynchronous calls,
results can be received in callback routines by using the statement RECEIVE, whereas in the case
of transactional calls, transferring results is not possible.
The server of the called function module must be available for synchronous and asynchronous calls.
To be able to call a function module using the RFC interface, the function module in question must be
flagged as being remote-capable in its properties, and for its interface parameter, only pass by value
is allowed. Even for table parameters, a pass by value is performed implicitly. Within the system in
which they are defined, remote-capable function modules can either be called using the RFC
interface, or like normal function modules. The normal call is made using the statement CALL
FUNCTION without using one of the additions DESTINATION, STARTING NEW TASK or IN
BACKGROUND TASK. When making the call using the RFC interface, you must either specify
the special destination "NONE" (see below), or you must perform an asynchronous or transactional
RFC without specifying a destination.
All the possible destinations are stored in the database table RFCDES, whose content is managed using
transaction SM59. When calling a function module remotely from an ABAP program, the
destination is specified using addition DESTINATION of the statement CALL FUNCTION, in the
form of a key value in column RFCDEST of database table RFCDES. The relevant rows of the
database table contain all parameters defined in transaction SM59 that are used for communicating
with the external system.
There are two predefined destinationen that do not have to be entered using transaction SM59:
Destination "NONE" has the effect that the function module is started on the same application server
as the calling program, however through the RFC interface and in its own RFC context. This
destination is possible for all types of call.
Destination "BACK" can be used in a function module that is called remotely, and links back to the
caller. You can only specify this in function modules that have been called synchronously.
Destination "BACK" can be used to call each remote-capable function module of the calling system
in all three execution types. For a synchronous callback, the relevant function group is loaded into

the internal session of the calling program, if it is not yet available there. The existint RFC
connection is used for this callback.
As well as the destinations created in transaction SM59 and the two predefined destinations, you can
also specify destinations directly, in the form "hostname_sysid_sysnr". Here, "hostname" refers to
the name of the application server, "sysid" is the name of an SAP system, and "sysnr" is the system
number, as is displayed using transaction SM51, for example.
RFC Performance Profile
When a function module that is defined in a different system to the calling program is called, this
process is referred to as a Remote Function Call (RFC). For this type of program communication,
RFC interfaces are available. These support function calls between different SAP systems (for
example, NW Application Servers) or between an SAP system and an external system. In this
process, an RFC client calls the function module, while an RFC server supplies and executes this.
The RFC interface performs the following actions:
Calls and manages the communication routines that are required in order to communicate with the
remote system.
Logs on to and off from the remote system and performs authorization checks for the function group
that is used.
Converts actual parameters into the display required by the remote system, and the other way round.
This may also include platform-specific conversions (such as differing code pages or byte
sequences). This conversion supports all ABAP data types.
Handles all errors that occurr during the communication and, if requested, forwards them to the
caller.
In the example comprising communication between different SAP systems, two ABAP programs
communicate with each other using the RFC interface, whereas in the case of communication
between SAP systems and external systems, an ABAP program communicates with a program of a
different programming language (C, C++, Visual Basic, Java or .NET).
For communication with programs of different programming languages, RFC libraries are available for
all operating systems that are supported by SAP, such as MS Windows, Unix (RS/6000, SUN
Solaris, HP-UX), Linux, z/OS (OS/390) and OS400:
Java Connector (JCo) for Java
.NET Connector for .NET (C#, VB.NET)
RFC Software Development Kit (SDK) for C and C++
The following additions to the statement CALL-FUNCTION-RFC effect a Remote Function Call:
CALL FUNCTION - DESTINATION (synchronous RFC)
If the addition DESTINATION is specified without one of the following two additions, the calling
program waits until the remotely-called function has finished.

CALL FUNCTION - STARTING NEW TASK (asynchronous RFC, aRFC)

With the addition STARTING NEW TASK, the processing of the calling program is continued as soon
as the remotely-called function is started, without waiting for it to end. The results can be obtained
from callback routines.
CALL FUNCTION - IN BACKGROUND TASK (transactional RFC, tRFC)
With the addition IN BACKGROUND TASK, the remotely-called function is marked for execution and
is started using the statement COMMIT WORK.
RFC Context
Every remote call of a function module that is made using the RFC interface defines a separate context
in the target system. The function group of the function module is loaded into an internal session of
the context, and is retained. What this means is that, if repeated calls of function modules belonging
to the same destination and the same function group are made, the global data of this function group
can be accessed collectively. When functions are called in external systems, this behavior is
simulated by the API of the RFC library. A connection and its context is retained until it is explicitly
closed, or until the calling program is finished. To close a connection explicitly, the function
module RFC_CONNECTION_CLOSE can be used, or the API functions RfcAbort and RfcClose.
RFC Exceptions
For the external function call, you can use the addition EXCEPTIONS of the statement CALL
FUNCTION - RFC (RFC variants) to assign return values to the exceptions defined in the interface
of the called function module. Class-based exceptions cannot be propagated to the caller from a
remotely-called function module, and have the effect of an exception that cannot be processed.
In addition to the exceptions defined in the interface of the called function module, an external function
call may trigger the following predefined exceptions:
The exception SYSTEM_FAILURE occurs if a runtime error arises during execution of the remotelycalled function module.
The exception COMMUNICATION_FAILURE occurs if the connection cannot be made to the
partner system, or if the connection is broken during communication.
RFC System Fields
As is the case every time a function module is called, when an RFC is made, the system field sy-subrc
is initialized in the calling program, or set to the value that is specified in exception handling. In
addition, each time a function module is called remotely, the system fields sy-msgid, sy-msgno, symsgty and sy-msgv1 to sy-msgv4 are initialized in the calling program. While a remotely-called
function module is being executed, if an error message or termination message is sent using the
statement Message, then the exception SYSTEM_FAILURE is triggered in the calling program.
You can assign a return value to this for the call. When exceptions occur, these system fields are
supplied with the properties of the message.

RFC Authorization

When a remote call of a function module is made, an automatic authorization check is performed,
provided that the profile parameter auth/rfc_authority_check is set to 1. The authorization check
uses the authorization object S_RFC to check whether the user defined in the destination has RFC
authorization for the function group of the called function module.

In addition to the function groups belonging to the application function modules, authorization object
S_RFC must also contain any RFC function groups in order to perform technical processes during
communication:

For tRFC and qRFC calls between two SAP systems: Function groups ERFC and ARFC
For all RFC calls in external (non-SAP) systems: function group SYST

When a function module is called remotely from within the same system, the automatic authorization
check only takes place if the client and user ID are not the same. Across system boundaries, the
automatic authorization check is only performed in systems that are not recognized as
trustworthy. Rating a system as an RFC Trusted/Trusting System is done using transaction
SMT1.
The automatic authorization check is made by implicitly calling function module
AUTHORITY_CHECK_RFC. If it detects an authorization issue, this function module triggers one
of the exceptions defined in its interface, namely USER_DONT_EXIST or
RFC_NO_AUTHORITY, thus triggering a runtime error. We recommend that you call the function
module AUTHORITY_CHECK_RFC explicitly before a remote call, thus enabling you to handle
any exceptions that may arise. If it detects the relevant authorization, the function module does not
return an explicit result. Instead, like all function modules that are performed successfully, it sets
sy-subrc to 0.
RFC Trusted/Trusting Systems
You can use transaction SMT1 to define a calling system in the system being called as a trusted system.
The system being called is then referred to as a trusting system.
Trusted SAP systems can log on to another SAP system without the need for a password. The existence
of trust relations such as this between SAP systems has the following advantages:
"Single Sign-On" across system boundaries
No password transfer across the net
Timeout mechanism for the logon data prevents misuse.
User-specific logon data for the trusted system is checked.

You can configure multiple SAP systems as mutual trusted systems. When building a trust relationship
between two systems, the initiative starts with the called system (server system). Here, users of the
calling system who are allowed to make RFC calls by way of a trust relationship of this kind, must
be identified in the system being called (trusted users).
Before a trusted system can be defined, a destination for this system must be created in the trusting
system. In addition, the RFC users must have the corresponding authorizations in the trusting
system (authorization object S_RFCACL). You can check the authorizations for the logged on users
in the trusting system in advance, by using the function module
AUTHORITY_CHECK_TRUSTED_SYSTEM.

This graphic is explained in the accompanying textIn a trust relationship, the calling system (client
system) plays the role of the trusted system, and the called system (server system) plays the role of
the trusting system.
RFC Restrictions
In contrast to the normal function module call, the following restrictions apply to an RFC:
For each call that is made using synchronous RFC, a database commit is performed. For this reason, a
synchronous RFC must not be used between Open SQL statements that open or close a database
cursor.
In a function module that is called remotely, you must not use statements that close the current
context and therefore the connection. An example of this is the statement LEAVE PROGRAM, or
SUBMIT without the addition RETURN.
In the case of a synchronous RFC, dynpros and selection screens that are called in a remotely-called
function module are displayed in the calling system if the calling program is executed in dialog
processing, and if the user defined in the destination has dialog authorization. The screen data is
transmitted by the RFC interface to the calling system. In this particular case, you can display lists
that are written in a remotely-called function module by using LEAVE TO LIST-PROCESSING.
As only pass by value is used for the RFC, when exceptions do occur, you can never access interim
results when a synchronous RFC is made.
Information messages are warnings are handled in the same way as status messages.
Technical Requirements

The following sections describe which technical prerequisites you have to fulfill in particular scenarios,
to be able to use RFC.

External Systems

SAP Systems
Code Pages
External Systems
External systems must support TCP/IP.
MS Windows platforms:
Microsoft standard
UNIX and Linux platforms: TCP/IP
OS/390:
TCP/IP for OS/390 from IBM.
OS/400:
Manufacturers standard.
The RFCSDK contains the RFC API and various test and example programs. For the given platforms,
the RFCSDK contains the following libraries and include files:
saprfc.h
This include file contains all the required data types, structures and declarations of the
RFC functions.
sapitab.h
This include file contains all the functions required to manipulate internal tables
RFC
Depending on the platform, the following libraries are required:
library
MS Windows:
For Unicode: librfc32u.dll, librfc32u.lib for
Compile/Link
For Non-Unicode: librfc32.dll and librfc32.lib, for
Compile/Link
UNIX and Linux
For Unicode: librfcu.a, librfcum.so
platforms:
For Non-Unicode: librfc.a, librfccm.so
OS/390:
For Unicode: librfcu.o
For Non-Unicode: librfc.o
OS/400:
For Unicode: librfcu.dll
For Non-Unicode: librfc.dll
SAP Systems

RFC functionality between two SAP systems or between an external system and an SAP system has
been available since Release 2.1 of the SAP system.

Up to Release 3.0 of the SAP system, RFCs are executed directly using the application server; in later
versions, the load can be distributed across application servers by using a pre-activated message
server.

The RFC offers a variety of service qualities. These are:

 Synchronous RFC
Asynchronous RFC without further service promise
Transactional RFC, which guarantees one-time execution and is offered as of Version 3.0
Queue RFC, which guarantees one-time execution while assuring the call sequence and is offered as
of Version 3.1.

Note for Linking to R/2

In the R/2 system, function modules are available as a concept for modularizing ABAP programs as of
Version 5.0. From Version 5.0D, function modules can also be called and executed remotely.

Destinations are stored and maintained in the R/2 System using the transaction SM59 in table TRFCD.

In the case of an RFC between an R/2 System in an IBM environment and another SAP system or
external systems, an SAP Gateway must be running on a machine that supports SNA LU6.2
protocol for the IBM host. The SNA product must also be installed on this machine, and the SAP
Gateway must be able to run in conjunction with this product. This is necessary, because some SNA
products are not compatible on the same machines.

The following SNA products are currently supported:

SNA services or SNA server on IBM-AIX systems
SNAplusLink on HP-UX systems
Communication Manager on OS/2
SNA Server on Windows NT systems
SNALink SNA peer-to-peer 8.0 on SUN systems
TRANSIT-SERVER and TRANSIT-CPIC on SNI-SINIX systems.

Code Pages
The RFC performs the conversion between different technical formats (integer display, Little versus big
Endian, and so on), as well as between code pages of sender and recipient.
In the case where two SAP systems that have different code pages exchange data with each other, and
where these do not use Unicode code pages, the code page conversion is performed on the receiver
system side. The binary codes of characters that cannot be converted into the code page of the
receiver system are retained.
In the case where two SAP systems that have different code pages exchange data with each other, and
where one of these systems uses a Unicode code page, the code page conversion is always
performed on the side of the system that uses the Unicode code page. The binary codes of
characters that can not be converted into the non-Unicode code page, are substituted with
replacement characters.
In the case where two SAP systems of the same code page (non-Unicode or Unicode) exchange data
with each other, the RFC only performs the technical conversions, no code page conversion.
RFC and Unicode
The RFC between a Unicode system and a non-Unicode system must convert the text data between the
code pages that are use on both sides. Here, the following situations are possible:
An input character cannot be converted into the output code page.
Example: a Chinese Unicode character cannot be displayed in any European code page following
ISO8859.
The conversion leads to an overrun of the output buffer.
Example: a sequence of Japanese Unicode characters may cause an output buffer of the same length
to overrun, when converting into the Japanese multibyte code page SHIFTJIS.
Characters in the input data are incorrect; for example, in non-Unicode multibyte code pages, not all
combinations of 2 bytes are permitted.
Example: the Japanese code page SHIFTJIS (SAP number 8000) is a multibyte code page that has
byte pairs whose first half lies in the range 0x80-0xEF, and whose second half lies in the range
0x40-0xFC. All other byte pairs are illegal and therefore cannot be converted.
Data that contains characters such as these are therefore already incorrect before the conversion;
they may have entered the system from outside, through uncontrolled channels, or may have arisen
from using text processing operations in the system that are unsuitable.
RFC Between Unicode Systems and MDMP Systems
If the RFC takes place between a Unicode system and a non-Unicode system that has multiple code
pages (MDMP system), then the data is available on the MDMP side in different code pages. In this
case, the RFC takes into account the language keys included in the date, and assigns the code page
used in the MDMP system to each language.
The procedure described here is applied to tables of type 1 (in principle, these are tables that have a flat
row structure). The RFC transmits deep structures (structures that have at least one table type; see
section BC-ABAP Dictionary, Types, Structures in the online documentation) in XML, and codes
the text data in UTF-8. If a non-Unicode system receives such data, then it converts it into the code
page of the logon language. If a non-Unicode system sends such data, then it converts it from the
code page that is currently set.

The language-related conversion of data takes place in the Unicode systems. Here, the Unicode systems
emulate non-Unicode systems, thereby ensuring compatibility with old non-Unicode systems
(downward compatibility).
During the conversion, the Unicode system assigns the MDMP code page to the languages as follows:
MDMP system
The MDMP system sends its assignment of languages to code pages within the
calls Unicode
RFC log.
system
For older MDMP systems, the Unicode system uses a predefined assignment
list. This list can be found in the documentation for transaction SM59 Defining
the RFC Destination in the section Predefined Code Pages.
Unicode system
The assignment is specified in the Unicode system, for the RFC destination.
calls MDMP
Transaction SM59 enables you to display and maintain the assignment.
system

Structures with LANG Fields

The RFC gets the language from the LANG fields that are included in the transported tables of type 1.
In each case, the relevant LANG field is flagged as a text language by a DDIC attribute.
Transaction SE11 enables you to display and maintain this indicator.
If one structure uses .INCLUDE or .APPEND to refer to another structure with LANG fields, then the
indicator in the structure making the reference must also be reset; the structure being referenced can
be opened and displays the indicator field that can be maintained.
In a structure that has 1 LANG field, this implicitly serves as the text language; when such a structure is
created, the DDIC attribute is activated. This setting can be reset in transaction SE11.

If tables are defined as deep structures in an import, export or changing parameter, then the language
is not evaluated.
Structures Without LANG Fields
If a structure has no LANG field, or if none of the LANG fields are flagged as the text language, then
the Unicode system converts in the following way:
MDMP
Corresponding to the code page given by the sender
system
calls
Unicode
system
Unicode
Converts into the non-Unicode code page that is normally assigned to the logon
system
language (in the Unicode system).
calls
You also have the option of using the logon language of the RFC destination
MDMP
(instead of that of the current context), by making a special setting for the RFC
system
destination in SM59: call transaction SM59 and for this destination select the RFC
Bit Options on the tab page Special Options in the section Special Flags. Then
select the checkbox Determined Communication Code Page (hexadecimal value

0x200).-{}-

In particular, the IDocs, which are used in the ALE interfaces, do not have a language ID.
Unknown Languages
The transferred data may contain a language that is unknown in the configuration of the MDMP system.
This can occur in both transfer directions, and independently of the client/server role of the systems
involved.
Data may also contain a LANG field with the value (space), although this value is invalid according
to the value table. Here, the same rules apply as for structures without LANG fields (see above).
Unicode system
The RFC terminates with the error SYSTEM_FAILURE. In this case, you can
calls MDMP
activate the user trace (SM04), in whose output you can find information
system
about the unknown language.
MDMP system
The RFC terminates with the error SYSTEM_FAILURE and sets the error
calls Unicode
message to Connection closed (no data).
system
You can find the unknown language by activating the user trace in the MDMP
system (SM04), repeating the RFC, and analyzing the trace files of the called
Unicode system.