Distributing user requests to work processes means that individual clients at presentation server level are assigned to a work process for a particular period after which the request uses another work process. After the work process has processed the user input in a dialog step, the user and the program context are rolled out of the work process. Another user can then use the work process.

 

The three-tier architecture is more scalable than a “fat” client architecture, where the presentation and application levels run on one server. With a three-tier architecture, the number of database users is lower than the number of users active in the system. A lower number of database users enables better database performance.

 

 

Implicit Database Commits

When a screen is displayed, the current work process is released on the application server. The release of the work process triggers the release of the respective database work process and automatically initiates an implicit database commit.

 

Releasing the work process before each user dialog ensures that the user actions, which usually last longer, do not block any work processes on the application server and, particularly, on the database server, which significantly reduces the load on the database server. When a user has completed processing the screen, the user context is “rolled in” with the program context. The user is returned to a work process for processing. The screen then requires internal program processing.

 

Hint: Due to the implicit database commits triggered at the end of a dialog step, changes that belong to an SAP LUW may not be placed in different dialog steps. This is because these steps may not be in the same database LUW.