Show TOC

Background documentationDynamic Work Processes Locate this document in the navigation structure


Dynamic work processes enable the work process configuration of the SAP NetWeaver Application Server (AS ABAP) to be modified in accordance with the current specifications while the system is running. This includes restarting new work processes and closing work processes no longer needed.


In older releases there was only the CCMS Operation Mode Switching that enabled the work process type to be changed while the system was running. Work processes of dialog type during the day could be assigned type batch at night time. This type switch was not dynamic (controlled by the system), and neither was it possible to start new processes while the system was running.

Dynamic work processes enable a kind of adaptive computing on the one hand, and on the other hand, enable the system to free itself from deadlocks. They can be seen as a supplement to operation mode switching.

Adaptive Computing

The earlier strategy for configuring an application server assumed fixed hardware conditions. The available hardware resources were distributed on the running applications, and the profile parameters set accordingly. To activate new hardware resources, the server had to be restarted. The SAP configuration could be easily changed in the profile file.

The concept of adaptive computing is to let applications run on “virtual hosts”, where resources can be changed while the system is running (for instance, a CPU can be added.) For this reason the application server must be able to change the fixed hardware conditions dynamically in order to:

  • Use the available hardware resources to full capacity

  • Release these resources when they are needed for other tasks

Once more CPUs have been added to a virtual server, the administrator can use these to full capacity by adding further work processes.


The situation may arise where one work process needs a further work process in order to process a request. In particular when using RFC, dialog work processes reserve further dialog work processes. Deadlocks may occur when RFC cascades are used to parallelize the workload on a server. This problem cannot be solved with conventional configuration, but with dynamic work processes the dispatcher can recognize deadlocks and start further work processes.


The procedure to make more work processes available is implemented in two stages:

  • Reserved (restricted) work processes

    In addition to familiar work process types (dialog, background, spool, and so on), there is also the type reserved. The number of initial work processes (as with the other types also) is specified in the profile parameter rdisp/wp_no_restricted. No further reserved WPs can be created while the system is running.

    Reserved work processes are always of the dialog type. They are kept free in normal operation and not used until the system identifies a bottleneck and needs additional work processes to remove it.

  • Work processes started dynamically

    If the dynamic work processes are active (rdisp/dynamic_wp_check=TRUE), the system can start new work processes up to the limit specified in rdisp/wp_max_no in order to resolve deadlocks. Dynamic work processes can have different types (dialog, batch, update, and so on).

    The possibility of creating processes dynamically is also used for handling deadlocks. If all the processes have the same type, such as dialog status is On Hold, if possible, a process with this type is restarted. After the bottleneck has been resolved, the “dynamic” process is stopped again (see rdisp/dynamic_wp_check).

When the instance is started, as many work processes as the sum of the following parameters are started:








The sum of the parameters must be smaller or equal to the value of parameter rdisp/wp_max_no.

If the operating mode is switched, the number of individual process types can be changed. The criterion that the total must not exceed the value of rdisp/max_wp_no still applies.

Standard Setting

No reserved work processes are configured in the standard setting (rdisp/no_restricted = 0), but up to two work processes can be started dynamically (rdisp/max_wp_no=<Sum of all configured WPs + 2>).

Recommendation Recommendation

This setting is appropriate if deadlocks are only expected in exceptional cases. If there are many applications transmitting a large number of RFCs, we recommend you configure additional dynamic work processes. To do this set the value to the sum of all configured work processes plus the required number of dynamic work processes (see example below).

End of the recommendation.

Dynamic and reserved work processes are configured in profile parameters. All of the parameters described below are documented in detail in the system (transaction RZ11). The newly-added profile parameters are highlighted with an asterisk (*}.

Caution Caution

The maximum number of work processes is 600. This means the sum of all work process types plus the possible number of dynamic work processes. The parameter rdisp/wp_max_no is restricted to this sum.

End of the caution.
Profile Parameters for Work Process Configuration

Parameter Name



Standard value


Number of work processes of type dialog

Whole number (between 2 and 600)



Number of work processes of type batch (background processing)

Whole number (between 0 and 600)



Number of work processes of type enqueue (only on the enqueue instance >0)

Whole number (between 0 and 5)



Number of work processes of type V1 update (time-critical)

Whole number (between 0 and 600)



Number of work processes of type V2 update (not time-critical)

Whole number (between 0 and 600)



Number of work processes of type spool (print)

Whole number (between 0 and 600)



Number of reserved work processes (see above)

Whole number (between 0 and 600)



Maximum number of work processes including those created dynamically (see above)

Whole number between 2 and 600 (must be larger than the sum of all work process types), or DEFAULT

DEFAULT (Sum of all WPs + 2)


Activation of the check in the dispatcher, and if necessary of the starting of dynamic WPs (FALSE deactivates the capability of the server to create dynamic WPs)

Truth value



Lifespan of dynamic work processes: Dynamic work processes should be stopped once the bottleneck is removed. If you are not processing a request, the work processes are stopped after this time interval.




Number of configurable work processes for the Operation Mode Switching.

To enable the Dispatcher to resolve deadlocks automatically, at least wpsForDeadlockHandling work processes are excluded from operation mode switching in the DEFAULT setting:

configurable_wp_no = wp_max_no - wpsForDeadlockHandling

whereby presently the kernel works with a fixed wpsForDeadlockHandling = 2 (only the kernel can change this setting).

If, as before, the number of processes is defined by the number of type-specific work processes (DIA, BTC, and so on), the sum of these processes is the number of configurable work processes. The maximum number of work processes rdisp/wp_max_no is increased accordingly by wpsForDeadlockHandling.

Caution Caution

This parameter should have the standard value DEFAULT. Only change the value in exceptional situations and after consulting SAP.

End of the caution.

Whole number between 0 and 600, or DEFAULT

DEFAULT (maximum number of WPs minus wpsForDeadlockHandling, presently therefore: number of WPs minus 2)


You can see all the work processes currently running in the process overview (transaction SM50, see Displaying and Managing Work Processes).

If you select   List   Configuration   and select the checkbox With Info Area, in the header area you can see how many dynamic work processes are possible and whether any are currently running.

Example Example

In the system the parameters have the following settings:

rdisp/wp_no_dia = 16

rdisp/wp_no_btc = 3

rdisp/wp_no_vb = 1

rdisp/wp_max_no = 30

The process overview (transaction SM50) might look like this:

This graphic is explained in the accompanying text.

Work Process Overview

End of the example.

The information shown means the following:

  • Total Number of Processes: Number of work processes currently running

  • Dialog: Number of configured work processes, number of dialog WPs currently free

  • Update, Background, etc. : Analogous information for the other configured WP types

  • Configurable: Value of parameter rdisp/configurable_wp_no: (here DEFAULT, calculated using the formula maximum number of WPs – 2: 30–2 = 28

  • Dynamic: maximum number of WPs – configured WPs: 30–20 = 10

  • Blockade Handling: Here you can see whether the dispatcher has created an additional work process for blockade handling (since the start or the last reset). You can see whether the process is still running in the Total Number of Processes. Choose   List   Reset   to reset the display. The number of dynamic/reserved processes will be set to zero and the line disappears from the display.

More Information

You can find information about the configuration and monitoring of server resources when using parallel RFCs in the documentation Configuration of System Resources for aRFC, tRFC, qRFC.