Structure of an ABAP Application Server
Components of Application Server
- Work Processes
- Shared Memory
- Database Connection
An application server encloses work processes, which are constituents that can run an application. Each work process is associated with a memory area containing the context of the application being run. The context holds the existing data for the application program and these requests to be available in each dialog step.
Each application server has a dispatcher and it is the link between the work processes and the users logged on to the application server. Its task is to accept requests for dialog steps from the SAP GUI and divert them to a free work process. In the same way, it directs screen output resulting from the dialog step back to the suitable user.
Each application server encloses a gateway and it is an interface for R/3 communication protocols. It can communicate with other application servers in the same R/3 System, with other R/3 Systems, R/2 Systems and also with non-SAP systems.
The application server structure as expressed here supports the performance and scalability of the entire R/3 System. The fixed number of work processes and the dispatch of dialog steps lead to optimal memory use since it means that certain components and the memory areas of a work process are application independent and reusable. The fact that the individual work processes work independently makes them suitable for a multi-processor architecture. The methods used in the dispatcher to distribute tasks to work processes are discussed more closely in the section Dispatching Dialog Steps.
For better information on SAP ABAP please check the below demo video
All of the work processes on an application server use a major memory area called shared memory to save circumstance or to buffer constant data locally.
The resources that all work processes use are controlled in shared memory. Memory management in the R/3 System ensures that the work processes constantly address the correct context i.e. the data relevant to the current state of the program that is running. A mapping process projects the required context for a dialog step from shared memory into the address of the significant work process. This condenses the actual copying to a minimum.
Local buffering of data in the shared memory of the application server decreases the number of database reads required. This reduces access times for application programs significantly. For optimal use of the buffer, you can deliberate individual applications into separate application server groups.
When you start up a R/3 System, each application server schedules its work processes with the database layer and receives a single dedicated channel for each. While the system is running, each work process is a user of the database system. You cannot transform the work process registration while the system is running. Neither can you move a database channel from one work process to another. For this reason, a work process can only make database modifications within a single database logical unit of work. A database LUW is an indivisible string of database operations.