You are on page 1of 7

SAP R/3 Architecture

In software engineering there are 3 architectures

Single tier architecture
Two tier architecture
Three tier architecture
Single tier architecture: A system which is responsible for loading the program,
compiling, interpreting, executing as well as storing the data in the same system is
called single tier architecture. In simple words a system responsible for front end
and back end operations is called single tier architecture.
Ex: All C language programs in olden days are written using single tier architecture.
Two tier architecture: In this architecture we have two layers, server layer and
client layer.
2. a. Sever layer: In this layer we have a single system with very high configuration
called as server. This sever is responsible for executing the programs as well as
storing the data.
2. b. Client layer: In this later we have multiple systems which are connected to a
server. All the business users will be operating from client systems. The server will
receive the request from the client system and gives back the response (i.e. result).
Ex: SAP R/2, Oracle
Disadvantages of two tier architecture:
As the number of client systems increases the load on the database server will
increase and the response time will be delayed
Since the response time is delayed the output will be very slow on the client system
which is very big disadvantage
To overcome this problem we have a new architecture called as three tier

SAP R/3 Architecture in detail

As name suggests SAP R/3 has three layers

Presentation Layer

Application Layer

Database Layer

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 organizations,
all the end users will be accessing SAP through a GUI installed in their
systems. GUIs may be a Window application / Java application / an HTML
application. With the help of these GUI applications, the end users operates
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
enters the application via 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 transaction, the request for add /
delete / search / retrieval of datas, to/ from the RDBMS flows via the Gateway.
Component 3: Buffering
The Buffering (or a buffer) is the temporary storage area for datas in order to
perform transactions with those datas. Usually, datas are stored as Tables in
RDBMS. Transactions are performed in an area called Work Process (WP).
Frequently changing tables (datas) are stored in buffer and transactions are
processed with datas from the buffer. It does not directly process with datas
from RDBMS. Eg., the datas regarding Currency of nation as stored in
Buffering area of the application since the value of 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 executes the dialog steps of application programs, i.e., it
actually processes the transactions. The work process (WP) consists of 3


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
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 database.

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 on 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 processes.

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

What is user context and roll area ?

User context : User context is a temporary memory area that contains information about users
which is used throughout the program processing.

When a user logs on, a user context is allocated for that logon and it contains the following
information about the user:
the current settings of the user
the user's authorizations
the names of the programs the user is currently running.
When they log off,the memory area assigned to them is released.
Roll area : Roll area is memory area which is allocated by work processes for the program
Each time a user starts a program, a roll area is created for that instance of the program.It
contains the following information about the program's execution :
the dynamic memory allocations

variables value

the current pointer of the program

The memory in the roll area becomes free when the program ends its execution.
If two users run the same program at the same time then two roll areas will be created one for
each user.