Overview of SAP Application Server

All of us know that R/3 system architecture consists of Presentation Server, Application Server and Database Server. Here I would like to share some details of Application Server. 

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. 

A work process is where individual dialog steps are actually processed and thework is done. Each work process handles one type of request.  

SAP Application Server

Functions of dispatcher:

1), Equal distribution of transaction load to the work processes

2), Management of buffer areas in main memory

3), Integration of the presentation levels

4), 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: viz. User Context and Program Roll Area.

User Context is memory area that contains information about the USER.

Program Roll Area is memory area that contains information about thePROGRAMS execution

User Context holds the following information of the User needed by R/3:

1), The user’s current settings

2), The user’s authorizations

3), 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:

1), The values of the variables

2), The dynamic memory allocations

3), 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

Task Handler:

All requests pass through the task handler, which then distributes the request to the appropriate part of the work process.

Interpreter:

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.

Database Interface:

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.

An update request can be divided into one primary (V1) and several Secondary update components (V2). Time-critical operations are placed in V1 component and those whose timing are less critical are placed in V2 components. If a V1 update fails, V2 components will not be processed.

Spool requests are generated during dialog or background processingand placed in the spool database with information about the printer and print format. The actual data is placed in the Tem Se (Temporary Sequential objects).

Also See: Central Address Management (CAM)