Calling RFC Function Modules in ABAP

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 remotefunction field can either be a literal or a variable. The field Dest can be either
a literal or a variable: its value is a logical destination (for example, "hw1071_53")
known to the local SAP System. You can define logical destinations in table RFCDES
using transaction SM59, or using the following menu path: Tools Administration 
Administration  Network  RFC Destinations.

Programming guidelines are available in the following topics:

Parameter Handling in Remote Calls

Characteristics Using Unicode

Calling Remote Functions Locally

Calling Remote Functions

CALL FUNCTION - RFC (RFC Variants)

Parameter Handling in Remote Calls

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

TABLES parameters

The actual table is transferred, but not the table header. If a table parameter is not
specified, an empty table is used in the called function.

The RFC uses a delta managing mechanism to minimize network load during parameter
and result passing. Internal ABAP tables can be used as parameters for function module
calls. When a function module is called locally, a parameter tables is transferred “by
reference". This means that you do not have to create a new local copy. RFC does not
support transfer “by reference”. Therefore, the entire table must be transferred back and
forth between the RFC client and the RFC server. When the RFC server receives the table
entries, it creates a local copy of the internal table. Then only delta information is
returned to the RFC client. This information is not returned to the RFC client every time a
table operation occurs, however; instead, all collected delta information is passed on at
once when the function returns to the client.

The first time a table is passed, it is given an object-ID and registered as a "virtual global
table" in the calling system. This registration is kept alive as long as call-backs are
possible between calling and called systems. Thus, if multiple call-backs occur, the
change-log can be passed back and forth to update the local copy, but the table itself need
only be copied once (the first time).

Characteristics Using Unicode

Characteristics Using 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. 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, and the character ‘~’ would have the value 007E,
for example. You can find a list of the Unicode character numbers at
http://www.unicode.org

Default: Ignore errors and replace characters that cannot be converted with the character
‘#’.

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

RFC from a Unicode System into a Non-Unicode System

The following errors may occur:

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.

Calling Remote Functions Locally

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

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

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.
CALL FUNCTION - RFC (RFC Variants)

CALL FUNCTION - RFC (RFC Variants)

Synchronous RFC

1. CALL FUNCTION func DESTINATION dest

parameter_list.

Asynchronous RFC

2. CALL FUNCTION func STARTING NEW TASK task

[DESTINATION {dest|{IN GROUP {group|
DEFAULT}}}]
parameter_list
[{PERFORMING subr}|{CALLING meth} ON END OF
TASK].

Transactional RFC
3. CALL FUNCTION func IN BACKGROUND TASK
[DESTINATION dest]
parameter_list
[AS SEPARATE UNIT].

Effect

Calling a function module or a function using the RFC interface.

Exceptions

Exceptions that cannot be handled

 Cause: The called function module is not released for RFC.

Runtime error: CALL_BACK_ENTRY_NOT_FOUND

 Cause: The type of the destination is not allowed.

Runtime error: CALL_FUNCTION_DEST_TYPE

 Cause: Current function is not called remotely

Runtime error: CALL_FUNCTION_NO_SENDER

 Cause: Missing communication type (I for internal connection, 3 for ABAP) when
executing an asynchronous RFC
Runtime error: CALL_FUNCTION_DESTINATION_NO_T

 Cause: The specified destination does not exist.

Runtime error: CALL_FUNCTION_NO_DEST

  Cause: Maximum length of options for the destination exceeded

Runtime error: CALL_FUNCTION_OPTION_OVERFLOW

 Cause: The specified destination (in load distribution mode) does not exist.
Runtime error: CALL_FUNCTION_NO_LB_DEST

 Cause: Data received for unknown CPI-C connection.

Runtime error: CALL_FUNCTION_NO_RECEIVER

 Cause: The function module being called is not flagged as being "remotely" callable.
Runtime error: CALL_FUNCTION_NOT_REMOTE

 Cause: While executing an RFC, an error occurred that has been logged in the calling
system.
Runtime error: CALL_FUNCTION_REMOTE_ERROR
 Cause: Logon data for the user is incomplete.
Runtime error: CALL_FUNCTION_SIGNON_INCOMPL

 Cause: Logon attempt in the form of an internal call in a target system not allowed
Runtime error: CALL_FUNCTION_SIGNON_INTRUDER

 Cause: RFC from external program without valid user ID

Runtime error: CALL_FUNCTION_SIGNON_INVALID

 Cause: Logon attempt in target system without valid user ID.

Runtime error: CALL_FUNCTION_SIGNON_REJECTED
This error codes may have any of the following meanings:
1) Incorrect password or invalid user ID
2) User locked
3) Too many login attempts
5) Error in authorization buffer (internal error)
6) No external user check
7) Invalid user type
8) Validity period of the user exceeded

 Cause: No authorization to log on as Trusted System.

Runtime error: CALL_FUNCTION_SINGLE_LOGIN_REJ
The error code may have any of the following meanings:
0) Incorrect logon data for valid security ID.
1) Calling system is not a Trusted Systemor security ID is invalid.
2) Either user does not have RFC authorization (authorization object S_RFCACL), or a
logon was performed using one of the protected users DDIC or SAP*.
3) Time stamp of the logon data is invalid.

 Cause: RFC without valid user ID only allowed when calling a system function
module. The meaning of the error codes is the same as for
CALL_FUNCTION_SINGLE_LOGIN_REJ.
Runtime error: CALL_FUNCTION_SYSCALL_ONLY

 Cause: Data error (info internal table) during a 'Remote Function Call'.
Runtime error: CALL_FUNCTION_TABINFO

 Cause: No memory available for table being imported

Runtime error: CALL_FUNCTION_TABLE_NO_MEMORY

 Cause: For asynchronous RFC only: task name is already being used.
Runtime error: CALL_FUNCTION_TASK_IN_USE

 Cause: For asynchronous RFC only: the specified task is already open.
Runtime error: CALL_FUNCTION_TASK_YET_OPEN
 Cause: No RFC authorization
Runtime error: CALL_FUNCTION_NO_AUTH

 Cause: No trusted authorization for RFC caller and trusted system.

Runtime error: CALL_RPERF_SLOGIN_AUTH_ERROR

 Cause: No valid trusted entry for the calling system.

Runtime error: CALL_RPERF_SLOGIN_READ_ERROR

 Cause: No RFC authorization for user.

Runtime error: RFC_NO_AUTHORITY

 Cause: Destination "BACK" is not permitted in current program

Runtime error: CALL_FUNCTION_BACK_REJECTED
Runtime error: CALL_XMLRFC_BACK_REJECTED

 Cause: Error while evaluating RFC destination

Runtime error: CALL_FUNCTION_DEST_SCAN

 Cause: Error while evaluating RFC destination

Runtime error: CALL_FUNCTION_DEST_SCAN

 Cause: Type conflict while transferring table

Runtime error: CALL_FUNCTION_CONFLICT_TAB_TYP

 Cause: No memory available for creating a local internal table.

Runtime error: CALL_FUNCTION_CREATE_TABLE

 Cause: Type conflict while transferring structure

Runtime error: CALL_FUNCTION_UC_STRUCT
Runtime error: CALL_FUNCTION_DEEP_MISMATCH

 Cause: Invalid data type while transferring parameters

Runtime error: CALL_FUNCTION_WRONG_VALUE_LENG
Runtime error: CALL_FUNCTION_PARAMETER_TYPE
Runtime error: CALL_FUNCTION_ILLEGAL_DATA_TYP

 Cause: Type conflict while transferring an integer.

Runtime error: CALL_FUNCTION_ILLEGAL_INT_LEN
Runtime error: CALL_FUNCTION_ILL_INT2_LENG

 Cause: Type conflict while transferring a floating point number

Runtime error: CALL_FUNCTION_ILL_FLOAT_FORMAT
Runtime error: CALL_FUNCTION_ILL_FLOAT_LENG
 Cause: Invalid LEAVE statement on RFC server
Runtime error: CALL_FUNCTION_ILLEGAL_LEAVE

 Cause: Type conflict while transferring a reference

Runtime error: CALL_FUNCTION_OBJECT_SIZE
Runtime error: CALL_FUNCTION_ROT_REGISTER

Using Predefined Exceptions for RFCs

Synchronous RFC (CALL FUNCTION-

DESTINATION)
Syntax

CALL FUNCTION func DESTINATION dest parameter list.

Effect

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

CALL FUNCTION - DESTINATION parameter list

Syntax
... [EXPORTING p1 = a1 ... pn = an]
[IMPORTING p1 = a1 p2 = a2 ...]
[CHANGING p1 = a1 p2 = a2 ...]
[TABLES t1 = itab1 t2 = itab2 ...]
[EXCEPTIONS exc1 = n1 exc2 = n2 ... [MESSAGE mess]
[OTHERS = n_others]].

Effect
These additions are used to assign actual parameters to the formal parameters of the
function module, and return values to exceptions that are not class-based. The additions
have the same meanings as for the general function module call, the only differences
being that, with the addition TABLES, only tables with flat character types can be
transferred, and that if a header line exists, it is not transferred. The additions
EXPORTING, IMPORTING and CHANGING allow you to transfer tables that have deep
character types, deep structures, and strings.

For EXCEPTIONS, you can also specify an optional addition MESSAGE for the special
exceptions SYSTEM_FAILURE and COMMUNICATION_FAILURE. If one of these
exceptions occurs, the first line of the corresponding short dump is entered in the field
mess, which must be flat and of character-type.

Transferring tables using the addition TABLES is considerably faster than using the
other additions, since a binary format is used internally instead of an XML format.

Using Predefined Exceptions for RFCs

Using Pre-Defined Exceptions for RFC

The RFC interface defines two additional exception types:

 SYSTEM_FAILURE

This exception reports all failures and system problems on the remote machine.

 COMMUNICATION_FAILURE

This exception is raised when a connection or communications failure occurs. It does not
report system problems (for example, abnormal termination) that occur on the remote
machine.

Requesting Error Messages

In the function modules that you call, you should use exceptions for any error reporting,
and not the MESSAGE keyword.
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.

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

Using Transactional RFCs

Using Transactional Remote Function Calls

Data can be transferred between two SAP systems reliably and safely using a
transactional RFC (tRFC).

The called function module is executed exactly once in the RFC server system. The
remote system need not be available at the time when the RFC client program is
executing a tRFC. The tRFC component stores the called RFC function together with the
corresponding data in the database of the SAP system, including a unique transaction
identifier (TID).

If a call is sent, and the receiving system is down, the call remains in the local queue until
a later time. The calling dialog program can proceed without waiting to see whether or
not the remote call was successful. If the receiving system does not become active within
a certain amount of time, the call is scheduled to run in batch.

Transactional RFCs use the suffix IN BACKGROUND TASK.

As with synchronous calls, the DESTINATION parameter defines a program context in

the remote system. As a result, if you call a function repeatedly (or different functions
once) at the same destination, the global data for the called functions may be accessed
within the same context.

The system logs the remote call request in the database tables ARFCSSTATE and
ARFCSDATA with all of its parameter values. You can display the log file using
transaction SM58. When the calling program reaches a COMMIT WORK, the remote
call is forwarded to the requested system for execution.

All tRFCs with a single destination that occur between one COMMIT WORK and the
next belong to a single logical unit of work (LUW). For more information on LUWs,
TIDs and on checking the status of transactional calls, see Transactional Integrity of
tRFCs.

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

Function modules that are to be called transactionally, cannot have any EXPORT
parameters in the definition, since an IMPORTING parameter in the calling program
leads to a syntax error.

Note also that you cannot make asynchronous calls to functions that perform call-backs.

When the Remote System is Unavailable

If the remote system is unavailable, the SAP System schedules the report RSARFCSE for
background processing with the relevant transaction ID as variant. This report, which
forwards asynchronous calls for execution, is called repeatedly until it succeeds in
connecting with the desired system.

When scheduled in batch, RSARFCSE runs automatically at set intervals (the default is
every fifteen minutes, for up to 30 attempts). You can customize this interval and the
length of time the program should go on trying. To do this, use the extension programs
SABP0000 and SABP0003 (or see the SAP Extension Concept and CALL CUSTOMER-
FUNCTION).

In transaction SM59 (menu path: Tools  Administration, Administration  Network 

RFC destinations) you can select Destination TRFC options which enables you to
configure each destination. Thus you can determine the number of connection attempts
up to the task and the time between repeat attempts.

If the system is not reachable within the specified amount of time, the system stops
calling RSARFCSE, and the status CPICERR is written to the ARFCSDATA table.
Within another specified time (the default is eight days), the corresponding entry in the
ARFCSSTATE table is deleted (this limit can also be customized). (It is still possible to
start such entries in transaction SM59 manually.)

CALL FUNCTION - IN BACKGROUND TASK

 CALL FUNCTION - IN BACKGROUND TASK
Syntax

CALL FUNCTION func IN BACKGROUND TASK

[DESTINATION dest]
parameter list
[AS SEPARATE UNIT].

Addition:

... AS SEPARATE UNIT

Effect

Transactional call of a remote-capable function module specified in func using the RFC
interface. You can use the addition DESTINATION to specify an individual destination in
dest. If the destination has not been specified, the destination NONE is used implicitly.
Character-type data objects are expected for func and dest.

When the transactional call is made, the name of the called function, together with the
destination and the actual parameters given in parameter list, are registered for the current
SAP LUW in the database tables ARFCSSTATE and ARFCSDATA of the current SAP
system under a unique transaction ID (abbreviated as TID, stored in a structure of type
ARFCTID from the ABAP Dictionary, view using transaction SM58). Following this
registration, the program making the call is continued by way of the statement CALL
FUNCTION.

When executing the COMMIT WORK statement, the function modules registered for
the current SAP LUW are started in the sequence in which they were registered. The
statement ROLLBACK WORKdeletes all previous registrations of the current SAP
LUW.

If the specified destination is not available for COMMIT WORK, an executable called
RSARFCSE is started in the background. This attempts to start the functional modules
registered for an SAP LUW in their destination, every 15 minutes up to a total of 30
times. You can make changes to these parameters using transaction SM59. If the
destination does not become available within the given time, this is noted in the database
table ARFCSDATA as a CPICERR entry. By default, this entry in database table
ARFCSSTATE is deleted after 8 days.
Addition

... AS SEPARATE UNIT

Effect

When using the addition AS SEPARATE UNIT, the relevant function module is executed
in a separate context, a context in which the global data of the function group is not
influenced by previous calls. Each function module that is registered with the addition AS
SEPARATE UNIT is given a separate transaction ID. Without the addition AS
SEPARATE UNIT, the usual description is applicable for the context of the called
function modules. What this means is that, when using the same destination for multiple
calls of function modules belonging to the same function group, the global data of this
function group is accessed collectively.

You can use the function module ID_OF_BACKGROUNDTASK to define the

transaction ID (TID) of the current SAP LUW, according to a transactional RFC.

The transactional RFC (tRFC) is suitable for realizing LUWs in distributed environments
(a typical application is ALE). Here it must be noted that although executing the function
modules within a transaction ID is predefined, the sequence of the LUWs on the RFC
servers does not necessarily correspond to the sequence of SAP LUWs in the RFC client.
To achieve a serialization on the RFC servers as well, the tRFC can be enhanced to
queued RFC (qRFC). For this, you can call function module
TRFC_SET_QUEUE_NAME before a transactional RFC.

CALL FUNCTION - IN BACKGROUND TASK parameter_list

Syntax
... [EXPORTING p1 = a1 p2 = a2... ]
[TABLES t1 = itab1 t2 = itab2 ...] ... .

Effect

These additions are used to assign actual parameters to the formal parameters of the
function module. The significance of the additions is the same as for synchronous RFC
with the exception that no values can be copied with IMPORTING and CHANGING, and
no return values can be allocated to exceptions that are not class-based.
Transactional Integrity of tRFCs

Transactional Integrity of tRFCs

You can execute function modules in background tasks in another SAP system or an
external program. When you call function modules in this way, they are not executed at
once, but wait until a COMMIT WORK is triggered.

Transactional RFCs receive there name from the fact that the associated remote function
call mechanism guarantees transactional integrity for all calls made with the IN
BACKGROUND TASKsuffix. As with database updates, LUWs (logical units of work)
are created for calls that are scheduled to run in background tasks. All tRFCs with a
single destination that occur between one COMMIT WORK and the next belong to a
single LUW. Within a given LUW, all calls:

 execute in the order they were called

 run in the same program context in the target system

 run as a single transaction: they are either committed or rolled back as a unit.

LUWs are identified by transaction IDs that are unique world-wide. The transaction ID
can be determined from an ABAP program by calling function module
ID_OF_BACKGROUNDTASK. (You must call this function after the first asynchronous
CALL, and before the related COMMIT WORK.)

Because the RFC is like a transaction, database operations are either all executed or, if a
function module terminates, all rolled back. If an LUW runs successfully, you cannot
execute it again. In some cases, it may be necessary to program the roll back of an LUW,
(for example, because a table is locked). To do this, you call the function module
RESTART_OF_BACKGROUNDTASK which performs a rollback and ensures that the
LUW is executed again later.

Normally, the LUW is executed immediately after COMMIT WORK in the specified
target system. However, you can also define a certain time at which you want the
execution to be made. To do this, call the function module
START_OF_BACKGROUNDTASK from within the affected LUW after the first
CALL... IN BACKGROUND TASK and before COMMIT WORK.
Checking the Status of Transactional Calls

All transactional RFCs are stored in the tables ARFCSSTATE and ARFCSDATA. Here,
each LUW is identified by a unique ID. When a COMMIT WORK is made, the calls
belonging to this ID are executed in the target system. The system function module
ARFC_DEST_SHIP transports the data to the target system and the function module
ARFC_EXECUTE executes the stored function calls. If an error or an exception occurs
during one of the calls, all the database operations started by the preceding calls are rolled
back and an appropriate error message is written to the file ARFCSSTATE.

There are two methods for checking on the status of a transaction ID:

 From an ABAP program

The function module ID_OF_BACKGROUNDTASK returns the ID of the LUW. You

call this module after the first CALL... IN BACKGROUND TASK and before COMMIT
WORK.

CALL FUNCTION ‘ID_OF_BACKGROUNDTASK’ IMPORTING TASK-ID = TID.

Once you have identified the ID of the LUW, you can use the function module
STATUS_OF_BACKGROUNDTASK to determine the status of the transactional RFC.

CALL FUNCTION ‘STATUS_OF_BACKGROUNDTASK’

EXPORTING TID = TASK-ID

IMPORTING ERRORTAB = ERTAB

EXCEPTIONS = 01
COMMUNICTATION

(Connection not available: will try

again later)

RECORDED = 02

(ARFC is scheduled)

ROLLBACK = 03

(Rollback triggered in target

system)

 Online
Call transaction SM58 (Tools  Administration  Monitoring  Transactional RFC).
This tool lists only those transactonal RFCs that could not be carried out successfully or
that had to be planned as batch jobs. The list includes the LUW ID and an error message.
Error messages displayed in SM58 are taken from the target system. To display the text of
the message, double-click on the message.

Transaction SM58 also lets you control your transactional RFC at various stages. If the
call ends abnormally during the sending process, you may need to use the Rollback LUW
function to manually rollback the LUW before attempting a resend. If the target system
was unavailable, you can use the Backgr.job function to display the batch job created for
your call. Execute funct. module lets you restart the call after the occurrence of a
temporary error (such as a syntax error).

If a LUW runs successfully in the target system, the function module

ARFC_DEST_CONFIRM is triggered and confirms the successful execution in the target
system. Finally, the entries in the Tables ARFCSSTATE and ARFCSDATA are deleted.

RFC API

You can also execute programs asynchronously in 'C'-implemented function modules

(connection type TCP/IP in transaction SM59, see Destination Types). Implementation of
the function modules occurs as usual in connection with the RFC API. This contains the
function modules ARFC_DEST_SHIP and ARFC_DEST_CONFIRM which call the
appropriate functions.

The qRFC Communication Model

The qRFC Communication Model

qRFC Properties and Possible Uses

All types of applications are instructed to communicate with other applications. This
communication may take place within an SAP system, with another SAP system, or with
an application from a remote external system. An interface that can be used for dealing
with this task is the Remote Function Call (RFC). RFCs can be used to start applications
in remote systems, and to execute particular functions.

Whereas the first version of the RFC, the synchronous RFC, (sRFC) required both
systems involved to be active in order to produce a synchronous communication, the
subsequent generations of RFC had a greater range of features at their disposal (such as
serialization, guarantee for one-time-only execution, and that the receiver system does
not have to be available). These features were further enhanced through the queued RFC
with inbound/outbound queue.

Communication between applications within an SAP system and also with a remote
system can basically be achieved using the Remote Function Call (RFC). Here, the
following scenarios are possible:

 Communication between two independent SAP systems

 Communication between a calling SAP system and an external receiving system

 Communication between a calling external system and an SAP receiving system

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

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

Scenario 1: tRFC

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

Scenario 2: qRFC with outbound queue

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

Scenario 3: qRFC with inbound queue (and outbound queue)

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

Properties of the Three Communication Types

To help you decide which communication type you should use in your system landscape
for your requirements, the advantages of the three communication types are listed below:

1. ...
1. 1. tRFC: for independent function modules only
2. 2. qRFC with outbound queue: guarantees that independent function modules
are sent one after each other and one time only (serialization). Suitable for
communication with non-SAP servers.
3. 3. qRFC with inbound queue: in addition to the outbound queue in the client
system, an inbound queue makes sure that only as many function modules are
processed in the target system (server) as the current resources allow. Client and
server system must be SAP systems. One work process is used for each inbound
queue.
4. 4.

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

The qRFC Communication Model

Queued Remote Function Call (qRFC)

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

Using Asynchronous RFCs

Using Asynchronous Remote Function Calls

Asynchronous remote function calls (aRFCs) are similar to transactional RFCs, in that
the user does not have to wait for their completion before continuing the calling dialog.
There are three characteristics, however, that distinguish asynchronous RFCs from
transactional RFCs:

 When the caller starts an asynchronous RFC, the called server must be available to
accept the request.

The parameters of asynchronous RFCs are not logged to the database, but sent directly to
the server.

 Asynchronous RFCs allow the user to carry on an interactive dialog with the remote
system.
 The calling program can receive results from the asynchronous RFC.

You can use asynchronous remote function calls whenever you need to establish
communication with a remote system, but do not want to wait for the 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 (or window). You can then switch back and
for between the calling dialog and the called session

To start a remote function call asynchronously, use the following syntax:

CALL FUNCTION Remotefunction STARTING NEW TASK Taskname

DESTINATION ...

EXPORTING...

TABLES ...

EXCEPTIONS...

The following calling parameters are available:

  TABLES

passes references to internal tables. All table parameters of the function

module must contain values.

  EXPORTING

passes values of fields and field strings from the calling program to the
function module. In the function module, the corresponding formal
parameters are defined as import parameters.

  EXCEPTIONS

See Using Predefined Exceptions for RFCs

RECEIVE RESULTS FROM FUNCTION Remotefunction is used within a FORM

routine to receive the results of an asynchronous remote function call. The following
receiving parameters are available:

  IMPORTING
   TABLES
  EXCEPTIONS

The addition KEEPING TASK prevents an asynchronous connection from being closed
after receiving the results of the processing. The relevant remote context (roll area) is
kept for re-use until the caller terminates the connection.

Details are explained in the following topics:

Calling Requirements for Asynchronous RFCs

Receiving Results from an Asynchronous RFC

Keeping the Remote Context

Parallel Processing with Asynchronous RFC

CALL FUNCTION - STARTING NEW TASK

RECEIVE

WAIT UNTIL

RFC Example

Calling Requirements for Asynchronous RFCs

When you call a remote function with the optional suffix STARTING NEW TASK, the
system starts the function in a new session. Rather than waiting for the remote call to be
completed, the user can resume processing as soon as the function module has been
started in the target system.

The remotely called function module can, for example, display a new screen using CALL
SCREEN, allowing the user to enter a dialog that connects him or her directly to the
remote system:
Client System

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.

You must not use IMPORTING when calling aRFCs.

Receiving Results from an Asynchronous RFC

Receiving Results from an Asynchronous RFC

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 the SET USER-COMMAND ‘OKCD’ statement is exactly
as if the user had entered the function in the command field and pressed
ENTER. This means that the current positioning of the list and the cursor is
taken into account.

No call-backs are supported.

The SET USER-COMMAND ‘OKCD’ statement replaces the REFRESH SCREEN

command. REFRESH SCREEN is no longer maintained and should therefore not be
used.

DATA: INFO LIKE RFCSI,

* Result of RFC_SYSTEM_INFO function module

MSG(80) VALUE SPACE.

* Exception handling

CALL FUNCTION ‘RFC_SYSTEM_INFO’

STARTING NEW TASK ‘INFO’

PERFORMING RETURN_INFO ON END OF TASK

EXCEPTIONS
 COMMUNICATION_FAILURE = 1 MESSAGE MSG

COMMUNICATION_FAILURE = 2.MESSAGE MSG.

IF SY-SUBRC = 0.

WRITE: ‘Wait for reply’.

ELSE.

WRITE MSG

ENDIF.

...

AT USER-COMMAND.

* Return from FORM routine RETURN_INFO via SET USER-COMMAND

IF SY-UCOMM = ‘OKCD’.

IF MSG = SPACE.

WRITE: ‘Destination =‘, INFO-RFCDEST.

ELSE.

WRITE MSG.

ENDIF.

ENDIF.

...

FORM RETURN_INFO USING TASKNAME.

RECEIVE RESULTS FROM FUNCTION ‘RFC_SYSTEM_INFO’

IMPORTING RFCSI_EXPORT = INFO

EXCEPTIONS

COMMUNICATION_FAILURE = 1 MESSAGE MSG

SYSTEM_FAILURE = 2 MESSAGE MSG.

SET USER-COMMAND ‘OKCD’. “Set OK-code

ENDFORM.
Keeping the Remote Context

Keeping the Remote Context

In the FORM routine that checks for results of an asynchronously called function with
RECEIVE RESULTS FROM FUNCTION, the addition KEEPING TASK prevents the
connection from being closed after receiving the results of the processing.

FORM RETURN_INFO USING TASKNAME.

RECEIVE RESULTS FROM FUNCTION ‘RFC_SYSTEM_INFO’

KEEPING TASK

...

ENDFORM.

The relevant remote context (roll area) is kept until the caller terminates the connection.
If you specify the same task name, you can re-use the remote context and roll area.

If the remote function module performs interactive tasks such as processing lists or
dynpros, screens are displayed until the calling program terminates. If the remote call is
made in debugging mode, this mode is visible until the caller dialog is terminated.

You should use the addition KEEPING TASK only if you want to re-use the current
remote context for a subsequent asynchronous call.

Keeping a remote context increases storage load and decreases performance due to
additional roll area management in the system.

Parallel Processing with Asynchronous RFC

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

Parallel-processing is implemented with a special variant of asynchonous RFC. It’s

important that you use only the correct variant for your own parallel processing
applications: the CALL FUNCTION STARTING NEW TASK DESTINATION IN
GROUP keyword. Using other variants of asynchronous RFC circumvents the built-in
safeguards in the correct keyword, and can bring your system to its knees

Details are discussed in the following subsections:

 Prerequisites for Parallel Processing

 Function Modules and ABAP Keywords for Parallel Processing

 Managing Resources in Parallel Processing

Prerequisites for Parallel Processing

Before you implement parallel processing, make sure that your application and your SAP
system meet these requirements:

 Logically-independent units of work:

The data processing task that is to be carried out in parallel must be logically independent
of other instances of the task. That is, the task can be carried out without reference to
other records from the same data set that are also being processed in parallel, and the task
is not dependent upon the results of others of the parallel operations. For example,
parallel processing is not suitable for data that must be sequentially processed or in which
the processing of one data item is dependent upon the processing of another item of the
data.

By definition, there is no guarantee that data will be processed in a particular order in

parallel processing or that a particular result will be available at a given point in
processing.

 ABAP requirements:
   The function module that you call must be marked as externally callable. This
attribute is specified in the Remote function call supported field in the function
module definition (transaction SE37).
  The called function module may not include a function call to the destination
“BACK.”
  The calling program should not change to a new internal session after making
an asynchronous RFC call. That is, you should not use SUBMIT or CALL
TRANSACTION in such a report after using CALL FUNCTION STARTING
NEW TASK.
  You cannot use the CALL FUNCTION STARTING NEW TASK
DESTINATION IN GROUP keyword to start external programs.

 System resources:

In order to process tasks from parallel jobs, a server in your SAP system must have at
least 3 dialog work processes. It must also meet the workload criteria of the parallel
processing system: Dispatcher queue less than 10% full, at least one dialog work process
free for processing tasks from the parallel job.

Function Modules and ABAP Keywords for Parallel Processing

You can implement parallel processing in your applications by using the following
function modules and ABAP keywords:

 SPBT_INITIALIZE: Optional function module.

Use to determine the availability of resources for parallel processing.

You can do the following:

  check that the parallel processing group that you have specified is correct.
  find out how many work processes are available so that you can more
efficiently size the packets of data that are to be processed in your data.

 CALL FUNCTION Remotefunction STARTING NEW TASK Taskname

DESTINATION IN GROUP:

With this ABAP statement, you are telling the SAP system to process function module
calls in parallel. Typically, you’ll place this keyword in a loop in which you divide up the
data that is to be processed into work packets. You can pass the data that is to be
processed in the form of an internal table (EXPORT, TABLE arguments). The keyword
implements parallel processing by dispatching asynchronous RFC calls to the servers that
are available in the RFC server group specified for the processing.

Note that your RFC calls with CALL FUNCTION are processed in work processes of
type DIALOG. The DIALOG limit on processing of one dialog step (by default 300
seconds, system profile parameter rdisp/max_wprun_time) applies to these RFC calls.
Keep this limit in mind when you divide up data for parallel processing calls.

 SPBT_GET_PP_DESTINATION: Optional function module.

Call immediately after the CALL FUNCTION keyword to get the name of the server on
which the parallel processing task will be run.

 SPBT_DO_NOT_USE_SERVER: Optional function module.

Excludes a particular server from further use for processing parallel processing tasks. Use
in conjunction with SPBT_GET_PP_DESTINATION if you determine that a particular
server is not available for parallel processing (for example, COMMUNICATION
FAILURE exception if a server becomes unavailable).

 WAIT: ABAP keyword

WAIT UNTIL <logical expression>

Required if you wish to wait for all of the asynchronous parallel tasks created with CALL
FUNCTION to return. This is normally a requirement for orderly background processing.
May be used only if the CALL FUNCTION includes the PERFORMING ON RETURN
addition.

 RECEIVE: ABAP keyword

RECEIVE RESULTS FROM FUNCTION Remotefunction

Required if you wish to receive the results of the processing of an asynchronous RFC.
RECEIVE retrieves IMPORT and TABLE parameters as well as messages and return
codes.

Managing Resources in Parallel Processing

You use the following destination additions to perform parallel execution of function
modules (asynchronous calls) in the SAP system:

In a predefined group of application servers:

CALL FUNCTION Remotefunction STARTING NEW TASK Taskname

DESTINATION IN GROUP Groupname

In all currently available and active application servers:

CALL FUNCTION Remotefunction STARTING NEW TASK Taskname

DESTINATION IN GROUP DEFAULT

The addition first determines the amount of resources (work processes) currently
available (i.e. in all servers or in a group of application servers, comparable with login
servers). The resources available for executing asynchronous calls on each application
server depends on the current system load.

The applications developer is responsible for the availability of RFC groups in the
production system (i.e. the customer's system). For details on how to maintain the RFC
groups, see Maintaining Group Destinations For Load Distribution.

After determining the available resources, the asynchronous call is executed in an

available application server. If no resources are available at that particular time, the
system executes the exception routine RESOURCE_FAILURE (see the addition
Exceptions). In the case of an asynchronous function module call, this exception must be
handled by the application program.

The process for determining available resources in an RFC group is as follows:

First, the system determines the length of the dispatcher queue for the relevant
application server. If it is greater than 10% of the overall length, the server makes no
resources available. If it is smaller, the system makes available the current number of free
dialog processes minus 2 (as a reserve instance for other purposes, e.g. for logon to the
system or administration programs). Thus, one application server must have at least 3
dialog processes if RFC parallel processing is taken into account.

  At present, only one RFC group per program environment is supported

for parallel execution of asynchronous calls. Using both additions
(DESTINATION IN GROUP Groupname and DESTINATION IN GROUP
DEFAULT) in one program is not allowed.
  The exception routine RESOURCE_FAILURE is only triggered in
connection with asynchronous RFCs with the additions DESTINATION IN
GROUP Groupname and DESTINATION IN GROUP DEFAULT.

You are recommended (for performance and other reasons) to use an RFC
group with sufficient resources for parallel processing of asynchronous
calls

Continue with the following section:

CALL FUNCTION - STARTING NEW TASK

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

[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

RECEIVE

Syntax

RECEIVE RESULTS FROM FUNCTION func

parameter list
[KEEPING TASK].

Addition:

... KEEPING TASK

Effect

This statement can be used in a callback routine specified for the asynchronous RFC, in
order to receive output parameters of an asynchronously called function func in the
parameter list parameter list, and to assign return values to exceptions.

If a function module is started multiple times in a row using asynchronous RFC, the
execuction sequence is not fixed, instead it depends in the system availability.

Addition

... KEEPING TASK

Effect

With the addition KEEPING TASK, the asynchronous RFC connection is retained, as is
the context of the called function module along with it. When a new call is made with the
same task ID, the same global data of the function group is addressed. Without the
addition KEEPING TASK, an asynchronous RFC connection is finished after the remote
function is executed or the results are copied.

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

RECEIVE - parameter_list

Syntax
... [IMPORTING p1 = a1 p2 = a2 ...]
[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
 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 The logical condition log_exp was fulfilled.
4 No asynchronous function calls exist.
Maximum time exceeded while specifying the addition
8
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. For this
reason, WAIT must not be used between Open SQL statements that open or close a
database cursor.

 There is also one variant of the statement WAIT that can be used independently of
the asynchronous RFC.

Exceptions
Exceptions that cannot be processed
 Cause: Undefined state of the statement WAIT
Runtime error: WAIT_ILLEGAL_CONTROL_BLOCK
 Cause: Negative time entry for sec.
Runtime error: WAIT_ILLEGAL_TIME_LIMIT

RFC Example

RFC Example
Parallel, asynchronous processing of the function module RFC_SYSTEM_INFO using
asynchronous Remote Function Calls. Ten calls are made, each occurring in separate
work processes due to them having different task IDs name. In the callback routine
rfc_info, the completed function modules are counted, and information about the target
system is received.
Through using the addition GROUP DEFAULT, the execution is distributed across all
application servers of the current system. If no more free work processes are available
after at least one successful call, the execution of the program is stopped until all function
modules started up to that point have been completed. This stoppage is limited to a
maximum of 5 seconds.

After all function modules have been started, the system waits until all callback routines
have been executed. After that, the internal table task_list filled there is output. The
output shows the sequence in which the individual tasks completed, and on which
application server each of them was executed.

TYPES: BEGIN OF task_type,

name TYPE string,
dest TYPE string,
END OF task_type.

DATA: snd_jobs TYPE i,

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

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

WAIT UNTIL rcv_jobs >= snd_jobs.

LOOP AT task_list INTO task_wa.
WRITE: / task_wa-name, task_wa-dest.
ENDLOOP.

FORM rfc_info USING name.

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

Writing Remote Function Modules in ABAP

Writing Remote Function Modules in ABAP

This section provides specifics on writing function modules that can be called remotely.
For information about writing function modules generally, see the system documentation
on "Writing Function Modules".

This section contains the following topics:

Steps for Implementing Remote Function Modules

Programming Help
 Debugging Remote Function Modules

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

Function Builder

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

Steps for Implementing Remote Function Modules

To implement a remote function module in ABAP, perform the following steps:

2. ...
5. 1. Write the code for the function module.

For guidelines for creating function modules in the Application Server ABAP Repository,
see: Function Builder

6. 2. Register the module as remotely callable in the RFC server system.

In the function module Administration screen (transaction code SE37), set the field Can
be called via Remote Function Call. Registering a module as remote causes an RFC stub
to be generated for it.

7. 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 the RFCDES table using
transaction SM59 (Tools Administration, Administration Network RFC
destinations). For more detailed information, see Maintaining Remote Destinations.

You can then use this destination in your programs to call the function module.

Programming Tips

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

Declaring Parameters

For normal (non-remote) function modules, if a parameter is not defined like an ABAP
Dictionary field, it takes the data type of the actual parameter used at run-time. A remote
function module, however, does not have this information available. As a result, all
parameter fields for a remote function module must be defined as reference fields, that is,
like ABAP Dictionary fields. (This applies to IMPORT, EXPORT, CHANGING and
TABLES parameters.)

For character structures or fields, the caller's parameters need not be as long as expected
by the called program. When incoming parameters are shorter, RFC simply pads them
with blanks. This means that the ABAP Dictionary definition of character parameters
need not be exactly the same on the calling and called sides. (However, the caller's
parameters may not be longer than expected on the called side).
Writing for Transactional Execution

There are two restrictions on writing remote functions that are to be called
transactionally:

 ● Transactional calls cannot return parameter values. As a result, the

interface for these functions should not specify any EXPORT parameters.
 ● Functions that run transactionally may not perform call-backs: the
caller's context does not necessarily still exist when the call-back is
relayed back to the original system.

Exceptions

You can trigger exceptions in a remote function just as you would in a locally called
function.

Since the system raises COMMUNICATION_FAILURE and SYSTEM_FAILURE

internally, there is no reason for you to trigger them in your function module.

Calling Other Remote Functions

A remote function can call other remote functions, just like an ordinary function module.

In particular, it can use the call-back feature to call function modules running in the
system of the original caller.

For more detailed information about callbacks between SAP systems, see Calling Remote
Functions Back.

Debugging Remote Function Modules

 Debugging Remote Function Modules
For testing "ABAP-to-ABAP" RFCs, you can use the ABAP Debugger. Here, you can
debug the execution of the RFC function in the remote system. Static breakpoints, single-
stepping, variable-watching and source display are possible.

With remote calls, the ABAP debugger (including the debugging interface) runs on the
local system. Data values and other run information for the remote function are passed in
from the remote system.

Continue with the following section:

Maintaining Remote Destinations

Maintaining Remote Destinations

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

For more details, see the following sections:

 Displaying, Maintaining and Testing Destinations

 Entering Destination Parameters

 Destination Types

 Maintaining Group Destinations

 Settings for Special Code Pages

 Trusted System: Trust Relationships Between SAP Systems

 Displaying, Maintaining, and Testing Destinations
To display, create, or change destinations, choose the following from the SAP menu:
Tools  Administration  Administration Network RFC Destinations
(transaction SM59).

Remote destinations are stored in the table RFCDES. The table RFCDES describes
logical destinations for remote function calls (RFCs). You cannot maintain the table
RFCDES directly.

Displaying Destinations

The initial screen shows a tree which that allows you to select different connection types
(such as partner systems or partner programs). For more information, see Destination
Types.

To find a destination, choose Find and enter your selection criteria. A list of suitable
entries is displayed. You can display all the available information for each entry.

Creating Destinations

On the initial screen for destinations, the connection types and all existing destinations
are displayed in a tree structure.

For an explanation of the available connection types, see Destination Types.

To create a new RFC destination, choose Create. A new screen is displayed with empty
fields in which you make entries.

If you are creating a remote destination, you can enter one particular application server,
or a group of servers to distribute system load.

For more detailed information on destination parameters, see Entering Destination

Parameters.
Changing Existing Destinations

On the initial screen for destinations (transaction SM59), the connection types and all
existing destinations are displayed in a tree structure.

To change an existing RFC destination, choose Change.

For more detailed information on destination parameters, see Entering Destination

Parameters.

Testing Destinations

To test a destination, choose the required function from the Test menu.

 Connection (also a pushbutton)

 Authorization (checks logon data)

 Network of Application Servers(returns a list of application servers)

Destination Types
Each destination has a connection-type field (Connection type) that indicates the system
connection type:

● R/2 Connections (Type 2)

Type 2 entries indicate R/2 systems. No further specification is required. When you create
a type 2 entry, therefore, you only need to specify the host name. All communications
information is already stored in the background info table in the SAP Gateway host. If
you want, you can also specify logon information.

Example entry name: K50

● ABAP Connections (Type 2)

Type 3 entries indicate ABAP systems. When you create a type 3 entry, you need to
specify the host name and communication service. If you want, you can also specify
logon information. As of Release 3.0, you can also select the load-balancing option.

You can specify an application server from the ABAP message server. The application
server is then determined according to the load-balancing process. This applies to RFCs
between two ABAP systems and to RFCs between an ABAP system and an external
system.

Example entry name: K11

● Internal Connections (Type I)

Type I entries indicate ABAP systems connected to the same data base as the current
system. These entries are pre-defined and cannot be modified. The entry names are the
same as those used in the SAP Message Server (transaction SM51)

Example entry name: hs0010_K11_24

 ○ hs0010=host name
 ○ K11=system name (database name)
 ○ 24=TCP-service name

● Logical Destinations (Type L)

Instead of indicating a system connection, type L (logical) entries refer to a physical

destination. Type L destinations can also refer to other type L entries. A type L entry uses
the information in the reference entry and adds further information of its own. Normally,
the reference entry contains the host information, while the type-L entry contains logon
data. You can also specify a user name, an explicit password, a logon language or an
explicit client.

A type L entry can refer to other type L entries.

Example entry name: K11_SD or K11_01

 ○ K11=name of RFCDES entry for ABAP system K11

 ○ SD or 01: for the fields User='SD_INPUT' or client='001'

● Connections via ABAP Driver (Type X)

Type X entries indicate systems where device drivers in ABAP have been specially
installed. When you create a type X entry, you need to specify the name of the ABAP
device driver.
● TCP/IP Connections (Type T)

Type T destinations are connections to external programs that use the RFC library to
receive RFCs. The activation type can be either Start or Registration.

If it is Start, you need to specify the host name and the path name of the program that you
want to start.

Activation Type Start

The communication method depends on how you select the program location:

 ○ Explicit host
In this case, the program is started either by the default gateway for the system or
by the explicitly specified gateway (gwrd) via remote shell.
Ensure that the computer with the gateway process can access the specified
computer by entering /etc/ping <host name>.
If you want to start a program on another computer using the remote shell, the
target system must meet certain conditions.
 The user ID of the gateway process must exist, and the user’s directory
must contain a file called .rhosts.
 The file .rhosts must contain the name of the calling computer.
To check this, log on to the computer containing the gateway process with the
appropriate user ID and enter the command remsh <host name> <program name>.
The <host name> and <program name> must be the same as in SM59 . (If you
call an RFC server program without any parameters, the RfcAccept call always
returns an error code (RFC_HANDLE_NULL), and the program terminates
immediately.)
 ○ Application Server
When choosing Application server and specifying your program, you can start the
program from the SAP application server.
First, ensure that the program can be accessed from the SAP application server
and that the SAP application server has the authorization to start the program.
To check this, log on with the user ID of the SAP application server (e.g.
c11adm). If possible, change to the working directory of the SAP application
server (/usr/sap/.../D.../work) and try to start the RFC server program manually
from there. (If you call an RFC server program without any parameters, the
RfcAccept call always returns an error code (RFC_HANDLE_NULL), and the
program terminates immediately.)
 ○ Front-End Workstation
When choosing Front-end workstation and specifying your program, you can start
the program from the SAPGUI.
Ensure that you can access the program with SAPGUI.
 Ensure that SAPGUI has the authorization to start the program.
To check this, simply call the RFC server program in your environment.
The function call can also be transactional (CALL FUNCTION... IN
BACKGROUND TASK DESTINATION...).

Activation Type Registration

If the activation type is Registration, you have to identify a registered RFC program.
With an SAP gateway, you can register an RFC server program under this ID and then
wait for RFC calls from other SAP Systems.

Example entry name: SERVER_EXEC

● Type M

Type M entries are asynchronous RFC connections to ABAP systems via CMC (protocol
X.400).

● Type S

Type S corresponds to type 2, except that the destination is SNA or APPC.

HTTP Connection to Ext. Server (Connection Type G)

Select the connection you require. You can choose from the following logon procedures:

● No logon. The server program does not require you to enter a user or password.

● Basic Authentication. The server program requires you to enter a user and
password. Basic Authentication is a standard HTTP authentication method. When the
user logs on to the target system, a user ID and a password are provided for
authentication. This information is then transmitted across the HTTP connection to the
server, in the form of a base64 encoded string in a header variable.

● SSL Client Certificate. If you use client certificates for the authentication,
the client authentication is performed using the Secure Sockets Layer (SSL) protocol. In
this instance, you also have to select the SSL client PSE of the Application Server, which
contains the certificate that is to be used for the authentication. The target system must
treat the system that issues the client certificate of the SAP NW AS as a “trusted” system.

●
On the Logon/Security tab page, you can also activate SSL, so that HTTPS is used
as a protocol (you must then make sure that the correct port is set under Technical
Settings). To define which type of SSL client is used, call the security transaction
STRUST. ( Getting Started with the Trust Manager, Trust Manager).

As an additional protective measure, the field Authorization for Destination

has been introduced. We recommend that you specify a user and a password for the RFC
destination.

HTTP Connection to an ABAP System (Connection Type H)

Here you have a variety of options for authentication in the target system.

The settings on the Technical Settings and Special Options tab pages are
identical to those of connection type G. On the Logon/Security tab page, connection
type H has additional logon processes compared to connection type G. As with the
external server, you can (de)activate SSL and specify an authorization.

As the destination system is an SAP System, you can set the client and language for the
logon as well as the user name and password. If you check Current User, you have
to specify the password again.

The options available for the authentication are Basic Authentication, SAP
Standard, SAP Trusted System and SSL Client Certificate.

● HTTP Basic Authentication: Logon using user and password.

● SAP Standard: This method uses a logon like the RFC logon processes. Here, the RFC
Single Sign-On procedures within a system also apply. The same SAP user (client,
language, and user name) is used for logon.

● SAP Trusted System: Trusted RFC logon to another SAP system (see: Trusted System:
Trust Relationships Between SAP Systems).

● SSL Client Certificate: Using the SSL protocol, the logon can be made using client
certificates.

Maintaining Group Destinations

 Maintaining Group Destinations
To achieve a balanced load distribution in the target system, you must define a group of
application servers as an RFC destination. When processing tasks in parallel, you can use
the group destination only in connection with the asynchronous RFC.

The resources available on each application server depends on the current system load.

To display and maintain the RFC groups, proceed as follows:

3. .
4.
8. 1. Call transaction SM59.
9. 2. From the RFC destination overview screen, choose RFC  RFC groups.

You then see:

  the names of any RFC groups that have already been defined
  a list of the instances (host, system and instance number) in your SAP system
  the current status (active or not) of each server.
10. 3. To define an RFC group, choose Edit  Create. Enter a server group name
and an instance in the dialog window.

To add instances to an existing group, double click the group name and enter a new
instance in the dialog window.

By creating duplicate entries, you can assign a server to more than one group. In this
case, jobs that use the group will compete for free work processes on the shared server(s).

Usage examples:

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

Settings for Special Code Pages

Settings for Special Code Pages

In Unicode systems, you configure the conversion of text data for the RFC destinations
on the tab page Special Options. Here, F1 help is available for you to get more
information. You can configure the following:

Character Width in Target System

Here you specify whether the RFC destination is a Unicode system or a non-Unicode
(MDMP) system. A pushbutton gets this information from the target system.

MDMP Setting for Non-Unicode Destinations

For non-Unicode destinations, the RFC either uses a preconfigured assignment of

languages to code pages that is the same for all destinations, or an assignment which can
be maintained for the destination; at the push of a button you can get the assignment list
of the destination system by way of RFC.

Character Conversion

Here you define how conversion errors are handled:

 The RFC terminates when conversion errors occur, or continues despite conversion
errors, whereby non-convertible characters are replaced with replacement characters.

 The RFC replaces non-convertible characters with the replacement character ‘#’.
 The RFC replaces non-convertible characters with another character that you can
choose.

Preconfigured Code Pages

The RFC uses a preconfigured assignment of text languages to code pages if:

 The destination is set to non-Unicode and MDMP inactive.

 A non-Unicode system calls a function in a Unicode system and does not make
known its assignment list; this is true for systems with kernel older than Release 6.20,
Patch level 375. More recent systems transmit their assignment list to the called Unicode
system, meaning that the preconfiguration is not required.

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

Transport Code Page:

Language (ISO, SAP ID): Non EBCDIC
EBCDIC
West European languages 1100 0120
East European languages 1401 0410
Baltic languages 1900 0120
Japanese (JA, J) 8000
Chinese (ZH, 1) 8400
Korean (KO, 3) 8500
Arabic (AR, A) 8700
Taiwanese (ZF, M) 8300
Thai (TH, 2) 8600 0860
Ukrainian (UK, 8) 1500 0500
Hebrew (HE, B) 1800 0800
Greek (EL, G) 1700 0700
Russian (RU, R) 1500 0500
Turkish (TR, T) 1610 0610
Bulgarian (BG, W) 1500 0500
This table applies to standard transport code pages that are based on ISO standards (such
as 1100, ISO8859-1) or country-specific standards (such as 8000, SJIS). If SAP’s own
code pages are used as transport code pages, then the following assignment applies:

Transport Code Page: Examples Assigned Code Page:

SAP blended 6100 SAP Standard code page depending on text
ambiguous Unification language.
6200 Asian Data is therefore reinterpreted uniquely,
Unification language-dependently.
6500 Diocletian
SAP blended 6300 Euro Japan The same code page.
unambiguous Data is already coded uniquely.
Transliteration 1180 1180.
Data is already coded uniquely.

Trusted System: Trust Relationships Between SAP Systems

Trusted System: Trust Relationships Between SAP

Systems

SAP systems may establish trusted relationships between each other.

If a calling SAP system is known to the called system as a trusted system, no password
must be supplied.

The calling SAP system must be registered with the called SAP system as a trusted
system. The called system is called the trusting system.
 Trust relationships between SAP systems have the following advantages:

 Single Sign-On is possible beyond system boundaries.

 No passwords are transmitted in the network.

 Timeout mechanism protects against replay attacks.

 User-specific logon data are checked in the trusting system.

Using this feature, you can create a virtual SAP system consisting of various SAP
systems that are called remotely. Remote logon data are checked in the trusting system.

The trust relationship is not mutual, which means, it applies to one direction only. To
establish a mutual trust relationship between two partner systems, you must define each
of the two as trusted systems in its respective partner system.

For additional security, you can make use of SAP’s SNC interface (Secure Network
Communications) for third-party security systems such as Kerberos and SECUDE.

Displaying, Maintaining and Testing Trusted Systems

To display or maintain a trusted system in the trusting system, proceed as follows:

11. 1. If you want to define an SAP system as a trusted system, you must first
create a logical destination that allows a trusted system relationship.
12. 2. From the RFC destination overview screen (transaction SM59), choose
RFC  Trusted systems or enter transaction code SMT1.
13. 3. If trusted systems have already been defined, they are displayed in a
hierarchy tree. To display existing trusted systems, expand the nodes in the hierarchy
tree.
14. 4. To create a trusted system, click the Create icon.
15. 5. In the dialog window, enter the destination for the remote system. To
change a destination, see Changing Trusted Destinations below.
16. 6. All the necessary information such as application server name and
security key is supplied automatically.
17. 7. If you want to restrict the validity period of the logon data, enter an end
date in the Validity period field.
18. 8. If you want take over the transaction code of the calling program into the
called system, mark the appropriate checkbox.
19. 9. Only then will an authorization check be performed in the called system
for the transaction code (field RFC_TCODE of the S_RFCACL authorization object,
see Logon Authorization Checks in the Trusting System below).
 As you delete a trusted system relationship, the logon screen of the relevant system is
displayed, if no valid logon data are provided. You must log on to that system to complete
the deletion.

Changing Trusted Destinations

You can change existing destinations for each system from the trusted system
maintenance screen (RFC  Trusted systems, transaction code SMT1) by clicking on the
Maintain destination pushbutton.

In trusted systems, destinations for trusting systems are automatically created. These
destinations are used when you display trusting systems via RFC  Trusting systems
(transaction code SMT2).

To prevent others from making changes to your trusted destination, mark the checkbox
Destination not changeable in the Attributes section. To make the destination changeable
again, double-click the checkbox.

Note that destinations must be kept consistent. For this reason, you are not allowed to
change the ID of the target system, the system number, or the destination name.

Displaying Trusting Systems

In a trusted system, you can obtain a list of all trusting systems. Choose RFC  Trusting
systems to display the list of trusting systems.

Click on the name of a trusting system to display the application servers of that system.
The application server names contain the suffix _TRUSTED.

Double-clicking the name of an application server displays a dialog box, in which you
can enter the transaction that you want to execute in the trusting system. You can also
specify whether the transaction is to be executed in the same session, or in a new one.

Logon Authorization Checks in the Trusting System

The logon data used for logging on to a trusting system undergo an authorization check.

The data provided by the trusted system is checked for system name, client, user name,
and other optional data. These data must match the field values of authorization object
S_RFCACL.
The system administrator can check a user’s logon data using the function module
AUTHORITY_CHECK_TRUSTED_SYSTEM.

Error return codes are explained in the Troubleshooting section below.

Testing Trusting Systems

To test a trusted system, you can perform the authorization checks for the current server
and the trusting system. To do this, choose the menu entry. If no valid logon data are
supplied, the logon screen of the trusted systems appears. You should log on to the
system. If your test is not successful, read the section Troubleshooting in
Trusted/Trusting Systems below.

Troubleshooting in Trusted/Trusting Systems

After creating a trusted system, you have to test the destination. To do this, log on to the
trusted system using remote login.

Alternatively, you can also perform an authorization check for the trusted server. To do
this, select the respective function from the test menu.

If your login attempt fails, you will receive the following message: No authorization to
log in as trusted system (error code = <0|1|2|3>). Note that the special users DDIC and
SAP* must not be used.

The error code explanation is as follows:

 Invalid login data (user ID and client) for the trusting system

 Solution: Create the user ID for the client in the trusting system.

 No trusted system entry exists for the calling system, or the security key for the
system is invalid.

 Solution: Create the trusted system entry again.

 The user does not have a trusted system authorization (object S_RFCACL).

 Solution: Provide the user with the necessary authorization.

 The time stamp of the login data is invalid.

 Solution: Check the clock settings on both the client and server host and the
expiration date of the login data. (Note that the default expiration period 00:00:00 means
no limit.)
You can check whether correct login information has been provided for the trusted
system in the trusting system by means of the function module
AUTHORITY_CHECK_TRUSTED_SYSTEM.

If all your tests are successful and you still don’t get access to the trusting system, refresh
the relevant database by choosing Environment  Mass changes Reset all buffers
from the user maintenance screen.

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

For more detailed information and practical tips for trusted/trusting relationships, see:

Trusted/Trusting Relationships between SAP Systems

Trusted System: Trust Relationships Between SAP

Systems

SAP systems may establish trusted relationships between each other.

If a calling SAP system is known to the called system as a trusted system, no password
must be supplied.

The calling SAP system must be registered with the called SAP system as a trusted
system. The called system is called the trusting system.

Trust relationships between SAP systems have the following advantages:

  Single Sign-On is possible beyond system boundaries.

 No passwords are transmitted in the network.

 Timeout mechanism protects against replay attacks.

 User-specific logon data are checked in the trusting system.

Using this feature, you can create a virtual SAP system consisting of various SAP
systems that are called remotely. Remote logon data are checked in the trusting system.

The trust relationship is not mutual, which means, it applies to one direction only. To
establish a mutual trust relationship between two partner systems, you must define each
of the two as trusted systems in its respective partner system.

For additional security, you can make use of SAP’s SNC interface (Secure Network
Communications) for third-party security systems such as Kerberos and SECUDE.

Displaying, Maintaining and Testing Trusted Systems

To display or maintain a trusted system in the trusting system, proceed as follows:

20. 1. If you want to define an SAP system as a trusted system, you must first
create a logical destination that allows a trusted system relationship.
21. 2. From the RFC destination overview screen (transaction SM59), choose
RFC  Trusted systems or enter transaction code SMT1.
22. 3. If trusted systems have already been defined, they are displayed in a
hierarchy tree. To display existing trusted systems, expand the nodes in the hierarchy
tree.
23. 4. To create a trusted system, click the Create icon.
24. 5. In the dialog window, enter the destination for the remote system. To
change a destination, see Changing Trusted Destinations below.
25. 6. All the necessary information such as application server name and
security key is supplied automatically.
26. 7. If you want to restrict the validity period of the logon data, enter an end
date in the Validity period field.
27. 8. If you want take over the transaction code of the calling program into the
called system, mark the appropriate checkbox.
28. 9. Only then will an authorization check be performed in the called system
for the transaction code (field RFC_TCODE of the S_RFCACL authorization object,
see Logon Authorization Checks in the Trusting System below).
 As you delete a trusted system relationship, the logon screen of the relevant system is
displayed, if no valid logon data are provided. You must log on to that system to complete
the deletion.

Changing Trusted Destinations

You can change existing destinations for each system from the trusted system
maintenance screen (RFC  Trusted systems, transaction code SMT1) by clicking on the
Maintain destination pushbutton.

In trusted systems, destinations for trusting systems are automatically created. These
destinations are used when you display trusting systems via RFC  Trusting systems
(transaction code SMT2).

To prevent others from making changes to your trusted destination, mark the checkbox
Destination not changeable in the Attributes section. To make the destination changeable
again, double-click the checkbox.

Note that destinations must be kept consistent. For this reason, you are not allowed to
change the ID of the target system, the system number, or the destination name.

Displaying Trusting Systems

In a trusted system, you can obtain a list of all trusting systems. Choose RFC  Trusting
systems to display the list of trusting systems.

Click on the name of a trusting system to display the application servers of that system.
The application server names contain the suffix _TRUSTED.

Double-clicking the name of an application server displays a dialog box, in which you
can enter the transaction that you want to execute in the trusting system. You can also
specify whether the transaction is to be executed in the same session, or in a new one.

Logon Authorization Checks in the Trusting System

The logon data used for logging on to a trusting system undergo an authorization check.

The data provided by the trusted system is checked for system name, client, user name,
and other optional data. These data must match the field values of authorization object
S_RFCACL.

The system administrator can check a user’s logon data using the function module
AUTHORITY_CHECK_TRUSTED_SYSTEM.
Error return codes are explained in the Troubleshooting section below.

Testing Trusting Systems

To test a trusted system, you can perform the authorization checks for the current server
and the trusting system. To do this, choose the menu entry. If no valid logon data are
supplied, the logon screen of the trusted systems appears. You should log on to the
system. If your test is not successful, read the section Troubleshooting in
Trusted/Trusting Systems below.

Troubleshooting in Trusted/Trusting Systems

After creating a trusted system, you have to test the destination. To do this, log on to the
trusted system using remote login.

Alternatively, you can also perform an authorization check for the trusted server. To do
this, select the respective function from the test menu.

If your login attempt fails, you will receive the following message: No authorization to
log in as trusted system (error code = <0|1|2|3>). Note that the special users DDIC and
SAP* must not be used.

The error code explanation is as follows:

 Invalid login data (user ID and client) for the trusting system

 Solution: Create the user ID for the client in the trusting system.

 No trusted system entry exists for the calling system, or the security key for the
system is invalid.

 Solution: Create the trusted system entry again.

 The user does not have a trusted system authorization (object S_RFCACL).

 Solution: Provide the user with the necessary authorization.

 The time stamp of the login data is invalid.

 Solution: Check the clock settings on both the client and server host and the
expiration date of the login data. (Note that the default expiration period 00:00:00 means
no limit.)
You can check whether correct login information has been provided for the trusted
system in the trusting system by means of the function module
AUTHORITY_CHECK_TRUSTED_SYSTEM.

If all your tests are successful and you still don’t get access to the trusting system, refresh
the relevant database by choosing Environment  Mass changes Reset all buffers
from the user maintenance screen.

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

For more detailed information and practical tips for trusted/trusting relationships, see:

Trusted/Trusting Relationships Between SAP Systems

Trusted/Trusting Relationships Between SAP

Systems
Using an RFC trusted/trusting relationship between two SAP systems has the effect that,
in the case of an RFC from a trusted system to a trusting system, passwords are no longer
sent for logging on to the trusting system. However, the user being used for the logon
must have the corresponding authorization object S_RFCACL in the trusting system. The
trusted system always corresponds to the RFC client role, and the trusting system to the
RFC server role.

Solution

Building a trusted/trusting relationship:

A trusted/trusting relationship must always be built starting from the trusting system
(server). The following describes the individual steps for defining a trusted/trusting
relationship of the trusted system C00 (client) to trusting system S00 (server):

Log on to the trusting system S00 (server). Here, create a destination for the trusted
system C00 (client) using transaction SM59 (for example, C00_SYSTEM). It is
important that the option 'Trusted System' is not set to active for this destination (Security
Option Trusted System = No).

We recommend that you do not specify any

logon data in this destination, as someone could use a remote login to misuse this

destination in SM59 by working as the user that is

defined here. This destination must only be used for creating and deleting the
trusted/trusting relationship and not for any other purpose. It must therefore be named
correspondingly.

Call transaction SMT1 (or SM59 and then transaction menu RFC  Trusted
Systems).

Choose Create. Enter the destination of the client system (in the example,
C00_SYSTEM) in the dialog box. After confirming this, an RFC logon to the client
system occurs, and the necessary information is exchanged between the systems (S00 <->
C00).

If no logon data has been entered in the destination

(in the example, C00_SYSTEM), an RFC logon screen is displayed for the

client system (C00). In this particular case, a manual logon must be

performed. In each case, a successful logon to the client system

must be performed in this step, so that the trusted

relationship can be built.

When a trusted relationship has been successfully built, the trusted entry for the client
system (C00) is displayed. If you want to restrict the validity of the logon data for the
client system, enter a timeframe in the corresponding field. The default value (00:00:00)
means that the validity is unrestricted.
In the scenario where the same user and client are used, you can use the menu option
Entry to perform authorization checks: These checks first attempt to reach the client using
the logon data specified in the definition destination (in the example, C00_SYSTEM),
and then try to log back on to the server system with the same logon data, using a trusted
RFC. Choosing the menu option Current Server forces the return path to occur on the
current application server, and choosing menu option Trusting System induces load
balancing, meaning that the logon takes place on any application server in the server
system.

If different users or clients are used for the trusted scenario, you must create an RFC
destination on the client side, and perform an authorization check for the specified logon
data, setting the flag for "Trusted System" to "Yes".

Using a Trusted/Trusting Relationship

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

A prerequisite for successfully using a trusted/trusting relationship is that the user being
used has the corresponding authorization object S_RFCACL in the trusting server
system. If you want to create a suitable authorization for different

clients and users, note that you have to enter the caller data (caller client and caller user)
of the caller system (in our example from system C00) into the S_RFCACL fields
RFC_CLIENT and RFC_USER. For example, if user U_1 under client M_1 in caller
system C00 wants to work as user U_2 with client M_2 in the called system S00 under a
trusted relationship, then the user (U_2, M_2) in the system S00 must have authorization
ZRFCACL_XXX, which has the following settings:

RFC_SYSID : C00

RFC_CLIENT: M_1

RFC_USER : U_1

RFC_EQUSER: N (for NO)

RFC_TCODE : *

RFC_INFO : *
 ACTVT : 16

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

SU03 + double-click the entry "AAAB" "Cross-Application Authorization

Objects" and then choose "Authorization check for RFC user (ex. trusted system)"
as the object class, then double-click the authorization object S_RFCACL and
create Z_RFCACL_XXX.

After this, make sure you activate your settings.

If the same user is always used in the client system and server system for a
trusted/trusting relationship (meaning that U_1 = U_2), the authorization
Z_RFCACL_XXX can also be defined as follows:

 RFC_SYSID : C00

 RFC_CLIENT: M_1

 RFC_USER : ' '

 RFC_EQUSER: Y (for Yes)

 RFC_TCODE : *

 RFC_INFO : *

 ACTVT : 16

Setting the authorization field RFC_EQUSER to 'Y' is the same as setting the field
RFC_USER = SY-UNAME for the logged user in the caller system (here, system
C00).

Note that when maintaining and assigning S_RFCACL authorizations (in

this case, Z_RFCACL_XXX), you must use as few generic values (for
example '*') for RFC_SYSID, RFC_CLIENT and RFC_USER as possible. By
doing this, those users who fulfill these criteria regarding RFC_CLIENT and
RFC_USER, can call RFC modules from within the caller system, using the
called user.
You must ensure that high security requirements in the caller system is linked with the
usage of user maintenance transactions (such as SU01). If this is not the case, anyone
who has this authorization can get a user and log on to the trusting system (S00).

After you have maintained the authorization Z_RFCACL_XXX, you must create an
authorization profile as follows, and link it to the authorization
Z_RFCACL_XXX:

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

After this, make sure you activate the profile.

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

You can check the authorizations for the logged on users in the current system in
advance, by using the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.

As of Release 40B, for security reasons, the authorization profile SAP_ALL does not
contain an authorization for S_RFCACL.

Authorization errors that occur while using an RFC destination which has the 'Trusted
Systems' flag set to ‘Yes’ are documented with the following messages:

No authorization to log on as a trusted system (trusted RC = <0 1 2

3>).

Here, the trusted return codes ( = 0, 1, 2 or 3 ) have the following meanings:

0 Invalid logon data (user ID and client) for the trusting

 system.

Solution: In the server system (trusting system), create the user

in the corresponding client.

1 Calling system is not a trusted system, or security

ID for the system is invalid.

Solution: Create (again) the trusted system (see above).

2 User has no authorization for the server system

(trusting system, for object S_RFCACL), or a logon was made

using one of the protected users DDIC or

SAP*.

Solution:

Provide the user with the corresponding authorization or avoid using the protected users
DDIC and SAP*. Authorization errors that occur while using an RFC destination which
has the ‘Trusted Systems’ flag set to ‘Yes’ are documented with the following messages:

No authorization to log on as trusted system

(Trusted RC = <0 1 2 3>).

Here, the trusted return codes ( = 0, 1, 2 or 3 ) have the following meanings:

0 Invalid logon data (user ID and client) for the trusting

system.

Solution: In the server system (trusting system), create the user

in the corresponding client.

1 Calling system is not a trusted system, or security

ID for the system is invalid.

 Solution: Create (again) the trusted system (see above).

2 User has no authorization for the server system

(trusting system, for object S_RFCACL), or a logon was made

using one of the protected users DDIC or

SAP*.

Solution: Provide the user with the corresponding

authorization or avoid using the protected

users DDIC and SAP*.

3 Time stamp of the logon data is invalid.

Solution: Check the system time on the client host and server

host, as well as the validity date of the logon data.

(Note that the default date 00:00:00 means unrestricted

validity.)

Trusting Transaction SMT2

The trusting transaction SMT2 (or SM59  RFC  Trusting Systems) constructs a list of
all trusting systems that have been established for this trusted system. Here, a logon and
authorization check for the current user and client is performed, using the destination
TRUSTING_SYSTEM@S00 that has been automatically created.

This basically corresponds to transaction SM51, if you use Remote Login to perform a
logon on a different application server.

If problems occur while setting the destination TRUSTING_SYSTEM@S00 (such as

host name or service information), you either have to create a new destination for your
needs, and then enter the host name or service information using SAP router strings, or
adjust the network settings of the server. To correct the problem in transaction SMT2, you
have to adjust the network configuration of the server. As this transaction is only to be
used for test purposes, in this case you could also choose to ignore the
error.

To perform a logon as a different user or client, you have to create a new RFC destination
with a trusted option set.

In this scenario, the following error text in SMT2 can be ignored:

No authorization to log on as a trusted system (Trusted RC=0)

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

Continue with:

Configuring System Resources for Parallel RFC, tRFC, and qRFC

Configuration of System Resources for aRFC, tRFC,

qRFC
Use

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

Integration

Note that RFC calls with CALL FUNCTION are processed in DIALOG work processes.
Therefore, the DIALOG limitation for processing a dialog step (default: 300 seconds,
system profile parameter rdisp/max_wprun_time) also applies to these RFC calls.
Remember to take this limitation into consideration when you are dividing up your data
packets for parallel processing.

The configuration options described here are valid for the following RFC types.

Asynchronous RFC with Load Distribution (aRFC)

You can use this RFC type to program parallel RFC calls. The resources are checked and
assigned as far as the set quotas allow.

The required ABAP language element is:

CALL FUNCTION remote function STARTING NEW TASK task name

DESTINATION IN GROUP group name

With this ABAP command, you are telling the SAP system to process function module
calls in parallel. The command implements parallel processing by sending asynchronous
RFC calls to the appropriate servers. These are servers in the RFC server group Group
Name specified as being available for processing requests. The group name DEFAULT
means that all available application servers are being used.

qRFC with Outbound Queue

The qRFC LUWs are executed using the outbound scheduler. The outbound scheduler
uses parallel RFC for processing the outbound queue. For this to be possible, you have to
maintain the destinations using transaction SMQS.
The outbound scheduler then checks the resources and executes parallel RFCs, if
resources are available. If no resources are available, synchronous RFC is used.

qRFC with Inbound Queue

If you are using the inbound queue, the inbound scheduler takes over the processing of
the inbound queue. You have to register the queue names to be processed using the
inbound scheduler. To do this, use transaction SMQR.
The inbound scheduler then checks the resources and executes parallel RFCs, if resources
are available. If no resources are available, the scheduler waits until resources become
available.

For more information, see Monitor Transactional RFC and Queued RFC.

tRFC and qRFC

The transactional RFC and the qRFC use the resource check. The associated ABAP
language elements for both RFC types is:

CALL FUNCTION Remote function IN BACKGROUND TASK DESTINATION

destination

With a preceding additional function call (TRFC_SET_QIN_PROPERTIES or

TRFC_SET_QUEUE_NAME) tRFC can be defined as qRFC.

This ABAP command flags the function module remote function for asynchronous
processing. The module is not executed immediately. The data transferred with
EXPORTING or TABLES is placed in a database table. A COMMIT WORK then
triggers the function module. There are various cases:

● The data is updated. If tRFC/qRFC has been triggered within the update, these are
executed in parallel after the V1 update (within the update). If the tRFC/qRFC call is
registered in the scheduler, the scheduler is simply triggered within the update. The
execution of tRFC/qRFC takes place outside the update through the scheduler.

● The data is not updated. Then the tRFC/qRFC function modules started within the
application LUW are executed in parallel as far as possible. If local system resources are
exhausted, the tRFC/qRFC is serialized so as not to further increase resource utilization.
This however is not the case if the tRFC/qRFC function modules are processed in batch.
If the tRFC/qRFC have been started in batch, they are always processed in parallel as in
the update process, regardless of the system resource utilization.

No resource checks are run with RFC calls from the update process or batch,
since these must always be processed in parallel to avoid deadlocks. Here

Additional Information

Details about using and programming RFCs can be found in the RFC documentation:

Parallel Processing with Asynchronous RFC

Defining RFC Groups for Parallel Processing Jobs

SAP note 597583 (Performance Improvement Using RFC Parallelization) describes for
which purposes specific RFC types and hence ABAP language elements are
recommended.

Features

This documentation is divided into the following sections:

RFC Resources on the Application Server

● Describes which resources are relevant for the use of parallel RFCs, and how you can
monitor the available resources system-wide.

System Configuration for Parallel RFCs

● Describes how RFC resources can be manipulated - dynamically or from settings in

profile parameters

 Calculating Resources for Asynchronous and Transactional RFC

● Describes how resources are checked in the system and explains the difference
between local and remote checks (on a different server).

Constraints

Note that the techniques for monitoring and controlling resources described in this
document only apply to the RFC types mentioned above.

Even if you have correctly configured the quotas, your system may still become flooded
with RFCs if these are not of the correct types (such as synchronous RFCs, qRFC,
asynchronous RFCs without the added DESTINATION IN GROUP …).

Known problems, their causes and solutions are described in the following section:

Problems with RFC Resource Assignment

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

Resources can be assigned from the following areas:

Logging On to the SAP System

A total of rdisp/tm_max_no users can be simultaneously logged on to the server (using

the GUI or RFC). If rdisp/rfc_max_login percent of the maximum number of users are
logged on, no more RFC logons can be accepted. An RFC user may occupy a maximum
of rdisp/rfc_max_own_login percent of the login slots (see isp/tm_max_no).

You can see a user overview in transaction SM04. For more information, see Display
and Manage User Sessions.

RFC Requests in the Dialog Queue

The dialog queue of the dispatcher contains rdisp/elem_per_queue entries. A maximum of

rdisp/rfc_max_queue percent of these may be filled by RFC requests.
You can see a server overview in transaction SM51. For more information, see
Overview of SAP Application Servers.

Entries in the Communication Table

The communication table contains an entry for every CPIC communication for all parties
involved. The table can contain a maximum of rdisp/max_comm_entries entries.
rdisp/rfc_max_comm_entries

percent of these may be occupied by one user.

You can see a server overview in transaction SM51. For more information, see
Overview of SAP Application Servers.

Dialog Work Processes

When the server is started, it has rdisp/wp_no_diadialog work processes. This number
can, however, be changed while the server is running. One way to do this is to use
operation mode switching. You can find out the current number of processes in the
Process Overview (transaction SM50; see also Display and Control Work Processes).
Of the dialog work processes, the dispatcher keeps rdisp/rfc_min_wait_dia_wp free for
“genuine” dialog requests (not RFC).

A user may occupy a maximum of rdisp/rfc_max_own_used_wp percent of dialog

processes.

The same parameters are used to control the number of plug-in requests (HTTP or SMTP
requests coming from the ICM) that can be processed at the same time. See ICM
Parameters.

Server-side dispatcher check

The dispatcher checks whether it has free resources for each RFC request it receives. If it
has, it assigns the request to a dialog work process, otherwise it puts the request in the
dispatcher queue. You can control the detail level of this check using parameter
rdisp/rfc_check.

Overview of All RFC Resources in the SAP System

Transaction SARFC is used to monitor the resources on all servers in the SAP system.
This is described in the section Monitoring RFC Resources on the Application Server.
 Monitoring RFC Resources on the Application
Server
Use

You can monitor the RFC resources on all application servers and thus find out the load
incurred by parallel RFCs on a server.

You can also dynamically change the various quotas on all servers. For procedure for
doing this is described in the section Dynamically Configuring RFC Quotas.

Procedure

Execute the transaction SARFC.

You then see a list of all SAP servers with information for each server, stating whether
resources for asynchronous RFCs are available at the time you executed the transaction
(text Resources ok) . If no resources are available, a short text explaining the reason is
displayed.

Note that this list only represents the situation at the exact moment that you executed the
transaction. Choose Refresh to update the display.

This is a list of the possible results of the resource check with return values and
meanings.

0: resources are available on the server. The text ‘Resources ok’ is

displayed.

1: The resource check is deactivated (parameter rdisp/rfc_use_quotas is set to

0).

The other return values indicate that the server currently has no available resources for
asynchronous RFCs.

The server may have no resources for one of the following reasons:
 The server is not running.

 The server has been wrongly configured.

 An unexpected error has occurred.

In these cases, the text appears on a red background. You can find out the exact cause of
the problem (for example, where exactly the incorrect configuration is located) by briefly
activating and deactivating the trace for the server (see below). See the dispatcher trace
file dev_disp of the server for the required information.

The individual return values are described below. Each value has a text (appears on a
yellow background).

2: The server has too few free dialog work processes.

3: The quota for the RFC communication channels is too small. Increase the parameter
rdisp/rfc_max_comm_entries or change the value dynamically.

4: the quota for the RFC communication channels (rdisp/rfc_max_comm_entries) has

reached its maximum.

5: The local queue for asynchronous RFC responses is full. This queue retains the
responses to asynchronous RFCs until they are sent back to the caller. You can increase
the size of the queue by increasing the value of the parameter rdisp/max_arq.

6: The quota for a dialog work process occupied by an RFC user is too small. Increase the
size of the parameter rdisp/rfc_max_own_used_wp or change the value
dynamically.

7: the quota for a dialog work process occupied by an RFC user

(rdisp/rfc_max_own_used_wp) is too small.

8: The quota for the RFC requests in the dialog queue is too small. Increase the size of the
parameter rdisp/rfc_max_queue or change the value
dynamically.

9: the quota for the RFC requests in the dialog queue (rdisp/rfc_max_queue) has reached
its maximum.

10: An error occurred when the request queue length was being determined.

11: The quota for RFC logons to the server is too small. Increase the size of the value of
the parameter rdisp/rfc_max_login.
12: the quota for RFC logons to the server (rdisp/rfc_max_login) has reached its
maximum.

13: The quota for “own” RFC logons to the server is too small. Increase the size of the
parameter rdisp/rfc_max_own_login or change the value dynamically.

14: the quota for own RFC logons to the server (rdisp/rfc_max_own_login) has reached
its maximum.

15: The server has been deactivated and cannot process any requests.

16: The server is being stopped.

17: The server has been stopped.

18: The server is being started.

19: The server has just been started and is in the initialization
phase.

20: The server is in an unknown state.

Activating the Trace

Choose Goto  Activate Trace. The system then writes the detailed result of the check to
the trace file of the dispatcher on the server in question. To read the file, you have to log
on to the server in question. To do this, open transaction SM51, double-click on the
server name, then choose Process  Trace  Dispatcher  Display File).

It may make sense to do this if, for example, a server constantly has too few resources,
and you want to find out the exact cause.

Configuration of RFC Resources

Section System Configuration for Parallel RFCs describes how to configure your system.