Dialog Processing in SAP S/4HANA

The dispatcher selects a free dialog work process (DIA) to process the logon request. If load-balancing is configured, the connection will be made to the message server, after which the user will be redirected to the dispatcher of the application server with the most available resources. During the logon process, the assignment of the user to the application server is fixed. The user remains in the assigned application server until he or she logs off.

A DIA work process is not reserved for a single user. Once a user request is processed, the work process becomes available again for another request from the same or a different user. In this way the processing of transactions that consist of multiple screens can be executed using multiple dialog work processes. This distribution process is called multiplexing. Work process multiplexing means that a function with content that is logically connected but consisting of multiple substeps can be processed by different dialog work processes.

Dialog work processes use different memory areas. Some memory areas are used exclusively for the dialog work process (heap memory) while others are shared by all work processes (cross-process memory). As work processes are not exclusively assigned to user sessions, data and context must be made available at the beginning of a dialog step (rolled in) and saved at the end of the dialog step (rolled out), so that the next user request (screen in the same transaction) can be dealt with by another work process starting where the first left off.

The number and types of work processes are configured in the instance profile and determined at the startup of the application server. There might be situations in which all work processes are busy. To resolve such deadlocks, standby and dynamic work processes can be activated:

• Standby dialog work processes: are started together with the other work processes at the startup of the instance. They are kept free in normal operation and are only used when the application server identifies a bottleneck and needs extra work processes to resolve the issue. The number of standby work processes is defined by profile parameter rdisp/wp_no_restricted. In process overview Transaction SM50, standby dialog work processes are indicated by the status standby (see figure below).
• Dynamic work processes: can be of type dialog or update. When all work processes have status hold, the dynamic work processes are started by the application server. When the bottleneck is resolved, they are stopped again. When the application server is started, the value of profile parameter rdisp/wp_max_no is set automatically to the sum of the configured work processes plus five dynamic work processes.

Long-running tasks in online transactions are aborted after they exceed a configurable time limit. This ensures that dialog work processes are not blocked by long-running programs and forces users to start those tasks in background. The maximum runtime can be further prioritized by setting different time caps on high, medium, and low requests. Parameter rdisp/scheduler/prio_high/max_runtime sets the runtime for high-priority requests such as requests coming from end users. Parameter rdisp/scheduler/prio_ normal/max_runtime does the same for requests with a medium priority such as RFC requests. The maximum runtime for low-priority requests, such as dialog tasks triggered by background requests, can be set via parameter rdisp/scheduler/prio_low/max_runtime. Note that parameter rdisp/max_wprun_time supersedes the others. If it has been set, it overwrites the more detailed settings. We recommend replacing the rdisp/max_ wprun_time parameter with the above parameters as they give much more flexibility.

Parameter rdisp/max_wprun_time Is Deprecated: The older, and widely used, mechanism to control session time-outs is to set the rdisp/max_wprun_time profile parameter. As of SAP S/4HANA 2020, this parameter is removed from the ABAP kernel and the priority-based time-outs must be used (see SAP Note 2918906).

Large productive systems have multiple application servers. These have in most cases the same number and type of work processes to improve load-balancing and to guarantee continuity, in case one of the application servers fails. Although it is good practice to configure the application servers equally, it is not required. Application servers may have a different number of work processing depending on their hardware resources such as their amount of memory and CPUs.

Performance can be improved by using logon groups to separate dialog load from other load generated by for example, background processing. Logon groups can also be used to separate the processing of Remote Function Calls (RFC). Logon groups can be created and maintained with Transaction SMLG (Maintain Logon Groups).

Operating System Command to Monitor the Message Server: Operating system command lgtst can be used to test the connection to the message server and to list the available logon groups. The command lists the available SAP instances and the logon groups with their favorites. For more information, see SAP Note 64015.

Editor’s note: This post has been adapted from a section of the book SAP S/4HANA Administration by Mark Mergaerts and Bert Vanstechelman.