Writing RFC Programs in ABAP

Writing RFC Programs in ABAP
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_nwpi71/helpdata/en/22/0424ba488911d189490000e829fbbd/content.htm
Created on February 16, 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 Page 1 of 22
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
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 Parameters 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 Things to Look Out for in Unicode
1.1.4 RFC Exceptions
1.1.4.1 Using Pre-Defined Exceptions for RFC
1.1.4.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 Remote Contexts
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 Page 2 of 22
Writing RFC Programs in ABAP
Use
The following sections provide information about RFC programming in the ABAP environment:
● Calling RFC Function Modules in ABAP
● Writing Remote Function Modules in ABAP
Calling RFC Function Modules in ABAP

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
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 Remote Function field can be either a literal or a variable. The Dest field can be either a literal or a variable. Its value is a logical destination
("hw1071_53" for example) that is known to the local SAP System. You can define logical destinations in table RFCDES using transaction SM59 or by
choosing Tools → Administration ® Administration → Network → RFC Destinations .
Programming guidelines are available in the following topics:
Parameters in Remote Calls
Things to Look Out for in Unicode
Calling Remote Functions Locally
Calling Remote Functions Back
CALL FUNCTION RFC (RFC Variants)
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 Page 3 of 22
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.
Table RFCDES is configured using transaction SM59 ( Remote Destinations ).
Interface Functions
RFC frees the ABAP programmer from having to program his/her 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 an RFC server. The RFC client is the instance that calls up the Remote Function Call to execute the function
that is provided by an RFC server. From here on, the functions that can be executed remotely are referred to as RFC functions, and the functions provided via
RFC API are referred to as 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 are retained until the connection is explicitly closed, or until the calling program is terminated. Function module
RFC_CONNECTION_CLOSE can be used to explicitly close a connection.
More Information
You can find detailed information about RFC calls here:
● Parameters in Remote Calls
● Calling Remote Functions Locally
● Calling Remote Functions Back
● RFC Call Restrictions
● RFC Variants
1.1.2.1 Parameters in Remote Calls

When you make a remote function call, the system handles parameters differently than it does with local calls.
TABLES Parameters
The actual table is transferred, but not the table header. If you do not specify a table parameter, the called function module uses an empty table.
The RFC uses a delta managing mechanism to minimize network load during parameter and result transfer. Internal ABAP tables can be used as parameters for
function module calls. When a function module is called locally, a parameter table 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. Only delta information is then returned to the RFC client.
However, this information is not returned to the RFC client every time a table operation occurs. Instead, all collected delta information is transferred at once when
the function returns to the RFC client.
The first time a table is transferred, 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

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 are different for both cases (this is explained in more detail in 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 Function
Calls.)
DESTINATION ‘NONE’
PUBLIC Page 4 of 22
EXPORTING F1 = a1
F2 = a2
TABLES t1 = ITAB
EXCEPTIONS ...
●
●
Local Call:
● CALL FUNCTION... [no DESTINATION used]
This is a local call, even though the function module is registered as remote. The module does not run in a separate roll area, and is essentially like a normal
function call. Parameter transfer is handled as for normal function modules. In particular, if the call leaves some EXPORTING parameters unspecified, it
terminates abnormally.
EXPORTING F1 = a1
F2 = a2
TABLES t1 = ITAB
EXCEPTIONS ...
You can also call a function for parallel processing in the same system. For more details, see Parallel Processing with Asynchronous RFCs.
1.1.2.3 Calling Remote Functions Back

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

Unlike 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. Synchronous RFC must therefore 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.
PUBLIC Page 5 of 22
Things to Look Out for in Unicode
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. The Unicode system is therefore 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
The output buffer overflows when the results are returned
The way in which the called Unicode system reacts to conversion errors depends on the profile parameters
rfc/cp_convert/ignore_error
rfc/cp_convert/conversion_char
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 in the non-Unicode system overflows.
In the calling system, the reaction to conversion errors can be configured separately for each destination.
See transaction SM59 Defining Remote Destinations.
For the called system, conversion errors are 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

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. Class-based exceptions cannot be propagated to the caller from a remotely-called function module, and have the effect of
an exception that cannot be processed.
In addition to the exceptions defined in the interface of the called function module, an external function call may trigger the following predefined exceptions:
● 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.
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.
PUBLIC Page 6 of 22
More Information
You can find further information about RFC exceptions under:
● Usnig Pre-Defined Exceptions for RFC
● Untreatable Exceptions
Using Pre-Defined Exceptions for RFC

The RFC interface defines two additional exception types:
● SYSTEM_FAILURE
This exception reports all failures and system problems on the remote machine.
● COMMUNICATION_FAILURE
This exception is raised whenever a connection or communications failure occurs. It does not report system problems (such as abnormal termination) that
occur on the remote machine.
Requesting Error Messages

In the function modules that you call, you should define exceptions for any error reporting, and not just the MESSAGE keyword.
DESTINATION Dest
EXPORTING...
IMPORTING...
TABLES...
EXCEPTIONS
SYSTEM_FAILURE = 1 MESSAGE msg
COMMUNICATION_FAILURE = 2 MESSAGE msg
The system sets the message variable (msg) to the system message. You can then display the message or log it in a file. You should not try to interpret
message text in your program.
You can use MESSAGE only with the two system exceptions described here.
1.1.4.2 Exceptions That Cannot Be Handled

This section provides a list of exceptions that occur during RFC calls and that cannot be handled.
Exceptions That Cannot Be Handled
Runtime Error 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)
PUBLIC Page 7 of 22
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
RFC Variants
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
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
PUBLIC Page 8 of 22
[{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). 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. are executed in the order in which they are called
2. are executed in the same program context in the target system
3. run as 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.
We recommend using bgRFC, as it offers considerably better performance than tRFC and qRFC.
1.1.5.1 Synchronous RFC (sRFC)

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. If the remotely called function is terminated, the calling program is
continued using the CALL FUNCTION statement.
PUBLIC Page 9 of 22
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.
Transferring tables using addition TABLES is considerably faster than using the other additions, as a binary format is used internally instead of an
XML format.
1.1.5.2 Asynchronous RFC (aRFC)

ARFC are similar to transactional RFCs, in that the user does not have to wait for their completion before continuing the calling dialog. However, asynchronous
RFCs have three important distinguishing features.
● 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 result of the
function module 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 between the calling dialog and the called session, and vice versa.
To start a remote function call asynchronously, use the following syntax:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
DESTINATION ...
EXPORTING...
TABLES ...
EXCEPTIONS...
The following calling parameters are available:

■ TABLES
passes references to internal tables. All of the function module’s table parameters 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 in a FORM routine to receive the results of an asynchronous RFC. The
following receiving parameters are available:
■ IMPORTING
■ TABLES
■ EXCEPTIONS
Addition KEEPING TASK keeps an asynchronous connection open after the results have been sent. The relevant remote context (role 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 RFC
● Receiving Results from an Asynchronous RFC
● Keeping Remote Contexts
● 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
PUBLIC Page 10 of 22
Call Properties of Asynchronous RFCs
When you call a remote function with the optional suffix STARTING NEW TASK, the system starts the function in a new session. Rather than waiting for the
remote call to be completed, the user can resume processing as soon as the function module has been started in the target system.
The remotely called function module can, for example, display a new screen using CALL SCREEN, allowing the user to enter a dialog that connects him or her
directly to the remote system:
Client System
STARTING NEW TASK Taskname
DESTINATION Dest
Server System
FUNCTION Remotefunction.
CALL SCREEN 100.
ENDFUNCTION.
If you do not specify a destination, the asynchronous RFC mechanism starts a new session within the calling system.
You must not use IMPORTING parameters when calling aRFCs.
Receiving Results from an Asynchronous RFC

To receive results from an asynchronously called function, use the following syntax:
PERFORMING RETURN_FORM ON END OF TASK.
Once the called function is completed, the next dialog step in the calling program (such as AT USER-COMMAND) guides the system into the FORM routine that
checks for results. This FORM routine consists of special syntax and must be called with a USING parameter that refers to the name of the task:
Client System
DESTINATION Dest
PERFORMING RETURN_FLIGHT ON END OF TASK.
...
FORM RETURN_FLIGHT USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION Remotefunction
IMPORTING F1 = a1
EXCEPTIONS SYSTEM_FAILURE MESSAGE SYSTEM_MSG.
SET USER-COMMAND ‘OKCD’.
ENDFORM.
■ If a function module does not return a result, you can leave out addition PERFORMING RETURN_FORM ON END OF TASK.
■ If an asynchronous call calls several consecutive function modules with the same destination, you must assign a different task name to each one.
■ A calling program that starts an asynchronous RFC with PERFORMING cannot switch role 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 role area switch with SUBMIT or
CALL TRANSACTION.
■ If the calling program that executed the asynchronous call is terminated, even though it is awaiting 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. You can find out more about the WAIT statement in the online help for ABAP editor.
■ Key word RECEIVE only exists with the function module call CALL FUNCTION Remotefunction STARTING NEW TASK Taskname. If the
function module does not return any results, you can leave this part.
■ 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.
Call-backs are not supported.
The SET USER-COMMAND ‘OKCD’ statement replaces the REFRESH SCREEN command. REFRESH SCREEN is no longer maintained
and should therefore not be used.
DATA: INFO LIKE RFCSI,

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

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 (role area) is kept until the caller terminates the connection. If you specify the same task name, you can re-use the remote context and
role area.
If the remote function module performs interactive tasks such as list or screen processing, screens are displayed until the calling program terminates. If the
remote call is made in debugging mode, this mode is visible until the caller dialog is terminated.
You should use 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 impairs performance due to additional role area management in the system.
Parallel Processing with Asynchronous RFC

To achieve a balanced distribution of the system load, you can use destination additions to perform function modules in parallel tasks in any application server or
in a predefined application server group of an SAP system.
Parallel processing is implemented with a special asynchonous RFC variant. 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.
By using other variants of asynchronous RFC, you are no longer protected by the built-in safeguards in the correct keyword, and can cause your
system to crash.
You can find details in:
● Prerequisites for Parallel Processing
● Function Modules and ABAP Keywords for Parallel Processing
● Managing Resources in Parallel Processing
Prerequisites for Parallel Processing

Before implementing parallel processing, make sure that your application and your SAP system meet these requirements:
● Logically-independent units of work:
The data processing task 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 other parallel
operation tasks. For example, parallel processing is not suitable for data that must be sequentially processed or in which the processing of one data item is
dependent upon the processing of another item of the data.
By definition, there is no guarantee that data will be processed in a particular order in parallel processing or that a particular result will be available at a given
point in processing.
● ABAP requirements:
○ The function module that you call must be marked as externally callable. This attribute is specified in the Remote function call supported field in the
function module definition (transaction SE37).
○ The called function module may not include a function call to the destination “BACK.”
○ The calling program should not change to a new internal session after making an asynchronous RFC call. That is, you should not use SUBMIT or CALL
TRANSACTION in such a report after using CALL FUNCTION STARTING NEW TASK.
○ You cannot use the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword to start external programs.
● System resources:
In order to process tasks from parallel jobs, a server in your SAP system must have at least 3 dialog work processes. It must also meet the workload criteria
of the parallel processing system: Dispatcher queue less than 10% full, at least one dialog work process free for processing tasks from the parallel job.
Function Modules and ABAP Keywords for Parallel Processing

You can implement parallel processing in your applications by using the following function modules and ABAP keywords:
● SPBT_INITIALIZE: Optional function module.
Use to determine the availability of resources for parallel processing.
You can
○ 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 Remote function STARTING NEW TASK Task name 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 with SPBT_GET_PP_DESTINATION if you find that a particular
server is not available for parallel processing (for example, COMMUNICATION FAILURE exception if a server becomes unavailable).
● WAIT: ABAP keyword
WAIT UNTIL <logical expression>
Required if you wish to wait for all of the asynchronous parallel tasks created with CALL FUNCTION to return. This is normally a requirement for orderly
background processing. May be used only if the CALL FUNCTION includes the PERFORMING ON RETURN addition.
● RECEIVE: ABAP keyword
RECEIVE RESULTS FROM FUNCTION Remotefunction
Required if you wish to receive the results of the processing of an asynchronous RFC. RECEIVE retrieves IMPORT and TABLE parameters as well as
messages and return codes.
Managing Resources in Parallel Processing

You use the following destination additions to run function modules in parallel (asynchronous calls) in the SAP system:
In a predefined group of application servers:
DESTINATION IN GROUP Groupname
In all currently available and active application servers:
DESTINATION IN GROUP DEFAULT
The addition first determines the amount of resources (work processes) currently available (i.e. in all servers or in a group of application servers, comparable with
login servers). The resources available for executing asynchronous calls on each application server depend 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). One application server must therefore have at least three dialog processes if RFC parallel
processing is taken into account.
■ At present, only one RFC group per program environment is supported for parallel execution of asynchronous calls. Using both additions
(DESTINATION IN GROUP Groupname and DESTINATION IN GROUP DEFAULT) in one program is not allowed.
■ 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
Syntax
CALL FUNCTION func STARTING NEW TASK task
[DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]
parameter list
[{PERFORMING subr}|{CALLING meth} ON END OF TASK].
Additions:
1. ...DESTINATION IN GROUP { group |DEFAULT}
2. ...{PERFORMING subr}|{CALLING meth} ON END OF TASK

Effect
Asynchronous call of a remote-capable function module specified in func using the RFC interface. You can use the addition DESTINATION to specify a single
destination in dest, or to specify a group of application servers by using IN GROUP. The latter supports parallel processing of multiple function modules. The
calling program is continued using the statement CALL FUNCTION, as soon as the remotely called function has been started in the target system, without having
to wait for its processing to be finished. You can use PERFORMING and CALLINGto specify callback routines for copying results when the remotely called
function is finished. Character-type data objects are expected for func and dest.
If the destination has not been specified, the destination NONE is used implicitly. When the destination NONE is used, a new main session is opened for the
current user session. The asynchronous RFC does not support communication with external systems or programs written in other programming languages.
A character-type data object must be specified for task, one which contains for the remotely called function module a freely definable task ID that has a maximum
eight digits. This task ID must be unique for each call, and is handed to the callback routines for identifying the function. Each task ID defines a separate RFC
connection with its own context, meaning that, in the case of repeated function module calls of the same task ID, the global data of the relevant function group can
be accessed, if the connection still exists.
In dialog processing, note that the maximum number of six main sessions cannot be exceeded, else an error message is displayed.
Addition 1
... DESTINATION IN GROUP {group|DEFAULT}
Effect
Specifying IN GROUP as a destination allows you to execute multiple function modules in parallel on a predefined group of application servers in the current
SAP system.
For group, you must specify a data object of the type RZLLI_APCL from the ABAP Dictionary, one that is either initial, or one that includes the name of an RFC
server group created in transaction RZ12. When specifying DEFAULT, or if group is initial, all application servers that are currently available in the current SAP
system are used as a group. Only one RFC server group may be used within a program. During the first asynchronous RFC using the addition IN GROUP, the
specified RFC server group is initialized. For each asynchronous RFC where the group is specified, the most suitable application server is determined
automatically, and the called function module is executed on this.
If the function module cannot be executed on any application server, due to not enough resources being currently available, this leads to the predefined exception
RESOURCE_FAILURE, to which a return value can be assigned, in addition to the remaining RFC exceptions. For this exception, the addition MESSAGE is not
permitted.
● The parallel processing of function modules using the addition IN GROUP makes optimum use of the resources available, and is preferred to self-
programmed parallel processing with destinations that are specified explicitly.
● An application server that is used as part of an RFC server group for parallel processing must have at least three dialog work processes, of which one is
currently free. Other resources such as requests in the queue, number of system logons and so on, are also taken into account, and are not allowed to
exceed certain limit values.
● To ensure that only those application servers that have enough resources are accessed, we recommend that you work with explicitly defined RFC server
groups instead of working with the addition DEFAULT.
● The function modules of the function group SPBT provide service functions for parallel processing, for example, initialization of RFC server groups,
determining the used destination, or temporarily removing an application server from an RFC server group.
Addition 2
... {PERFORMING subr}|{CALLING meth} ON END OF TASK
Effect
You can use this addition to specify either a subprogram subr or, as of Release 6.20, a method meth as a callback routine, which is executed after the
asynchronously called function module has finished. For subr, you have to directly specify a subprogram of the same program. For meth, you can enter the
same details as for the general method call.
The specified subprogram subr can have exactly one SING parameter of type clike only. The method meth must be public, and can have only one non-
optional input parameter p_task of type clike. When the RFC interface is called, this parameter is supplied with the task ID of the remotely called function that
was specified in the call in task. The results of the remote function can be received in the subprogram subr or method meth using the statement RECEIVE. In
the callback routine, no statements can be executed that cause the program run to terminate or end an SAP LUW. Statements for list output are not executed.
Prerequisite for executing a callback routine is that, after the remote function has ended, the calling program is still internally available. It is then executed the next
time the work process is changed. If the program has ended, or if it is part of a call sequence in the stack, then the callback routine is not executed. The
statement WAIT can be used to stop the program execution until certain or all callback routines have been executed.
CALL FUNCTION - STARTING NEW TASK parameter_list
Syntax
... [EXPORTING p1 = a1 p2 = a2 ...]
Effect
These additions are used to assign actual parameters to the formal parameters of the function module, and return values to exceptions that are not class-based.
These additions have the same meaning as for the synchronous RFC. The only exception is that no values can be copied with IMPORTING and CHANGING.
1.1.5.2.6 RECEIVE
Syntax
RECEIVE RESULTS FROM FUNCTION func
parameter list
[KEEPING TASK].
Addition:
... KEEPING TASK
Effect
This statement can be used in a callback routine specified for the asynchronous RFC, in order to receive output parameters of an asynchronously called function
func in the parameter list parameter list, and to assign return values to exceptions.
If a function module is started multiple times in a row using asynchronous RFC, the execution sequence is not fixed, but depends on the system
availability instead.
Addition
... KEEPING TASK
Effect
With the addition KEEPING TASK, the asynchronous RFC connection is retained, together with the context of the called function module. 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
completed after the remote function has been executed and/or the results have been copied.
You should only use addition KEEPING TASK if the context of the called function module is required for other function calls.
RECEIVE - parameter_list
Syntax
... [IMPORTING p1 = a1 p2 = a2 ...]
Effect
With these additions, the defined formal parameters of the function module specified in func are transferred to the actual parameters of the callback routine in the
calling program, and return values are assigned to non-class-based exceptions. The meaning of the additions is the same as for synchronous RFC. In particular,
the special exceptions SYSTEM_FAILUREand 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
Syntax
WAIT UNTIL log_exp [UP TO sec SECONDS].
Addition:
... UP TO sec SECONDS
Effect
This variant of the statement WAIT is only intended to be used after an asynchronous RFC with callback routines. It interrupts the program execution for as long as
the result of the logical expression log_exp is false. Any logical expression can be specified for log_exp.
If the result of log_exp is false, the program waits until a callback routine of a function that was previously called asynchronously has been executed, and then
checks the logical expression again. If the result of the logical expression is true, or if the callback routines of all functions that were previously called
asynchronously have been executed, then the program execution continues with the statement following WAIT.
Addition
... UP TO sec SECONDS
Effect
Specifying UP TO restricts the program interruption to a maximum number of seconds, specified in sec. A data object of type f is expected for sec, which must
contain a positive integer. After the specified time period has passed at the very latest, the program execution continues with the statement following WAIT.
System Fields
sy-subrc Meaning
0 Logical condition log_exp has been complied with.
4 There are no asynchronous function calls.
8 Maximum time exceeded while specifying addition UP TO.
● 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. WAIT must therefore not be used between Open SQL statements that open or close
a database cursor.
● There is also a variant of statement WAIT that can be used independently of asynchronous RFC.
Exceptions
Exceptions that cannot be processed
Cause: Undefined state of the statement WAIT
Runtime error: WAIT_ILLEGAL_CONTROL_BLOCK
Cause: Negative time entry for sec.
Runtime error: WAIT_ILLEGAL_TIME_LIMIT
aRFC Programming Example

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.
1.1.5.3 Transactional RFC (tRFC)
When using transactional RFC (tRFC), the called function module is executed exactly once in the called system (service property: Exactly Once ).
The remote system does not have to be available when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function in the
SAP system database under a unique transaction number (TID), along with the corresponding data.
If a call is sent, and the receiving system is down, the call remains in the local queue. The calling dialog program can proceed without waiting to see whether 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. If you call a function module with the same destination
several times (or several function modules once), you can therefore access the global data for the called function module in the same context.
The system logs the remote call request in database tables ARFCSSTATE and ARFCSDATA with all 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.
Function modules that are called transactionally cannot have any EXPORT parameters in their definition, as a corresponding IMPORTING
parameter in the calling program causes syntax errors.
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 uses the relevant transaction ID (TID) to schedule report RSARFCSE as a background processing variant.
This report, which forwards asynchronous calls for execution, is called repeatedly until it succeeds in connecting with the system in question.
When scheduled in batch, RSARFCSE runs automatically at set intervals (the default setting is for up to 30 attempts at 15 minute intervals). You can customize
this interval and the length of time the program should carry on trying for. 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 . This enables you to set the maximum
number of connection attempts and the intervals at which they are made.
If the system cannot be reached 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 will be deleted (this limit can also
be customized). It is still possible to start this type of entry manually in transaction SM59.
Further 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
Syntax
CALL FUNCTION func IN BACKGROUND TASK
[DESTINATION dest]
parameter list
[AS SEPARATE UNIT].
Addition:
... AS SEPARATE UNIT
Effect
Transactional call of a remote-capable function module specified in func using the RFC interface. You can use the addition DESTINATION to specify an
individual destination in dest. If the destination has not been specified, the destination NONE is used implicitly. Character-type data objects are expected for
func and dest.
When the transactional call is made, the name of the called function, together with the destination and the actual parameters given in parameter list, are
registered for the current SAP LUW in the database tables ARFCSSTATE and ARFCSDATA of the current SAP system under a unique transaction ID (abbreviated
as TID, stored in a structure of type ARFCTID from the ABAP Dictionary, view using transaction SM58). Following this registration, the program making the call is
continued by way of the statement CALL FUNCTION.
When executing the COMMIT WORK statement, the function modules registered for the current SAP LUW are started in the sequence in which they were
registered. The statement ROLLBACK WORKdeletes all previous registrations of the current SAP LUW.
If the specified destination is not available for COMMIT WORK, an executable called RSARFCSE is started in the background. This attempts to start the functional
modules registered for an SAP LUW in their destination, every 15 minutes up to a total of 30 times. You can make changes to these parameters using transaction
SM59. If the destination does not become available within the given time, this is noted in the database table ARFCSDATA as a CPICERR entry. By default, this
entry in database table ARFCSSTATE is deleted after 8 days.
Addition
... AS SEPARATE UNIT
Effect
When using the addition AS SEPARATE UNIT, the relevant function module is executed in a separate context, a context in which the global data of the function
group is not influenced by previous calls. Each function module that is registered with the addition AS SEPARATE UNIT is given a separate transaction ID.
Without the addition AS SEPARATE UNIT, the usual description is applicable for the context of the called function modules. What this means is that, when using
the same destination for multiple calls of function modules belonging to the same function group, the global data of this function group is accessed collectively.
You can use the function module ID_OF_BACKGROUNDTASK to define the transaction ID (TID) of the current SAP LUW, according to a
transactional RFC.
The transactional RFC (tRFC) is suitable for realizing LUWs in distributed environments (a typical application is ALE). Here it must be noted that
although executing the function modules within a transaction ID is predefined, the sequence of the LUWs on the RFC servers does not necessarily
correspond to the sequence of SAP LUWs in the RFC client. To achieve a serialization on the RFC servers as well, the tRFC can be enhanced to
queued RFC ( qRFC). For this, you can call function module TRFC_SET_QUEUE_NAME before a transactional RFC.
CALL FUNCTION - IN BACKGROUND TASK parameter_list

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

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 processed or the time when this happens. 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 .
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 (and outbound queue)
In this scenario, as well as an outbound queue in the sender system (client), there is also an inbound queue in the target system (server). If a qRFC with inbound
queue exists, this always means that an outbound queue exists in the sender system.
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)
Writing Remote Function Modules in ABAP

This section describes how to write function modules that can be called remotely. You can find more general information about writing function modules in the
system documentation on "Writing Function Modules".
This section contains the following topics:
Steps for Implementing Remote Function Modules
Programming Tips
Debugging Remote Function Modules
If required, you can find more detailed information about function modules under:
Function Builder
To view the entire directory tree of the function module documentation, choose Synchronize from the upper left part of the screen. You can
then navigate through the entire function module documentation.
1.2.1 Steps for Implementing Remote Function Modules

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 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), select the Can be called via Remote Function Call field. Registering a module as
remote causes an RFC stub to be generated for it.
3.
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 table RFCDES in transaction SM59 ( Tools ® Administration, Administration ® Network
® RFC Destinations ). For more detailed information, see Maintaining Remote Destinations.
You can then use this destination in your programs to call the function module.
1.2.2 Programming Tips

The following sections describe some points to remember when writing a remote function module.
Declaring Parameters
For normal (non-remote) function modules, if a parameter is not defined like an ABAP Dictionary field, it takes the data type of the actual parameter used at run-
time. However, a remote function module does not have this information available. You therefore need to define all parameter fields in a remote function module as
reference fields, that is, they must refer to an ABAP Dictionary field with LIKE. (This applies to IMPORT, EXPORT, CHANGING and TABLES parameters.)
For character structures or fields, the caller's parameters need not be as long as expected by the called program. When incoming parameters are shorter, RFC
simply pads them with blanks. This means that the ABAP Dictionary definition of character parameters need not be exactly the same on the calling and called
sides. (However, the caller's parameters may not be longer than expected on the called side).
Writing for Transactional Execution
There are two restrictions on writing remote functions that are to be called transactionally.
● Transactional calls cannot return parameter values. As a result, the interface for these functions should not specify any EXPORT parameters.
● Functions that run transactionally may not perform call-backs: the caller's context does not necessarily still exist when the call-back is relayed
back to the original system.
Exceptions
You can trigger exceptions in a remote function just as you would in a locally called function.
Since the system raises COMMUNICATION_FAILURE and SYSTEM_FAILURE internally, there is no reason for you to trigger them in your function module.
Calling Other Remote Functions

A remote function can call other remote functions, just like an ordinary function module.
In particular, it can use the call-back feature to call function modules running in the system of the original caller.
For more detailed information about callbacks between SAP systems, see Calling Remote Functions Back.
1.2.3 Debugging Remote Function Modules

For testing "ABAP-to-ABAP" RFCs, you can use the ABAP Debugger. Here, you can debug the RFC function call 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.

Writing RFC Programs in ABAP

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Writing RFC Programs in ABAP

Загружено:

Авторское право:

Доступные форматы

Writing RFC Programs in ABAP

PDF download from SAP Help Portal:

Created on February 16, 2015

Calling RFC Function Modules in ABAP

Table RFCDES is configured using transaction SM59 ( Remote Destinations ).

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

RFC from a Non-Unicode System into a Unicode System

The Unicode system sends incorrect characters.

The output buffer overflows when the results are returned

by using a replacement character, or by terminating the call.

RFC from a Unicode System into a Non-Unicode System

The non-Unicode system returns incorrect results data.

A text language is unknown.

The receiver buffer in the non-Unicode system overflows.

1.1.4 RFC Exceptions

Using Pre-Defined Exceptions for RFC

Requesting Error Messages

1.1.4.2 Exceptions That Cannot Be Handled

Exceptions That Cannot Be Handled

Runtime Error 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_NO_DEST The specified destination does not exist.

CALL_FUNCTION_OPTION_OVERFLOW Maximum length of options for the destination exceeded .

CALL_FUNCTION_NO_RECEIVER Data received for unknown CPI-C connection.

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.

CALL_FUNCTION_SINGLE_LOGIN_REJ No authorization to log on as Trusted System.

CALL_FUNCTION_TABLE_NO_MEMORY No memory available to import table.

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_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_WRONG_VALUE_LENG Invalid data type during parameter transfer.

CALL_FUNCTION_ILLEGAL_INT_LEN Type conflict while transferring an integer.

CALL_FUNCTION_ILL_FLOAT_FORMAT Type conflict while transferring a floating point number.

CALL_FUNCTION_ILLEGAL_LEAVE Invalid LEAVE statement on RFC server.

CALL_FUNCTION_OBJECT_SIZE Type conflict while transferring a reference.

1. CALL FUNCTION func DESTINATION dest

2. CALL FUNCTION func STARTING NEW TASK task

3. CALL FUNCTION func IN BACKGROUND UNIT

4. CALL FUNCTION func IN BACKGROUND TASK

1.1.5.1 Synchronous RFC (sRFC)

CALL FUNCTION func DESTINATION dest parameter list.

... [EXPORTING p1 = a1 ... pn = an]

1.1.5.2 Asynchronous RFC (aRFC)

The following calling parameters are available:

You must not use IMPORTING parameters when calling aRFCs.

Receiving Results from an Asynchronous RFC

DATA: INFO LIKE RFCSI,

1.1.5.2.3 Keeping Remote Contexts

Parallel Processing with Asynchronous RFC