Various processes may require a large number of follow-up processes to be created. For example, the adjustment of master data requires a very large amount of dependent master data to be adjusted. In the case of processing using bgRFC, unsuitable settings can lead to significant performance problems, which have the potential to noticeably increase system response times or cause processes to terminate with timeouts. This effect can occur if the number of subsequent processes is similar to or exceeds the number of free-work processes. To avoid the effects described, it is essential to select suitable settings for the processing of bgRFC queues by SAP BASIS. As these settings have a major impact on the basic behavior of the system, the settings should always be made by SAP Basis. The settings for the follow-up processes can also be made by the user. The following text explains the various options:

Transaction RZ10

In this transaction under basic settings, you can first define how many processes the system makes available. These settings must always be taken into account in the bgRFC settings. For example, the bgRFC settings may not use more processes than the system provides. The following image shows these settings for the work processes, where, for example, a maximum of 6 background processes and 10 dialog processes are set:

Transaction RZ10 (system parameters) / RZ11 (profile parameters)

The parameter rdisp/rfc_max_own_used_wp can be set in transaction RZ10 under extended maintenance as well as in transaction RZ11. This parameter regulates the absolute number of work processes that can be used via RFC.

Transaction RZ12 (RFC server group)

A dedicated server group for processing bgRFC processes can be created in this transaction. A specific application server can be specified here, for example, so that the performance for users is not impaired.  The maximum percentage of work processes that can be used by this server group can also be set here.

Transaction SBGRFCCONF

This transaction contains the two parameters "Scheduler number" and "Number of open connections" at the application server level and destination level. The two parameters have the following meaning:

Parameter scheduler number

The parameter can be set to the values -1, 0, or >0. According to the description, "-1" means that the number of schedulers is determined methodically, but can be high. The setting "0" means that the destination cannot be used for bgRFC. This setting can therefore not be selected for FUP applications. A value greater than 0 defines the maximum number of schedulers.

Parameter Number of open connections

This parameter controls how many processes may be started for a destination. If several destinations are used for bgRFC applications, the total number of possible processes across all destinations may exceed the maximum permitted number of processes. In this case, the above parameter should be used.

Tab "Scheduler: Application server"

The two parameters can be set on this tab for outbound and inbound destinations:

Tab "Scheduler: Destination"

The two parameters can be set for each destination on this tab:

Tab "Inbound Destination"

If an inbound destination is used for bgRFC, a server group can be assigned for each destination. This means, for example, that the bgRFC processes can be processed on a dedicated server without affecting the performance of the user.

Transaction FUP Customizing

The follow-up processes can be set in the QPPD Customizing transaction /SCT/QP_CUST under Basic settings:

The name prefixes for the queue names can be set in the "Subsequent processes" sub-dialog. Follow-up processes can be grouped into queues by selecting suitable prefixes or by implementing the ABAP interface /SCT/QP_IF_FUP~DO_CHANGE_QUEUE_NAME to adapt the queue name. This grouping increases the number of units per queue but reduces the number of queues. As only one unit is ever processed per queue, the maximum number of processes used is also reduced.

A type of prioritization is also possible by using this grouping: units with a lower priority are processed in a shared queue and units with a higher priority are processed in new queues. As 10 processes can be executed in parallel, for example, 10 - 1 = 9 free processes are available for higher-priority units, which can be processed immediately.