Writing RFC Programs in ABAP

PDF download from SAP Help Portal:

http://help.sap.com/saphelp_nw73/helpdata/en/2a/e4af97d5ae4733b484671b9871b0e5/content.htm
Created on August 04, 2015

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

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

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

Table of content

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

Page 1 of 24

Table of content
1 Writing RFC Programs in ABAP
1.1 Calling RFC Function Modules in ABAP
1.1.1 Introduction
1.1.2 RFC Calls
1.1.2.1 Parameter Handling in Remote Calls
1.1.2.2 Calling Remote Functions Locally
1.1.2.3 Calling Remote Functions Back
1.1.2.4 RFC Call Restrictions
1.1.3 Characteristics Using Unicode
1.1.4 RFC Exceptions
1.1.4.1 Class-Based RFC Exceptions
1.1.4.1.1 Class-Based RFC Exceptions
1.1.4.1.1.1 Semantic Considerations for Classic Exceptions
1.1.4.1.1.2 Class-Based Exceptions in Asynchronous RFC
1.1.4.2 Classic RFC Exceptions
1.1.4.2.1 Usnig Pre-Defined Exceptions for RFC
1.1.4.2.2 Exceptions That Cannot Be Handled
1.1.5 RFC Variants
1.1.5.1 Synchronous RFC (sRFC)
1.1.5.2 Asynchronous RFC (aRFC)
1.1.5.2.1 Call Properties of Asynchronous RFCs
1.1.5.2.2 Receiving Results from an Asynchronous RFC
1.1.5.2.3 Keeping the Remote Context
1.1.5.2.4 Parallel Processing with Asynchronous RFC
1.1.5.2.5 CALL FUNCTION - STARTING NEW TASK
1.1.5.2.6 RECEIVE
1.1.5.2.7 WAIT UNTIL
1.1.5.2.8 aRFC Programming Example
1.1.5.3 Transactional RFC (tRFC)
1.1.5.3.1 CALL FUNCTION - IN BACKGROUND TASK
1.1.5.4 Queued RFC (qRFC)
1.2 Writing Remote Function Modules in ABAP
1.2.1 Steps for Implementing Remote Function Modules
1.2.2 Programming Tips
1.2.3 Debugging Remote Function Modules

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

Page 2 of 24

1 Writing RFC Programs in ABAP

Procedure
The following sections provide information about RFC programming in the ABAP environment:
Calling RFC Function Modules in ABAP
Writing Remote Function Modules in ABAP

1.1 Calling RFC Function Modules in ABAP

Procedure
This section describes how to call an RFC function module. You can find the following topics here:
Introduction
RFC Calls
Characteristics Using Unicode
RFC Exceptions
RFC Variants

1.1.1 Introduction
Use
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
EXPORTING

F1 = a1
F2 = a2

IMPORTING

F3 = a3

CHANGING

F4 = a4

TABLES

t1 = ITAB

EXCEPTIONS

...

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 transaction SM59, or using the following menu path:
Tools
Administration, Administration
Network
RFC Destinations .
Programming guidelines are available in the following topics:
Parameter Handling in Remote Calls
Characteristics Using Unicode
Calling Remote Functions Locally
Calling Remote Functions Back
RFC Variants

1.1.2 RFC Calls

Use
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 to the CALL FUNCTION statement:

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

Page 3 of 24

The destination parameter displays an entry in the RFCDES table. This entry contains all necessary parameters to connect to and log in the destination system.

Note
Table RFCDES is configured using transaction SM59 ( Remote Destinations ).
Interface Functions
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.
Context Management
Every remote function module call made using the RFC interface defines its own 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.
A connection and its context is retained until it is explicitly closed, or until the calling program is finished. Function module RFC_CONNECTION_CLOSE can be
used to explicitly close a connection.

More Information
You can find detailed information about RFC calls here:
Parameter Handling in Remote Calls
Calling Remote Functions Locally
Calling Remote Functions Back
RFC Call Restrictions
RFC Variants

1.1.2.1 Parameter Handling in Remote Calls

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

Page 4 of 24

1.1.2.1 Parameter Handling in Remote Calls

Use
When you make a remote function call, the system handles parameter transfer differently than it does with local calls.

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

1.1.2.2 Calling Remote Functions Locally

Use
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.)
CALL FUNCTION Remotefunction
DESTINATION 'NONE'
EXPORTING

F1 = a1
F2 = a2

TABLES

t1 = ITAB

EXCEPTIONS

...

Local Call:
CALL FUNCTION... [no DESTINATION]
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.
CALL FUNCTION Remotefunction
EXPORTING

F1 = a1
F2 = a2

TABLES

t1 = ITAB

EXCEPTIONS

...

You can also call a function for parallel processing within the same system. For more details, see Parallel Processing with Aynchronous RFCs.

1.1.2.3 Calling Remote Functions Back

Use
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:

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

Page 5 of 24

CALL FUNCTION... DESTINATION 'BACK'

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

1.1.2.4 RFC Call Restrictions

Use
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 remotely called function module, you must not use statements that close the current context and thus 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.

1.1.3 Characteristics Using Unicode

Use
RFC from a Non-Unicode System into a Unicode System
The following errors may occur:
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

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. The character "~ " would
therefore have the value 007E, for example. You can find a list of the Unicode character numbers at http://www.unicode.org/ .
Default: Ignore errors and replace non-convertible characters with character '#'.
The system making the call receives the exception COMMUNICATION_FAILURE with the message connection closed.

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

Page 6 of 24

RFC from a Unicode System into a Non-Unicode System

The following errors may occur:
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.

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.

1.1.4 RFC Exceptions

Use
As of SAP NetWeaver Release 7.1 you can execute the exception handling for RFC calls on the basis of ABAP classes. Class-based exceptions make it
possible for the RFC Client to handle all exceptions using TRY/CATCH syntax.
The use of ABAP classes replaces the previous form of exception handling. This means you can use class-based exceptions not only for ABAP objects but also
for all ABAP program contexts.
There are some exception classes that exist for the RFC field with which RFC-specific exceptions can be handled.

Note
You can however still use classic exception handling.

Constraints
It is not possible to use both forms of exception handling (classic and class-based) at the same time in a function call.

More Information
You can find further information about RFC exception handling under:
Class-Based RFC Exceptions
Classic RFC Exceptions

1.1.4.1.1 Class-Based RFC Exceptions

Use
The class hierarchy of RFC-specific exception and error classes is constructed in the following way:
RFC Exception Class Hierarchy

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

Page 7 of 24

Class CX_REMOTE_UNSPECIFIED_EXC is the super class for all exception classes that are used to replace the original exception. This is necessary
when all original exception are unknown in the RFC Client or if the transport of the exception to the RFC Client failed.
Class CX_REMOTE_APPL_ERROR handles error situation that were caused during the call or when executing the function module at the server side. It
essentially corresponds to the classic RFC exception SYSTEM_FAILURE.

Note
Some special cases of SYSTEM_FAILURE are assigned to the class CX_CONNECTIVITY_ERROR.
Class CX_CONNECTIVITY_ERROR contains all exceptions that were returned during the connection creation, resource allocation, or in the communication
layer during the function call. it corresponds to the classic exception COMMUNICATION_FAILURE, RESOURCE_FAILURE and some special cases of
SYSTEM_FAILURE.
Attribute REMOTE_CONTEXT in class CX_ROOT transports additional information in the case of application errors to the target system (for example, the name of
the affected application server or the ABAP destination).
Application-specific class-based exceptions are transported directly, that is, directly to the RFC Client without any additional wrapper by a class. This makes it
easier for the RFC Client to access the exception and facilitates the context of the RFC call to persist when the exception was propagated outside the function call.

More Information
For more detailed information on using class-based exception in the field of RFC:
Class-Based RFC Exceptions

1.1.4.1.1 Class-Based RFC Exceptions

Use
Basically, the use of class-based exception in the field of RFC takes place in the same way as with local function calls. There are however some details to note
for remote function calls, as described in the sections below.
The most important difference is that class-based RFC exceptions are serialized for the transport from the server to the client program in basXML format (Binary
ABAP Serialization XML). Therefore both the client side and the RFC destination have to support basXML.

Prerequisites
Both the client and server are based on SAP NetWeaver 7.1 or higher.
Function call does not contain an EXCEPTION block.

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

Page 8 of 24

Note
The classic exception handling is used for function calls that contain an EXCEPTION block.

Note
If a class-based exception is triggered on the server during classic exception handling then this causes a runtime error and the classic exception
SYSTEM_FAILURE is returned at the client side.
The function module to be called is defined in the RFC Client. Restrictions
For releases < 7.11, all logon and authorization errors are mapped to exception class CX_REMOTE_APLL_ERROR. The error text is found in the
MESSAGE_TEXT field.
If not system message fields are set for communicating with releases < 7.11 (for example, sy-msgty, sy-msgid, sy-msgno, sy-mgsv1,,sy-msgv4),
method GET_TEXT does not return a valid value in some cases for exception class CX_REMOTE_APLL_ERROR. The error text is found in the
MESSAGE_TEXT field.

Procedure
For class-based exception handling in your function call use TRY/CATCH syntax instead of the EXCEPTIONS block.

More Information
It is also possible to handle classic exceptions with class-based exception handling. There are however a few semantic considerations in the RFC field with
regard to local function calls. For more information:
Semantic Considerations for Classic Exceptions
The following rules apply in certain cases when using asynchronous RFC calls. For further information, see:
Class-Based Exceptions in Asynchronous RFC
You can find a more detailed description of local class-based exception handling in the ABAP field under:
Class-Based Exceptions

1.1.4.1.1.1 Semantic Considerations for Classic Exceptions

Use
If you use class-based exception handling, you can also catch and handle classic exceptions with exception class CX_CLASSIC_EXCEPTION.
If you use statements RAISE and MESSAGE RAISING, then this always produces a classic exception.
In an RFC call the statement MESSAGE always behaves differently than in a local function call:
For all RFC types with a background processing exception (tRFC/qRFC, bgRFC), messages of the type X, A or E cause an exception of type
SYSTEM_FAILURE.
In background processing, messages of type X, A or E in the affected LUWs/units cause a corresponding error status. Messages of type W, S or I are
ignored. The corresponding LUWs/units are executed.
The ERROR_MESSAGE addition in EXCEPTIONS block stays in the RFC case without any other effect.
If you use class-based exception handling, ever exception that appears as the result of a MESSAGE statement causes an exception of class
CX_REMOTE_APPL_ERROR in the RFC client.

1.1.4.1.1.2 Class-Based Exceptions in Asynchronous RFC

Use
If you use an RFC call of type aRFC (asynchronous RFC) with a response (RECEIVE RESULTS FROM FUNCTION), the transfer of the exception object to the
RFC client is different from the remaining RFC types in the following ways:
The EXCEPTIONS block in the RECEIVE RESULTS FROM FUNCTION application is then always permitted when the corresponding CALL FUNCTION
application also contains an EXCEPTIONS block. Likewise, the EXCEPTIONS block can then only be left out when this happens in both statements. The
check is executed at runtime.

Note
Any alternative use of the EXCEPTIONS block can cause a runtime error. Since the assignment of both of the statements is not unique, syntax checks
are not supported.
If the function call is implemented without the EXCEPTIONS block, the callback routine is to be implemented as the method (referenced using the CALLING
addition).
The class-based exception can be caught using TRY...CATCH...ENDTRY if the statement RECEIVE RESULTS FROM FUNCTION is contained in this block
(or in methods/forms that are called in this block).
Class-based exceptions must be caught and handled within the callback routine and cannot be propagated to the outside. Every uncaught exception
causes the runtime error UNCAUGHT_EXCEPTION.
If the class-based exception handling is active and the statement RECEIVE RESULTS FROM FUNCTION is missing in the callback routine, then a runtime
error is returned.

Note
These remarks do not need to be taken into consideration for RFC types with asynchronous properties (aRFC without response, tRFC, qRFC, bgRFC)

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

Page 9 of 24

because:
Exceptions are not transported to the RFC client for aRFC without response.
the client program does not contain the response for tRFC, qRFC, and bgRFC, rather the RFC layer itself executes the handling of all error situations
(for both classic and class-based exceptions).

1.1.4.2 Classic RFC Exceptions

Use
For the external function call, you can use the addition EXCEPTIONS of the statement CALL FUNCTION to assign return values to the exceptions defined in the
interface of the called function module.
In addition to the exceptions defined in the interface of the called function module, an external function call may trigger the following predefined exceptions:
Exception SYSTEM_FAILURE occurs if a runtime error occurs 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.

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

More Information
You can find further information about RFC exceptions under:
Usnig Pre-Defined Exceptions for RFC
Exceptions That Cannot Be Handled

1.1.4.2.1 Usnig Pre-Defined Exceptions for RFC

Use
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.
CALL FUNCTION Remotefunction
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.

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

1.1.4.2.2 Exceptions That Cannot Be Handled

Use
This section provides a list of exceptions that occur during RFC calls and that cannot be handled.
Runtime errors

Cause

CALL_BACK_ENTRY_NOT_FOUND

The called function module is not released for RFC.

CALL_FUNCTION_DEST_TYPE

The destination type is not allowed.

CALL_FUNCTION_NO_SENDER

The function cannot be executed remotely.

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

Page 10 of 24

CALL_FUNCTION_DESTINATION_NO_T

Missing communication type (I for internal connection, 3 for ABAP) when performing an
asynchronous RFC.

CALL_FUNCTION_NO_DEST

The specified destination does not exist.

CALL_FUNCTION_OPTION_OVERFLOW

Maximum length of options for the destination exceeded.

CALL_FUNCTION_NO_LB_DEST

The specified destination (in load distribution mode) does not exist.

CALL_FUNCTION_NO_RECEIVER

Data received for unknown CPI-C connection.

CALL_FUNCTION_NOT_REMOTE

The function module being called is not flagged as "remotely" callable.

CALL_FUNCTION_REMOTE_ERROR

While performing an RFC, an error occurred that has been logged in the calling system.

CALL_FUNCTION_SIGNON_INCOMPL

The user's logon data is incomplete.

CALL_FUNCTION_SIGNON_INTRUDER

Logon attempt not allowed as internal call in a target system.

CALL_FUNCTION_SIGNON_INVALID

RFC from external program without valid user ID.

CALL_FUNCTION_SIGNON_REJECTED

Logon attempt in target system without valid user ID.

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

CALL_FUNCTION_SINGLE_LOGIN_REJ

No authorization to log on as trusted system.

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 System or 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.

CALL_FUNCTION_SYSCALL_ONLY

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.

CALL_FUNCTION_TABINFO

Data error (info internal table) during a Remote Function Call.

CALL_FUNCTION_TABLE_NO_MEMORY

No memory available to import table.

CALL_FUNCTION_TASK_IN_USE

For asynchronous RFC only: The task name is already being used.

CALL_FUNCTION_TASK_YET_OPEN

For asynchronous RFC only: The specified task is already open.

CALL_FUNCTION_NO_AUTH

No RFC authorization.

CALL_RPERF_SLOGIN_AUTH_ERROR

No trusted authorization for RFC caller and trusted system.

CALL_RPERF_SLOGIN_READ_ERROR

No valid trusted entry for the calling system.

RFC_NO_AUTHORITY

Destination "BACK" is not allowed in the current system.

CALL_FUNCTION_BACK_REJECTE

No RFC authorization for user.

CALL_XMLRFC_BACK_REJECTED
CALL_FUNCTION_DEST_SCAN

Error while evaluating the RFC destination.

CALL_FUNCTION_DEST_SCAN

Error while evaluating the RFC destination.

CALL_FUNCTION_CONFLICT_TAB_TYP

Type conflict while transferring a table.

CALL_FUNCTION_CREATE_TABLE

No memory available for creating a local internal table.

CALL_FUNCTION_UC_STRUCT

Type conflict while transferring a structure.

CALL_FUNCTION_DEEP_MISMATCH
CALL_FUNCTION_WRONG_VALUE_LENG

Invalid data type during parameter transfer.

CALL_FUNCTION_PARAMETER_TYPE
CALL_FUNCTION_ILLEGAL_DATA_TYP
CALL_FUNCTION_ILLEGAL_INT_LEN

Type conflict while transferring an integer.

CALL_FUNCTION_ILL_INT2_LENG
CALL_FUNCTION_ILL_FLOAT_FORMAT

Type conflict while transferring a floating point number.

CALL_FUNCTION_ILL_FLOAT_LENG
CALL_FUNCTION_ILLEGAL_LEAVE

Invalid LEAVE statement on RFC server.

CALL_FUNCTION_OBJECT_SIZE

Type conflict while transferring a reference.

CALL_FUNCTION_ROT_REGISTER

1.1.5 RFC Variants

Use
This section provides a description of the various RFC variants. Depending on the required service properties, you can use the following RFC variants.
Synchronous RFC
1. CALL FUNCTION func DESTINATION dest parameter_list .
Synchronous RFC (sRFC) performs a function call directly and waits for the reply from the called function module. The data is not written to the database before the

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

Page 11 of 24

call. When using synchronous RFC, the called system must therefore be available. The call is only made once. If the called system is not available or problems
occur, the call fails (service property: At Most Once ).
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]. Despite its name, asynchronous RFC (aRFC) does not actually entail asynchronous function calls in the strict
sense of the word. Although the function check returns to the calling program directly after the call, the data is not actually written to the database. The call can
therefore only take place on a directly available system.
If the called system is not available, the call fails. Like the sRFC, the aRFC also only has service property At Most Once .
Background RFC
3. CALL FUNCTION func IN BACKGROUND UNIT parameter_list.
Unlike the aRFC, the background RFC (bgRFC) can be termed a "genuine" asynchronous communication method, which performs the function module called in
the RFC server exactly one time (service property: Exactly Once) . Exactly Once). The remote system need not be available at the time when the RFC client
program is executing a bgRFC. The bgRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique
transaction ID (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.
bgRFC is always used if a function is executed as a Unit . Within a given unit, all calls:
1. executed in the order in which they are called
2. executed in the same program context in the target system
3. are executed in a single transaction: they are either committed or rolled back as a unit.
Using bgRFC is always recommended if you want to maintain the transactional sequence of the calls in a unit. bgRFC can be either transactional (type T) or
queued (type Q). When using type Q, units belonging to multiple calls are also sent and processed in exactly the sequence in which they were written to the
database.
Transactional RFC
4. CALL FUNCTION func IN BACKGROUND TASK [DESTINATION dest] parameter_list [AS SEPARATE UNIT].
Transactional RFC is the predecessor of bgRFC for transactional RFC calls. It has the same service properties as bgRFC. tRFC can still be used in exactly the
same way as bgRFC. However, it is not possible to use the two methods in parallel.
Queued RFC
queued RFC (qRFC) is the predecessor of bgRFC type Q. qRFC also allows you to fix the processing sequence. The technology behind qRFC is based on tRFC.
The only difference is that function module TRFC_SET_QUEUE_NAME is executed before the actual tRFC call. This function module makes it possible to
serialize using queues.

Note
We recommend using bgRFC, as it offers considerably better performance than tRFC and qRFC.

1.1.5.1 Synchronous RFC (sRFC)

Use
Synchronous RFC (sRFC) is the most "basic" RFC variant.
It has the following syntax:
CALL FUNCTION func DESTINATION dest parameter list.
This statement causes a 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.

Note
Execution of a function module called by synchronous RFC does not lead to a database commit in an update function. For more information on updating data in
SAP systems, see Updating in SAP Systems.
The parameter list has the following 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] ].
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.

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

Page 12 of 24

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

1.1.5.2 Asynchronous RFC (aRFC)

Use
ARFC 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 function's
result before continuing processing. Asynchronous RFCs can also be sent to the same system. In this case, the system opens a new session (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...

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

More Information
You can find more information about aRFC in:
Call Properties of Asynchronous RFCs
Receiving Results from an Asynchronous RFC
Keeping the Remote Context
Parallel Processing with Asynchronous RFC
You can find a description of the various statements for aRFC in:
CALL FUNCTION - STARTING NEW TASK
RECEIVE
WAIT UNTIL
RFC Example

1.1.5.2.1 Call Properties of Asynchronous RFCs

Use
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
CALL FUNCTION Remotefunction
STARTING NEW TASK Taskname

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

Page 13 of 24

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.

Caution
You must not use IMPORTING parameters when calling aRFCs.

1.1.5.2.2 Receiving Results from an Asynchronous RFC

Use
To receive results from an asynchronously called function, use the following syntax:
CALL FUNCTION Remotefunction
STARTING NEW TASK Taskname
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
CALL FUNCTION Remotefunction
STARTING NEW TASK Taskname
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 statement SET USER-COMMAND 'OKCD' is exactly as if the user had entered the function in the command field and pressed ENTER. The
current positioning of the list and the cursor are thus 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 response'.
ELSE.
WRITE MSG
ENDIF.
...

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

Page 14 of 24

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'. "Sets OK code
ENDFORM.

1.1.5.2.3 Keeping the Remote Context

Use
In the FORM routine that searches for the results of an asynchronously called function with RECEIVE RESULTS FROM FUNCTION, 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.

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

1.1.5.2.4 Parallel Processing with Asynchronous RFC

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

Caution
Parallel-processing is implemented with a special variant of asynchonous RFC. With your own parallel processing applications, It is therefore important that
you only use the correct variant:
CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP.
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

Process
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

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

Page 15 of 24

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
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. Create a loop for this command by splitting up the
data to be processed into work packages. Transfer the data to be processed to an internal table (EXPORT arguments, 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. Remember to consider this restriction when dividing up
your data packets for parallel processing.
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 key word
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 key word
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:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
DESTINATION IN GROUP Groupname
In all currently available and active application servers:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
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.

Note
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

1.1.5.2.5 CALL FUNCTION - STARTING NEW TASK

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

Page 16 of 24

Use
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 CALLING to 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.

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

Note
The parallel processing of function modules using the addition IN GROUP makes optimum use of the resources available, and is preferred to selfprogrammed 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 nonoptional 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 ...]

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

Page 17 of 24

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

1.1.5.2.6 RECEIVE
Use
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.

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

Note
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 ...]
[TABLES t1 = itab1 t2 = itab2 ...]
[EXCEPTIONS exc1 = n1 exc2 = n2 ... [MESSAGE mess]
[OTHERS = n_others]].
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.

1.1.5.2.7 WAIT UNTIL

Use
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

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

Page 18 of 24

Specifying UP TO restricts the program interruption to a maximum number of seconds, specified in seconds. 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
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 Handled
Cause : Undefined status of WAIT statement
Runtime error : WAIT_ILLEGAL_CONTROL_BLOCK
Cause : Negative time entry for sec.
Runtime error : WAIT_ILLEGAL_TIME_LIMIT

1.1.5.2.8 aRFC Programming Example

Use
This example shows parallel asynchronous processing of 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

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

Page 19 of 24

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.

1.1.5.3 Transactional RFC (tRFC)

Use
When using transactional RFC (tRFC), the called function module is executed exactly once in the called system (service property: Exactly Once ).
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.
All tRFCs with a single destination that occur between one COMMIT WORK and the next belong to a single logical unit of work (LUW).
tRFC Process Flow Diagram

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

Page 20 of 24

You can use transactional RFCs, for example, for complex processes that require updating of related database tables during different phases in a transaction.
Transactional RFC processing ensures that all the planned updates are carried out when the program reaches the COMMIT WORK statement.

Caution
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.
System Availability
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. Use enhancement programs SABP0000 and SABP0003 to do this.
To configure a destination, call transaction SM59, select the screen for a destination and choose
of connection attempts up to the task and the time between repeat attempts.

Edit

TRFC Options

. Thus you can determine the number

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.)
More Information
You can find a description of the statements for tRFC in:
CALL FUNCTION IN BACKGROUND TASK

1.1.5.3.1 CALL FUNCTION - IN BACKGROUND TASK

Use
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 WORK deletes 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

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

Page 21 of 24

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.

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

1.1.5.4 Queued RFC (qRFC)

Use
The qRFC (queued Remote Function Call) is an extension of the tRFC. It allows you to serialize tRFC calls using a queue.
The tRFC call is preceded by function module TRFC_SET_QUEUE_NAME, which starts the serialization. The calls are then actually dispatched by a tRFC call.
The qRFC can be made with an outbound queue (serialization at the calling application) and also an inbound queue (serialization at the called application).
This results in the following scenarios for transactional data transfer:

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

Page 22 of 24

Scenario 1: tRFC
This scenario is appropriate is the data being sent is independent of each other. A calling application (client) in system 1 uses a tRFC connection to a called
application (r 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 once 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 sending system uses an outbound queue to serialize the data being sent. This means that mutually dependent function modules are placed in
the outbound queue of the sending system. When the data is sent, the exact order is kept to, and the calls are sent to the target system exactly once in order .
Exactly Once In Order) .

Note
The server system coding does not need to be changed in order to process qRFC calls. However, it must be tRFC enabled.
Scenario 3: qRFC with Inbound Queue (& 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.
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 just one inbound queue in the server system is not possible, since the outbound queue is needed in the client system
in order to set the order and to prevent individual applications from blocking all work processes in the client system.

More Information
You can find detailed information about qRFC in:
Queued Remote Function Call (qRFC)

1.2 Writing Remote Function Modules in ABAP

Use
This section describes the procedure when creating and editing remote function modules. This document contains information about the following topics:
Steps for Implementing Remote Function Modules
Programming Tips
Debugging Remote Function Modules
More Information
For more detailed information on creating function modules with the ABAP Workbench, see:
Function Builder

Note
To view the entire directory tree of the function module documentation, choose Synchronize from the upper left part of the screen.

1.2.1 Steps for Implementing Remote Function Modules

Use
To implement a remote function module in ABAP, perform the following steps:
1. Write the code for the function module.
For guidelines for creating function modules in the Application Server ABAP Repository, see: Function Builder
2. 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 by REMOTE CALL . Registering a module as remote
causes an RFC stub to be generated for it.

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

Administration, Administration

1.2.2 Programming Tips

Use
The following sections describe some points to remember when you write a remote function module.

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

Page 23 of 24

Procedure
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 runtime. 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 not longer than expected on the called side).
Writing for Transactional Execution

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

1.2.3 Debugging Remote Function Modules

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

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

Page 24 of 24