Understanding the Application Server
ERP/ R/3 system architecture consists of amongst others:
- Presentation Server
- Application Server
- Database Server
- You can display a list of application servers that have registered themselves with the SAP message server by executing Transaction SM51, or by choosing Administration –> System Administration –>Monitor –>System Monitoring –>Servers.
The application server may have the following Message Types: Services provided by the application server This contains the configured SAP Work Process types (Dialog, update (Update and Upd2), Enqueue, Batch and Spool) as well as the following services:
- ICM This means that on the application server in question an Internet Communication Manager (ICM) is configured that can accept or send requests from the Internet (HTTP and other protocols). You can find documentation under Internet Communication Manager (ICM)
- J2EE: The J2EE Engine is configured on this server. This server can execute Java programs as well as ABAP programs (see AS Java (Application Server für Java)
- VMC: The SAP Virtual Machine Container is configured on this server, which means that there is a Java VM as well as an ABAP VM in the work process.
Application Server basically consists of a Dispatcher and multiple Work Processes.
SAP dispatcher is the control agent which manages the resources for the R/3 applications such as:
- Equal distribution of transaction load to the work processes
- Management of buffer areas in main memory
- Integration of the presentation levels
- Organization of communication activities
All requests that come in from presentation servers are directed first to the dispatcher. The dispatcher writes them first to the dispatcher queue. The dispatcher pulls the requests from the queue on a first-in, first-out basis. Each request is then allocated to the first available work process. (A work process handles one request at a time.)
In order to do any processing for a user’s request, work process needs two special memory areas:
- User Context
- Program Roll Area
User Context is memory area that contains information about the user.
Program Roll Area is memory area that contains information about programs execution
User Context holds the following information of the User:
- The user’s current settings
- The user’s authorizations
- The names of the programs the user is currently running
When a user logs on, a User Context is allocated for that logon. When they log off, it is freed.
Roll Area holds the following information of the program:
- The values of the variables
- The dynamic memory allocations
- The current program pointer
Every time a user starts a program, a roll area is created for that instance of the program.
If three users run the same program at the same time, three roll areas will exist-one for each user. The roll area is freed when the program ends.
An ABAP/4 program occupies only one work process for one dialog step. At the beginning of the dialog step, the Roll Area and User Context are rolled in to the work process. At the end of the dialog step, they are rolled out.
During the roll-in, pointers to the roll area and user context are populated in the work process. This enables the work process to access the data in those areas and so perform processing for that user and that program. Processing continues until the program sends a screen to the user. At that time, both areas are rolled out. Roll-out invalidates the pointers and disassociates these areas from the work process. That work process is now free to perform processing for other requests. The program is now only occupying memory, and not consuming any CPU. The user is looking at the screen that was sent, and will soon send another request.
When the next request is sent from the user to continue processing, the dispatcher allocates that request to the first available work process. It can be the same or a different work process. The user context and roll area for that program are again rolled in to the work process, and processing resumes from the point at which it was left off. Processing continues until the next screen is shown, or until the program terminates. If another screen is sent, the areas are again rolled out.
When the program terminates, the Roll Area is freed.
The User Context remains allocated until the user logs off.
In a system with many users running many programs, only a few of those programs will be active in work processes at any one time. When they are not occupying a work process, they are rolled out to extended memory and only occupy RAM. This conserves CPU and enables the R/3 system to achieve high transaction throughput.
Components of Work Process:
Each work process has the following components:
- A task handler
- An ABAP/4 interpreter
- A screen interpreter
- A database interface
All requests pass through the task handler, which then distributes the request to the appropriate part of the work process.
The interpreters interpret the ABAP/4 code. There are two interpreters: theABAP/4 interpreter and the Screen interpreter. ABAP/4 Interpreter is data processing language and Screen Interpreter is very specialized screen processing language. Each is processed by its own interpreter.
The database interface handles the job of communicating with the database.
Type of Work Processes:
There are seven types of work processes. Each handles specific type of request.
DIA – Work process for executing dialog steps in user transactions
UPD – Update process for executing update requests
ENQ – Process for executing enqueue requests
BTC – Process for executing batch requests
SPO – Process for executing spool requests
UP2 – Process for executing V2 update requests