Hardware and Operating System SAP R/3 Basis ... - SAP Techies

Introduction To SAP R/3 Basis 

----------------------------------------------------------- 

Understanding Basis 

Basis is like an operating system for R/3. It sits between the ABAP/4 code 

and the computer's operating system. SAP likes to call it middleware 

because it sits in the middle, between ABAP/4 and the operating system. 

Production 

Planning 

Human 

Resources 

Materials 

Management 

Finance and 

Controlling 

SAP R/3 Basis Software 

Sales and 

Distribution 

Hardware and Operating System 

Compiled By: Ashwin Vavaiya 1 of 44


----------------------------------------------------------- 

Basis sitting between ABAP/4 and the operating system. ABAP/4 cannot 

run directly on an operating system. It requires a set of programs 

(collectively called Basis) to load, interpret, and buffer its input and output. 

Without Basis, ABAP/4 programs cannot run. When the operator starts up 

R/3, you can think of him as starting up Basis. Basis is a collection of R/3 

system programs that present you with an interface. Using this interface the 

user can start ABAP/4 programs. 

Basis makes ABAP/4 programs portable. 

What is ABAP? 

What platforms does R/3 support? 

Operating Systems Supported 

Hardware 

Platforms and Databases Supported by R/3 

Supported Front- 

Ends 

Supported 

Databases 

AIX SINIX IBM SNI SUN Win 3.1/95/NT DB2 for AIX 

SOLARIS HP-UX Digital HP OSF/Motif Informix-Online 

Digital-UNIX Bull OS/2 Oracle 7.1 

Macintosh ADABAS D 

Windows NT AT&T Compaq Win 3.1/95/NT Oracle 7.1 

Bull/Zenith OSF/Motif SQL Server 6.0 

HP (Intel) SNI OS/2 ADABAS D 

IBM (Intel) Macintosh 

Digital (Intel) 

Data-General 

OS/400 AS/400 Win95 OS/2 DB2/400 



----------------------------------------------------------- 

Role of Basis Administrator 

SAP R/3 

Security 

Coordinator 

What is client server…? 

SAP R/3 System Administrator 

SAP R/3 Administrator 


Database 

Administrator 


Correction and 

Transport 

Administrator 



----------------------------------------------------------- 

R/3 System Architecture 

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

Logical Grouping of layers 



----------------------------------------------------------- 

The Presentation Layer 

The Application Layer 

The Database Layer 

Those SAP R/3 software components that 

specialize in processing business 

applications form the Application Layer. 

Three tired client server Architecture [ Logical View ] 

Communication 


specialize in interacting with end-users 

form the Presentation Layer. 


specialize in the management, storage and 

retrieval of data form the Database Layer 



----------------------------------------------------------- 

The Presentation Layer 

collects user input and 

creates process requests. 


uses the application logic of 

SAP programs to collect and 

process the process requests. 


stores and retrieves all data. 

Physical Distribution of R/3 Logical Layer’s 

Presentation Layer 

components 

Presentation servers: 

Systems capable of 

providing a graphical 

interface. 

Application Layer 

components 

reside in: reside in: reside in: 

Application servers: 

Specialized systems 

multiple CPUs and 

vast amounts of 

RAM. 

Database Layer 

components 

Database servers: 

Specialized systems 

with fast and large 

hard drives. 

Physical Distribution of R/3 ‘s Three Layered Client server Architecture 



----------------------------------------------------------- 

Presentation Layer components are installed across many PCs. 


components are installed 

across one or more highend 

servers. 

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 


components are installed on 

one high-end database 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. 

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. 

R/3 System Configuration 

Computer 

“A” 

Centralistic 

Presentation Layer Application Layer Database Layer 



----------------------------------------------------------- 

Computer 

“A” 

Computer 

“A-1” 

Computer 

“A-2” 

Computer 

“A-n” 

Computer 

“A” 

Computer 

“A-1” 

Computer 

“A-2” 

Computer 

“A-n” 

Distributed Presentation 

Computer 

“B” 

Two tier Client/Server 

Computer 

“B” 



----------------------------------------------------------- 

Computer 

“A” 

Computer 

“A-1” 

Computer 

“A-2” 

Computer 

“A-n” 

Computer 

“A” 

Computer 

“A-1” 

Computer 

“A-2” 

Computer 

“A-n” 

Computer 

“B” 

Computer 

“B-1” 

Computer 

“B-n” 

Computer 

“C” 

Multi-tier, cooperative Client/Server 

Computer 

“B” 

Computer 

“B-1” 

Computer 

“B-n” 

Three tier Client/Server 

Computer 

“C” 

Computer 

“C-n” 



----------------------------------------------------------- 

Computer 

“A” Computer 

“B” 

Computer 

“A-1” 

Computer 

“A-2” 

Computer 

“A-n” 

Computer 

“B-1” 

Distributed Applications? 

PP 

PS 

MM- 

INV 

MM- 

PUR 

Computer 

“B-n” 

SD- 

SHP 

MM- 

INV 

Computer 

“C” 

Computer 

“C-n” 

One central system is not always optimal for unifying business processes with 

integrated applications 

Compiled By: Ashwin Vavaiya 11 of 44 

GL 

CO 


Database 

Administrator


----------------------------------------------------------- 

Using the SAP Basis System, applications can run on different platforms 

with high performance and can be adapted to meet individual user 

requirements. 

 

SAP Basis: 

Provides the runtime environment for all SAP applications 

Optimally embeds the application in the system environment 

Defines a stable architecture framework for system enhancements 

Contains the tools for administering the entire system 

Allows the distribution of resources and system components 

Provides interfaces for decentralized system parts and external 

products. 

The architecture of the SAP Basis System is especially well-suited for 

client / server configurations 



----------------------------------------------------------- 

SAP Application Server Architecture & System Kernel 

The components of an application server are shown in Figure 1.19. It consists of a 

dispatcher and multiple work processes. 

The following components on the application level are involved in processing a dialog 

request. 

The dispatcher 

Work process queues (administered by the dispatcher) for incoming requests 



----------------------------------------------------------- 

One of the dialog work processes 

Buffers in shared memory and also possibly the roll file 

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 



----------------------------------------------------------- 

Dialog Work Process execution sequence 

Execution Sequence 

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. 



----------------------------------------------------------- 

The task handler coordinates activity within a dialog work process. It activates 

the screen processor or the ABAP processor (which control the screen flow 

logic and process ABAP statements, respectively) and executes the roll-in and 

the roll-out of the user context. 

The memory management system differentiates between main memory areas 

that are available exclusively to a work process, and memory areas that can be 

used by all work processes. The memory space used exclusively by a work 

process stores session-specific data that must be kept longer than the duration 

of a work step. This data is automatically made available to the process at the 

start of a dialog step (rolled-in) and saved at the end of the dialog step (rolledout). 

This data characterizes users (user context), such as their authorizations, 

administration information and additional data for the ABAP and dialog 

processor. Also it contains data collected by the system in the preceding dialog 

steps in the running transaction (see following slide). Additional memory areas 

used by all processes in shared memory include areas for the factory calendar, 

screen, table, and program buffers. 

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. 

Both the roll area and the user context play an important part in dialog step 

processing. 

Understanding a Dialog Step 

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. 



----------------------------------------------------------- 

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. 



----------------------------------------------------------- 

Understanding the Components of a Work Process 

Each work process has four components (see Figure ). 

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. 



----------------------------------------------------------- 

R/3 Database Interfaces 

When interpreting open SQL statements, the R/3 database interface 

checks the syntax of these statements and automatically ensures the local 

SAP buffers in the shared memory of the application server are utilized 

optimally. Data frequently required by the applications is stored in these 

buffers so that the system does not have to access the database server to 

read this data. In particular, all technical data such as ABAP programs, 

screens, and ABAP Dictionary information, as well as some business 

process parameters usually remain unchanged in a running system, 

making them ideal buffering candidates. The same applies to certain 

business application data, which is accessed as read-only. 



----------------------------------------------------------- 

Work Process Multiplexing and SAP Transactions 



----------------------------------------------------------- 

Locks in R/3 at the Business Process Level 



----------------------------------------------------------- 

Requesting a Lock From the Enqueue WP 

When a lock is requested, the system checks to determine whether the 

requested lock conflicts with any entries in the lock table. If there are 

conflicts, the lock request is rejected. The application program then 

informs the user that the operation cannot currently be executed. A 

message appears,for example, “Data is currently in use. Change not 

possible.” 

The locks (enqueues) are administered by the enqueue work process 

using the lock table. The lock table is stored in the main memory of the 

server where the enqueue work process is running. If the dialog work 

process and enqueue work process are not running on the same server, 

they communicate through the message server. 

Locks set by application programs are reset either by the application 

program itself or by a special update program (in the second part of SAP- 

LUW) 



----------------------------------------------------------- 

Asynchronous Update 

Updating Log Records 



----------------------------------------------------------- 

Background Processing 

The R/3 Instance 



----------------------------------------------------------- 

R/3 Memory Areas 

Users need two kinds of memory: 

R/3 buffers 

Memory accessible to all users, for: 

Programs 

Table and field definitions 

Customizing tables 

User context 

Memory attached to individual users, for: 

Variables, lists, internal tables 

Administrative data (such as authorizations) 

Physical and Virtual Memory 

 

Unlike physical memory, virtual memory can be allocated. The operating 

system determines if the allocated memory area resides in the physical memory 

or in the operating system swap space. 

Depending on the operation system, the maximum size of the virtual 

memory may vary between the size of the operating system swap space and the 

sum of physical memory and operating system swap space. 



----------------------------------------------------------- 

The six R/3 memory areas are: 

 

Buffers 

Extended memory 

Heap memory 

Roll memory 

R/3 paging memory 

Local work process memory 

R/3 Memory – OverView 



----------------------------------------------------------- 

R/3 Memory I: Local Memory for Work Processes 



----------------------------------------------------------- 

R/3 Memory II: R/3 Buffers 



----------------------------------------------------------- 

R/3 Memory III: Extended Memory 



----------------------------------------------------------- 

R/3 Memory IV: Heap Memory 



----------------------------------------------------------- 

R/3 Memory V: Roll Memory 



----------------------------------------------------------- 

R/3 Memory VI: Paging Memory 



----------------------------------------------------------- 

User Context Data & Roll-in, Roll-out 

In an R/3 system, many frontend users are connected to one or more application 

servers. The work that users request from the system is performed in work 

processes. Normally, there are fewer work processes than frontend users. 

A work process is dedicated to a frontend user only while a specific dialog 

step is being processed by the application server. A user can be dispatched to 

one work process in one dialog step, and to another work process in the 

following dialog step. Over the course of time, users are dispatched to different 

work processes. 

In the course of their work in dialog work processes, users accumulate 

various pieces of data, such as pointers to programs they are using. This 

accumulated data is called the "user context". A user context enables, for 

example, the material number you are working on to be remembered by the 

system and proposed as the default in a following transaction. 

Roll Area and Paging Area 

The data processed in work processes is stored in two memory areas: 

The roll area, in which user context data is stored. User context data may 

include pointers to 

active programs, set/get parameters (related to the most recent input of the 

user), authorizations,internal tables, and report lists. 

The paging area, which stores the application program data that correspond to 

specific ABAP commands including EXTRACT, IMPORT TO MEMORY, 

EXPORT FROM MEMORY, and CALL TRANSACTION. 

 

The size of these areas is configurable using R/3 profile parameters. 



----------------------------------------------------------- 

Roll Buffer and Paging Buffer 

Where there is buffer space available, the roll area and the paging area are 

held in the respective buffers in the application servers. When there is not 

sufficient buffer space, the roll area and the paging area must be stored in the 

respective physical disk files (roll file and paging file). 

Thus, the user data processed in work processes is stored in two areas: 

The roll file and its associated buffer 

The page file and its associated buffer 



----------------------------------------------------------- 

R/3 Extended Memory 

User contexts are not only stored in roll files and the corresponding buffers. 

As of R/3 Release 3.0, they are primarily stored in R/3 extended memory. 

In R/3 extended memory, a large area of memory shared by all available 

work processes can be accessed through pointers. Using extended memory as 

well as roll files thus reduces the amount of copying from roll areas that is 

required during user context switches, and avoids the overhead caused by large 

roll-in or roll-out tasks. 



----------------------------------------------------------- 

Memory Allocation Sequence for Dialog WPs 

Sequence: 1 Initial Portion of roll area 

To keep the usage of the roll area to a minimum and make more use of 

extended memory, only a small portion of the roll area is used initially. 

The size of this portion is set by the parameter ztta/roll_first. 



----------------------------------------------------------- 

Sequence: 2 Extended memory until it full or user quota is 

reached. 

The user quota defines the maximum amount of R/3 extended memory that can 

be used by any one user, and is set with the parameter ztta/roll_extension. 



----------------------------------------------------------- 

Sequence: 3 Rest of the roll area 

The remaining portion of R/3 roll memory is used when the 

system can no longer allocate R/3 extended memory, either because 

R/3 extended memory is full or because the quota has been reached. 

The reason for using the remaining portion of R/3 roll memory is 

to avoid using heap memory, which is local memory, and avoid 

entering PRIV mode 



----------------------------------------------------------- 

Sequence: 4 Local heap memory 

If the work process requires still more space after using up all 

available roll area and extended memory, the system is forced to 

allocate R/3 heap memory locally. 



----------------------------------------------------------- 

Allocation Sequence for Dialog WPs – Overview 

The memory allocation strategy for dialog work 

processes aims to prevent work processes from 

allocating R/3 heap memory and thus entering PRIV 

mode. 

When a work process enters PRIV mode, it remains 

connected to the user until the user ends the ransaction. 



----------------------------------------------------------- 

Allocation Sequence for Non-Dialog WPs 



----------------------------------------------------------- 

Memory Management Parameters 



----------------------------------------------------------- 

ztta/roll_first: 

Defines the first part of the roll area that is allocated to a dialog 

process 

ztta/roll_area: 

Defines the total roll area per work process 

rdisp/roll_SHM: 

Defines the size of the roll buffer 

rdisp/roll_MAXFS : 

Defines the size of roll buffer and roll file 

em/initial_size_MB: 

Defines the fixed size of extended memory 

ztta/roll_extension: 

Defines the user quota for extended memory 

abap/heap_area_dia : 

Defines the limit for the amount of local memory allocated to dialog 

work processes 

abap/heap_area_nondia : 

defines the limit for the amount of local memory allocated to nondialog 


abap/heap_area_total: 

Defines the limit for the total amount of heap memory allocated to all

Hardware and Operating System SAP R/3 Basis ... - SAP Techies

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?