Sie sind auf Seite 1von 6

SAP R/3 Architecture explained

Last Updated: August 10th 2017 by Ashok Kumar Reddy

What is SAP R/3 architecture? Explain SAP R/3 architecture in detail SAP r/3 is a
three layer architecture

Note: Don`t be panic to read and understand below, the below is the complex and detailed
explanation, you will understand this in next lessons
As name suggests SAP R/3 has three layers

Presentation Layer
Application Layer
Database Layer
SAP R/3 Architecture in detail

Presentation Layer
Presentation layer is the first layer of R/3. This is the top layer of the system. Presentation
layer presents the end user how an SAP system looks at the front end for performing
transactions (operations of end user).
This layer consists of GUIs (Graphical User Interface), an interface which connects the
system and the end user to perform transactions. GUIs are installed in the system to
use the application. Each and every end user system has a GUI application. If there are 100
end users in an organization, all the end users will be accessing SAP through a GUI
installed in their systems. GUIs may be a Windows application / Java application / an
HTML application. With the help of these GUI applications, the end users operate on SAP.
Application Layer
The Application Layer is the middle layer of R/3 architecture. This layer is the heart of SAP
R/3 products. This layer consists of the application. All Transactions of the end user are
performed in this layer. An application in the Application Layer consists of 5 components.

Work Process (WP)

Component 1: Dispatcher
The Dispatcher acts as an interface between the application layer and the presentation
layer. The requests of the user from the presentation layer enter the application via a
dispatcher. After the request is processed, the response to the user is given back through
the dispatcher.
Component 2: Gateway
The Gateway is another type of an interface. This interface connects the application in the
application layer with the RDBMS (database) in the database layer. Here, during the
process of the transaction, the request for added / delete / search / retrieval of data, to/ from
the RDBMS flows via the Gateway.
Component 3: Buffering
The Buffering (or a buffer) is the temporary storage area for data in order to perform
transactions with those data. Usually, data are stored as Tables in RDBMS. Transactions
are performed in an area called Work Process (WP). Frequently changing tables (data) are
stored in the buffer and transactions are processed with data from the buffer. It does not
directly process with data from the RDBMS. Eg., the data regarding Currency of nation as
stored in the Buffering area of the application since the value of a currency changes
The transaction time for each transaction when processing via buffering is 0.2 milliseconds.
While, the transaction time for each transaction when processing directly via RDBMS is 6
milliseconds. Hence, to increase the performance, almost all transactions are processed via
buffering and not directly via RDBMS.
Component 4: Work Process (WP)
The Work Process is the actual transaction processing area in an application. Work
Processes execute the dialog steps of application programs, i.e., it actually processes the
transactions. The work process (WP) consists of 3 components.

ABAP processor
Database Interface

Dialog: Dialog is also called as Screen Processor. From a programming point of view, user
interaction is controlled by screens. A screen consists of flow logic. The screen flow logic
controls a large part of the user interaction. The R/3 Basis system contains a special
language for programming screen flow logic. The screen processor executes the screen
flow logic. Via the dispatcher, it takes over the responsibility for communication between the
work process and the GUI, calls modules in the flow logic, and ensures that the field
contents are transferred from the screen to the flow logic.
ABAP Processor: The actual processing logic of an application program is written in ABAP
SAPs own programming language. The ABAP processor executes the processing
logic of the application program, and communicates with the database interface. The screen
processor tells the ABAP processor, which module of the screen flow logic should be
processed next.
Database Interface: The database interface provides the following services:

Converts Open SQL into Native SQL of the application.

Establishing and terminating connections between the work process and the
Access to database tables.
Access to R/3 Repository objects (ABAP programs, screens and so on).
Access to catalog information (ABAP Dictionary).
Controlling transactions (commit and rollback handling).
Table buffer administration of the application server.

Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They
allow you to access data irrespective of the database system that the R/3 installation is
using. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL;
in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE)
data. The tasks of the Data Definition Language (DDL) and Data Control Language (DCL)
parts of Standard SQL are performed in the R/3 System by the ABAP Dictionary and the
authorization system. These provide a unified range of functions, irrespective of database,
and also contain functions beyond those offered by the various database systems.
Native SQL is only loosely integrated into ABAP, and allows access to all of the functions
contained in the programming interface of the respective database system. Unlike Open
SQL statements, Native SQL statements are not checked and converted, but instead are
sent directly to the database system. Programs that use Native SQL are specific to the
database system for which they were written. R/3 applications contain as little Native SQL
as possible. In fact, it is only used in a few Basis components (for example, to create or
change table definitions in the ABAP Dictionary).
Types of Work Processes
The services offered by an application server are determined by the types of its work

Dialog Work Process:

Dialog work processes deal with requests from an active user to execute dialog steps.

Update Work Process:

Update work processes execute database update requests. Update requests are part of an
SAP LUW (Logical Unit of Work) that bundle the database operations resulting from the
dialog in a database LUW for processing in the background.

Background Work Process:

Background work processes, process programs that can be executed without user
interaction (background jobs).

Enqueue Work Process:

The enqueue work process, administers a lock table in the shared memory area. The lock
table contains the logical database locks for the R/3 System and is an important part of the
SAP LUW concept. In an R/3 System, you may only have one lock table. You may therefore
also only have one application server with enqueue work processes.

Spool Work Process:

The spool work process passes sequential datasets to a printer or to optical archiving. Each
application server may contain only one spool work process. Here Spool Numbers are
generated and actions are performed according to the order of spool number.
Component 5: Message
Message is used for Internal Communication between applications in the application layer.
It uses "Idoc" to exchange information. Idoc, short for Intermediate Document, is a SAP
document format for transferring the data for a business transaction. Idoc is similar to XML
in purpose, but differs in syntax. Both serve the purpose of data exchange and automation
in computer systems.