RFC Basics

PDF download from SAP Help Portal:

http://help.sap.com/saphelp_nw73/helpdata/en/48/9f1952a81417cee10000000a421937/content.htm
Created on August 04, 2015

The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.

Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.

2015 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Table of content

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 1 of 8

Table of content
1 RFC Basics
1.1 RFC Interface
1.2 RFC Communication Scenarios
1.3 RFC Destinations
1.4 RFC System Fields
1.5 RFC Authorizations
1.6 Code Pages
1.7 Maintaining Trust Relationships between SAP Systems

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 2 of 8

1 RFC Basics
Use
This section provides an introduction to the basic elements of RFC.
Here, you can learn about:
how the RFC Interface functions
the functionality provided by RFC
the technical requirements for RFC with SAP and external systems.
This section provides information about the following topics:
RFC Interface
RFC Communication Scenarios
RFC Destination
RFC System Fields
RFC Authorizations
Code Pages
Maintaining Trust Relationships between SAP Systems

1.1 RFC Interface

Use
A remote function call (RFC) calls a function module in a different system to the calling program.

Note
It is also possible to call a function module is the system by RFC. Normally though, the caller and the called function module are in different systems.
In the SAP system, these functions are provided by the RFC interface system. The RFC interface 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 elements:
Calling interface for ABAP programs
Each ABAP program can call a remote function module using the command CALL FUNCTION...DESTINATION. The parameter DESTINATION informs the
SAP system that the called function module runs in a different system to the calling system. RFC communication with the remote system takes place as a
part of the CALL FUNCTION command.
RFC function modules in an SAP system must be real function modules and must be registered as remote enabled in the SAP system.
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. The called program must be a function module that is registered as remote enabled.
Interfaces for calling non-ABAP programs
If either the calling program or the called partner is not an SAP program, the program in question must be programmed in such a way that it can play the
role of the other partner in RFC communication.
RFC-supported and GUI-supported interfaces can be used by external programs to call function modules in SAP systems, and execute them in these
systems. Likewise, ABAP programs can also use these interfaces to use functions supplied by external programs.

Note
SAP provides a special RFC API for this purpose.

More Information
You can find more information about calling remote-enabled function modules in:
Calling RFC Function Modules in ABAP
You can find more information about writing function modules that you want to call remotely in:
Writing Remote Function Modules in ABAP
If you want to set up an RFC communication with external systems, read:
The RFC API

1.2 RFC Communication Scenarios

Use
The RFC interface can be used in various constellations, depending on the type of the partner system. Basically, there are four different scenarios:
AS
AS
AS
AS

ABAP
ABAP
ABAP
ABAP

- AS ABAP
- External system
- SAP Java (SAP NetWeaver Application Server)
- External Java system

Scenario 1: ABAP - ABAP

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 3 of 8

In this scenario, two SAP systems - actually two AS ABAP systems - communicate with each other. Here, the data exchange between the two partner systems is
made via the RFC interface. An additional conversion of the data format is not necessary.
Scenario 1: ABAP-ABAP

Scenario 2: ABAP - External System

In this scenario, the partner system is not an SAP system: Here, the RFC API is used to implement an interface that converts the ABAP date format.
Scenario 2: ABAP - External System

Scenario 3: ABAP - Java (SAP)

In this scenario, the communication does not have to be between two separate systems. However, the RFC interface is also required for communication between
AS ABAP and AS Java within the SAP NetWeaver Application Server. At the AS Java end, SAP Java Connector performs the interface function and is
responsible for mapping the ABAP-Java data types. SAP JCo is lagged by SAP Java Resource Adapter , which is based on the Java EE standard architecture.
This scenario can also be used for communication with an external AS Java.
Scenario 3: ABAP - Java (SAP)

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 4 of 8

Scenario 4: ABAP - Java (Non-SAP)

Here, AS ABAP communicates with a Java system that is not based on SAP AS Java. In this scenario too, SAP JCo performs the interface function and data
mapping for the non-SAP Java system.
Scenario 4: ABAP - Java (external system)

For more information, see

You can find more detailed information about the various scenarios under:
The RFC API (see separate documentation for standalone products: service.sap.com/connectors )
SAP JCo Application Scenarios
SAP JRA for SAP Java Applications

1.3 RFC Destinations

Use
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 sRFC and aRFC 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 aRFC calls, no connection to external systems is possible (TCP/IP connections in transaction SM59).
For sRFC calls, the results of the called function are copied directly. For aRFC 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.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 5 of 8

The server of the called function module must be available for sRFC and aRFC 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 value transfer is allowed. Only the value transfer is allowed for its interface parameter. 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, IN BACKGROUND UNIT.. When making the call using the RFC interface, you must either specify the special destination "NONE"
(see below), or you must perform an aRFC 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 destinations 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 methods. 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.

1.4 RFC System Fields

Use
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. Each of the following system calls is initialized in the calling program too:
sy-msgid
sy-msgno
sy-msgty and
sy-msgv1 to sy-msgv4
initialized in the calling program.
If an error message or termination message is sent using statement Message while a remotely-called function module is being executed, 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.

1.5 RFC Authorizations

Use
The authorization check uses authorization object S_RFC to check whether the user defined in the destination has RFC authorization for the function module to be
called. The authorization check is performed at the function group level. If the user is assigned to a certain function group, he or she can call all function modules
that belong to this function group.
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
additionally for all RFC calls in external (non-SAP) systems: function group SYST.

More Information
You can find an overview of other authorization objects in the RFC environment in the RFC Security Guide, under:
Authorizations

1.6 Code Pages

Use
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.
If two SAP systems with different code pages exchange data with each other, and these systems do not use Unicode code pages, the code page conversion is
performed at the receiver system. The binary codes of characters that cannot be converted into the code page of the receiver system are retained.
If two SAP systems with 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 at the system that uses the Unicode code page. The binary codes for characters that cannot be converted into the non-Unicode
code page are replaced by a replacement character.
If two SAP systems in the same code page (non-Unicode or Unicode) exchange data with each other, the RFC only performs the technical conversions and no
code page conversion.
RFC and Unicode

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 6 of 8

The RFC between a Unicode system and a non-Unicode system has to convert the text data between the code pages used 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 according to 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 0x800xEF, and whose second half lies in the range 0x40-0xFC. All other byte pairs are illegal and therefore cannot be converted. Data containing characters of
this kind are therefore already incorrect before conversion. They may have entered the system from outside, through uncontrolled channels, or may be the
result of using unsuitable text processing operations in the system.
RFC Between Unicode Systems and MDMP Systems
If the RFC is place between a Unicode system and a non-Unicode system with multiple code pages (MDMP system), 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 (these tables normally have a flat row structure). The RFC transmits deep structures in XML, and
codes the text data in UTF-8. If a non-Unicode system receives data like this, it converts it into the code page for the logon language. If a non-Unicode system
sends this type of data, it converts it from the code page that is currently set.
The language-compatible conversion of the 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 conversion, the Unicode system assigns the MDMP code page to the languages, as follows:
MDMP system calls Unicode system

The MDMP system passes on its assignment of languages to code pages in the RFC
log. For older MDMP systems, the Unicode system uses a predefined assignment list.
See Settings for Code Pages

Unicode system calls MDMP system

The assignment is specified in the Unicode system, for the RFC destination. Transaction
SM59 enables you to display and maintain the assignment.

Structures with LANG Fields

The RFC gets the language from the LANG fields in transported tables of type 1. Every 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, 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 with a 1 LANG field, this implicitly serves as the text language. When this type of structure is created, the DDIC attribute is activated. This setting
can be reset in transaction SE11.

Note
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 does not have a LANG field, or if none of the LANG fields are flagged as the text language, the Unicode system performs the conversion as follows:
MDMP system calls Unicode system

According to the code page specified by the sender

Unicode system calls MDMP system

Converts to the non-Unicode code page that is normally assigned to the logon language
(in the Unicode system). You also have the option of using the logon language for the
RFC destination (instead of that of the current context), by making a special setting for
the RFC destination in SM59 call transaction SM59 and selecting the RFC Bit Options
for this destination on the Special Options tab page in section Special Flags . Then
select the checkbox Determined Communication Code Page (hexadecimal value
0x200).

Note
In particular, IDocs that are used in the ALE interfaces do not have a language ID.
Unknown Languages
The transferred data might contain a language that is unknown in the MDMP system configuration. 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 calls MDMP system

The RFC terminates with the error SYSTEM_FAILURE. In this case, you can activate
the user trace (SM04), in whose output you can find information about the unknown
language.

MDMP system calls Unicode system

The RFC terminates with the error SYSTEM_FAILURE and sets the error message to
"Connection closed (no data)". 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.

1.7 Maintaining Trust Relationships between SAP Systems

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 7 of 8

1.7 Maintaining Trust Relationships between SAP Systems

Use
SAP systems can build trust relationships to one another in order to minimize the requirement for authentication when logging on to a remote system:
If a calling SAP system is known to the called system as a calling system, no password is required during the logon.
The calling SAP system must be registered in the called system as a calling system. The called system is known as the trusting or called system.
Trust relationships between SAP systems offer the following benefits:
Single Sign-On is possible beyond system boundaries.
No passwords are transmitted in the network.
Timeout mechanisms for the logon data protect against illegal logon attempts.
User-specific logon data is checked in the called system.
The trust relationship is not mutual, meaning that it applies to one direction only. To establish a mutual trust relationship between two partner systems, you must
define each of the two as a calling system in its respective partner system.

Note
For extra security, you can use SAP's SNC Interface ( Secure Network Communications) for third-party security systems such as Kerberos and SECUDE.
You can configure multiple SAP systems as mutual trusted systems. Setting up a trust relationship between two systems is normally initiated by the called
system (server system). Here, users of the calling system who are allowed to make RFC calls by this type of trust relationship must be identified in the called
system (trusted users).
Before a calling system can be defined, a destination must be created for this system in the calling system. The RFC users also need the relevant authorizations
in the calling system (authorization object S_RFCACL). You can check the authorizations for the logged on users in the calling system in advance, by using the
function module AUTHORITY_CHECK_TRUSTED_SYSTEM.

More Information
You can find detailed information about maintaining trust relationships in:
Maintaining Trust Relationships between SAP Systems

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 8 of 8