SAP ARCHITECTURE

SAP based the architecture of R/3 on a three-tier client/server model.

Presentation Server
Application Server
Database Server

Presentation Server
The presentation server is actually a program named sapgui.exe. It is usually
installed on a user's workstation. To start it, the user double-clicks on an icon on
the desktop or chooses a menu path. When started, the presentation server
displays the R/3 menus within a window. This window is commonly known as the
SAPGUI, or the user interface (or simply, the interface). The interface accepts
input from the user in the form of keystrokes, mouse-clicks, and function keys,
and sends these requests to the application server to be processed. The
application server sends the results back to the SAPGUI which then formats the
output for display to the user.

Application Server
An application server is a set of executables that collectively interpret the ABAP/4
programs and manage the input and output for them. When an application server
is started, these executables all start at the same time. When an application
server is stopped, they all shut down together. The number of processes that
start up when you bring up the application server is defined in a single
configuration file called the application server profile.
Each application server has a profile that specifies its characteristics when it
starts up and while it is running. For example, an application sever profile
specifies:
Number of processes and their types
Amount of memory each process may use
Length of time a user is inactive before being automatically logged off
The application server exists to interpret ABAP/4 programs, and they only run
there-the programs do not run on the presentation server. An ABAP/4 program
can start an executable on the presentation server, but an ABAP/4 program
cannot execute there.
If your ABAP/4 program requests information from the database, the application
server will format the request and send it to the database server.

Discovering the Database Server

The database server is a set of executables that accept database requests from
the application server. These requests are passed on to the RDBMS (Relation
Database Management System). The RDBMS sends the data back to the
database server, which then passes the information back to the application
server. The application server in turn passes that information to your ABAP/4
program.
There is usually a separate computer dedicated to house the database server,
and the RDBMS may run on that computer also, or may be installed on its own
computer.

Configuring the Servers

In a three-tier client/server configuration, the presentation servers, applications
servers, and database server all run on separate machines. This is the most
common configuration for large systems, and is common in production.
In the distribution presentation configuration, the application and database
servers are combined on one computer and the presentation servers run
separately. This is used for smaller systems, and is often seen on a development
system.
In the two-tier client/server configuration, the presentation and application
servers are combined and the database server is separate. This configuration is
used in conjunction with other application servers. It is used for a batch server
when the batch is segregated from the online servers. A SAPGUI is installed on it
to provide local control.
When all servers are combined onto a single machine, you have a central
configuration. This is rarely seen because it describes a standalone R/3 system
with only a single user.

Defining an R/3 System

The simplest definition of an R/3 system is "one database." In one R/3 system,
there is only one database. To expand the definition, R/3 is considered to be all
of the components attached to that one database. One R/3 system is composed
of one database server accessing a single database, one or more application
servers, and one or more presentation servers. By definition, it is all of the
components attached to one database. If you have one database, you have one
system. If you have one system, you have one database. During an
implementation, there is usually one system (or one database) assigned to
development, one or more systems designated for testing, and one assigned to
production.
The term R/3 system landscape denotes a description of the number of systems
within an SAP installation and how they are designated, such as development,
test, or production.

Defining an R/3 Instance

When you hear someone say the word instance, most of the time, that person
will be referring to an application server. The term instance is synonymous with
application server.
The term central instance refers to the database server. If an application server
and database server both reside on the same machine, the term central instance
refers to the computer on which both reside.
In the most general terms, an instance is a server. It is a set of R/3 processes
providing services to the R/3 system.

Application Server Architecture

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.
To perform any processing for a user's request, a work process needs to address
two special memory areas: the user context and the program roll area. The user
context is a memory area that contains information about the user, and the roll
area is a memory area that contains information about the programs execution.

Understanding a User Context

A user context is memory that is allocated to contain the characteristics of a user
that is logged on the R/3 system. It holds information needed by R/3 about the
user, such as:
The user's current settings
The user's authorizations
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. It is used during program processing, and its importance is
described further in the following sections.

Understanding a Roll Area

A roll area is memory that is allocated by a work process for an instance of a
program. It holds information needed by R/3 about the program's execution, such
as:
The values of the variables
The dynamic memory allocations
The current program pointer

Each time a user starts a program, a roll area is created for that instance of the
program. If two users run the same program at the same time, two roll areas will
exist-one for each user. The roll area is freed when the program ends.

Understanding a Roll Area

A roll area is memory that is allocated by a work process for an instance of a
program. It holds information needed by R/3 about the program's execution, such
as:
The values of the variables
The dynamic memory allocations
The current program pointer
Each time a user starts a program, a roll area is created for that instance of the
program. If two users run the same program at the same time, two roll areas will
exist-one for each user. The roll area is freed when the program ends.
NOTE
When speaking to a Basis consultant, you might hear the term roll area
used to refer to all roll areas for one user or even all roll areas on one
application server. You usually can determine the intended meaning from
the context in which it is used.
Both the roll area and the user context play an important part in dialog step
processing.

Understanding a Dialog Step

NOTE
A dialog step is used by Basis consultants as the unit of measure for system
response time.
A dialog step is the processing needed to get from one screen to the next. It
includes all processing that occurs after the user issues a request, up to and
including the processing needed to display the next screen. For example, when
the user clicks the Enter key on the Change Vendor: Initial Screen, he initiates a
dialog step and the hourglass appears, preventing further input. The sapmf02k
program retrieves the vendor information and displays it on the Change Vendor:
Address screen, and the hourglass disappears. This marks the end of the dialog
step and the user is now able to make another request.
There are four ways the user can initiate a dialog step. From the SAPGUI:
Press Enter.
Press a function key.
Click on a button on the screen.
Choose a menu item.
It is important for an ABAP/4 programmer to know about dialog steps because
they form a discrete unit of processing for an ABAP/4 program.

Understanding Roll-In/Roll-Out Processing

An ABAP/4 program only occupies a 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.
NOTE
ABAP/4 programs do not have the capability to intercept many common
Windows events. The events that generate a lot of messages such as key
presses, focus changes, and mouse movements are not passed to ABAP/4
programs. As a result, there is no way of performing some of the functions that
are found in other Windows programs. For example, in ABAP/4, you cannot
validate the contents of a field when the user presses the Tab key. You must
instead wait until the user initiates a dialog step.

Discovering How the Data Is Sent to the Presentation Server

The messages exchanged between the presentation server and the application
server are in an SAP proprietary format. The SAPGUI accepts the screen
information sent from the application server and formats it appropriately for the
platform it is running on. This enables different end-user hardware platforms to
connect to a single application server. For example, an OS/2 PC and a Windows
PC can both connect to the same application server at the same time.

Understanding the Components of a Work Process

Each work process is composed of the following:
A task handler
An ABAP/4 interpreter
A screen interpreter
A database interface
All requests pass through the task handler, which then funnels the request to the
appropriate part of the work process.
The interpreters interpret the ABAP/4 code. Notice that there are two interpreters:
the ABAP/4 interpreter and the screen interpreter. There are actually two dialects
of ABAP/4. One is the full-blown ABAP/4 data processing language and the other
is a very specialized screen processing language. Each is processed by its own
interpreter.
The database interface handles the job of communicating with the database.

Understanding the Types of Work Processes

There are seven types of work processes. Each handles a specific type of
request. The type of work processes and the types of requests that they handle
are shown in Table 1.2.
Table 1.2 Types of Work Processes and the Types of Requests they Handle
WP Type Request Type
D (Dialog) Dialog requests
V (Update) Requests to update data
in the database
B (Background) Background jobs
S (Spool) Print spool requests
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

Understanding the Logon Client

The term logon client has nothing to do with Client/Server-it is completely
different.
The number entered here by the user corresponds to a set of rows within each
client-dependent table within the database.

Understanding Client-Dependent and Client-Independent Tables

There are two types of tables in an R/3 database: client-dependent and client-
independent. A table is client-dependent if the first field is of type CLNT. The
length will always be 3, and by convention, this field is always named mandt. If
the first field is not of type CLNT, the table is client-independent.
This program selects rows from table lfa1 and writes out lfa1-lifnr. When this
program is run, only two rows are selected: only those where mandt equals 800.
This happens automatically because the first field in the table is of type CLNT.
There are five rows in the table, but the program writes out only those rows
where mandt equals 800. If the user were to log on to client 700 and run the same
program, three rows of data would be found and written out. If the user were to
log on to client 900, only one row of data would be found.
The logon client mechanism divides the rows within a client-dependant table into
distinct groups. To access a different set of data, the user logs on and specifies a
different client number.
NOTE
The user master records (containing R/3 user IDs) are client-dependent.
Therefore, to gain access to a client, the security administrator must create
a new user ID for you within that client.
Developers and testers use the logon client mechanism to create and access
multiple, independent sets of data within a single table.
For example, assume two typical, asocial programmers are working on an
enhancement to the billing system. Jim is modifying the update transaction and
Jane is creating a new report to go with Jim's modifications.
Jane sets up data for her test run, executes her report and obtains output. Jim
works in the next cubicle, but due to his antisocial tendencies is blissfully
unaware that his transaction uses the same tables as Jane's report. He runs his
transaction and updates the data. Jim got what he wanted, but Jane then
modifies her code and runs her program again. Her output differs from the last
run, and the differences many not result from her changes, but rather they may
result from Jim's changes. What we have here is a failure to communicate.
If the tables used by Jim and Jane's programs were client-dependent, they could
each log in to separate clients, set up independent sets of data, and test their
programs without ever talking to each other. They could perform all of their
testing in the comfort of their cubicles and in isolation from their coworkers.
To make their tables client-dependant, they only need mandt as the first field and
the R/3 system will take care of the rest. When records are added to the table,
the system automatically moves the current logon client into the mandt field when
the record is send to the database. Their Open SQL select statements will only
return rows where the client number in the table is equal to the their current logon
client number. The Open SQL database statements insert, update, modify, and
delete also provide automatic client handling.
If the tables involved are all client-dependent, there can be more than one group
of testers working at a time in one test system. Two teams of testers can test
divergent functionality in the same set of programs at the same time provided
they log on to different logon clients. The updates done by one team will not
change the data belonging to the other team.
A training client could also exist on the test system. The students could log on to
one client and the testers could log on to another. Both would run the same set of
programs, but the programs would access independent sets of data.
NOTE
The average R/3 installation has three systems: development, test, and
production. By default, each system comes with three clients installed: 000, 001,
and 066. It is common to have from three to six clients in the development and
test systems, but rarely will you see more than one client in production.