You can optimize the configuration of your SAP system for the purposes of working with parallel RFCs. This section describes the tools (profile parameters, transactions, and so on) you use to do this.
To use parallel RFCs effeciently, your system has to be configured accordingly and must meet the following prerequisites.
More dialog work processes than non-dialog work processes have to be configured on every server that is available for processing parallel RFCs.
The profile parameter rdisp/wp_no_<wptyp>uses <wptyp> = dia, spo, upd, up2, btc to determine the number of work processes of one type. This number is not, however, necessarily the most up-to-date number, as the work process types can be changed while the server is in operation (by means of operation mode switching, for example). You can find out the current number of work processes in the Process Overview (SM50; see also Display and Control Work Processes).
A range of profile parameters is available for resource distribution during the processing of parallel RFCs. These parameters are described in the following sections:
For more parameters to do with RFC, open transaction RZ11 and search for isp/rfc*.
Note that the parameters rdisp/rfc* only apply to the above-mentioned RFC types, and not to any other types, such as synchronous RFC or asynchronous RFC without a group.
In other words, the parameters only apply to qRFC and parallel RFC.
The standard values for the quotas are restrictive, since you must assume that dialog users are also active in the system and they are given priority. You can set the maximum resources for RFC users as follows.
rdisp/rfc_max_login = 100
rdisp/rfc_max_own_login = 100
rdisp/rfc_max_own_used_wp = 100
rdisp/rfc_max_comm_entries = 100
These can of course affect the response time for dialog users.
As well as setting the parameters, you can also change the ARFC resources dynamically in the running system immediately before running the application that uses a high volume of parallel RFCs.
To do this, use transaction SARFC, as described in the section Dynamically Configuring RFC Quotas.
Note the following points when configuring the system:
i. The number of available resources in the system is a snapshot relating to the current workload in the system. No program can assume that these resources will also be available long term.
ii. If one of the quotas is exceeded, no resources are returned to the caller.
iii. The calculated resources are not reserved for the caller. Thus it could happen that competing programs are calculating resources at the same time, and are occupying more dialog work processes than has been set in the quota. A program therefore cannot assume that the resources calculated are actually also available.