Configuring System Resources for Parallel RFC,
tRFC, and qRFC
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 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.
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.
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.
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.
Transactional RFC uses resource checking only. It does not use parallel RFCs.
The required ABAP language element is:
CALL FUNCTION remote function DESTINATION destination IN BACKGROUND TASK
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. In this case the function module is executed within the update following the V1 phase, usually even on a different server.
· The data is not updated. In this case the function module is executed in the same work process.

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.
See also the following sections:
Parallel Processing
with Asynchronous RFC
Defining RFC Groups
for Parallel Processing Jobs
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 without inbound queue, 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
The following sections contain:
·
RFC Resources in the
Application Server
Describes which resources are relevant for the use of parallel RFCs, and how
you can monitor
the available resources system-wide.
·
System Configuration
for Parallel RFCs
Describes how RFC resources can be manipulated - dynamically or from settings
in profile parameters
·
Determining Resources
for Asynchronous and Transactional RFC
Describes how resources are checked in the system and explains the difference
between local and remote checks (on a different server).
