RFC Programming in ABAP

RFC Programming in ABAP
RFC Basics
Calling RFC Function Modules in ABAP
Writing Remote Function Modules in ABAP
Maintaining Remote Destinations
Trusted System: Trust Relationships Between SAP Systems
Configuring System Resources for Parallel RFC, tRFC, and qRFC

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

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

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.


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

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

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 remotely-called 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.

We strongly recommend that you assign a return value to these two exceptions for each RFC, and that you process these, otherwise a
runtime error may occur in the exception situations described.

RFC System Fields

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, sy-msgty 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

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.
For detailed information on security-relevant aspects of communication using RFC, see:
RFC/ICF Security Guide

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.

In 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

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

You can skip this section and go directly to the next main section:

External Systems

External systems must support TCP/IP.

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:
For more detailed information, refer to: The RFC API

SAP Systems

MS Windows platforms: Microsoft standard
UNIX and Linux platforms: TCP/IP
OS/390: TCP/IP for OS/390 from IBM.
OS/400:
Manufacturers standard.
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 library Depending on the platform, the following libraries are required:
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
platforms:
For Unicode: librfcu.a, librfcum.so
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

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 calls Unicode system The MDMP system sends its assignment of languages to code
pages within the RFC log.
For older MDMP systems, the Unicode system uses a predefined
assignment list. This list can be found in the documentation for

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:

In particular, the IDocs, which are used in the ALE interfaces, do not have a language ID.

Unknown Languages
transaction SM59 Defining the RFC Destination in the section
Predefined 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.
MDMP system calls Unicode system Corresponding to the code page given by the
sender
Unicode system calls MDMP system Converts into 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 of 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 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).-{}-

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).


This section contains the following topics:
Introduction
Parameter Handling in Remote Calls
Characteristics Using Unicode
Calling Remote Functions Locally
Calling Remote Functions

Or go directly to the next section:
CALL FUNCTION - RFC (RFC Variants)

Introduction
You can use the CALL FUNCTION statement to call remote functions, just as you would call local function
modules. However, you must include an additional DESTINATION clause to define where the function should run:
CALL FUNCTION Remotefunction
DESTINATION Dest

The remotefunction field can either be a literal or a variable. The field Dest can be either a literal or a variable: its value is a logical
destination (for example, "hw1071_53") known to the local SAP System. You can define logical destinations in table RFCDES using
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.
EXPORTING F1 = a1
F2 = a2
IMPORTING F3 = a3
CHANGING F4 = a4
TABLES t1 = ITAB
EXCEPTIONS
transaction SM59, or using the following menu path: Tools Administration Administration Network RFC Destinations.
Programming guidelines are available in the following topics:

When you make a remote function call, the system handles parameter transfer differently than it does with local
calls.
TABLES parameters
The actual table is transferred, but not the table header. If a table parameter is not specified, an empty table is
used in the called function.
The RFC uses a delta managing mechanism to minimize network load during parameter and result passing.
Internal ABAP tables can be used as parameters for function module calls. When a function module is called
locally, a parameter tables is transferred by reference". This means that you do not have to create a new local
copy. RFC does not support transfer by reference. Therefore, the entire table must be transferred back and forth
between the RFC client and the RFC server. When the RFC server receives the table entries, it creates a local
copy of the internal table. Then only delta information is returned to the RFC client. This information is not returned
to the RFC client every time a table operation occurs, however; instead, all collected delta information is passed
on at once when the function returns to the client.
The first time a table is passed, it is given an object-ID and registered as a "virtual global table" in the calling
system. This registration is kept alive as long as call-backs are possible between calling and called systems. Thus,
if multiple call-backs occur, the change-log can be passed back and forth to update the local copy, but the table
itself need only be copied once (the first time).


RFC from a Non-Unicode System into a Unicode System
The following errors may occur:

The Unicode system being called reacts to conversion errors depending on the profile parameters
rfc/cp_convert/ignore_error
rfc/cp_convert/ignore_error
by using a replacement character, or by terminating the call.
You can specify the replacement character using its UTF-16 character number; the default character therefore has
the value 0023, and the character ~ would have the value 007E, for example. You can find a list of the Unicode
character numbers at http://www.unicode.org

The Unicode system sends incorrect characters.
An MDMP system sends data in an unknown language. Due to this, the Unicode system is unable to
determine the code page of this data for the conversion.
Unicode return characters cannot be converted into the required non-Unicode code page
Output buffer is overrun while returning the results
Default: Ignore errors and replace characters that cannot be converted with the character #.

The system making the call receives the exception COMMUNICATION_FAILURE with the message connection
closed.

RFC from a Unicode System into a Non-Unicode System
The following errors may occur:

In the calling system, the reaction to conversion errors can be configured separately for each destination.
See transaction SM59 Defining Remote Destinations.

For the system being called, a conversion error is not visible. The calling Unicode system identifies errors in the
input data before it triggers an action on the called page; the calling Unicode system only identifies errors in the
output data if the called context has already been disconnected.


If you want to call a function module, which is registered as being remote in an SAP system, in the same SAP
system, you have two options for making this call:
As a remote call
As a local call
The CALL FUNCTION statement and the parameter handling is different for both cases (this is explained in more
detail under Parameter Handling in Remote Calls).

Remote Call:
CALL FUNCTION...DESTINATION = 'NONE'
This is a remote call, even though DESTINATION = 'NONE' means that the remote function will run in the same system as the caller. As a
remote call, the function module runs in its own roll area, and parameter values are handled as for other remote calls (described in Parameter
Handling in Remote Calls.)

Local Call:
The non-Unicode system returns incorrect results data.
A text language is unknown.
The Unicode system sends characters that cannot be converted into the required non-Unicode code
page.
The receiver buffer of the non-Unicode system overruns.
DESTINATION NONE
EXPORTING F1 = a1
F2 = a2
TABLES t1 = ITAB
EXCEPTIONS ...
CALL FUNCTION... [no DESTINATION used]
This is a local call, even though the function module is registered as remote. The module does not run in a separate roll area, and is
essentially like a normal function call. Parameter transfer is handled as for normal function modules. In particular, if the call leaves some
EXPORTING parameters unspecified, it terminates abnormally.
You can also call a function for parallel processing within the same system. For more details, see Parallel
Processing with Aynchronous RFCs.


Calling Remote Functions Back
The client and the server are determined at the start of an RFC. While a function is being processed on the server,
this server can call a function on the client. In other words, the remote function can invoke its own caller (if the
caller is itself a function module), or any function module loaded with the caller. The called-back function then runs
in the same program context as the original caller.
You can trigger this call-back mechanism by using the special destination name BACK. If this name is specified
in an RFC call on the system acting as the server, the system uses the same RFC connection that was
established when the server received the first call. Once an RFC connection is established, it is maintained until it
is either explicitly closed or until the calling program terminates. During a call-back, the system will always attempt
to use existing RFC connections before establishing a new one.
To perform a call-back, the syntax is:
CALL FUNCTION... DESTINATION 'BACK'

In the diagram, remote function B of System B invokes remote function A in the calling System A.

EXPORTING F1 = a1
F2 = a2
TABLES t1 = ITAB
EXCEPTIONS ...


Synchronous RFC

1. CALL FUNCTION func DESTINATION dest
parameter_list.

Asynchronous RFC

2. CALL FUNCTION func STARTING NEW TASK task
[DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]
parameter_list
[{PERFORMING subr}|{CALLING meth} ON END OF TASK].

Transactional RFC

3. CALL FUNCTION func IN BACKGROUND TASK
[DESTINATION dest]
parameter_list
[AS SEPARATE UNIT].
Effect
Calling a function module or a function using the RFC interface.
Exceptions
Exceptions that cannot be handled
Cause: The called function module is not released for RFC.
Runtime error: CALL_BACK_ENTRY_NOT_FOUND
Cause: The type of the destination is not allowed.
Runtime error: CALL_FUNCTION_DEST_TYPE
Cause: Current function is not called remotely
Runtime error: CALL_FUNCTION_NO_SENDER
Cause: Missing communication type (I for internal connection, 3 for ABAP) when executing an asynchronous RFC
Runtime error: CALL_FUNCTION_DESTINATION_NO_T
Cause: The specified destination does not exist.
Runtime error: CALL_FUNCTION_NO_DEST
Cause: Maximum length of options for the destination exceeded
Runtime error: CALL_FUNCTION_OPTION_OVERFLOW
Cause: The specified destination (in load distribution mode) does not exist.
Runtime error: CALL_FUNCTION_NO_LB_DEST
Cause: Data received for unknown CPI-C connection.
Runtime error: CALL_FUNCTION_NO_RECEIVER
Cause: The function module being called is not flagged as being "remotely" callable.
Runtime error: CALL_FUNCTION_NOT_REMOTE
Cause: While executing an RFC, an error occurred that has been logged in the calling system.
Runtime error: CALL_FUNCTION_REMOTE_ERROR
Cause: Logon data for the user is incomplete.
Runtime error: CALL_FUNCTION_SIGNON_INCOMPL
Cause: Logon attempt in the form of an internal call in a target system not allowed
Runtime error: CALL_FUNCTION_SIGNON_INTRUDER
Cause: RFC from external program without valid user ID
Runtime error: CALL_FUNCTION_SIGNON_INVALID
Cause: Logon attempt in target system without valid user ID.
Runtime error: CALL_FUNCTION_SIGNON_REJECTED
This error codes may have any of the following meanings:
1) Incorrect password or invalid user ID
2) User locked
3) Too many login attempts
5) Error in authorization buffer (internal error)
6) No external user check
7) Invalid user type
8) Validity period of the user exceeded
Cause: No authorization to log on as Trusted System.
Runtime error: CALL_FUNCTION_SINGLE_LOGIN_REJ
The error code may have any of the following meanings:
0) Incorrect logon data for valid security ID.
1) Calling system is not a Trusted Systemor security ID is invalid.
2) Either user does not have RFC authorization (authorization object S_RFCACL), or a logon was performed using one of the protected
users DDIC or SAP*.
3) Time stamp of the logon data is invalid.
Cause: RFC without valid user ID only allowed when calling a system function module. The meaning of the error codes is the same as
for CALL_FUNCTION_SINGLE_LOGIN_REJ.
Runtime error: CALL_FUNCTION_SYSCALL_ONLY
Cause: Data error (info internal table) during a 'Remote Function Call'.
Runtime error: CALL_FUNCTION_TABINFO
Cause: No memory available for table being imported
Runtime error: CALL_FUNCTION_TABLE_NO_MEMORY
Cause: For asynchronous RFC only: task name is already being used.
Runtime error: CALL_FUNCTION_TASK_IN_USE
Cause: For asynchronous RFC only: the specified task is already open.
Runtime error: CALL_FUNCTION_TASK_YET_OPEN
Cause: No RFC authorization
Runtime error: CALL_FUNCTION_NO_AUTH
Cause: No trusted authorization for RFC caller and trusted system.
Runtime error: CALL_RPERF_SLOGIN_AUTH_ERROR
Cause: No valid trusted entry for the calling system.
Runtime error: CALL_RPERF_SLOGIN_READ_ERROR
Cause: No RFC authorization for user.
Runtime error: RFC_NO_AUTHORITY
Cause: Destination "BACK" is not permitted in current program
Runtime error: CALL_FUNCTION_BACK_REJECTED
Runtime error: CALL_XMLRFC_BACK_REJECTED
Cause: Error while evaluating RFC destination
Runtime error: CALL_FUNCTION_DEST_SCAN
Cause: Error while evaluating RFC destination
Runtime error: CALL_FUNCTION_DEST_SCAN
Cause: Type conflict while transferring table
Runtime error: CALL_FUNCTION_CONFLICT_TAB_TYP
Cause: No memory available for creating a local internal table.
Runtime error: CALL_FUNCTION_CREATE_TABLE
Cause: Type conflict while transferring structure
Runtime error: CALL_FUNCTION_UC_STRUCT
Runtime error: CALL_FUNCTION_DEEP_MISMATCH
Cause: Invalid data type while transferring parameters
Runtime error: CALL_FUNCTION_WRONG_VALUE_LENG
Runtime error: CALL_FUNCTION_PARAMETER_TYPE
Runtime error: CALL_FUNCTION_ILLEGAL_DATA_TYP
Cause: Type conflict while transferring an integer.
Runtime error: CALL_FUNCTION_ILLEGAL_INT_LEN
Runtime error: CALL_FUNCTION_ILL_INT2_LENG
Cause: Type conflict while transferring a floating point number
Runtime error: CALL_FUNCTION_ILL_FLOAT_FORMAT
Runtime error: CALL_FUNCTION_ILL_FLOAT_LENG
Cause: Invalid LEAVE statement on RFC server
Runtime error: CALL_FUNCTION_ILLEGAL_LEAVE
Cause: Type conflict while transferring a reference
Runtime error: CALL_FUNCTION_OBJECT_SIZE
Runtime error: CALL_FUNCTION_ROT_REGISTER

Using Predefined Exceptions for RFCs

Synchronous RFC (CALL FUNCTION-DESTINATION)
Syntax
CALL FUNCTION func DESTINATION dest parameter list.
Effect
Synchronous call of a remote-capable function module specified in func using the RFC interface. With the addition
DESTINATION, the destination is specified in dest. Character-type data objects are expected for func and dest.
The calling program is continued using the statement CALL FUNCTION, if the remotely called function has
finished.

CALL FUNCTION - DESTINATION parameter list
Syntax
... [EXPORTING p1 = a1 ... pn = an]
[IMPORTING p1 = a1 p2 = a2 ...]
[CHANGING p1 = a1 p2 = a2 ...]
[TABLES t1 = itab1 t2 = itab2 ...]
[EXCEPTIONS exc1 = n1 exc2 = n2 ... [MESSAGE mess]
[OTHERS = n_others]].
Effect
These additions are used to assign actual parameters to the formal parameters of the function module, and return
values to exceptions that are not class-based. The additions have the same meanings as for the general function
module call, the only differences being that, with the addition TABLES, only tables with flat character types can be
transferred, and that if a header line exists, it is not transferred. The additions EXPORTING, IMPORTING and
CHANGING allow you to transfer tables that have deep character types, deep structures, and strings.
For EXCEPTIONS, you can also specify an optional addition MESSAGE for the special exceptions
SYSTEM_FAILURE and COMMUNICATION_FAILURE. If one of these exceptions occurs, the first line of the
corresponding short dump is entered in the field mess, which must be flat and of character-type.
Transferring tables using the addition TABLES is considerably faster than using the other additions, since a binary format is used
internally instead of an XML format.

Using Predefined Exceptions for RFCs

Using Pre-Defined Exceptions for RFC
The RFC interface defines two additional exception types:
SYSTEM_FAILURE
This exception reports all failures and system problems on the remote machine.
COMMUNICATION_FAILURE
This exception is raised when a connection or communications failure occurs. It does not report system problems (for example, abnormal
termination) that occur on the remote machine.
Requesting Error Messages
In the function modules that you call, you should use exceptions for any error reporting, and not the MESSAGE
keyword.
DESTINATION Dest
EXPORTING...
IMPORTING...
TABLES...
EXCEPTIONS
SYSTEM_FAILURE = 1 MESSAGE msg
COMMUNICATION_FAILURE = 2 MESSAGE msg
The system sets the message variable (msg) to the system message. You can then display the message or log it
in a file. You should not try to interpret message text in your program.

You can use MESSAGE only with the two system exceptions described here.

Using Transactional RFCs

Using Transactional Remote Function Calls
Data can be transferred between two SAP systems reliably and safely using a transactional RFC (tRFC).
The called function module is executed exactly once in the RFC server system. The remote system need not be
available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called
RFC function together with the corresponding data in the database of the SAP system, including a unique
transaction identifier (TID).
If a call is sent, and the receiving system is down, the call remains in the local queue until a later time. The calling
dialog program can proceed without waiting to see whether or not the remote call was successful. If the receiving
system does not become active within a certain amount of time, the call is scheduled to run in batch.
Transactional RFCs use the suffix IN BACKGROUND TASK.
As with synchronous calls, the DESTINATION parameter defines a program context in the remote system. As a
result, if you call a function repeatedly (or different functions once) at the same destination, the global data for the
called functions may be accessed within the same context.
The system logs the remote call request in the database tables ARFCSSTATE and ARFCSDATA with all of its
parameter values. You can display the log file using transaction SM58. When the calling program reaches a
COMMIT WORK, the remote call is forwarded to the requested system for execution.
All tRFCs with a single destination that occur between one COMMIT WORK and the next belong to a single logical
unit of work (LUW). For more information on LUWs, TIDs and on checking the status of transactional calls, see
Transactional Integrity of tRFCs.
Transactional RFC requests are transferred, with parameter data in byte-stream form, using TCP/IP or X400.

As an example, you can use transactional RFCs for specific types of update procedures. Some complex dialogs
require that several related database tables be updated during different phases within a transaction. If the update
functions needed are located on a remote machine, and if it is not essential that the table changes be carried out
immediately before continuing the dialog, you can use transactional RFC calls. Instead of having to wait for each
separate update procedure to be completed, the user can proceed to the end of the transaction without delay.
Transactional RFC processing ensures that all the planned updates are carried out when the program reaches the
COMMIT WORK statement.

Function modules that are to be called transactionally, cannot have any EXPORT parameters in the definition, since an IMPORTING
parameter in the calling program leads to a syntax error.
Note also that you cannot make asynchronous calls to functions that perform call-backs.
When the Remote System is Unavailable
If the remote system is unavailable, the SAP System schedules the report RSARFCSE for background processing
with the relevant transaction ID as variant. This report, which forwards asynchronous calls for execution, is called
repeatedly until it succeeds in connecting with the desired system.
When scheduled in batch, RSARFCSE runs automatically at set intervals (the default is every fifteen minutes, for
up to 30 attempts). You can customize this interval and the length of time the program should go on trying. To do
this, use the extension programs SABP0000 and SABP0003 (or see the SAP Extension Concept and CALL
CUSTOMER-FUNCTION).
In transaction SM59 (menu path: Tools Administration, Administration Network RFC destinations) you can
select Destination TRFC options which enables you to configure each destination. Thus you can determine the
number of connection attempts up to the task and the time between repeat attempts.
If the system is not reachable within the specified amount of time, the system stops calling RSARFCSE, and the
status CPICERR is written to the ARFCSDATA table. Within another specified time (the default is eight days), the
corresponding entry in the ARFCSSTATE table is deleted (this limit can also be customized). (It is still possible to
start such entries in transaction SM59 manually.)

CALL FUNCTION - IN BACKGROUND TASK

CALL FUNCTION - IN BACKGROUND TASK
Syntax
CALL FUNCTION func IN BACKGROUND TASK
[DESTINATION dest]
parameter list
[AS SEPARATE UNIT].
Addition:
... AS SEPARATE UNIT
Effect
Transactional call of a remote-capable function module specified in func using the RFC interface. You can use the
addition DESTINATION to specify an individual destination in dest. If the destination has not been specified, the
destination NONE is used implicitly. Character-type data objects are expected for func and dest.
When the transactional call is made, the name of the called function, together with the destination and the actual
parameters given in parameter list, are registered for the current SAP LUW in the database tables ARFCSSTATE
and ARFCSDATA of the current SAP system under a unique transaction ID (abbreviated as TID, stored in a
structure of type ARFCTID from the ABAP Dictionary, view using transaction SM58). Following this registration,
the program making the call is continued by way of the statement CALL FUNCTION.
When executing the COMMIT WORK statement, the function modules registered for the current SAP LUW are
started in the sequence in which they were registered. The statement ROLLBACK WORKdeletes all previous
registrations of the current SAP LUW.
If the specified destination is not available for COMMIT WORK, an executable called RSARFCSE is started in the
background. This attempts to start the functional modules registered for an SAP LUW in their destination, every 15
minutes up to a total of 30 times. You can make changes to these parameters using transaction SM59. If the
destination does not become available within the given time, this is noted in the database table ARFCSDATA as a
CPICERR entry. By default, this entry in database table ARFCSSTATE is deleted after 8 days.
Addition
... AS SEPARATE UNIT
Effect
When using the addition AS SEPARATE UNIT, the relevant function module is executed in a separate context, a
context in which the global data of the function group is not influenced by previous calls. Each function module that
is registered with the addition AS SEPARATE UNIT is given a separate transaction ID. Without the addition AS
SEPARATE UNIT, the usual description is applicable for the context of the called function modules. What this
means is that, when using the same destination for multiple calls of function modules belonging to the same
function group, the global data of this function group is accessed collectively.
You can use the function module ID_OF_BACKGROUNDTASK to define the transaction ID (TID) of the current SAP LUW,
according to a transactional RFC.
The transactional RFC (tRFC) is suitable for realizing LUWs in distributed environments (a typical application is ALE). Here it must be
noted that although executing the function modules within a transaction ID is predefined, the sequence of the LUWs on the RFC servers
does not necessarily correspond to the sequence of SAP LUWs in the RFC client. To achieve a serialization on the RFC servers as well, the
tRFC can be enhanced to queued RFC (qRFC). For this, you can call function module TRFC_SET_QUEUE_NAME before a transactional
RFC.

CALL FUNCTION - IN BACKGROUND TASK parameter_list
Syntax
... [EXPORTING p1 = a1 p2 = a2... ]
[TABLES t1 = itab1 t2 = itab2 ...] ... .
Effect
These additions are used to assign actual parameters to the formal parameters of the function module. The
significance of the additions is the same as for synchronous RFC with the exception that no values can be copied
with IMPORTING and CHANGING, and no return values can be allocated to exceptions that are not class-based.

Transactional Integrity of tRFCs

Transactional Integrity of tRFCs
You can execute function modules in background tasks in another SAP system or an external program. When you
call function modules in this way, they are not executed at once, but wait until a COMMIT WORK is triggered.
Transactional RFCs receive there name from the fact that the associated remote function call mechanism
guarantees transactional integrity for all calls made with the IN BACKGROUND TASKsuffix. As with database
updates, LUWs (logical units of work) are created for calls that are scheduled to run in background tasks. All
tRFCs with a single destination that occur between one COMMIT WORK and the next belong to a single LUW.
Within a given LUW, all calls:
execute in the order they were called
run in the same program context in the target system
run as a single transaction: they are either committed or rolled back as a unit.
LUWs are identified by transaction IDs that are unique world-wide. The transaction ID can be determined from an
ABAP program by calling function module ID_OF_BACKGROUNDTASK. (You must call this function after the first
asynchronous CALL, and before the related COMMIT WORK.)
Because the RFC is like a transaction, database operations are either all executed or, if a function module
terminates, all rolled back. If an LUW runs successfully, you cannot execute it again. In some cases, it may be
necessary to program the roll back of an LUW, (for example, because a table is locked). To do this, you call the
function module RESTART_OF_BACKGROUNDTASK which performs a rollback and ensures that the LUW is
executed again later.
Normally, the LUW is executed immediately after COMMIT WORK in the specified target system. However, you
can also define a certain time at which you want the execution to be made. To do this, call the function module
START_OF_BACKGROUNDTASK from within the affected LUW after the first CALL... IN BACKGROUND TASK
and before COMMIT WORK.

Checking the Status of Transactional Calls
All transactional RFCs are stored in the tables ARFCSSTATE and ARFCSDATA. Here, each LUW is identified by
a unique ID. When a COMMIT WORK is made, the calls belonging to this ID are executed in the target system.
The system function module ARFC_DEST_SHIP transports the data to the target system and the function module
ARFC_EXECUTE executes the stored function calls. If an error or an exception occurs during one of the calls, all
the database operations started by the preceding calls are rolled back and an appropriate error message is written
to the file ARFCSSTATE.
There are two methods for checking on the status of a transaction ID:
From an ABAP program
The function module ID_OF_BACKGROUNDTASK returns the ID of the LUW. You call this module after the first CALL... IN
BACKGROUND TASK and before COMMIT WORK.
CALL FUNCTION ID_OF_BACKGROUNDTASK IMPORTING TASK-ID = TID.
Once you have identified the ID of the LUW, you can use the function module STATUS_OF_BACKGROUNDTASK to determine the
status of the transactional RFC.
CALL FUNCTION STATUS_OF_BACKGROUNDTASK
Online
Call transaction SM58 (Tools Administration Monitoring Transactional RFC). This tool lists only those transactonal RFCs that
could not be carried out successfully or that had to be planned as batch jobs. The list includes the LUW ID and an error message. Error
messages displayed in SM58 are taken from the target system. To display the text of the message, double-click on the message.
Transaction SM58 also lets you control your transactional RFC at various stages. If the call ends abnormally during the sending process,
you may need to use the Rollback LUW function to manually rollback the LUW before attempting a resend. If the target system was
unavailable, you can use the Backgr.job function to display the batch job created for your call. Execute funct. module lets you restart the call
after the occurrence of a temporary error (such as a syntax error).
If a LUW runs successfully in the target system, the function module ARFC_DEST_CONFIRM is triggered and
confirms the successful execution in the target system. Finally, the entries in the Tables ARFCSSTATE and
ARFCSDATA are deleted.

RFC API
You can also execute programs asynchronously in 'C'-implemented function modules (connection type TCP/IP in
transaction SM59, see Destination Types). Implementation of the function modules occurs as usual in connection
with the RFC API. This contains the function modules ARFC_DEST_SHIP and ARFC_DEST_CONFIRM which
call the appropriate functions.

The qRFC Communication Model

qRFC Properties and Possible Uses
EXPORTING TID = TASK-ID
IMPORTING ERRORTAB = ERTAB
EXCEPTIONS
COMMUNICTATION
= 01
(Connection not available: will try
again later)

RECORDED = 02
(ARFC is scheduled)
ROLLBACK = 03
(Rollback triggered in target system)
All types of applications are instructed to communicate with other applications. This communication may take
place within an SAP system, with another SAP system, or with an application from a remote external system. An
interface that can be used for dealing with this task is the Remote Function Call (RFC). RFCs can be used to start
applications in remote systems, and to execute particular functions.
Whereas the first version of the RFC, the synchronous RFC, (sRFC) required both systems involved to be active in
order to produce a synchronous communication, the subsequent generations of RFC had a greater range of
features at their disposal (such as serialization, guarantee for one-time-only execution, and that the receiver
system does not have to be available). These features were further enhanced through the queued RFC with
inbound/outbound queue.
Communication between applications within an SAP system and also with a remote system can basically be
achieved using the Remote Function Call (RFC). Here, the following scenarios are possible:

Communication between two independent SAP systems
Communication between a calling SAP system and an external receiving system
Communication between a calling external system and an SAP receiving system

The following communication model shows what these communication scenarios may look like in reality. The
actual sending process is still done by the tRFC (transactional Remote Function Call). Inbound and outbound
queues are added to the tRFC, leaving us with a qRFC (queued Remote Function Call). The sender system is also
called the client system, while the target system corresponds to the server system.

In practice, the following three scenarios for data transfer exist:

Scenario 1: tRFC
This scenario is appropriate is the data being sent is independent of each other. A calling application (or client) in
system 1 uses a tRFC connection to a called application (or server) in system 2. In this scenario, data is
transferred by tRFC, meaning that each function module sent to the target system is guaranteed to be executed
one time only. You cannot define the sequence in which the function modules are executed, nor the time of
execution. If an error occurs during the transfer, a batch job is scheduled, which sends the function module again
after 15 minutes.

Scenario 2: qRFC with outbound queue
In this scenario, the sender system uses an outbound queue, to serialize the data that is being sent. This means
that function modules which depend on each other (such as update and then change) are put into the outbound
queue of the sender system, and are guaranteed to be sent to the target system one after each other and one time
only. The called system (server) has no knowledge of the outbound queue in the sender system (client), meaning
that in this scenario, every SAP system can also communicate with a non-SAP system. (Note: the programming
code of the server system must not be changed. However, it must be tRFC-capable.)

Scenario 3: qRFC with inbound queue (and outbound queue)
In this scenario, as well as an outbound queue in the sender system (client), there is also an inbound queue in the
target system (server). If a qRFC with inbound queue exists, this always means that an outbound queue exists in
the sender system. This guarantees the sequence and efficiently controls the resources in the client system and
server system. The inbound queue only processes as many function modules as the system resources in the
target system (server) at that time allow. This prevents a server being blocked by a client. A scenario with inbound
queue in the server system is not possible, since the outbound queue is needed in the client system, in order to
guarantee the sequence and to prevent individual applications from blocking all work processes in the client
system.

Properties of the Three Communication Types
To help you decide which communication type you should use in your system landscape for your requirements,
the advantages of the three communication types are listed below:
tRFC: for independent function modules only
qRFC with outbound queue: guarantees that independent function modules are sent one after each other and one time only (serialization).
Suitable for communication with non-SAP servers.
qRFC with inbound queue: in addition to the outbound queue in the client system, an inbound queue makes sure that only as many function
modules are processed in the target system (server) as the current resources allow. Client and server system must be SAP systems. One work
process is used for each inbound queue.

For more detailed information, refer to the qRFC documentation under:

Queued Remote Function Call (qRFC)

To view the entire qRFC directory tree, choose Synchronize from the upper left part of the screen. You can then navigate through the
entire qRFC documentation.

Using Asynchronous RFCs

Using Asynchronous Remote Function Calls
Asynchronous remote function calls (aRFCs) are similar to transactional RFCs, in that the user does not have to
wait for their completion before continuing the calling dialog. There are three characteristics, however, that
distinguish asynchronous RFCs from transactional RFCs:
When the caller starts an asynchronous RFC, the called server must be available to accept the request.
The parameters of asynchronous RFCs are not logged to the database, but sent directly to the server.
Asynchronous RFCs allow the user to carry on an interactive dialog with the remote system.
The calling program can receive results from the asynchronous RFC.
You can use asynchronous remote function calls whenever you need to establish communication with a remote
system, but do not want to wait for the functions result before continuing processing. Asynchronous RFCs can
also be sent to the same system. In this case, the system opens a new session (or window). You can then switch
back and for between the calling dialog and the called session
To start a remote function call asynchronously, use the following syntax:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
DESTINATION ...
EXPORTING...
TABLES ...
EXCEPTIONS...

The following calling parameters are available:
TABLES
passes references to internal tables. All table parameters of the function module must contain values.
EXPORTING
passes values of fields and field strings from the calling program to the function module. In the function module, the
corresponding formal parameters are defined as import parameters.
EXCEPTIONS
See Using Predefined Exceptions for RFCs

RECEIVE RESULTS FROM FUNCTION Remotefunction is used within a FORM routine to receive the results of an asynchronous remote
function call. The following receiving parameters are available:
IMPORTING
TABLES
EXCEPTIONS
The addition KEEPING TASK prevents an asynchronous connection from being closed after receiving the results
of the processing. The relevant remote context (roll area) is kept for re-use until the caller terminates the
connection.

Details are explained in the following topics:
Calling Requirements for Asynchronous RFCs
Receiving Results from an Asynchronous RFC
Keeping the Remote Context
Parallel Processing with Asynchronous RFC
CALL FUNCTION - STARTING NEW TASK
RECEIVE
WAIT UNTIL
RFC Example

Calling Requirements for Asynchronous RFCs
When you call a remote function with the optional suffix STARTING NEW TASK, the system starts the function in a
new session. Rather than waiting for the remote call to be completed, the user can resume processing as soon as
the function module has been started in the target system.
The remotely called function module can, for example, display a new screen using CALL SCREEN, allowing the
user to enter a dialog that connects him or her directly to the remote system:
Client System
STARTING NEW TASK Taskname
DESTINATION Dest

Server System
FUNCTION Remotefunction.
CALL SCREEN 100.
ENDFUNCTION.
If you do not specify a destination, the asynchronous RFC mechanism starts a new session within the calling
system.

You must not use IMPORTING when calling aRFCs.


To receive results from an asynchronously called function, use the following syntax:
PERFORMING RETURN_FORM ON END OF TASK.
Once the called function is completed, the next dialog step in the calling program (such as AT USER-COMMAND)
guides the system into the FORM routine that checks for results. This FORM routine consists of a special syntax
and must be called with a using parameter that refers to the name of the task:
Client System
DESTINATION Dest
PERFORMING RETURN_FLIGHT ON END OF TASK.
...
FORM RETURN_FLIGHT USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION Remotefunction
IMPORTING F1 = a1
EXCEPTIONS SYSTEM_FAILURE MESSAGE SYSTEM_MSG.
SET USER-COMMAND OKCD.
ENDFORM.

If a function module returns no result, the addition PERFORMING RETURN_FORM ON END OF TASK can be omitted.
If an asynchronous call calls several consecutive function modules with the same destination, you must assign a different task name to
each.
A calling program which starts an asynchronous RFC with PERFORMING cannot switch roll areas or change to an internal mode.
This is because the asynchronous function module call reply cannot be passed on to the relevant program. You can perform a roll area
switch with SUBMIT or CALL TRANSACTION.
If the calling program which has executed the asynchronous call is terminated, despite the fact that it is expecting replies, these replies
from the asynchronous call cannot be delivered.
You can use the WAIT statement with PERFORMING form ON END OF TASK to wait for the reply to a previously started
asynchronous call. In this case, WAIT must be in the same program context.
The program processing continues after WAIT if either the condition of a logical expression was satisfied by the subroutine that
performs the task in question, or a specified time period has been exceeded. For more information on the WAIT statement, see the online
help in the ABAP editor.
The key word RECEIVE occurs only with the function module call CALL FUNCTION Remotefunction STARTING NEW TASK
Taskname. If the function module returns no results, this part need not be defined.
The effect of the SET USER-COMMAND OKCD statement is exactly as if the user had entered the function in the command field
and pressed ENTER. This means that the current positioning of the list and the cursor is taken into account.

No call-backs are supported.

The SET USER-COMMAND OKCD statement replaces the REFRESH SCREEN command. REFRESH SCREEN is no longer
maintained and should therefore not be used.

DATA: INFO LIKE RFCSI,
* Result of RFC_SYSTEM_INFO function module
MSG(80) VALUE SPACE.
* Exception handling
CALL FUNCTION RFC_SYSTEM_INFO
STARTING NEW TASK INFO
PERFORMING RETURN_INFO ON END OF TASK
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG
COMMUNICATION_FAILURE = 2.MESSAGE MSG.
IF SY-SUBRC = 0.
WRITE: Wait for reply.
ELSE.
WRITE MSG
ENDIF.
...
AT USER-COMMAND.
* Return from FORM routine RETURN_INFO via SET USER-COMMAND
IF SY-UCOMM = OKCD.
IF MSG = SPACE.
WRITE: Destination =, INFO-RFCDEST.
ELSE.
WRITE MSG.
ENDIF.
ENDIF.
...
FORM RETURN_INFO USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION RFC_SYSTEM_INFO
IMPORTING RFCSI_EXPORT = INFO
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG
SYSTEM_FAILURE = 2 MESSAGE MSG.
SET USER-COMMAND OKCD. Set OK-code
ENDFORM.


In the FORM routine that checks for results of an asynchronously called function with RECEIVE RESULTS FROM
FUNCTION, the addition KEEPING TASK prevents the connection from being closed after receiving the results of
the processing.
FORM RETURN_INFO USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION RFC_SYSTEM_INFO
KEEPING TASK
...
ENDFORM.
The relevant remote context (roll area) is kept until the caller terminates the connection. If you specify the same
task name, you can re-use the remote context and roll area.
If the remote function module performs interactive tasks such as processing lists or dynpros, screens are
displayed until the calling program terminates. If the remote call is made in debugging mode, this mode is visible
until the caller dialog is terminated.

You should use the addition KEEPING TASK only if you want to re-use the current remote context for a subsequent asynchronous call.
Keeping a remote context increases storage load and decreases performance due to additional roll area management in the system.


To achieve a balanced distribution of the system load, you can use destination additions to execute function
modules in parallel tasks in any application server or in a predefined application server group of an SAP system.

Parallel-processing is implemented with a special variant of asynchonous RFC. Its important that you use only the correct variant for your
own parallel processing applications: the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword. Using other
variants of asynchronous RFC circumvents the built-in safeguards in the correct keyword, and can bring your system to its knees
Details are discussed in the following subsections:
Prerequisites for Parallel Processing
Function Modules and ABAP Keywords for Parallel Processing
Managing Resources in Parallel Processing
Prerequisites for Parallel Processing
Before you implement parallel processing, make sure that your application and your SAP system meet these
requirements:
Logically-independent units of work:
The data processing task that is to be carried out in parallel must be logically independent of other instances of the task. That is, the task can
be carried out without reference to other records from the same data set that are also being processed in parallel, and the task is not
dependent upon the results of others of the parallel operations. For example, parallel processing is not suitable for data that must be
sequentially processed or in which the processing of one data item is dependent upon the processing of another item of the data.
By definition, there is no guarantee that data will be processed in a particular order in parallel processing or that a particular result will be
available at a given point in processing.
ABAP requirements:
The function module that you call must be marked as externally callable. This attribute is specified in the Remote function call
supported field in the function module definition (transaction SE37).
The called function module may not include a function call to the destination BACK.
The calling program should not change to a new internal session after making an asynchronous RFC call. That is, you should not use
SUBMIT or CALL TRANSACTION in such a report after using CALL FUNCTION STARTING NEW TASK.
You cannot use the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword to start external programs.
System resources:
In order to process tasks from parallel jobs, a server in your SAP system must have at least 3 dialog work processes. It must also meet the
workload criteria of the parallel processing system: Dispatcher queue less than 10% full, at least one dialog work process free for processing
tasks from the parallel job.
Function Modules and ABAP Keywords for Parallel Processing
You can implement parallel processing in your applications by using the following function modules and ABAP
keywords:
SPBT_INITIALIZE: Optional function module.
Use to determine the availability of resources for parallel processing.
You can do the following:
check that the parallel processing group that you have specified is correct.
find out how many work processes are available so that you can more efficiently size the packets of data that are to be processed in
your data.
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname DESTINATION IN GROUP:
With this ABAP statement, you are telling the SAP system to process function module calls in parallel. Typically, youll place this keyword
in a loop in which you divide up the data that is to be processed into work packets. You can pass the data that is to be processed in the form
of an internal table (EXPORT, TABLE arguments). The keyword implements parallel processing by dispatching asynchronous RFC calls to
the servers that are available in the RFC server group specified for the processing.
Note that your RFC calls with CALL FUNCTION are processed in work processes of type DIALOG. The DIALOG limit on processing of
one dialog step (by default 300 seconds, system profile parameter rdisp/max_wprun_time) applies to these RFC calls. Keep this limit in
mind when you divide up data for parallel processing calls.
SPBT_GET_PP_DESTINATION: Optional function module.
Call immediately after the CALL FUNCTION keyword to get the name of the server on which the parallel processing task will be run.
SPBT_DO_NOT_USE_SERVER: Optional function module.
Excludes a particular server from further use for processing parallel processing tasks. Use in conjunction with
SPBT_GET_PP_DESTINATION if you determine that a particular server is not available for parallel processing (for example,
COMMUNICATION FAILURE exception if a server becomes unavailable).
WAIT: ABAP keyword
WAIT UNTIL <logical expression>
Required if you wish to wait for all of the asynchronous parallel tasks created with CALL FUNCTION to return. This is normally a
requirement for orderly background processing. May be used only if the CALL FUNCTION includes the PERFORMING ON RETURN
addition.
RECEIVE: ABAP keyword
RECEIVE RESULTS FROM FUNCTION Remotefunction
Required if you wish to receive the results of the processing of an asynchronous RFC. RECEIVE retrieves IMPORT and TABLE
parameters as well as messages and return codes.
Managing Resources in Parallel Processing
You use the following destination additions to perform parallel execution of function modules (asynchronous calls)
in the SAP system:
In a predefined group of application servers:
DESTINATION IN GROUP Groupname
In all currently available and active application servers:
DESTINATION IN GROUP DEFAULT
The addition first determines the amount of resources (work processes) currently available (i.e. in all servers or in
a group of application servers, comparable with login servers). The resources available for executing
asynchronous calls on each application server depends on the current system load.
The applications developer is responsible for the availability of RFC groups in the production system (i.e. the
customer's system). For details on how to maintain the RFC groups, see Maintaining Group Destinations For Load
Distribution.
After determining the available resources, the asynchronous call is executed in an available application server. If
no resources are available at that particular time, the system executes the exception routine
RESOURCE_FAILURE (see the addition Exceptions). In the case of an asynchronous function module call, this
exception must be handled by the application program.
The process for determining available resources in an RFC group is as follows:
First, the system determines the length of the dispatcher queue for the relevant application server. If it is greater
than 10% of the overall length, the server makes no resources available. If it is smaller, the system makes
available the current number of free dialog processes minus 2 (as a reserve instance for other purposes, e.g. for
logon to the system or administration programs). Thus, one application server must have at least 3 dialog
processes if RFC parallel processing is taken into account.

At present, only one RFC group per program environment is supported for parallel execution of asynchronous calls. Using both
additions (DESTINATION IN GROUP Groupname and DESTINATION IN GROUP DEFAULT) in one program is not allowed.
The exception routine RESOURCE_FAILURE is only triggered in connection with asynchronous RFCs with the additions
DESTINATION IN GROUP Groupname and DESTINATION IN GROUP DEFAULT.
You are recommended (for performance and other reasons) to use an RFC group with sufficient resources for parallel
processing of asynchronous calls

Continue with the following section:

Syntax
CALL FUNCTION func STARTING NEW TASK task
[DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]
parameter list
[{PERFORMING subr}|{CALLING meth} ON END OF TASK].
Additions:
1. ...DESTINATION IN GROUP { group |DEFAULT}

2. ...{PERFORMING subr}|{CALLING meth} ON END OF TASK
Effect
Asynchronous call of a remote-capable function module specified in func using the RFC interface. You can use
the addition DESTINATION to specify a single destination in dest, or to specify a group of application servers by
using IN GROUP. The latter supports parallel processing of multiple function modules. The calling program is
continued using the statement CALL FUNCTION, as soon as the remotely called function has been started in the
target system, without having to wait for its processing to be finished. You can use PERFORMING and CALLINGto
specify callback routines for copying results when the remotely called function is finished. Character-type data
objects are expected for func and dest.
If the destination has not been specified, the destination NONE is used implicitly. When the destination NONE is
used, a new main session is opened for the current user session. The asynchronous RFC does not support
communication with external systems or programs written in other programming languages.
A character-type data object must be specified for task, one which contains for the remotely called function
module a freely definable task ID that has a maximum eight digits. This task ID must be unique for each call, and
is handed to the callback routines for identifying the function. Each task ID defines a separate RFC connection
with its own context, meaning that, in the case of repeated function module calls of the same task ID, the global
data of the relevant function group can be accessed, if the connection still exists.

In dialog processing, note that the maximum number of six main sessions cannot be exceeded, else an error message is displayed.
Addition 1
... DESTINATION IN GROUP {group|DEFAULT}

Effect
Specifying IN GROUP as a destination allows you to execute multiple function modules in parallel on a predefined
group of application servers in the current SAP system.
For group, you must specify a data object of the type RZLLI_APCL from the ABAP Dictionary, one that is either
initial, or one that includes the name of an RFC server group created in transaction RZ12. When specifying
DEFAULT, or if group is initial, all application servers that are currently available in the current SAP system are
used as a group. Only one RFC server group may be used within a program. During the first asynchronous RFC
using the addition IN GROUP, the specified RFC server group is initialized. For each asynchronous RFC where
the group is specified, the most suitable application server is determined automatically, and the called function
module is executed on this.
If the function module cannot be executed on any application server, due to not enough resources being currently
available, this leads to the predefined exception RESOURCE_FAILURE, to which a return value can be assigned,
in addition to the remaining RFC exceptions. For this exception, the addition MESSAGE is not permitted.

The parallel processing of function modules using the addition IN GROUP makes optimum use of the resources available, and is
preferred to self-programmed parallel processing with destinations that are specified explicitly.
An application server that is used as part of an RFC server group for parallel processing must have at least three dialog work processes,
of which one is currently free. Other resources such as requests in the queue, number of system logons and so on, are also taken into
account, and are not allowed to exceed certain limit values.
To ensure that only those application servers that have enough resources are accessed, we recommend that you work with explicitly
defined RFC server groups instead of working with the addition DEFAULT.
The function modules of the function group SPBT provide service functions for parallel processing, for example, initialization of RFC
server groups, determining the used destination, or temporarily removing an application server from an RFC server group.

Addition 2
... {PERFORMING subr}|{CALLING meth} ON END OF TASK

Effect
You can use this addition to specify either a subprogram subr or, as of Release 6.20, a method meth as a callback
routine, which is executed after the asynchronously called function module has finished. For subr, you have to
directly specify a subprogram of the same program. For meth, you can enter the same details as for the general
method call.
The specified subprogram subr can have exactly one SING parameter of type clike only. The method meth must
be public, and can have only one non-optional input parameter p_task of type clike. When the RFC interface is
called, this parameter is supplied with the task ID of the remotely called function that was specified in the call in
task. The results of the remote function can be received in the subprogram subr or method meth using the
statement RECEIVE. In the callback routine, no statements can be executed that cause the program run to
terminate or end an SAP LUW. Statements for list output are not executed.
Prerequisite for executing a callback routine is that, after the remote function has ended, the calling program is still
internally available. It is then executed the next time the work process is changed. If the program has ended, or if it
is part of a call sequence in the stack, then the callback routine is not executed. The statement WAIT can be used
to stop the program execution until certain or all callback routines have been executed.

CALL FUNCTION - STARTING NEW TASK parameter_list
Syntax
... [EXPORTING p1 = a1 p2 = a2 ...]
Effect
These additions are used to assign actual parameters to the formal parameters of the function module, and return
values to exceptions that are not class-based. These additions have the same meaning as for the synchronous
RFC. The only exception is that no values can be copied with IMPORTING and CHANGING.

RECEIVE

RECEIVE
Syntax
RECEIVE RESULTS FROM FUNCTION func
parameter list
[KEEPING TASK].
Addition:
... KEEPING TASK
Effect
This statement can be used in a callback routine specified for the asynchronous RFC, in order to receive output
parameters of an asynchronously called function func in the parameter list parameter list, and to assign return
values to exceptions.
If a function module is started multiple times in a row using asynchronous RFC, the execuction sequence is not fixed, instead it
depends in the system availability.
Addition
... KEEPING TASK
Effect
With the addition KEEPING TASK, the asynchronous RFC connection is retained, as is the context of the called
function module along with it. When a new call is made with the same task ID, the same global data of the function
group is addressed. Without the addition KEEPING TASK, an asynchronous RFC connection is finished after the
remote function is executed or the results are copied.

You must only use the addition KEEPING TASK if the context of the called function module is required for other function calls.

RECEIVE - parameter_list
Syntax
... [IMPORTING p1 = a1 p2 = a2 ...]
Effect
With these additions, the defined formal parameters of the function module specified in func are transferred to the
actual parameters of the callback routine in the calling program , and return values are assigned to non-class-
based exceptions. The meaning of the additions is the same as for a synchronous RFC. In particular, the special
exceptions SYSTEM_FAILURE and COMMUNICATION_FAILURE can be assigned return values. If no exceptions
occur, RECEIVE sets the contents of sy-subrc to 0.

WAIT UNTIL

WAIT UNTIL
Syntax
WAIT UNTIL log_exp [UP TO sec SECONDS].
Addition:
... UP TO sec SECONDS
Effect
This variant of the statement WAIT is only intended to be used after an asynchronous RFC with callback routines.
It interrupts the program execution for as long as the result of the logical expression log_exp is false. Any logical
expression can be specified for log_exp.
If the result of log_exp is false, the program waits until a callback routine of a function that was previously called
asynchronously has been executed, and then checks the logical expression again. If the result of the logical
expression is true, or if the callback routines of all functions that were previously called asynchronously have been
executed, then the program execution continues with the statement following WAIT.
Addition
... UP TO sec SECONDS
Effect
Specifying UP TO restricts the program interruption to a maximum number of seconds, specified in sec. A data
object of type f is expected for sec, which must contain a positive integer. After the specified time period has
passed at the very latest, the program execution continues with the statement following WAIT.
System Fields System Fields System Fields System Fields

The statement WAIT causes a switch in the work process, which is linked to the rollout and rollin of all loaded programs. For this
reason, the time given in sec must not be less than one second, to avoid burdening the system with too many work process switches.
Each time the statement WAIT is used, a database commit is performed. For this reason, WAIT must not be used between Open SQL
statements that open or close a database cursor.
There is also one variant of the statement WAIT that can be used independently of the asynchronous RFC.
Exceptions
Exceptions that cannot be processed
Cause: Undefined state of the statement WAIT
Runtime error: WAIT_ILLEGAL_CONTROL_BLOCK
Cause: Negative time entry for sec.
Runtime error: WAIT_ILLEGAL_TIME_LIMIT

RFC Example

sy-subrc Meaning
0 The logical condition log_exp was fulfilled.
4 No asynchronous function calls exist.
8 Maximum time exceeded while specifying the addition UP TO.
RFC Example
Parallel, asynchronous processing of the function module RFC_SYSTEM_INFO using asynchronous Remote
Function Calls. Ten calls are made, each occurring in separate work processes due to them having different task
IDs name. In the callback routine rfc_info, the completed function modules are counted, and information about
the target system is received.
Through using the addition GROUP DEFAULT, the execution is distributed across all application servers of the
current system. If no more free work processes are available after at least one successful call, the execution of the
program is stopped until all function modules started up to that point have been completed. This stoppage is
limited to a maximum of 5 seconds.
After all function modules have been started, the system waits until all callback routines have been executed. After
that, the internal table task_list filled there is output. The output shows the sequence in which the individual tasks
completed, and on which application server each of them was executed.
TYPES: BEGIN OF task_type,
name TYPE string,
dest TYPE string,
END OF task_type.

DATA: snd_jobs TYPE i,
rcv_jobs TYPE i,
exc_flag TYPE i,
info TYPE rfcsi,
mess TYPE c LENGTH 80,
indx TYPE c LENGTH 4,
name TYPE c LENGTH 8,
task_list TYPE STANDARD TABLE OF task_type,
task_wa TYPE task_type.

DO 10 TIMES.
indx = sy-index.
CONCATENATE 'Task' indx INTO name.
CALL FUNCTION 'RFC_SYSTEM_INFO'
STARTING NEW TASK name
DESTINATION IN GROUP DEFAULT
PERFORMING rfc_info ON END OF TASK
EXCEPTIONS
system_failure = 1 MESSAGE mess
communication_failure = 2 MESSAGE mess
resource_failure = 3.
CASE sy-subrc.
WHEN 0.
snd_jobs = snd_jobs + 1.
WHEN 1 OR 2.
MESSAGE mess TYPE 'I'.
WHEN 3.
IF snd_jobs >= 1 AND
exc_flag = 0.
exc_flag = 1.
WAIT UNTIL rcv_jobs > = snd_jobs
UP TO 5 SECONDS.
ENDIF.
IF sy-subrc = 0.
exc_flag = 0.
ELSE.
MESSAGE 'Resource failure' TYPE 'I'.
ENDIF.
WHEN OTHERS.
MESSAGE 'Other error' TYPE 'I'.
ENDCASE.
ENDDO.

WAIT UNTIL rcv_jobs >= snd_jobs.
LOOP AT task_list INTO task_wa.
WRITE: / task_wa-name, task_wa-dest.
ENDLOOP.

FORM rfc_info USING name.
task_wa-name = name.
rcv_jobs = rcv_jobs + 1.
RECEIVE RESULTS FROM FUNCTION 'RFC_SYSTEM_INFO'
IMPORTING
rfcsi_export = info
EXCEPTIONS
system_failure = 1 MESSAGE mess
communication_failure = 2 MESSAGE mess.
IF sy-subrc = 0.
task_wa-dest = info-rfcdest.
ELSE.
task_wa-dest = mess.
ENDIF.
APPEND task_wa TO task_list.
ENDFORM.


This section provides specifics on writing function modules that can be called remotely. For information about
writing function modules generally, see the system documentation on "Writing Function Modules".
This section contains the following topics:
Steps for Implementing Remote Function Modules
Programming Help
Debugging Remote Function Modules

If required, you can find more detailed information about function modules under:
Function Builder

To view the entire directory tree of the function module documentation, choose Synchronize from the upper left part of the screen.
You can then navigate through the entire function module documentation.

Steps for Implementing Remote Function Modules
To implement a remote function module in ABAP, perform the following steps:
Write the code for the function module.
For guidelines for creating function modules in the Application Server ABAP Repository, see: Function Builder
Register the module as remotely callable in the RFC server system.
In the function module Administration screen (transaction code SE37), set the field Can be called via Remote Function Call. Registering a
module as remote causes an RFC stub to be generated for it.

Define the destination of the RFC server in the RFC client system that calls the remote function.
Either you or your system administrator can maintain the RFCDES table using transaction SM59 (Tools
Administration, Administration Network RFC destinations). For more detailed information, see Maintaining
Remote Destinations.
You can then use this destination in your programs to call the function module.

Programming Tips

Programming Tips
The following sections describe some points to remember when you write a remote function module.
Declaring Parameters
For normal (non-remote) function modules, if a parameter is not defined like an ABAP Dictionary field, it takes the
data type of the actual parameter used at run-time. A remote function module, however, does not have this
information available. As a result, all parameter fields for a remote function module must be defined as reference
fields, that is, like ABAP Dictionary fields. (This applies to IMPORT, EXPORT, CHANGING and TABLES
parameters.)
For character structures or fields, the caller's parameters need not be as long as expected by the called program.
When incoming parameters are shorter, RFC simply pads them with blanks. This means that the ABAP Dictionary
definition of character parameters need not be exactly the same on the calling and called sides. (However, the
caller's parameters may not be longer than expected on the called side).
Writing for Transactional Execution

There are two restrictions on writing remote functions that are to be called transactionally:
Transactional calls cannot return parameter values. As a result, the interface for these functions should not specify any EXPORT
parameters.
Functions that run transactionally may not perform call-backs: the caller's context does not necessarily still exist when the call-back is
relayed back to the original system.
Exceptions
You can trigger exceptions in a remote function just as you would in a locally called function.
Since the system raises COMMUNICATION_FAILURE and SYSTEM_FAILURE internally, there is no reason for
you to trigger them in your function module.
Calling Other Remote Functions
A remote function can call other remote functions, just like an ordinary function module.
In particular, it can use the call-back feature to call function modules running in the system of the original caller.
For more detailed information about callbacks between SAP systems, see Calling Remote Functions Back.


For testing "ABAP-to-ABAP" RFCs, you can use the ABAP Debugger. Here, you can debug the execution of the
RFC function in the remote system. Static breakpoints, single-stepping, variable-watching and source display are
possible.
With remote calls, the ABAP debugger (including the debugging interface) runs on the local system. Data values
and other run information for the remote function are passed in from the remote system.

Continue with the following section:

In transaction SM59, choose Tools System Administration Administration Network RFC Destinations.

For more details, see the following sections:

Displaying, Maintaining and Testing Destinations
Entering Destination Parameters
Destination Types
Maintaining Group Destinations
Settings for Special Code Pages

Displaying, Maintaining, and Testing Destinations

To display, create, or change destinations, call the SAP menu and choose Tools Administration
Administration Network RFC Destinations (Transaction SM59).
Remote destinations are stored in table RFCDES. Table RFCDES describes logical destinations for remote

function calls (RFCs). You cannot maintain table RFCDES directly.
Displaying Destinations
The initial screen shows a tree which that allows you to select various connection types (such as partner systems
or partner programs). For more information, see Destination Types.
To find a destination, choose Search and enter your selection criteria. A list of suitable entries is displayed. You
can display all information available for each entry.
Creating Destinations
On the initial screen for destinations, the connection types and all existing destinations are displayed in a tree
structure.
For an explanation of the available connection types, see Destination Types.
To create a new RFC destination, choose Create. A new screen is displayed with empty fields where you have to
make entries.
If you are creating a remote destination, you can enter a particular application server, or a group of servers to
distribute system load.
For more detailed information on destination parameters, see Entering Destination Parameters.
Changing Existing Destinations
On the initial screen for destinations (transaction SM59), the connection types and all existing destinations are
displayed in a tree structure.
To change an existing RFC destination, choose Change.
For more detailed information on destination parameters, see Entering Destination Parameters.
Testing Destinations
To test a destination, choose the relevant function from the Test menu.
Connection (also a pushbutton)
Authorization (checks logon data)
Network of Application Servers (returns a list of application servers)

Entering Destination Parameters

In addition to the RFC destination, you must enter the following information:
Technical settings
Connection type
Enter an existing connection type.
For an explanation of the available connection types, see Destination Types.
Trace
Mark the Trace option to have the RFC communication logged and stored in a file. You can then display the file, both in the calling and
receiving system, using report RSRFCTRC.
Load balance
If you choose load balancing, you must specify the following information:
Target system (For a list of available servers, log on to the target system and choose Tools Administration, Monitor System
Monitor Servers.)
Message server (Log on to the target system and choose Control Control Panel from the CCMS main menu. It is the server that
offers the service M.)
Group (of servers) (see SAP Logon Group of Servers)
Otherwise, you must specify the following information:
Target host
The name of a server host of the target system that you want to use as a port to the system.
System number
Communications service used with the target system. To obtain it, choose Tools Administration Monitor System Monitor
Servers.
Security Options
The following options are available only with some connection types:
Trusted system (for type 3 only) If the target system is a trusted system, choose Yes. For detailed information about trusted systems, see
Trusted/Trusting Relationships Between SAP Systems.
SNC (Secure Network Communications, available for types 3 and T only) If you have an active SNC-supported security system, you
can activate additional security options which you must set via Destinations SNC options.
Description
Text description of the entry.
Logon
Language
System language to be used
Client
Client code
User
User name to be used for remote logon, if different from current user name
Password
User password
Current user
The current user name is to be used for remote logon.

The Attributes section contains creation and change information.

Destination Types

Destination Types
Each destination has a connection-type field (Connection type) that indicates the system connection type:
R/2 Connections (Type 2)
Type 2 entries indicate R/2 systems. No further specification is required. When you create a type 2 entry, therefore, you only need to specify
the host name. All communications information is already stored in the background info table in the SAP Gateway host. If you want, you
can also specify logon information.
Example entry name: K50
ABAP Connections (Type 2)
Type 3 entries indicate ABAP systems. When you create a type 3 entry, you need to specify the host name and communication service. If
you want, you can also specify logon information. As of Release 3.0, you can also select the load-balancing option.

You can specify an application server from the ABAP message server. The application server is then determined according to the load-
balancing process. This applies to RFCs between two ABAP systems and to RFCs between an ABAP system and an external system.
Example entry name: K11
Internal Connections (Type I)
Type I entries indicate ABAP systems connected to the same data base as the current system. These entries are pre-defined and cannot be
modified. The entry names are the same as those used in the SAP Message Server (transaction SM51)
Example entry name: hs0010_K11_24
hs0010=host name
K11=system name (database name)
24=TCP-service name
Logical Destinations (Type L)
Instead of indicating a system connection, type L (logical) entries refer to a physical destination. Type L destinations can also refer to other
type L entries. A type L entry uses the information in the reference entry and adds further information of its own. Normally, the reference
entry contains the host information, while the type-L entry contains logon data. You can also specify a user name, an explicit password, a
logon language or an explicit client.
A type L entry can refer to other type L entries.
Example entry name: K11_SD or K11_01
K11=name of RFCDES entry for ABAP system K11
SD or 01: for the fields User='SD_INPUT' or client='001'
Connections via ABAP Driver (Type X)
Type X entries indicate systems where device drivers in ABAP have been specially installed. When you create a type X entry, you need to
specify the name of the ABAP device driver.
TCP/IP Connections (Type T)
Type T destinations are connections to external programs that use the RFC library to receive RFCs. The activation type can be either Start
or Registration.
If it is Start, you need to specify the host name and the path name of the program that you want to start.
Activation Type Start
The communication method depends on how you select the program location:
Explicit host
In this case, the program is started either by the default gateway for the system or by the explicitly specified gateway (gwrd) via remote
shell.
Ensure that the computer with the gateway process can access the specified computer by entering /etc/ping <host name>.
If you want to start a program on another computer using the remote shell, the target system must meet certain conditions.
The user ID of the gateway process must exist, and the users directory must contain a file called .rhosts.
The file .rhosts must contain the name of the calling computer.
To check this, log on to the computer containing the gateway process with the appropriate user ID and enter the command remsh <host
name> <program name>. The <host name> and <program name> must be the same as in SM59 . (If you call an RFC server program
without any parameters, the RfcAccept call always returns an error code (RFC_HANDLE_NULL), and the program terminates
immediately.)
Application Server
When choosing Application server and specifying your program, you can start the program from the SAP application server.
First, ensure that the program can be accessed from the SAP application server and that the SAP application server has the authorization to
start the program.
To check this, log on with the user ID of the SAP application server (e.g. c11adm). If possible, change to the working directory of the SAP
application server (/usr/sap/.../D.../work) and try to start the RFC server program manually from there. (If you call an RFC server program
without any parameters, the RfcAccept call always returns an error code (RFC_HANDLE_NULL), and the program terminates
immediately.)
Front-End Workstation
When choosing Front-end workstation and specifying your program, you can start the program from the SAPGUI.
Ensure that you can access the program with SAPGUI.
Ensure that SAPGUI has the authorization to start the program.
To check this, simply call the RFC server program in your environment.
The function call can also be transactional (CALL FUNCTION... IN BACKGROUND TASK DESTINATION...).
Activation Type Registration
If the activation type is Registration, you have to identify a registered RFC program. With an SAP gateway, you can register an RFC server
program under this ID and then wait for RFC calls from other SAP Systems.
Example entry name: SERVER_EXEC
Type M
Type M entries are asynchronous RFC connections to ABAP systems via CMC (protocol X.400).
Type S
Type S corresponds to type 2, except that the destination is SNA or APPC.

HTTP Connection to Ext. Server (Connection Type G)
Select the connection you require. You can choose from the following logon procedures:
No logon. The server program does not require you to enter a user or password.
Basic Authentication. The server program requires you to enter a user and password. Basic Authentication is a standard HTTP
authentication method. When the user logs on to the target system, a user ID and a password are provided for authentication. This
information is then transmitted across the HTTP connection to the server, in the form of a base64 encoded string in a header variable.
SSL Client Certificate. If you use client certificates for the authentication, the client authentication is performed using the
Secure Sockets Layer (SSL) protocol. In this instance, you also have to select the SSL client PSE of the Application Server, which contains
the certificate that is to be used for the authentication. The target system must treat the system that issues the client certificate of the SAP
NW AS as a trusted system.

On the Logon/Security tab page, you can also activate SSL, so that HTTPS is used as a protocol (you must
then make sure that the correct port is set under Technical Settings). To define which type of SSL client is
used, call the security transaction STRUST. ( Getting Started with the Trust Manager, Trust Manager).
As an additional protective measure, the field Authorization for Destination has been introduced. We
recommend that you specify a user and a password for the RFC destination.

HTTP Connection to an ABAP System (Connection Type H)
Here you have a variety of options for authentication in the target system.
The settings on the Technical Settings and Special Options tab pages are identical to those of
connection type G. On the Logon/Security tab page, connection type H has additional logon processes
compared to connection type G. As with the external server, you can (de)activate SSL and specify an
authorization.
As the destination 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 again.
The options available for the authentication are Basic Authentication, SAP Standard, SAP Trusted
System and SSL Client Certificate.
HTTP Basic Authentication: Logon using user and password.
SAP Standard: This method uses a logon like the RFC logon processes. Here, the RFC Single Sign-On procedures within a system also
apply. The same SAP user (client, language, and user name) is used for logon.
SAP Trusted System: Trusted RFC logon to another SAP system (see: Trusted System: Trust Relationships Between SAP Systems).
SSL Client Certificate: Using the SSL protocol, the logon can be made using client certificates.


To achieve a balanced load distribution in the target system, you must define a group of application servers as an
RFC destination. When processing tasks in parallel, you can use the group destination only in connection with the
asynchronous RFC.
The resources available on each application server depends on the current system load.
To display and maintain the RFC groups, proceed as follows:
Call transaction SM59.
From the RFC destination overview screen, choose RFC RFC groups.
You then see:
the names of any RFC groups that have already been defined
a list of the instances (host, system and instance number) in your SAP system
the current status (active or not) of each server.
To define an RFC group, choose Edit Create. Enter a server group name and an instance in the dialog window.
To add instances to an existing group, double click the group name and enter a new instance in the dialog window.
By creating duplicate entries, you can assign a server to more than one group. In this case, jobs that use the group will compete for free
work processes on the shared server(s).

Usage examples:
You could use groups to allow different parallel-processed jobs to run at the same time without competing for the same servers. In this case,
the different groups used by the jobs would specify different servers.
You could also use groups to separate processing from servers on which dialog users are active. In this case, the group used for processing
would name servers other than those in the logon groups for users.


In Unicode systems, you configure the conversion of text data for the RFC destinations on the tab page Special
Options. Here, F1 help is available for you to get more information. You can configure the following:
Character Width in Target System
Here you specify whether the RFC destination is a Unicode system or a non-Unicode (MDMP) system. A
pushbutton gets this information from the target system.
MDMP Setting for Non-Unicode Destinations
For non-Unicode destinations, the RFC either uses a preconfigured assignment of languages to code pages that is
the same for all destinations, or an assignment which can be maintained for the destination; at the push of a button
you can get the assignment list of the destination system by way of RFC.
Character Conversion
Here you define how conversion errors are handled:
The RFC terminates when conversion errors occur, or continues despite conversion errors, whereby non-convertible characters are
replaced with replacement characters.
The RFC replaces non-convertible characters with the replacement character #.
The RFC replaces non-convertible characters with another character that you can choose.

Preconfigured Code Pages
The RFC uses a preconfigured assignment of text languages to code pages if:
The destination is set to non-Unicode and MDMP inactive.
A non-Unicode system calls a function in a Unicode system and does not make known its assignment list; this is true for systems with
kernel older than Release 6.20, Patch level 375. More recent systems transmit their assignment list to the called Unicode system, meaning
that the preconfiguration is not required.

The following table shows this assignment; the called system uses the transport code page specified by the caller,
to determine whether the data involved is EBCDIC data or not.

This table applies to standard transport code pages that are based on ISO standards (such as 1100, ISO8859-1)
or country-specific standards (such as 8000, SJIS). If SAPs own code pages are used as transport code pages,
then the following assignment applies:

Language (ISO, SAP ID):
Transport Code Page:
Non EBCDIC EBCDIC
West European languages 1100 0120
East European languages 1401 0410
Baltic languages 1900 0120
Japanese (JA, J) 8000
Chinese (ZH, 1) 8400
Korean (KO, 3) 8500
Arabic (AR, A) 8700
Taiwanese (ZF, M) 8300
Thai (TH, 2) 8600 0860
Ukrainian (UK, 8) 1500 0500
Hebrew (HE, B) 1800 0800
Greek (EL, G) 1700 0700
Russian (RU, R) 1500 0500
Turkish (TR, T) 1610 0610
Bulgarian (BG, W) 1500 0500
Transport Code Page: Examples Assigned Code Page:
SAP blended ambiguous 6100 SAP Unification
6200 Asian Unification
6500 Diocletian
Standard code page depending on text language.
Data is therefore reinterpreted uniquely, language-
dependently.
SAP blended unambiguous 6300 Euro Japan The same code page.


Trusted System: Trust Relationships Between SAP
Systems

SAP systems may establish trusted relationships between each other.
If a calling SAP system is known to the called system as a trusted system, no password must be supplied.
The calling SAP system must be registered with the called SAP system as a trusted system. The called system is
called the trusting system.
Trust relationships between SAP systems have the following advantages:
Single Sign-On is possible beyond system boundaries.
No passwords are transmitted in the network.
Timeout mechanism protects against replay attacks.
User-specific logon data are checked in the trusting system.
Using this feature, you can create a virtual SAP system consisting of various SAP systems that are called
remotely. Remote logon data are checked in the trusting system.
The trust relationship is not mutual, which means, it applies to one direction only. To establish a mutual trust
relationship between two partner systems, you must define each of the two as trusted systems in its respective
partner system.
For additional security, you can make use of SAPs SNC interface (Secure Network Communications) for third-
party security systems such as Kerberos and SECUDE.
Displaying, Maintaining and Testing Trusted Systems
To display or maintain a trusted system in the trusting system, proceed as follows:

If you want to define an SAP system as a trusted system, you must first create a logical destination that allows a trusted system
relationship.
From the RFC destination overview screen (transaction SM59), choose RFC Trusted systems or enter transaction code SMT1.
If trusted systems have already been defined, they are displayed in a hierarchy tree. To display existing trusted systems, expand the
nodes in the hierarchy tree.
To create a trusted system, click the Create icon.
In the dialog window, enter the destination for the remote system. To change a destination, see Changing Trusted Destinations below.
All the necessary information such as application server name and security key is supplied automatically.
If you want to restrict the validity period of the logon data, enter an end date in the Validity period field.
If you want take over the transaction code of the calling program into the called system, mark the appropriate checkbox.
Data is already coded uniquely.
Transliteration 1180 1180.
Data is already coded uniquely.
Only then will an authorization check be performed in the called system for the transaction code (field RFC_TCODE of the S_RFCACL
authorization object, see Logon Authorization Checks in the Trusting System below).

As you delete a trusted system relationship, the logon screen of the relevant system is displayed, if no valid logon data are provided. You
must log on to that system to complete the deletion.

Changing Trusted Destinations
You can change existing destinations for each system from the trusted system maintenance screen (RFC
Trusted systems, transaction code SMT1) by clicking on the Maintain destination pushbutton.
In trusted systems, destinations for trusting systems are automatically created. These destinations are used when
you display trusting systems via RFC Trusting systems (transaction code SMT2).
To prevent others from making changes to your trusted destination, mark the checkbox Destination not
changeable in the Attributes section. To make the destination changeable again, double-click the checkbox.
Note that destinations must be kept consistent. For this reason, you are not allowed to change the ID of the target
system, the system number, or the destination name.
Displaying Trusting Systems
In a trusted system, you can obtain a list of all trusting systems. Choose RFC Trusting systems to display the
list of trusting systems.
Click on the name of a trusting system to display the application servers of that system. The application server
names contain the suffix _TRUSTED.
Double-clicking the name of an application server displays a dialog box, in which you can enter the transaction that
you want to execute in the trusting system. You can also specify whether the transaction is to be executed in the
same session, or in a new one.
Logon Authorization Checks in the Trusting System
The logon data used for logging on to a trusting system undergo an authorization check.
The data provided by the trusted system is checked for system name, client, user name, and other optional data.
These data must match the field values of authorization object S_RFCACL.
The system administrator can check a users logon data using the function module
AUTHORITY_CHECK_TRUSTED_SYSTEM.
Error return codes are explained in the Troubleshooting section below.
Testing Trusting Systems
To test a trusted system, you can perform the authorization checks for the current server and the trusting system.
To do this, choose the menu entry. If no valid logon data are supplied, the logon screen of the trusted systems
appears. You should log on to the system. If your test is not successful, read the section Troubleshooting in
Trusted/Trusting Systems below.
Troubleshooting in Trusted/Trusting Systems
After creating a trusted system, you have to test the destination. To do this, log on to the trusted system using
remote login.
Alternatively, you can also perform an authorization check for the trusted server. To do this, select the respective
function from the test menu.
If your login attempt fails, you will receive the following message: No authorization to log in as trusted system
(error code = <0|1|2|3>). Note that the special users DDIC and SAP* must not be used.
The error code explanation is as follows:
Invalid login data (user ID and client) for the trusting system
Solution: Create the user ID for the client in the trusting system.
No trusted system entry exists for the calling system, or the security key for the system is invalid.
Solution: Create the trusted system entry again.
The user does not have a trusted system authorization (object S_RFCACL).
Solution: Provide the user with the necessary authorization.
The time stamp of the login data is invalid.
Solution: Check the clock settings on both the client and server host and the expiration date of the login data. (Note that the default
expiration period 00:00:00 means no limit.)

You can check whether correct login information has been provided for the trusted system in the trusting system
by means of the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.
If all your tests are successful and you still dont get access to the trusting system, refresh the relevant database
by choosing Environment Mass changes Reset all buffers from the user maintenance screen.

To find out the cause of an error, activate the trace flag on the destination details screen, reproduce the error and read the information
provided with the error ID CALL_FUNCTION_SINGLE_LOGIN_REJ in the short dump created in the called system (the trusting system).

For more detailed information and practical tips for trusted/trusting relationships, see:
Trusted/Trusting Relationships Between SAP Systems

Trusted/Trusting Relationships Between SAP Systems
Using an RFC trusted/trusting relationship between two SAP systems has the effect that, in the case of an RFC
from a trusted system to a trusting system, passwords are no longer sent for logging on to the trusting system.
However, the user being used for the logon must have the corresponding authorization object S_RFCACL in the
trusting system. The trusted system always corresponds to the RFC client role, and the trusting system to the RFC
server role.
Solution
Building a trusted/trusting relationship:
A trusted/trusting relationship must always be built starting from the trusting system (server). The following
describes the individual steps for defining a trusted/trusting relationship of the trusted system C00 (client) to
trusting system S00 (server):
Log on to the trusting system S00 (server). Here, create a destination for the trusted system C00 (client) using
transaction SM59 (for example, C00_SYSTEM). It is important that the option 'Trusted System' is not set to active
for this destination (Security Option Trusted System = No).
We recommend that you do not specify any
logon data in this destination, as someone could use a remote login to misuse this
destination in SM59 by working as the user that is
defined here. This destination must only be used for creating and deleting the trusted/trusting relationship and not for any other purpose. It
must therefore be named correspondingly.
Call transaction SMT1 (or SM59 and then transaction menu RFC Trusted Systems).
Choose Create. Enter the destination of the client system (in the example, C00_SYSTEM) in the dialog box. After
confirming this, an RFC logon to the client system occurs, and the necessary information is exchanged between
the systems (S00 <-> C00).
If no logon data has been entered in the destination
(in the example, C00_SYSTEM), an RFC logon screen is displayed for the
client system (C00). In this particular case, a manual logon must be
performed. In each case, a successful logon to the client system
must be performed in this step, so that the trusted
relationship can be built.
When a trusted relationship has been successfully built, the trusted entry for the client system (C00) is displayed. If
you want to restrict the validity of the logon data for the client system, enter a timeframe in the corresponding field.
The default value (00:00:00) means that the validity is unrestricted.
In the scenario where the same user and client are used, you can use the menu option Entry to perform
authorization checks: These checks first attempt to reach the client using the logon data specified in the definition
destination (in the example, C00_SYSTEM), and then try to log back on to the server system with the same logon
data, using a trusted RFC. Choosing the menu option Current Server forces the return path to occur on the current
application server, and choosing menu option Trusting System induces load balancing, meaning that the logon
takes place on any application server in the server system.
If different users or clients are used for the trusted scenario, you must create an RFC destination on the client side,
and perform an authorization check for the specified logon data, setting the flag for "Trusted System" to
"Yes".

Using a Trusted/Trusting Relationship
You can now use the configured trusted/trusting relationship to create RFC destinations in the trusted system
(client), which are for the trusting system (server), by using transaction SM59 and the Trusted System flag. The
result of this is that, when such destinations are used for the RFC logon to the trusting system, no password is
sent.

A prerequisite for successfully using a trusted/trusting relationship is that the user being used has the
corresponding authorization object S_RFCACL in the trusting server system. If you want to create a suitable
authorization for different
clients and users, note that you have to enter the caller data (caller client and caller user) of the caller system (in
our example from system C00) into the S_RFCACL fields RFC_CLIENT and RFC_USER. For example, if user
U_1 under client M_1 in caller system C00 wants to work as user U_2 with client M_2 in the called system S00
under a trusted relationship, then the user (U_2, M_2) in the system S00 must have authorization ZRFCACL_XXX,
which has the following settings:
RFC_SYSID : C00
RFC_CLIENT: M_1
RFC_USER : U_1
RFC_EQUSER: N (for NO)
RFC_TCODE : *
RFC_INFO : *
ACTVT : 16

The following steps describe how you can enter the above settings for server system S00:

SU03 + double-click the entry "AAAB" "Cross-Application Authorization Objects" and then choose
"Authorization check for RFC user (ex. trusted system)" as the object class, then double-click the
authorization object S_RFCACL and create Z_RFCACL_XXX.
After this, make sure you activate your settings.

If the same user is always used in the client system and server system for a trusted/trusting relationship (meaning
that U_1 = U_2), the authorization Z_RFCACL_XXX can also be defined as follows:
RFC_SYSID : C00
RFC_CLIENT: M_1
RFC_USER : ' '
RFC_EQUSER: Y (for Yes)
RFC_TCODE : *
RFC_INFO : *
ACTVT : 16
Setting the authorization field RFC_EQUSER to 'Y' is the same as setting the field RFC_USER = SY-UNAME for
the logged user in the caller system (here, system C00).
Note that when maintaining and assigning S_RFCACL authorizations (in this case, Z_RFCACL_XXX), you must use
as few generic values (for example '*') for RFC_SYSID, RFC_CLIENT and RFC_USER as possible. By doing this, those
users who fulfill these criteria regarding RFC_CLIENT and RFC_USER, can call RFC modules from within the caller
system, using the called user.

You must ensure that high security requirements in the caller system is linked with the usage of user maintenance
transactions (such as SU01). If this is not the case, anyone who has this authorization can get a user and log on to
the trusting system (S00).
After you have maintained the authorization Z_RFCACL_XXX, you must create an authorization profile as follows,
and link it to the authorization Z_RFCACL_XXX:

Call SU02 and in the field "Manually edit authorization profiles", enter Z_<C00> as the authorization
profile. Choose "Create work area for profiles" and then create a new profile. Enter S_RFCACL as the
object, and Z_RFCACL_XXX as the authorization.
After this, make sure you activate the profile.

You now have to assign the authorization profile you have just created to the trusted/trusting user. To do this,
enter the profile Z_<C00> on the tab page Profile in transaction SU01.

You can check the authorizations for the logged on users in the current system in advance, by using the function module
AUTHORITY_CHECK_TRUSTED_SYSTEM.
As of Release 40B, for security reasons, the authorization profile SAP_ALL does not contain an authorization for
S_RFCACL.
Authorization errors that occur while using an RFC destination which has the 'Trusted Systems' flag set to Yes
are documented with the following messages:

No authorization to log on as a trusted system (trusted RC = <0 1 2
3>).
Here, the trusted return codes ( = 0, 1, 2 or 3 ) have the following meanings:

0 Invalid logon data (user ID and client) for the trusting
system.
Solution: In the server system (trusting system), create the user
in the corresponding client.
1 Calling system is not a trusted system, or security
ID for the system is invalid.
Solution: Create (again) the trusted system (see above).
2 User has no authorization for the server system
(trusting system, for object S_RFCACL), or a logon was made
using one of the protected users DDIC or
SAP*.
3 Time stamp of the logon data is invalid.
Solution: Check the system time on the client host and server
host, as well as the validity date of the logon data.
(Note that the default date 00:00:00 means unrestricted
validity.)

Solution:
Provide the user with the corresponding authorization or avoid using the protected users DDIC and SAP*.
Authorization errors that occur while using an RFC destination which has the Trusted Systems flag set to Yes
are documented with the following messages:
No authorization to log on as trusted system
(Trusted RC = <0 1 2 3>).

Here, the trusted return codes ( = 0, 1, 2 or 3 ) have the following meanings:
0 Invalid logon data (user ID and client) for the trusting
system.
Solution: In the server system (trusting system), create the user
in the corresponding client.
1 Calling system is not a trusted system, or security
ID for the system is invalid.
Solution: Create (again) the trusted system (see above).
2 User has no authorization for the server system
(trusting system, for object S_RFCACL), or a logon was made
using one of the protected users DDIC or
SAP*.
Solution: Provide the user with the corresponding
authorization or avoid using the protected
users DDIC and SAP*.
3 Time stamp of the logon data is invalid.
Solution: Check the system time on the client host and server
host, as well as the validity date of the logon data.
(Note that the default date 00:00:00 means unrestricted
validity.)

Trusting Transaction SMT2
The trusting transaction SMT2 (or SM59 RFC Trusting Systems) constructs a list of all trusting systems that
have been established for this trusted system. Here, a logon and authorization check for the current user and
client is performed, using the destination TRUSTING_SYSTEM@S00 that has been automatically created.
This basically corresponds to transaction SM51, if you use Remote Login to perform a logon on a different
application server.

If problems occur while setting the destination TRUSTING_SYSTEM@S00 (such as host name or service
information), you either have to create a new destination for your needs, and then enter the host name or service
information using SAP router strings, or adjust the network settings of the server. To correct the problem in
transaction SMT2, you have to adjust the network configuration of the server. As this transaction is only to be used
for test purposes, in this case you could also choose to ignore the error.
To perform a logon as a different user or client, you have to create a new RFC destination with a trusted option
set.
In this scenario, the following error text in SMT2 can be ignored:
No authorization to log on as a trusted system (Trusted RC=0)

If the host name contains the character '_' (as in "my_host"), then the generation of the related trusting system
destination may lead to incorrect settings. This problem can be corrected by implementing Support Package
SAPKB46D09 (see below). For earlier releases, the changes required to correct the problem can be made
manually.

Continue with:
Configuring System Resources for Parallel RFC, tRFC, and qRFC

Configuration of System Resources for aRFC, tRFC, qRFC
Use
An application can make calculations and collect data simultaneously by using the various types of asynchronous
RFCs. This can also happen indirectly, as with the outbound or inbound queue in qRFC. Every RFC request
occupies a dialog work process on the application server on which the RFC is executed.
The possible configurations of an SAP system are described below.
Integration

Note that RFC calls with CALL FUNCTION are processed in DIALOG work processes. The DIALOG limitation for processing a dialog
step (default: 300 seconds, system profile parameter rdisp/max_wprun_time) thus also applies to these RFC calls. Remember to consider
this restriction when dividing up your data packets for parallel processing.
The configuration options described here are valid for the following RFC types.
Asynchronous RFC with Load Distribution (aRFC)
You can use this RFC type to program parallel RFC calls. The resources are checked and assigned as far as the
set quotas allow.
The required ABAP language element is:
CALL FUNCTION remote function STARTING NEW TASK task name DESTINATION IN GROUP group name
With this ABAP command, you are instructing the SAP system to process function module calls in parallel. The
instruction implements parallel processing by sending asynchronous RFC calls to the appropriate servers. These
are servers in the RFC server group Group Name specified as being available for processing requests. The group
name DEFAULT means that all available application servers are being used.
qRFC with Outbound Queue
The qRFC LUWs are executed using the outbound scheduler. The outbound scheduler uses parallel RFC to
process the outbound queue. To allow this, you need to maintain the destinations in transaction SMQS.
The outbound scheduler then checks the resources and executes parallel RFCs if resources are available. If no
resources are available, synchronous RFC is used instead.
qRFC with Inbound Queue
If you are using the inbound queue, the inbound scheduler takes is responsible for processing the inbound queue.
To allow this, you need to register the queue names to be processed using the inbound scheduler in transaction
SMQR.
The inbound scheduler then checks the resources and executes parallel RFCs if resources are available. If no
resources are available, the scheduler waits until resources become available.
For more information, see Monitor Transactional RFC and Queued RFC.
tRFC and qRFC
The transactional RFC and the qRFC use the resource check. The associated ABAP language elements for both
RFC types is:
CALL FUNCTION Remote function IN BACKGROUND TASK DESTINATION destination
With a preceding additional function call (TRFC_SET_QIN_PROPERTIES or TRFC_SET_QUEUE_NAME) tRFC
can be defined as qRFC.
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:
The data is updated. If tRFC/qRFC has been triggered within the update, these are executed in parallel after the V1 update (within the
update). If the tRFC/qRFC call is registered in the scheduler, the scheduler is simply triggered within the update. The execution of
tRFC/qRFC takes place outside the update through the scheduler.
The data is not updated. The tRFC/qRFC function modules started within the application LUW are executed in parallel as far as
possible. If local system resources are exhausted, the tRFC/qRFC is serialized so as not to further increase resource utilization. However,
this is not the case if the tRFC/qRFC function modules are processed in batch. If the tRFC/qRFC have been started in batch, they are always
processed in parallel as in the update process, regardless of the system resource utilization.

No resource checks are run with RFC calls from the update process or batch, since these must always be processed in parallel to avoid
deadlocks.
Additional Information
Details about using and programming RFCs can be found in the RFC documentation:
Defining RFC Groups for Parallel Processing Jobs

SAP note 597583 (Performance Improvement Using RFC Parallelization) describes which RFC types and ABAP language elements are
recommended for various purposes.
Features
This documentation is divided into the following sections:
RFC Resources in the Application Server
Describes which resources are relevant for the use of parallel RFCs, and how you can monitor the available resources system-wide.
System Configuration for Parallel RFCs
Describes how RFC resources can be manipulated: Dynamically or using profile parameters.
Determining Resources for Asynchronous and Transactional RFC
Describes how resources are checked in the system and explains the difference between local and remote checks (on a different server).
Restrictions

Note that the techniques for monitoring and controlling resources described in this document only apply to the
RFC types mentioned above.
Even if you have correctly configured the quotas, your system may still become flooded with RFCs if these are not
of the types mentioned (such as synchronous RFCs, qRFC, asynchronous RFCs without the suffix DESTINATION
IN GROUP).
Known problems, their causes and solutions are described in the following section:
Problems with RFC Resource Assignment

RFC Resources on the Application Server
The graphic below shows the SAP application server resources relevant for parallel RFC.

Resources can be assigned from the following areas:
Logging On to the SAP System
A total of rdisp/tm_max_no users can be simultaneously logged on to the server (using the GUI or RFC). If
rdisp/rfc_max_login percent of the maximum number of users are logged on, no more RFC logons can be
accepted. An RFC user may occupy a maximum of rdisp/rfc_max_own_login percent of the login slots (see
isp/tm_max_no).
You can see a user overview in transaction SM04. For more information, see Display and Manage User
Sessions.
RFC Requests in the Dialog Queue
The dialog queue of the dispatcher contains rdisp/elem_per_queue entries. A maximum of rdisp/rfc_max_queue
percent of these may be filled by RFC requests.
You can see a server overview in transaction SM51. For more information, see Overview of SAP Application
Servers.
Entries in the Communication Table
The communication table contains an entry for every CPIC communication for all parties involved. The table can
contain a maximum of rdisp/max_comm_entries entries. rdisp/rfc_max_comm_entries
percent of these may be occupied by one user.
You can see a server overview in transaction SM51. For more information, see Overview of SAP Application
Servers.
Dialog Work Processes
When the server is started, it has rdisp/wp_no_diadialog work processes. This number can, however, be changed
while the server is running. One way to do this is to use operation mode switching. You can find out the current
number of processes in the Process Overview (transaction SM50; see also Display and Control Work
Processes). Of the dialog work processes, the dispatcher keeps rdisp/rfc_min_wait_dia_wp free for genuine
dialog requests (not RFC).
A user may occupy a maximum of rdisp/rfc_max_own_used_wp percent of dialog processes.

The same parameters are used to control the number of plug-in requests (HTTP or SMTP requests coming from
the ICM) that can be processed at the same time. See ICM Parameters.
Server-side dispatcher check
The dispatcher checks whether it has free resources for each RFC request it receives. If it has, it assigns the
request to a dialog work process, otherwise it puts the request in the dispatcher queue. You can control the detail
level of this check using parameter rdisp/rfc_check.
Overview of All RFC Resources in the SAP System
Transaction SARFC is used to monitor the resources on all servers in the SAP system. This is described in the
section Monitoring RFC Resources on the Application Server.

Monitoring RFC Resources on the Application Server
Use
You can monitor the RFC resources on all application servers and thus find out the load incurred by parallel RFCs
on a server.
You can also dynamically change the various quotas on all servers. For procedure for doing this is described in the
section Dynamically Configuring RFC Quotas.
Procedure
Execute the transaction SARFC.
You then see a list of all SAP servers with information for each server, stating whether resources for asynchronous
RFCs are available at the time you executed the transaction (text Resources ok) . If no resources are available, a
short text explaining the reason is displayed.

Note that this list only represents the situation at the exact moment that you executed the transaction. Choose Refresh to update the display.
This is a list of the possible results of the resource check with return values and
meanings.
0: resources are available on the server. The text Resources ok is displayed.
1: The resource check is deactivated (parameter rdisp/rfc_use_quotas is set to 0).
The other return values indicate that the server currently has no available resources for asynchronous RFCs.

The server may have no resources for one of the following reasons:
The server is not running.
The server has been wrongly configured.
An unexpected error has occurred.
In these cases, the text appears on a red background. You can find out the exact cause of the problem (for
example, where exactly the incorrect configuration is located) by briefly activating and deactivating the trace for the
server (see below). See the dispatcher trace file dev_disp of the server for the required information.
The individual return values are described below. Each value has a text (appears on a yellow
background).
2: The server has too few free dialog work processes.
3: The quota for the RFC communication channels is too small. Increase the parameter
rdisp/rfc_max_comm_entries or change the value dynamically.
4: the quota for the RFC communication channels (rdisp/rfc_max_comm_entries) has reached its
maximum.
5: The local queue for asynchronous RFC responses is full. This queue retains the responses to asynchronous
RFCs until they are sent back to the caller. You can increase the size of the queue by increasing the value of the
parameter rdisp/max_arq.
6: The quota for a dialog work process occupied by an RFC user is too small. Increase the size of the parameter
rdisp/rfc_max_own_used_wp or change the value dynamically.
7: the quota for a dialog work process occupied by an RFC user (rdisp/rfc_max_own_used_wp) is too
small.
8: The quota for the RFC requests in the dialog queue is too small. Increase the size of the parameter
rdisp/rfc_max_queue or change the value dynamically.
9: the quota for the RFC requests in the dialog queue (rdisp/rfc_max_queue) has reached its
maximum.
10: An error occurred when the request queue length was being determined.
11: The quota for RFC logons to the server is too small. Increase the size of the value of the parameter
rdisp/rfc_max_login.
12: the quota for RFC logons to the server (rdisp/rfc_max_login) has reached its maximum.
13: The quota for own RFC logons to the server is too small. Increase the size of the parameter
rdisp/rfc_max_own_login or change the value dynamically.
14: the quota for own RFC logons to the server (rdisp/rfc_max_own_login) has reached its
maximum.
15: The server has been deactivated and cannot process any requests.
16: The server is being stopped.
17: The server has been stopped.
18: The server is being started.
19: The server has just been started and is in the initialization phase.
20: The server is in an unknown state.
Activating the Trace
Choose Goto Activate Trace. The system then writes the detailed result of the check to the trace file of the
dispatcher on the server in question. To read the file, you have to log on to the server in question. To do this, open
transaction SM51, double-click on the server name, then choose Process Trace Dispatcher Display File).
It may make sense to do this if, for example, a server constantly has too few resources, and you want to find out
the exact cause.
Configuration of RFC Resources
Section System Configuration for Parallel RFCs describes how to configure your system.

Configuring the SAP System for Parallel RFCs
Use
You can optimize the configuration of your SAP system for the purposes of working with parallel RFCs. This
section describes the tools (profile parameters, transactions, and so on) you use to do this.
Prerequisites
To use parallel RFCs effeciently, your system has to be configured accordingly and must meet the following
prerequisites.
More dialog work processes than non-dialog work processes have to be configured on every server that is
available for processing parallel RFCs.
The profile parameter rdisp/wp_no_<wptyp>uses <wptyp> = dia, spo, upd, up2, btc to determine the number of
work processes of one type. This number is not, however, necessarily the most up-to-date number, as the work
process types can be changed while the server is in operation (by means of operation mode switching, for
example). You can find out the current number of work processes in the Process Overview (SM50; see also
Display and Control Work Processes).
Procedure
Set Profile Parameters
A range of profile parameters is available for resource distribution during the processing of parallel RFCs. These
parameters are described in the following sections:
rdisp/rfc_check
rdisp/rfc_use_quotas
rdisp/rfc_max_queue
rdisp/rfc_max_login
rdisp/rfc_max_own_login
rdisp/rfc_min_wait_dia_wp
rdisp/rfc_max_own_used_wp
rdisp/rfc_max_comm_entries
rdisp/rfc_max_wait_time
For more parameters to do with RFC, open transaction RZ11 and search for isp/rfc*.

Note that the parameters rdisp/rfc* only apply to the above-mentioned RFC types, and not to any other types, such as synchronous RFC or
asynchronous RFC without a group.
In other words, the parameters only apply to qRFC and parallel RFC.
The standard values for the quotas are restrictive, since you must assume that dialog users are also active in the
system and they are given priority. You can set the maximum resources for RFC users as follows.
rdisp/rfc_max_login = 100
rdisp/rfc_max_own_login = 100
rdisp/rfc_max_own_used_wp = 100
rdisp/rfc_max_comm_entries = 100
These can of course affect the response time for dialog users.
Dynamic Changes
As well as setting the parameters, you can also change the ARFC resources dynamically in the running system
immediately before running the application that uses a high volume of parallel RFCs.
To do this, use transaction SARFC, as described in the section Dynamically Configuring RFC Quotas.

Note the following points when configuring the system:
i. The number of available resources in the system is a snapshot relating to the current workload in the system. No program can assume
that these resources will also be available long term.
ii. If one of the quotas is exceeded, no resources are returned to the caller.
iii. The calculated resources are not reserved for the caller. Thus it could happen that competing programs are calculating resources at the
same time, and are occupying more dialog work processes than has been set in the quota. A program therefore cannot assume that the
resources calculated are actually also available.

Dynamically Configuring RFC Quotas
Use
The report RSARFCLD is used to dynamically configure the RFC quotas on the server to which you are logged on.
Unlike parameter changes in the profile, these settings are lost when you next restart the computer.
Procedure
Execute the transaction SARFC.
You are then shown which servers are currently available in the system, and how the system is handling resources
for asynchronous RFCs on the servers (see Monitoring RFC Resources on the Application Server).
If you double-click on a server name, a dialog box appears in which you can change the values for your server.
If you have the necessary authorization, you can enter change mode and change the values.
The values that you set here overwrite (until the next restart) the following parameter values (in the same order):
rdisp/rfc_max_queue
rdisp/rfc_max_login
Choose Save to activate the new values.
Result
The quotas for RFC resources have now been reset.

Note that the settings you make using the report only apply to the instance to which you are currently logged on, and are lost when the
instance is next restarted. The parameter settings in the profile file then apply again.

rdisp/rfc_check
Use
In this parameter you can set the level of detail of the check made by the RFC server dispatcher. The dispatcher
checks whether sufficient dialog work processes are free for processing asynchronous RFC calls.
Integration
The number of available dialog work processes depends on the number of free dialog work processes and on the
number of work processes that must be kept free for the dialog application. (Compare with
rdisp/rfc_min_wait_dia_wp).
If no work process is free, the request is placed in the queue and processed later.
Prerequisites
The RFC resource check is active (see rdisp/rfc_use_quotas).
Properties
Value Range and Syntax
The parameter can be set to a whole number between 0 and 3. The number specifies the level of the resource
check. The values mean the following:
Level 0: No check is run
Level 1: Monitors the start of all asynchronous RFCs
Level 2: Monitors, additionally to level 1, all RFCs started anew from asynchronous RFC sessions. This includes
synchronous RFCs.So that applications that transmit a lot of RFCs can run at this level, the number of dialog
processes used for RFCs may have to be increased. (rdisp/rfc_min_wait_dia_wp may have to be reduced).
Level 3: monitors all RFCs (synchronous and asynchronous).
SAPs Recommendation
You must not set the value to 0.
Increase the value if you notice that your application server becomes flooded with RFCs and dialog mode is no
longer possible, even though you have set rdisp/rfc_min_wait_dia_wp.
More Information
Note the following documentation associated with this parameter:
Monitoring RFC Resources on the Application Server
Configuring the SAP System for Parallel RFCs

Use
This parameter is used to activate the use of quotas for resource allocation.

If the parameter is set to 0, all other rdisp/rfc*parameter settings are irrelevant. In this situation, you cannot use parallel RFCs. The
system acts as if all resources were in use and always returns the same corresponding return value.
Integration
Resource allocation is either carried out dynamically (see Dynamically Configuring RFC Quotas), via RFC group
maintenance, or in the profile via the following parameters:
rdisp/rfc_max_queue
rdisp/rfc_max_login
Work area Dispatcher/task handler
Unit Integer value
Standard value 1
Dynamically changeable Local and on all servers
If you do not want your changes to be permanent, you have the option of dynamically configuring RFC quotas.
These changes are lost when the instance is restarted.
Properties
The following values are permitted:
0: resource allocation deactivated
1: resource allocation activated (default)
SAPs Recommendation
Since when you are working with parallel RFCs, the parameter value 0 is not possible (see above), SAP
recommends that you do not change the default setting 1.

rdisp/rfc_max_queue
Use
This parameter specifies the contingent for the maximum number of outstanding requests in the dialog queue.

RFC is executed on the target server in a dialog work process. Therefore, if there is currently no free dialog work process, the request is
placed in the dialog queue of the dispatcher. You should ensure that the queue never becomes full.
Prerequisites
Properties
The value is given as a percentage of the entire dialog queue. In other words, it is dependent on the value
currently set in the profile. The parameter rdisp/elem_per_queue (default 2000) specifies the absolute number of
requests in the queue.
SAPs Recommendation
Unit Integer value
Standard value 1
Unit Integer value between 0 and 100 (percentage)
Standard value 5
You should set this value quite small, as the dialog requests are also kept in this queue, and it is important that the
queue does not become full.

You can monitor how full the dispatcher queues are in transaction SM51 ( Overview of SAP Application Servers) (Goto Server
Information Queue Info).
Example
If you retain the default setting of 2000, the dialog queue can accept a maximum of 2000 requests. If you set
rdisp/rfc_max_queue to 1 and the queue already contains 20 entries when a new RFC request comes in, the
request is rejected.

rdisp/rfc_max_login
Use
This parameter describes the contingent for the number of RFC users logged on to the SAP system. The
parameter rdisp/tm_max_no specifies the absolute number of logons to the SAP system.
Prerequisites
Properties
This parameter therefore describes the percentage of possible logons which, once exceeded, causes any further
RFC logons to the server to be rejected.
SAPs Recommendation
Open the User List (transaction SM04, see Display and Manage User Sessions) to see how many users are
currently logged on to a server in the SAP system. The User List also displays whether each logon is a GUI or an
RFC logon.
Example
Let us assume that rdisp/tm_max_no is set to 100, and disp/rfc_max_login to 90. Once there are 90 logons on the
system (whether they are GUI or RFC logons is not important), no more logons of the type RFC can be
accepted.10 more logons of the type GUI can, however, still be accepted. Once the eleventh GUI logon attempt is
made, the server returns the message Maximum number of terminals reached.

rdisp/tm_max_no
Use
Unit Integer value between 0 and 100 (percentage)
Standard value 90
This parameter restricts the maximum number of users per instance.
You can thus restrict how many users can log onto an instance simultaneously. All types of logons are counted
(with GUI, RFC, or HTTP).
You can see which users are logged on in the User Overview (transaction SM04).
Properties
You can specify a number between 0 and 10000.
SAPs Recommendation
If you should notice that the standard value 200 is too few, increase the value. At any rate you have to restart the
instance, since the parameter affects the size of the tm_adm structure of the dispatcher, and the shared memory is
created when the instance is started.

Use
With this parameter you can set the cut-off value for the number of own logons in the SAP system. It is different
from the parameter rdisp/rfc_max_login in that in this case, it is the logons of one user only that may not exceed
the quota.
This value is, therefore, a percentage of rdisp/tm_max_no. It restricts the logons of an (RFC) user and thus
prevents a program from sending RFCs to such a degree that other (RFC) users cannot log on to that server.

This parameter is valid only if the check is run locally. If the check is carried out on a remote server, the parameter is ignored and the next
more restrictive quota takes effect. You can find details of the different checks in Resource Determination for Asynchronous and
transactional RFC
Unit: percentage
Possible values: whole numbers between 1 and 100.
Default value: 25
Prerequisites
Properties
Unit Integer value
Standard value 200
Dynamically changeable No
Unit Integer value (percent)
Standard value 25
Possible values are whole numbers between 1 and 100 (percent).
Example
If you want to allow that one application is assigned the entire RFC resources of a server, you have to increase the
parameter. You could increase it to the value of rdisp/rfc_max_login, for example.
More Information

Use
This parameter is used to reserve a number of dialog work processes for dialog mode. It specifies the number of
dialog work processes that should be kept free for dialog mode, thereby preventing that all processes are occupied
by parallel RFCs.
Integration
The parameter rdisp/wp_no_diaspecifies the absolute number of dialog work processes.
The dispatcher controls the forwarding of RFC requests. The RFC request is only passed to a dialog work process
if the defined number of free dialog work processes is guaranteed. If it is not, the request is kept in the dispatcher
queue for processing later.
Prerequisites
Properties
You can set the parameter to values between 1 and the number of dialog work processes (rdisp/wp_no_dia).
SAPs Recommendation
If a sufficient number of dialog work processes has been configured, this value should be increased

It must be guaranteed that the value of parameter rdisp/rfc_min_wait_dia_wp is always smaller than rdisp/wp_no_dia, otherwise no RFC
requests can be processed.
Example
If 10 dialog work processes are configured for the instance (rdisp/wp_no_dia = 10) and the parameter
rdisp/rfc_min_wait_dia_wp = 3 is set, parallel RFCs can occupy a maximum of 7 dialog work
Unit Integer value
Standard value 1
processes. Three dialog work processes always remain free for dialog mode.
More Information

Use
This parameter determines the contingent of dialog work processes that an RFC user may occupy simultaneously.
The value is specified as a percentage of the configured dialog work processes.
You can use this parameter to prevent a user (or an application that is sending RFCs) from occupying all the
dialog work processes on the target server.

This parameter is effective only in dialog mode.If the report is running in the background or in update mode, it is ignored.
This parameter is valid only if the check is carried out on your local server (compare Determining Resources for Asynchronous and
Transactional RFCs). If the check is carried out on a remote server, the parameter is ignored and the next more restrictive quota takes effect.
The user name is not checked. This means, if one user logs on several times with the same name (name appears several times in SM04),
each of these entries is valid as an individual user (compare Displaying and Managing User Modesurl_link_0006_0002_0007).
Integration
When the server is started, it has rdisp/wp_no_dia dialog work processes. This number can, however, be changed
while the server is running. One way to do this is to use operation mode switching. You can find out the current
number of processes in the Process Overview (transaction SM50; see also Display and Control Work
Processes).
Prerequisites
Properties
Permitted values are whole numbers between 0 and 100.
Example
Let us assume that the parameter is set to the default value of 75, and you have 10 dialog work processes, of
which 2 are reserved for dialog operation (rdisp/rfc_min_wait_dia_wp). The parameter then has the effect that an
RFC application can occupy a maximum of 7 work processes at any one time. This number represents the
minimum number of work processes calculated from the work processes that are available for RFC (10-2=8) and
Standard value 75
Dynamically
changeable
Local and on all servers
the percentage defined by the parameter (75% of 10 is 7.5, of which the whole number is 7).
If you want an RFC application to have all the resources on the target server, set this parameter to 100. Then,
rdisp/rfc_min_wait_dia_wp is the last restricting factor.

More Information

Use
The value specifies the percentage of communication entries that may be occupied by the user.
This guarantees that the communication table can still administrate other CPIC conversations.
If this value is exceeded, no more RFC requests can be accepted, so that the server does not become overloaded.
Integration
The parameter rdisp/max_comm_entries specifies the absolute number of communication entries.
Prerequisites
Properties
More Information

rdisp/max_comm_entries
Use
This parameter specifies the maximum number of communication entries on an application server.
This parameter allows you to control the number of RFC/CPIC connections on an application server.
Every RFC or CPIC communication with a partner program requires an entry. If the initiator and recipient of an
RFC/CPIC program are running on the same application server, two entries per communication are required.
Standard value 90

Every communication entry requires 100 bytes of shared memory.
Integration
If a lot of RFC balancing accumulates on one application server and the value of parameter
rdisp/max_comm_entries has been increased to accommodate this, we recommend you set rdisp/max_arq to the
same value.
Properties
More Information

rdisp/max_arq
Use
This parameter determines the maximum number of asynchronous requests that can be kept in the local work
process queue.

The value should only be changed after consultation with SAP.
Integration
If a lot of RFC balancing accumulates on one application server and the value of parameter
rdisp/max_comm_entries has been increased to accommodate this, we recommend you set rdisp/max_arq to the
same value.
Background
A SAP work process can contain diverse messages:
Requests from a SAP-GUI
Requests from an ABAP program (RFC requests)
Requests from other WPs/application servers (messages)
Results of outstanding calls (enqueues, RFCs)
Unit Integer value
Standard value 500
Dynamically changeable No
The procedure is always that a message leads to the work process being activated. The work process performs an
action, possibly sends a result back and then waits for a new message.
There are also cases where while one message is being processed, other messages are sent and depending on
the circumstances, it may take a while before they can be dealt with. Examples of this are enqueue and
establishing RFC connections. Particularly with asynchronous RFC, the RFC replies can be sent at any time you
want.
As the work process cannot, however, process every type of message in every situation, each WP context has a
local queue. Here messages that cannot be immediately processed are stored temporarily. The parameter
rdisp/max_arq defines the size of this local queue.
Properties

Use
This parameter determines the maximum period of time in seconds that the system waits after a load check. The
wait time is calculated based on the amount of available resources. The fewer resources that are available, the
longer the wait time.
You can increase the wait time if you suspect that a resource bottleneck is about to occur, and if you cannot
resolve the bottleneck and are prepared to accept a longer wait time.
Prerequisites
Properties
Possible values are whole numbers between 1 and 120 (seconds).
More Information

Calculating Resources for Asynchronous and Transactional RFC
There are two stages in calculating the resources for an application server. First, the system checks whether there
are enough local resources for the check (communication channels and space for ARFC responses). Second, if
there are enough resources, the detailed check is then carried out. If you want to carry out a check on the
Work area Dispatcher
Unit Integer value
Standard value 500
Unit Integer value (seconds)
Standard value 15
application server, this is done in the work process. If you want to carry out a check on another application server,
the dispatcher of this server takes on the check.
The check algorithms are executed in the SAP kernel and are described in detail in the following chapters:
Local Check
Detailed Check
On the client you can also carry out a resource check on the RFC server. To do this use the ARFC options in
transaction SM59. These are described in section: Triggering Resource Checks on RFC Client.

You can control how detailed the check is on the server using the parameter rdisp/rfc_check.
Checking the Resources on the Local Application Server
To carry out a local check, call the function module TH_ARFC_LOCAL_RESOURCES.
This function module has the following parameters:
CHECK_CLIENT_ONLY: if this parameter is set to 1, the check only checks whether there are enough communication channels and
space for aRFC responses. This procedure of this check is described in the section Local Check.
If CHECK_CLIENT_ONLY is not set, the detailed check is carried out next in the work process.
TRACE: if the trace parameter is set, the calculated resources are written to the trace file of the dispatcher, dev_disp.
The function module returns the following export parameters:
NORES: number of resources for asynchronous RFC
WAIT: default value for wait time (in seconds)
REASON: reason why no resources are available
MAXRES: maximum number of available resources
IREASON: reason why no resources are available (internal)
Checking the Resources of Another Application Server
The function module TH_ARFC_REQUESTS is used to check the resources of another server. This function
module has the following import parameters:
SERVER: on which server should the resources be calculated?
TRACE: see above
The function module has the following export parameters:
NOREQ: number of possible asynchronous requests
MAXREQ: maximum number of possible asynchronous requests
REASON: reason why no resources are available
CREASON: reason why no resources are available
When the resources of another application server are checked, first the local check, then the detailed check are
carried out by the dispatcher of the remote application server.
Reducing Resources
Each resource may be reduced, if the current usage is very close to the quota.
new_resource = min((quota-count),resource)
Default Wait Time
If no more resources are available, the system offers the caller a wait time. The maximum wait time (max_wait) is
set using the profile parameter rdisp/rfc_max_wait_time. The default is 15 seconds.
The wait time is calculated as follows:
quota = resource * parameter value / 100
count = current usage of resource
As no resources are provided, count > quota
wait = min (max(1,count-quota), max_wait).

Local Check
The local check checks whether any resources are available locally. It makes sense to carry out a detailed check
only if local resources are available. If no local resources are available, the detailed check is not carried out. The
local check is always carried out in the work process.
(Only the whole number counts, numbers after the decimal point are ignored.)
The check proceeds as follows.
Initially, the maximum resources are set to 10,000: resources = 10000.
The communication channels are checked. Specifically, the system checks that there are still enough entries in the communication table
(display using transaction SM51 Go to Server Information Communication Table).
The following calculation is performed:
quota = (rdisp/max_comm_entries*rdisp/rfc_max_comm_entries) / 100 (only the whole number counts, numbers after the decimal point are
ignored).
If the quota is 0, the reason TH_ARFC_RES_LOCAL_LOW_MAX_COMM_ENTRIES and the return value = 2
(NEVER_GET_RESOURCES) are set.
The system determines the number of communication channels in use, sets the quota to this value, and checks whether the maximum
quota has been exceeded.
If the quota has been exceeded (count>quota), no resources are returned, and the reason
TH_ARFC_RES_LOCAL_MAX_COMM_ENTRIES and the return value 0 are returned.
Otherwise, the resources are calculated afresh (and may be reduced) (new_resources=min(quota count, resources)), and the reason
TH_ARFC_RES_OK and the return value 0 are returned.
Number of asynchronous messages.
The work process can temporarily store only a limited number of asynchronous messages. The profile parameter rdisp/max_arq (default
value=200) determines the exact number. This value cannot be dynamically changed.
quota = max(rdisp/max_arq act_size 20, 0 ). Besides the currently occupied queue entries, a buffer of 20 is subtracted.
count = asyn_rfcs (number of asynchronous RFCs).
If the quota has been exceeded (count>quota), no resources are returned, and the reason TH_ARFC_RES_LOCAL_ARFCQUEUE and
the return value 0 are returned.
Otherwise, the resources are calculated afresh, and the reason TH_ARFC_RES_OK and the return value 0 are set.

Detailed Check
This check can take place either in the dispatcher or in the work process. If the local application server is being
checked, the check takes place in the work process; if another server is being checked, it takes place in the
dispatcher of the server. This means that a free dialog work process is not needed to process the request. The
callers time is thus not wasted, as it does not have to wait for a free work process.
The procedure is as follows:
The maximum number of available resources is calculated thus: number of dialog work processes (dia_wps) number of dialog work
processes that have to stay free for the dialog user (wait_dia_wps). The profile parameter rdisp/rfc_min_wait_dia_wp performs this
calculation.
If the number of dialog work processes is smaller than the number of work processes that have to stay free, the number is then set to
wait_dia_wp = dia_wps 1.
The system also checks whether resource identification is active.
If resource identification is not active which is not allowed the return value is set to 2 and the reason is set to
TH_ARFC_RES_NOT_ACTIVATED.
The system checks whether there are free work processes available to accept requests.
...
The number of free work processes is calculated (waiting_wps).
If waiting_wps <= wait_dia_wps, no resources are returned and the reason TH_ARFC_RES_WAITING_DIAWP and the return value 0
are set.
The resources are calculated again.
First of all the number of work processes occupied with active RFCs is calculated. (function DpGetExtCheckedResourcesCnt). This number
is deducted from the maximum number of processes available:
dia_wps-wait_dia_wpsDpGetExtCheckedResourcesCnt()
. Take this value and compare it to the number of currently free dialog work processes. Whichever is the lower of the two values equals the
number of resources available.
resources=min(waiting_wps,(dia_wpswait_dia_wps-DpGetExtCheckedResourcesCnt()))
The communication channels are checked. Specifically, the system checks that there are still enough entries in the communication table
(display using transaction SM51 Go to Server information Communication table).
...
quota = (rdisp/max_comm_entries * rdisp/rfc_max_comm_entries) / 100 (only the whole number counts, numbers after the decimal point
are ignored).
If the total is 0, the reason TH_ARFC_RES_LOW_MAX_COMM_ENTRIES and the return value 2 (NEVER_GET_RESOURCES) are
set.
The system determines the number of communication channels in use, and checks whether the maximum quota has been exceeded.
If the quota has been exceeded (count>quota), no resources are returned, the reason TH_ARFC_RES_MAX_COMM_ENTRIES is set,
and the return value 0 is set.
Otherwise, the resources are calculated afresh (and may be reduced) (new_resources = min(quota count, resources )), and the reason
TH_ARFC_RES_OK and the return value 0 are set.
Work processes check: is the user already occupying too many work processes? (Display in SM50)
...
quota = (dia_wps * rdisp/rfc_max_own_used_wp) / 100 (only the whole number counts, numbers after the decimal point are ignored).
If the quota is 0, the reason TH_ARFC_RES_LOW_OWN_USED_WP and the return value = 2 (NEVER_GET_RESOURCES) are set.
The system determines the number of communication channels in use, and checks whether the maximum quota has been exceeded.
If the quota has been exceeded (count>quota), no resources are returned, and the reason TH_ARFC_RES_OWN_USED_WP and the
return value 0 are returned.
Dispatcher queue check (dispatcher dialog queue): because every RFC has an associated entry in the dialog queue, the system checks
whether there is enough space in the dialog queue for new requests. (Display in SM51 Goto Server Information Queue
Information, profile parameter rdisp/elem_per_queue, default=2000). The latest queue information is then read.
...
If an error occurs, the reason TH_ARFC_RES_REQQUEUE_ERROR and the return value 2 are set. Otherwise
que_max = maximum number of entries in the queue
count = current number of entries in the queue
quota = (que_max * rdisp/rfc_max_queue) / 100 (only the whole number counts, numbers after the decimal point are ignored).
If the quota is 0, the reason TH_ARFC_RES_LOW_REQQUEUE and the return value = 2 (NEVER_GET_RESOURCES) are set.
If the quota has been exceeded (count>quota), no resources are returned, and the reason TH_ARFC_RES_REQQUEUE and the return
value 0 are returned.
Logon
As every RFC is linked to a logon in the target system, the system checks whether any further logons can be carried out (display in SM04,
profile parameter rdisp/tm_max_no, default=200).
...
quota = (rdisp/tm_max_no * rdisp/rfc_max_login) / 100 (only the whole number counts, numbers after the decimal point are ignored).
If the quota is 0, the reason TH_ARFC_RES_LOW_LOGIN and the return value = 2 (NEVER_GET_RESOURCES) are set.
count = number of logons
If the quota has been exceeded (count>quota), no resources are returned, and the reason TH_ARFC_RES_LOGIN and the return value 0
are returned.
Own logons
As every RFC is linked to a logon in the target system, the system checks whether any further logons can be carried out. The amount of
own logons is restricted (display in SM04, profile parameter rdisp/tm_max_no, default=200), so that any one user cannot log on to the
system too many times.
...
quota = (rdisp/tm_max_no * rdisp/rfc_max_own_login) / 100 (only the whole number counts, numbers after the decimal point are
ignored).
If the quota is 0, the reason TH_ARFC_RES_LOW_OWN_LOGIN and the return value = 2 (NEVER_GET_RESOURCES) are set.
count = number of logons
If the quota has been exceeded (count>quota), no resources are returned, and the reason TH_ARFC_RES_OWN_LOGIN and the return
value 0 are returned. Otherwise, the resources are calculated afresh (and may be reduced).
Server status
So that the server can process an RFC request, it must be ready for use. The normal status of the server is RUNNING. If the server has a
different status, no resources are returned and the reason is set accordingly.
...
TH_ARFC_RES_SERVER_HIBERNATE: the server is deactivated (in SM51 or SMMS; this ensures that the server does not get any
more requests such as updates from other servers).
TH_ARFC_RES_SERVER_SHUTDOWN: the server is being shut down.
TH_ARFC_RES_SERVER_STOP: the server was stopped after being shut down.
TH_ARFC_RES_SERVER_STARTING: the server is in the starting-up phase and is not yet operational.
TH_ARFC_RES_SERVER_INIT: the server is being initialized (before starting-up phase).
TH_ARFC_RES_SERVER_UNKNOWN: the server is in an unknown phase (should not happen).

See also:
Trigger Resource Check for RFC Client

Triggering the RFC Client Resource Check
Use
In transaction SM59 you can trigger from the server the resource check for an RFC destination. This delays the
transmission of RFC calls.
Before the function module is executed the system checks whether the destination system has sufficient
resources. If it hasnt, the execution of the function module is delayed for a specified time.
The algorithm is the same as in the Detailed Check.
Procedure
In transaction SM59 select the required RFC destination and double-click on it. Then choose Destination ARFC Options.
Choose Load Check Active.
You can select either a static or a dynamic check.
Static check after n calls: default is n=10. You can change this value.
After n asynchronous calls, the current system load of the remote system is evaluated.
Dynamic check: First of all the number of available resources for this destination is determined. If these resources are occupied by
asynchronous calls, the next load check is carried out.
Result
This check on the client system ensures that requests do not accumulate in the dispatcher queue on the RFC
server.

See also:

You have defined your parameters so that resource bottle necks will not arise. Your applications make RFC calls
of the permitted types only. Yet you have realized that more work processes than allowed are occupied with RFC
calls.
This can happen in the following circumstances:
An asynchronous RFC transmits a synchronous RFC
The asynchronous RFC transmits one or more synchronous RFC calls in the destination system. For these the profile parameters are only
valid if rdisp/rfc_check is set to 3 in the target system.
SAPLARFC occupies all work processes
In the Work Process Overview of an instance (transaction SM50), you can see that many dialog work processes
are occupied with the program SAPLARFC. You might also see update or batch processes with the status stopped
RFC.
This is because in transaction SMQS as many tRFCs were started at the same time as the parameter settings
allow and this has resulted in the user contexts losing their rollability. This situation arises for instance when mass
data is processed. See SAP note 726148 for more information and possible solutions.

See also:
Limit Values for Resource Allocation for Asynchronous RFC

Limit Values for Resource Allocation for Asynchronous RFC

If one of the following criteria is not fulfilled, no resources are made available for the parallelization with
asynchronous RFC (or triggered by the system in the exceptional case RESOURCE_FAILURE):
Number of free dialog work processes: 1
The default value is 1 and can be defined using the profile parameter rdisp/rfc_min_wait_dia_wp. As standard, a certain number of dialog
work processes are kept free as reserve instances for other purposes, such as system logon or administration programs.
For this reason, a greater number of dialog processes must be free, than the number specified for the profile parameter
rdisp/rfc_min_wait_dia_wp.

Proportion of user-specific dialog work processes: 75%
You can change this default value using the profile parameter rdisp/rfc_max_own_used_wp. The number of dialog work processes is
defined using the profile parameter rdisp/wp_no_dia.

Proportion of requests waiting in the dialog queue: 5%
You can change this default value (5% of the total length of the dialog queue) using the profile parameter rdisp/rfc_max_queue.
The length of the dialog queues is defined using the profile parameter rdisp/elem_per_queue.

Proportion of logons in the system: 90%
If the proportion of logged on users already lies above this, then no resources are released.
You can change this default value using the profile parameter rdisp/rfc_max_login.
The maximum number of logons to a server is configured using the profile parameter rdisp/tm_max_no.

Proportion of separate logons in the system: 25%
You can change this default value (25% of all logons) using the profile parameter rdisp/rfc_max_own_login. For each RFC, a logon to the
target system takes place.

Proportion of used communication entries: 90%
Each server has a limited number of communication channels available. The default limit value is 90 per cent.
You can change this value using the profile parameter rdisp/rfc_max_comm_entries. The maximum number of communication channels is
configured using the profile parameter rdisp/max_comm_entries. Here, one entry for each connection is made for the client and server.

Checking Authorizations for RFC

Checking Authorizations for RFC
If the system profile parameter auth/rfc_authority_check is set (value 1), then the System automatically checks at
the CALL FUNCTION keyword whether the authorizations user has the required RFC authorization.
The RFC authorization object is S_RFC Authorization check at RFC access. The authorization checks access to
function modules by function module group. That is, whether a user has the right to run function modules that
belong to a particular group.
You can test a users RFC authorization with the function module AUTHORITY_CHECK_RFC. This function
module returns RC = 0 if the user is authorized for the group that you name. The function module does not check
whether an authority check will actually take place.

RFC Programming in ABAP

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RFC Programming in ABAP

Uploaded by

Copyright:

Available Formats

RFC Programming in ABAP

You might also like