Interesting details of Application Server

SAP Application Server
PAD architechture

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 the work is done. Each work process handles one type of request.

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 the PROGRAMS 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.


The interpreters interpret the ABAP/4 code. There are two interpreters: the ABAP/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.

WP Type

Request Type

D (Dialog/Online) Dialog requests (processes only one request at a time)
V (Update) (Primary and Secondary) Requests to update data in the database
B (Background) Background jobs (Starts at a specified time)
S (Spool) Print spool requests (generated online or during back ground processing for printing)
E (Enqueue) Logical lock requests
M (Message) Routes messages between application servers within an R/3 system
G (Gateway) Funnels messages into and out of the R/3 system

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 processing and 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).


Some Trivia

  1. If there are three R/3 systems in your current system landscape, then there will be three databases.
  2. If an R/3 system has two application servers, then it will have three instances. Two for the Application Servers and one for Database server
  3. A new roll area is allocated whenever a program is executed, and it is de-allocated when the program terminates. The roll area contains the values of the variables for that program and the current program pointer.
  4. A user context is allocated each time a user logs on, and de-allocated when he or she logs off. It contains information about the user, such as authorizations, profile settings, and TCP/IP address.
  5. The roll-out occurs at the end of a dialog step. It frees the work process to ready it for other requests, so that the program will not use CPU while waiting for user input.


  1. Ritesh –

    I am not an expert to answer this question but i would like to share my view.

    SAP gives much emphasis on data security, simply for the fact that mishandling of sensitive business data can cause huge financial losses. Companies pay huge amount of money to SAP partners for that. So SAP has given this concept of having one R/3 system and one Database so that malicious intent can be checked with proper authority checks in Production environment.

    I guess you might have one question with my reply? Can’t we have different clients in the same environment and access accordingly ?

    The answer to this question is –

    Just think what will happen to the data which are client independent…..

  2. “”””If there are three R/3 systems in your current system landscape, then there will be three databases.

    can u plz explain this one to one mapping between R/3 system and database ?

    i think…if aggregate database load is not high, 3 R/3 systems can work on one database if these R/3 syetm enjoy different clients.

    need ur input.


Please enter your comment!
Please enter your name here