Remote Function Calls Using SAPGUI

It is possible for an RFC client program to call ABAP function modules which are using ‘Dynpros’ or SAP graphics. This allows you to include normal SAP screens into your programs. Consequently, it is possible to call complete SAP transactions from external programs.

To use this functionality, a SAPGUI front end server (version 3.0C or later) must be installed on the external system where the RFC client program is running.

There are three methods to activate this new functionality:

...

1. Use RfcOpen

You can call the function RfcOpen with the special mode RFC_MODE_VERSION_3 and then set the field use_sapgui to a non-zero value in the structure RFC_CONNOPT_VERSION_3.

2. Use the saprfc.ini file

You can define an entry in the saprfc.ini file which includes all necessary connection parameters and the RFC-specific parameter USE_SAPGUI (=1) in the saprfc.ini file. An RFC client program can then issue the RfcOpen call with the mode RFC_MODE_PARAMETER and a destination pointed to the defined entry. See The SAPRFC.INI File for more details.

3. Use SYSTEM_ATTACH_GUI

You can call the function module RFC_ATTACH_GUI (without any parameter) within the ABAP funtion module you want to use before using any SAPGUI functionality.

This method can be used without modifying the C code of the RFC client program.

· This feature is available on all supported UNIX platforms (Motif).

· On Windows NT or Windows 95, it is only available with the 32-bit RFC library together with a 32-bit SAPGUI. In particular, this functionality is not supported for the 16-bit RFC library or for 16-bit SAPGUI (Windows 3.x, as well as the 16-bit subsystems of Windows NT and Windows 95).

· Under Windows NT and Windows 95 the SAPGUI program and its DLLs and auxiliary programs can be installed anywhere. However, you must have started SAPGUI once before it can be started automatically by RFC, because the SAPGUI must register itself in the Windows registry.

· On SAP-based UNIX systems, the SAPGUI program must be installed on the default ‘SAP path’ /usr/sap//SYS/exe/run.

Checking Authorizations for RFC

If the system profile parameter auth/rfc_authority_check is set (value 1), then the System automatically checks at the CALL FUNCTION keyword whether the authorizations user has the required RFC authorization.

The RFC authorization object is S_RFC Authorization check at RFC access. The authorization checks access to function modules by function module group. That is, whether a user has the right to run function modules that belong to a particular group.

You can test a user’s RFC authorization with the function module AUTHORITY_CHECK_RFC. This function module returns RC = 0 if the user is authorized for the group that you name. The function module does not check whether an authority check will actually take place.

Problems with RFC Resource Allocation

You have defined your parameters so that resource bottle necks will not arise. Your applications make RFC calls of the permitted types only. Yet you have realized that more work processes than allowed are occupied with RFC calls.

This can happen in the following circumstances:

An asynchronous RFC transmits a synchronous RFC

The asynchronous RFC transmits one or more synchronous RFC calls in the destination system. The profile parameters are not valid for these calls.

This problem is due to an error in the kernel and can be fixed by a kernel patch. The attribute with makes parameters configurable is passed on from the first RFC (this must be the right type) to other RFC calls.

Work process is changed by roll-out/roll-in

The asynchronous RFC occupies a work process in the destination system, but is rolled out because, for example, it contains the ABAP command COMMIT WORK or WAIT. If it is later rolled back in, the system does not check if the quotas have been exceeded.

This problem is due to an error in the kernel and can be fixed by a kernel patch. You can find out the patch number from the SAP Note 595032.

With the rdisp/rfc_check parameter in the RFC server you can change the settings in the check for how many RFC work processes are available.

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

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

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.

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:

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.

2. From the RFC destination overview screen (transaction SM59), choose RFC ® Trusted systems or enter transaction code SMT1.

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.

4. To create a trusted system, click the Create icon.

5. In the dialog window, enter the destination for the remote system. To change a destination, see Changing Trusted Destinations below.

6. All the necessary information such as application server name and security key is supplied automatically.

7. If you want to restrict the validity period of the logon data, enter an end date in the Validity period field.

8. If you want take over the transaction code of the calling program into the called system, mark the appropriate checkbox.

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

The RFC Interface

A remote function call (RFC) calls a function module in a different system to the calling program.

It is also possible to call a function module is the system by RFC. Normally though, the caller and the called function module are in different systems.

In the SAP system, these functions are provided by the RFC interface system. The RFC interface enables function calls between two SAP systems, or between an SAP system and an external system.

The RFC interface system is made up of the following elements:

● Interface for calling ABAP programs

● Every ABAP program can call a remote function module using the command CALL FUNCTION...DESTINATION. Parameter DESTINATION informs the SAP system that the called function module is running in a different system to the calling system. RFC communication with the remote system takes place as a part of the CALL FUNCTION command.

● RFC function modules in an SAP system must be real function modules and must be registered as remote enabled in the SAP system.

● If the calling program and the called program are both ABAP programs, the RFC interface provides both communication partners. The calling program can be any ABAP program. The called program must be a function module that is registered as remote enabled.

● Interfaces for calling non-ABAP programs

If either the calling program or the called partner is not an SAP program, the program in question must be programmed in such a way that it can play the role of the other partner in RFC communication.

RFC-supported and GUI-supported interfaces can be used by external programs to call function modules in SAP systems and to perform them in these systems. ABAP programs can also use these interfaces to use functions supplied by external programs.

SAP provides a special RFC API for this purpose.

Authorization Object S_RFC

Definition

Authorization check when using RFC to access program modules (such as function groups)

Defined Fields

This authorization object contains the following three fields:

RFC_TYPE: Type of the RFC object that is being protected

Currently, this field can take the value FUGR (function group).

RFC_NAME: Name of the RFC object that is being protected

Currently, this field contains the names of function groups. It can have a maximum of 18 characters. Only 18 characters can be checked.

ACTVT: Activity

Currently, this field can take the value 16 (Execute).

Example

If you want a user to be able to execute function modules from the group ABCD in the target system, then this user needs the following authorization in the target system:

Activity: 16

Name of the RFC object that is being protected: ABCD

Type of the RFC object that is being protected: FUGR

RFC Authorizations

The authorization check uses authorization object S_RFC to check whether the user defined in the destination has RFC authorization for the function module to be called. The authorization check is performed at the function group level. If the user is assigned to a certain function group, he or she can call all function modules that belong to this function group.

In addition to the function groups belonging to the application function modules, authorization object S_RFC must also contain any RFC function groups in order to perform technical processes during communication:

○ for tRFC and qRFC calls between two SAP systems: function groups ERFC and ARFC

○ for all RFC calls in external (non-SAP) systems: function group SYST

Checking RFC Authorizations

The automatic authorization check is made by implicitly calling function module AUTHORITY_CHECK_RFC. If it detects an authorization issue, this function module triggers one of the exceptions defined in its interface, namely USER_DONT_EXIST or RFC_NO_AUTHORITY, thus triggering a runtime error. We recommend that you call this function module explicitly before a remote call, thus enabling you to handle any exceptions that may arise. If it detects the relevant authorization, the function module does not return an explicit result. Instead, like all function modules that are performed successfully, it sets sy-subrc to 0.

The function module does not check whether an authorization check actually takes place.

When a function module is called remotely from within the same system, an automatic authorization check only takes place if the client and user ID are not the same. Across system boundaries, the automatic authorization check is only performed in systems that are not recognized as “trustworthy”.

Rating a system as an RFC Trusted/Trusting System is done using transaction SMT1.

If system profile parameter auth/rfc_authority_check is set to value 1, the system checks automatically whether the user has the required RFC authorization when CALL FUNCTION is reached

Limit Values for Resource Allocation for Asynchronous RFC

If one of the following criteria is not met, no resources are made available for parallelization with asynchronous RFC (or triggered by the system with RESOURCE_FAILURE):

● Number of free dialog work processes: 1
The default value is 1 and can be defined using profile parameter rdisp/rfc_min_wait_dia_wp. A certain number of dialog work processes are normally kept free as reserve instances for other purposes, such as system logon or administration programs.
It is therefore necessary to keep a greater number of dialog processes free than the number specified in profile parameter rdisp/rfc_min_wait_dia_wp.

● Proportion of user-specific dialog work processes: 75%
You can change this default value using profile parameter rdisp/rfc_max_own_used_wp. The number of dialog work processes is set by profile parameter rdisp/wp_no_dia.

● Proportion of requests waiting in the dialog queue: 5%
You can change this default value (5% of the total length of the dialog queue) using profile parameter rdisp/rfc_max_queue.
The length of the dialog queue is set by profile parameter rdisp/elem_per_queue.

● Proportion of logons in the system: 90%
If the proportion of logged-on users already exceeds this figure, no resources will be released.
You can change this default value using profile parameter rdisp/rfc_max_login.
The maximum number of logons to a server is configured using profile parameter rdisp/tm_max_no.

● Proportion of separate logons in the system: 25%
You can change this default value (25% of all logons) using profile parameter rdisp/rfc_max_own_login. For each RFC, a logon is made in the target system.

● Proportion of used communication entries: 90%
Each server has a limited number of communication channels at its disposal. The default limit value is 90 per cent.
You can change this value using profile parameter rdisp/rfc_max_comm_entries. The maximum number of communication channels is configured using profile parameter rdisp/max_comm_entries. Here, one entry is made for the client and one for the server for each connection.

●

Configuration of System Resources for RFC

Use

Every RFC call occupies a dialog work process on the application server. If parallel processing is used for the RFC (aRFC, qRFC, bgRFC), sufficient system resources must be available.

The various ways of configuring the SAP System are described below.

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

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 instructing the SAP system to process function module calls in parallel. The instruction 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 to process the outbound queue. To allow this, you need to maintain the destinations in 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 instead.

qRFC with Inbound Queue

If you are using the inbound queue, the inbound scheduler takes is responsible for processing the inbound queue. To allow this, you need to register the queue names to be processed using the inbound scheduler in 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 a function module Remotefunction for asynchronous processing. The module is not executed immediately. The data transferred with EXPORTING or TABLESis 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. 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. However, this 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.

Background RFC (bgRFC)

bgRFC is a newly developed RFC variant. With its characteristics type t (transactional) and type q (queued), it replaces tRFC and qRFC.

With both types, parallel processing is performed by the scheduler if enough dialog work processes are available.

Features

This documentation is divided into the following sections:

● 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

● Displays the configuration parameters for RFC resources either 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).

● Configuring Resources for bgRFC

Provides information about determining the required number of work processes for bgRFC and maintaining the relevant parameters.

Restrictions

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 types mentioned (such as synchronous RFCs, qRFC, asynchronous RFCs without the suffix DESTINATION IN GROUP).

Additional Information

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

● Problems with RFC Resource Assignment

Detailed information about parallel processing is provided under:

● Parallel Processing with Asynchronous RFC

● Defining RFC Groups for Parallel Processing Jobs

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

RFC Material pdf free download

The RFC API

The RFC Generator

RFC C++ Class Library (BC-FES-AIT)

RFC Java Class Library (BC-FES-AIT)

RFC Programming in ABAP

WebRFC Programming

RFC Material PDF Free download

The RFC API

The RFC Generator

RFC C++ Class Library (BC-FES-AIT)

RFC Java Class Library (BC-FES-AIT)

RFC Programming in ABAP

WebRFC Programming