ABAP Application Server

ABAP application servers are important software components of NetWeaver AS ABAP since all ABAP progrums run on these servers. The following sections describe the structure and functions of these application servers in more detail.

Structure of an ABAP Application Server

All ABAP application servers including the message server represent the application layer of the multi-tier architecture of an ABAP-based SAP System. These application servers execute ABAP applications and communicate with the presentation components, the database, and also with each other, using the message server.

The following diagram shows the structure of an ABAP application server:

In addition to several work processes whose number and type are determined at the startup of NetWeaver AS ABAP, each ABAP application server contains a dispatcher, a gateway and the shared memory. The tasks of these components are briefly described in the following:

Work Processes

Work processes are components that are able to execute an application (that is, one dialog step each). Each work process is linked to a memory area containing the context of the application being run. The context contains the current data for the application program. This needs to be available in each dialog step.

Dispatcher

The dispatcher is the link between the work processes and the users logged onto the ABAP application server (that is, the SAP GUIs of theseusers). Its task is to receive requests for dialog steps from the SAP GUI and direct them to a free work process. In the same way, it directs screen output resulting from the dialog step back to the appropriate user.

Gateway

This is the interface for the communication protocols of NetWeaver AS ABAP (RFC, CPI/C). It can communicate with other ABAP application servers of the same NW AS, with other SAP Systems, or with external non-SAP systems.

Shared Memory

All of the work processes on an ABAP application server use a common main memory area called shared memory to save contexts or to buffer constant data locally.

The resources that all work processes use (such as programs and table contents) are contained in shared memory. Memory management in the NetWeaver AS ABAP ensures that the work processes always address the correct context, that is 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 relevant work process. This reduces the actual copying to a minimum.

Advantages of this Type of Architecture

The structure of the ABAP application servers described here supports the performance and scalability of NetWeaver AS ABAP. The fixed number of work processes and dispatching of dialog steps leads 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.

Local buffering of data in the shared memory of the ABAP application server reduces the number of database reads required. This reduces access times for ABAP application programs considerably. For optimal use of the buffer, you can concentrate individual applications (financial accounting, logistics, human resources) into separate ABAP application server groups.

Database Connection

When you start up a NetWeaver AS ABAP, each ABAP application server registers its work processes with the database layer, and receives a single dedicated channel for each. While the NW AS is running, each work process is a user (client) of the database system (server). You cannot change the work process registration while the system is running. Neither can you reassign a database channel from one work process to another. For this reason, a work process can only make database changes within a single database logical unit of work (LUW), that is an inseparable sequence of database operations.