RFC

On this page
Use
More Information
Related Information
Use
Communication between applications of different systems in the SAP
environment includes connections between SAP systems as well as
between SAP systems and non-SAP systems. Remote Function Call
(RFC) is the standard SAP interface for communication between SAP
systems. RFC calls a function to be executed in a remote system.
There is now a whole series of different RFC variants, each of which has
different properties and is used for a specific purpose.
Synchronous RFC
The first version of RFC is synchronous RFC (sRFC). This type
of RFC executes the function call based on synchronous
communication, meaning that the systems involved must both be
available at the time the call is made.
Asynchronous RFC (aRFC)
Despite its name, aRFC is not really an asynchronous type of
communication, as it does not meet the conditions for this. With sRFC,
for example, the called system must be available during the call.
The main characteristics of aRFC are as follows:
 Function control returns to the calling program directly after the call.
 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.
 When the caller starts an aRFC, the called server must be available to
accept the request.
 The calling program can receive results from the asynchronous RFC.
Using aRFC is always a good idea when real-time communication is
established with a remote system, where processing in the calling
 program should not be interrupted until the results of the called
function module have been obtained (the term asynchronous is used in
this sense here).
Transactional RFC (tRFC)
Transactional RFC (tRFC, previously known as asynchronous RFC) is
a genuine asynchronous communication method that - unlike aRFC -
executes the called function module just once in the RFC server. 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 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.
tRFC is always used if a function is executed as a Logical Unit of
Work (LUW). Within a LUW, all calls are
 executed in the order in which they are called
 executed in the same program context in the target system
 are executed in a single transaction: they are either committed or rolled
back as a unit.
Implementation of tRFC is recommended if you want to maintain the
transactional sequence of the calls.
Disadvantages of tRFC
 tRFC processes all LUWs independently of one another. Due to the
amount of activated tRFC processes, this procedure can reduce
performance significantly in both the send and the target systems.
 In addition, the sequence of LUWs defined in the application cannot be
kept. It is therefore impossible to guarantee that the transactions will
be executed in the sequence dictated by the application. The only thing
that can be guaranteed is that all LUWs are transferred sooner or later.
Queued RFC (qRFC)
To guarantee that multiple LUWs are processed in the order specified
by the application, tRFC can be serialized using queues (inbound and
outbound queues). This type of RFC is called queued RFC (qRFC).
qRFC is therefore an extension of tRFC. It transfers an LUW
(transaction) only if it has no predecessors (based on the sequence
defined in different application programs) in the participating queues.
Implementation of qRFC is recommended if you want to guarantee that
several transactions are processed in a predefined order.
Background RFC (bgRFC)
bgRFC is the successor to tRFC and qRFC, with significant improvements
in terms of performance and functionality.
Note
Using bgRFC instead of tRFC and qRFC is therefore urgently
recommended.
Local Data Queue (LDQ)
The LDQ is a special case in RFC communication. Here, no data is sent
actively by the system. Instead, it is stored locally until being called by
an external application (such as a mobile device) according to the pull
principle.
Note
All asynchronous RFC procedures (tRFC, qRFC, bgRFC, LDQ) form part of
the Background Communication concept. As these procedures have
certain characteristics that set them apart from "normal" RFC, they are
described in detail separately.
Data transfer
All RFC types are transferred by means of CPI-C or TCP/IP. They
constitute a kind of gateway communication.
Caution
For information security-relevant aspects of communication with RFC,
see the RFC/ICF Implementation Guide.
More Information
Follow these links to find more information on RFC-related topics:
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.

Parameter Handling in Remote Calls

On this page
Use
Process

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

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.

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:
CALL FUNCTION... DESTINATION 'BACK'
 Example
In the diagram, remote function B of System B invokes remote function
A in the calling System A.

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.

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

RFC Exceptions
On this page
Use
More Information

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.

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

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.
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_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
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.
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.
 Asynchronous RFC (aRFC)
On this page
Use
More Information

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

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

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.

Parallel Processing with Asynchronous

RFC
On this page
Use
Process
Example

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 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:
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.
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 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.
Example
Sample Code
*&---------------------------------------------------------------------*
*& Report ZPAW_RP_PARALLEL_PROCESSING
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZPAW_RP_PARALLEL_PROCESSING.

FUNCTION fm.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" EXPORTING
*" ...
*" CHANGING
*" VALUE(STARTED) TYPE I
*" VALUE(STOPPED) TYPE I
*"----------------------------------------------------------------------
ADD 1 TO started.

" do something

ADD 1 TO stopped.

ENDFUNCTION.

*&---------------------------------------------------------------------*
*& Report RAL_SPBT_DEMO
*&---------------------------------------------------------------------*
*& Releases up to SAP NetWeaver 7.55 (ABAP Platform 2020)
*&---------------------------------------------------------------------*
REPORT spbt_demo_old.

DATA: job_count TYPE i VALUE 100,

task TYPE c LENGTH 10,
jobs_running TYPE i,
jobs_done TYPE i,
jobs TYPE i.

jobs_running = 0.
jobs_done = 0.

WHILE jobs < job_count.

task = |task{ sy-index }|.
CALL FUNCTION 'FM' STARTING NEW TASK task DESTINATION IN GROUP DEFAULT
PERFORMING collect ON END OF TASK
CHANGING
started = jobs_running
stopped = jobs_done
EXCEPTIONS
resource_failure = 1.
IF sy-subrc NE 0.
WAIT UP TO 30 SECONDS.
ELSE.
ADD 1 TO jobs.
ENDIF.
ENDWHILE.

WAIT FOR ASYNCHRONOUS TASKS UNTIL jobs_running = job_count AND jobs_done = job
_count.

EXIT.

FORM collect USING task.

RECEIVE RESULTS FROM FUNCTION 'FM' IMPORTING ....
"...
ENDFORM.
CALL FUNCTION - STARTING NEW TASK
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 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 ...]
[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.

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.

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

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

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

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

Queued RFC (qRFC)

On this page
Use
More Information

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

Background Communication
On this page
Use
More Information

Use
Background communication is a term used to describe various
asynchronous communication methods. With all the methods, the data
that is exchanged between calling and called applications is recorded in
 the database. The database can be used both by the caller and the
called application.
From the database, the data is transferred according to either
the push principle or the pull principle. With the push principle, the
transfer from the database is triggered by one or more schedulers.
With the pull principle, the receiver (the called application) collects the
data from the database on its own. This procedure is also known as
a no-send scenario in SAP terminology.
In all cases, the system ensures the data is transferred once only with
all the procedures ( exactly once or transactional in SAP terminology).
The caller can also determine precise adherence to the call order when
the data is transferred to the called application ( exactly once in
order or queued in SAP terminology).
Three current methods of background communication are described in
the sections below:
 qRFC ( queued remote function call)
 bgRFC ( background remote function call)
 LDQ ( local data queue)
bgRFC and LDQ are the successors of the methods qRFC and tRFC.
Unlike tRFC and qRFC, bgRFC and LDQ offer the following advantages:
 Improved scalability
 Less use of system resources
 More detailed configuration options
 Clear functional separation between the push and pull principles, as
well as between the transactional and queued methods.
 Better for the developers in terms of their complete, object-oriented
API and their integration into the ABAP programming language
With the bgRFC, solutions can be developed that process
either transactional or queued methods in accordance with
the push principle.
The LDQ offers a queued method in accordance with the pull principle.
Caution
 SAP strongly recommends not using the qRFC ( queued, push principle),
the qRFC no-send ( queued, pull principle), or the
tRFC ( transactional, push principle) in new applications on the basis of
the disadvantages described above.
More Information
For more information on the individual background
communication methods, see:
 Queued Remote Function Call (qRFC)
 bgRFC (Background RFC)
 Local Data Queue (LDQ)

bgRFC (Background Remote Function

Call)
Use
The bgRFC allows applications to record data that is received later by a
called application. When the data is received, you must ensure that the
data was transferred to the receiver either once only in any order
( transactional) or once only in the order of creation ( queued).
With the bgRFC, therefore, the asynchronies between the caller and the
called application can result in the following advantages:
 Within an SAP system (same system ID, same client).
Decoupling and (potentially) parallelization are possible. The load is
spread across the available application servers for this system. This
bgRFC scenario is known as an inbound procedure.
 Between two remote SAP Systems
Decoupling and therefore the physical segmentation of an application
or a business scenario are possible. As a result of the asynchronies,
differences in the key features of the application servers for the called
and calling applications can be balanced out. The recording is done in
the calling system. This scenario is an outbound procedure.
 Both procedures can be combined in an out-in procedure.
Here you can take advantage of all the optimization options. However,
if you chose to do this, the data is recorded twice, once for the caller
( outbound processing) and once for the called application (special type
of the inbound procedure). This results in additional load for the
database, and for the application server as well due to the scheduler.
The bgRFC organizes the different calls using queues. A call that is
placed in several queues at the same time creates a dependency
between these queues. This leads to a synchronization point, which is
similar to a lock.
The dependent queues can be processed until the entry for processing
is at the head of the queue that defines the dependency. This entry can
only then be processed if it is at the head of all the queues.
Note
This is a very powerful function (for example, for managing documents
in logistics). If used incorrectly by application development it can stop
queue processing.
The bgRFC offers developers an API that can be used to define the
properties of the transfer and record the data.
The recording is done by means of a call to an RFC-enabled function
module. Multiple function module calls can be bundled together to
form a unit. The unit is the then the unit of the transfer. It is either
transferred entirely or awaits transfer.
Restrictions
A combined use of the bgRFC with tRFC and qRFC is not possible within
a destination. However, for each destination you can define which
communication type you want to use.
Integration
 Applications that convert qRFC to bgRFC must support a migration
scenario in which a temporary link between queues in the qRFC and
queues in the bgRFC is created. In this way, the correct execution
sequence is ensured, even when changing from a qRFC to a bgRFC.
Note
 Changing back from bgRFC to qRFC is not supported.
 As of SAP NetWeaver Release 7.11 and higher, bgRFC can also be used
with the basXML communications protocol.
More Information
For more information about managing and programming the bgRFC,
see:
 bgRFC: Architecture
 bgRFC: Configuration
 bgRFC: Administration
 bgRFC: Programming

bgRFC Configuration
On this page
Use
Process
More Information

Use
To ensure the bgRFC communication functions optimally, various settings can or must be
made.
You can perform all the relevant steps using the transaction SBGRFCCONF.
Note
To perform bgRFC configuration tasks, you need authorizations from authorization
object S_BGRFC.
Process
You have the following configuration options:
Basic settings
Creating a Supervisor Destination
The bgRFC cannot function if a supervisor destination has not been defined.
Recreate inbound destinations
You can create separate inbound destinations for each application to distribute the load.
Assign queue prefixes to inbound destinations
You need to make these settings in order to assign existing queue prefixes for a "classic" qRFC
to an inbound destination, therefore ensuring that bgRFC works without errors.
Maintain logon server groups
By assigning server groups to an inbound destination you can distribute the load.
 Scheduler Configuration
To optimize the bgRFC function in terms of system performance you can make various settings
for the bgRFC schedulers.
Note
If you do not want to make any changes here, the system uses the valid default values.
More Information
You can find information about the authorizations required for bgRFC configuration under:
 bgRFC Authorizations
The settings described above can be found on the tab pages within the transaction
SBGRFCCONF.
For more information about the configuration options, see:
 Creating a Supervisor Destination
 Maintaining Inbound Destinations
 System-Specific Settings
 Application Server-Specific Settings
 Destination-Specific Settings

bgRFC Authorizations
On this page
Use
More Information

Use
For the configuration and administration of bgRFC functions, you need various authorizations,
depending on the type of activities you want to perform. The following is a description of the
authorizations required for:.
 bgRFC Configuration
 bgRFC Monitoring
 Debugging bgRFC Units
bgRFC Configuration
For bgRFC configuration, you need authorization object S_BGRFC. This object contains various
authorization fields where you can set the type and scope of the configuration authorizations.
The bgRFC Supervisor User also needs authorizations from authorization object S_RFC. These
are defined in role SAP_BC_BGRFC_SUPERVISOR.
bgRFC Monitoring
To be able to display bgRFC units in the monitor, you also need authorizations from object
S_BGRFC.
Debugging bgRFC Units
 You need the following authorization objects for debugging bgRFC units depending on the
scenario:
 S_BGRFC
 S_DEVELOP
 S_TCODE
 S_RFC
 S_RFCACL

Update Techniques
The main update technique for bundling database changes in a single
database LUW is to use CALL FUNCTION ... IN UPDATE TASK. This
section describes various ways of updating the database.
A program can send an update request using COMMIT WORK
To the update work process, where it is processed asynchronously. The
program does not wait for the work process to finish
the update ( Asynchronous Update ).
For asynchronous processing in two steps ( Updating Asynchronously in
Steps .)
To the update work process, where it is processed synchronously. The
program waits for the work process to finish
the update ( Synchronous Update ).
To its own work process locally. In this case, of course, the program has
to wait until the update is finished ( Local Update .)

Asynchronous Update
A typical SAP system installation contains dialog work processes and at
least one update work process. The update work processes are
responsible for updating the database. If, in a dialog work
 process, function modules that are stored temporarily are released for
processing in an update work process using CALL FUNCTION ... IN
UPDATE TASK through the ABAP statement COMMIT WORK, the dialog
work process does not wait for the update request to end. This kind
of update is called asynchronous update.
The following diagram shows a typical asynchronous update:

For example, let us suppose a user wishes to change an entry in a

database table, or add a new one. He or she enters the necessary data,
and then starts the update process by choosing Save. This starts the
following procedure in the ABAP program:
1. Firstly, the program locks the database entry against other users. For
this purpose, the enqueue work process is addressed (in a distributed
system, this takes place through the message server). This generates a
corresponding entry in the lock table. The user is informed whether
the update was successful, or whether the lock could not be set
because of other users.
2. If the lock is set, the program reads the entry that is to be changed
and modifies it. If the user has created a new entry, the program
checks whether a record with the same key values already exists.
3. The program calls a function module in the current dialog work
process using CALL FUNCTION ... IN UPDATE TASK and, in this
way, writes the change request as a log entry into table VBLOG(Now
VBHDR VBMOD VBDATA).
4. When the program is finished (maybe after further dialog steps), a
COMMIT WORK statement starts the final part of the SAP LUW. The
work process that is processing the current dialog step starts
an update work process.
5. Based on the information passed to it from the dialog work process,
the update work process reads the log entries belonging to the SAP
LUW from table VBLOG(Now VBHDR VBMOD VBDATA).
6. The update work process passes this data to the database for
updating, and analyzes the return message from the database. If
 the update was successful, the update work process triggers a
database commit after the last database change and deletes the log
entries from table VBLOG(Now VBHDR VBMOD VBDATA). If an
error occurrs, the update process triggers a database rollback, leaves
the log entries in table VBLOG(Now VBHDR VBMOD VBDATA), flags
them as containing errors, and sends an SAPmail to the user, who
should then inform the system administrator.
7. The corresponding entries in the lock table are reset by
the update work process.
Asynchronous updating is useful when the response time from the
transaction is critical, and the database updates themselves are so
complex that they justify the extra system load of logging them in
VBLOG. If you are running a transaction in a background work process,
asynchronous updating provides no advantages.

Updating Asynchronously in Steps

When you process a VBLOG entry asynchronously, you can do it in
two update steps. This allows you to divide the contents of
the update into primary and secondary steps. The primary step is called
V1, the secondary step V2. The V1 and V2 steps of a log entry are
processed in separate database LUWs. The entries in the lock table are
usually deleted once the V1 step has been processed. There is no
locking for the V2 step. Dividing up the update process allows you to
separate time-critical updates that require database locks from less
critical data updates that do not need locks. V2 steps receive lower
priority from the dispatcher than V1 steps. This ensures that the time-
and lock-critical updates are processed quickly, even when the system
is busy.
If an error occurs during the V1 processing, the database rollback
applies to all V1 steps in the log entry. The entire entry is replaced in
table VBLOG. If an error occurs during V2 processing, all of the V2 steps
in the log entry are replaced in table VBLOG, but the V1 updates are not
reversed.
The system marks rolled-back function modules as error functions in
the update task log. The error can then be corrected and
the function restarted later. To access the update task log, choose
Tools → Administration → Monitoring → Update. For further
information about update administration, see the Managing Updating
section of the BC System Services documentation.

Synchronous Update
In synchronous update, you do not submit update requests using
CALL FUNCTION …IN UPDATE TASK . Instead you use the ABAP
statement COMMIT WORK AND WAIT. When the update is finished,
control passes back to the program. Synchronous update works in the
same way as bundling update requests in a subroutine (PERFORM ON
COMMIT). This kind of update is useful when you want to use both
asynchronous and synchronous processing without having to program
the bundles in two separate ways. The following diagram illustrates the
synchronous update process:
Use this type of update whenever the changed data is required
immediately. For example, you may want to link SAP LUWs together
where one LUW depends on the results of the previous one.

Local Update
In a local update, the update program is run by the same work process
that processed the request. The dialog user has to wait for
the update to finish before entering further data. This kind of update is
useful when you want to reduce the amount of access to the database.
The disadvantage of local updates is their parallel nature. The updates
can be processed by many different work processes, unlike
asynchronous or synchronous update, where the update is serialized
due to the fact that there are fewer update work processes (and maybe
only one).

You switch to local update using the ABAP statement SET UPDATE TASK
LOCAL. This statement sets a "local update switch". When it is set, the
system interprets CALL FUNCTION ...IN UPDATE TASK as a request for
local update. The update is processed in the same work process as the
dialog step containing the COMMIT WORK. The transaction waits for
the update to finish before continuing.

As an example, suppose you have a program that uses

asynchronous update that you normally run in dialog mode. However,
this time you want to run it in the background. Since the system
response time is irrelevant when you are running the program in the
background, and you only want the program to continue processing
when the update has actually finished, you can set the
SET UPDATE TASK LOCAL switch in the program. You can then use a
system variable to check at runtime whether the program is currently
running in the background.

By default, the local update switch is not set, and it is reset after each
COMMIT WORK or ROLLBACK WORK. You therefore need to include a
SET UPDATE TASK LOCAL statement at the beginning of each SAP LUW.
If you reset data within the local update, the ROLLBACK WORK
statement applies to both the dialog and the update part of the
transaction, since no new SAP LUW is started for the update.

Creating Update Function Modules

 To create a function module, you first need to start
the Function Builder. To do this, choose Tools ABAP
Workbench Function Builder. You can find more information on how
to create function modules in the appropriate documentation ABAP
Workbench Tools.
To be able to call a function module in an update work process, you
must flag it in the Function Builder. When you create
the function module, set the Process Type attribute to one of the
following values:
 Update with immediate start
Set this option for high priority ("V1") functions that run in a shared SAP
LUW. These functions can be restarted by the update task if any errors
occur.
 Update with immediate start, no restart
Set this option for high priority ("V1") functions that run in a shared SAP
LUW. These functions may not be restarted by the update task.
 Update with delayed start
Set this option for low priority ("V2") functions that run in their
own update transactions. These functions can be restarted by
the update task if any errors occur.
To get to the attributes screen in the Function Builder,
choose Goto Administration.
Defining the Interface
Function modules that run in the update task have a restricted
interface:
 Result parameters or exceptions are not allowed since update-
task function modules cannot report on their results.
 You must specify input parameters and tables with reference fields or
reference structures defined in the ABAP Dictionary.

Calling Update Functions

 Synchronous or Asynchronous Processing?
Function modules that run in the update task can run synchronously or
asynchronously. You determine this by the form of the COMMIT
statement you use:
 COMMIT WORK
This is the standard form, which specifies asynchronous processing.
Your program does not wait for the requested functions to finish
processing.
 COMMIT WORK AND WAIT
This form specifies synchronous processing.
The COMMITstatement waits for the end of processing. Control returns
to your program after all high priority (V1) function modules have run
successfully.
The AND WAIT form is convenient for switching old programs to
synchronous processing without having to re-write the
code. Functionally, using AND WAIT for update-task updates is just the
same as dialog-task updates with PERFORM ON COMMIT.
Parameter Values at Execution
In ABAP, you can call update-task function modules in two different
ways. The way you choose determines what parameter values are used
when the function module is actually executed. Parameter values can
be set either at the time of the CALL FUNCTION statement, or at the
time of the COMMIT WORK. The following sections explain.
Calling Update Functions Directly
Adding Update Task Calls to a Subroutine
Note
The examples in these sections show asynchronous commits with
COMMIT WORK.

Calling Update Functions Directly

To call a function module directly, use CALL FUNCTION IN UPDATE TASK
directly in your source code.
CALL FUNCTION 'FUNCTMOD' IN UPDATE TASK EXPORTING...
The system then logs your request and executes
the function module when the next COMMIT WORK statement is
reached. The parameter values used to execute
the function module are those current at the time of the call.
Note

a = 1. CALL FUNCTION 'UPD_FM' IN UPDATE TASK EXPORTING par =

a...a = 2. CALL FUNCTION 'UPD_FM' IN UPDATE TASK EXPORTING par =
a... a = 3. COMMIT WORK.
Here the function module UPD_FM is executed twice in the update task
- once with the value 1 in par and once with the value 2 in par.

Adding Update-Task Calls to a

Subroutine
You can put the CALL FUNCTION IN UPDATE TASK into a subroutine and
call the subroutine with:
PERFORM SUBROUT ON COMMIT.
If you choose this method, the subroutine is executed at the commit.
Thus the request to run the function in the update task is also logged
during commit processing. As a result, the parameter values logged
with the request are those current at the time of the commit.
Note
a = 1.
PERFORM F ON COMMIT.
a = 2.
PERFORM F ON COMMIT.
a = 3.
COMMIT WORK.
FORM f.
CALL FUNCTION 'UPD_FM' IN UPDATE TASK EXPORTING par = a.
ENDFORM.

In this example, the function module UPD_FM is carried out with the
value 3 in par. The update task executes the function module only once,
despite the two PERFORM ON COMMIT statements. This is because a
repeatedly registered one can only be executed once in the case of
COMMIT WORK. The subroutine itself, containing
the function module call, cannot have parameters.
Note

The method described here is not suitable for use inside

dialog module code.

Special LUW Considerations

In the update task queue, the system identifies all function modules
belonging to the same transaction (SAP LUW) by assigning them a
common update key. At the next COMMIT WORK, the update task
reads the queue and processes all requests with the
predefined update key.
If your program calls an update-task function module, the request to
execute the module (or the subroutine calling it) is provided with
the update key of the current LUW and placed in the queue.
The following sections explain what happens to LUWs
when update function modules are included in other modules
(transactions or dialog modules) that are called by other programs.
Transactions That Call Update Task Functions
Dialog Modules That Call Update Task Functions
Transactions That Call Update Function
Modules
If your program calls another program that itself calls
an update function module, you should be aware of the following:
When the new program is called, a new SAP LUW begins, and a
new update key is generated. This key is used to identify all update-task
operations requested during the called program.
When returning from the program, the LUW of the calling program is
restored together with the old update key.
If the called program does not contain its own COMMIT WORK, the
database update requests are not processed, and
the update function modules are not called. In the following example,
F1, F2, and F3 are update function modules:
Here, F1 and F3 are executed in the update task, because the COMMIT
WORK for the main program triggers their execution. However, since
transaction ZABC contains no COMMIT WORKstatement,
the function F2 is never executed by the update task.

Dialog Modules that Call Update

Function Modules
Unlike transactions and executable programs, dialog modules do not start a new SAP LUW. Calls
to update-task function modules from a dialog module use the same update key as the ones in
the calling program. The result is that calls to update function modules from a
dialog module are executed only if a COMMIT WORK statement occurs in the calling program.
Note
If you place a COMMIT WORK in a dialog module, it does commit changes to the database (for
example, with UPDATE).However, it does not start the update task. The function modules are
not actually executed until a COMMIT WORK statement occurs in the calling program.
 Note
If you use dialog modules, try to avoid including calls to update function modules in subroutines
called with PERFORM ON COMMIT. In general, any occurrence of PERFORM ON COMMIT(with
or without update-task function calls) in a dialog module can be problematic.
This is because dialog modules have their own roll area, which disappears when
the module finishes. Consequently, all local data (including data used for parameter values
when calling an update function module) disappears as soon as the commit in the main
program is reached.
If you must use this method in a dialog module (i.e. include the call to an update-
task function in a subroutine), you must ensure that the values of the actual parameters still
exist when the update-task function actually runs. To do this, you can store the required values
with EXPORT TO MEMORY and then import them back into the main program (IMPORT FROM
MEMORY) before the COMMIT WORKstatement.

Error Handling for Bundled Updates

Runtime errors can occur when bundled updates are executed. How are
they handled? In general, COMMIT WORK processing occurs in the
following order:
1. All dialog-task FORM routines logged with PERFORM ON COMMIT are
executed.
1. All high-priority update task (V1) function modules are executed.
The end of V1 update processing marks the end of the modifying
transaction. If you used COMMIT WORKANDWAIT to trigger commit
processing, control returns to the dialog task program.
2. All low-priority update task (V2) function modules
are triggered.All background task function modules are triggered.
Runtime errors can occur either in the system itself or as a result of a
termination message (MESSAGE type 'A'). Also, the ROLLBACK WORK
statement automatically signals a runtime error. The system handles
errors according to where they occur:
 in a FORM routine (called with PERFORM ON COMMIT)
 Updates already executed for the current update transaction are
rolled back.
  No other FORM routines are started.
 No further update task or background task functions are started.
 An error message appears on the screen.
 in a V1 update task function module(requested IN UPDATE TASK)
 Updates already executed for V1 functions are rolled back.
 All further update task requests (V1 or V2) are discarded.
 All background task requests are discarded.
 Updates already executed for FORM routines called with PERFORM
ON COMMIT are not rolled back.
 An error message appears on the screen, if your system is set up to
send them.
 in a V2 update task function module(requested IN UPDATE TASK)
 Updates already executed for the current V2 function are rolled
back.
 All update task (V2) requests still to be executed are discarded.
 All background task requests still to be executed are carried out.
 No updates for previously executed V1 functions are rolled back.
 No updates previously executed for FORM routines (called with ON
COMMIT) are rolled back.
 An error message appears on the screen, if your system is set up to
send them.
 in a background task function module(requested IN BACKGROUND
TASK DESTINATION)
 Background task updates already executed for the current
DESTINATION are not rolled back.
 All further background task requests for the same DESTINATION
are discarded.
 Other previously executed updates are rolled back.
 No error message appears on the screen.
If your program detects that an error in remote processing has
occurred, the requests can be resubmitted at a later time.
For more information about RFC processing, see Components of SAP
Communication Technology .