Introduction To Sap Basis PDF

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.
Materials Management Production Planning
Finance and Controlling
Sales and Distribution
Human Resources
SAP R/3 Basis Software 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?

Platforms and Databases Supported by R/3 Operating Systems Supported Supported FrontHardware Ends AIX SINIX SOLARIS HP-UX Digital-UNIX Windows NT IBM SNI SUN Digital HP Bull AT&T Compaq Bull/Zenith HP (Intel) SNI IBM (Intel) Digital (Intel) Data-General OS/400 AS/400 Win95 OS/2 DB2/400 Win 3.1/95/NT OSF/Motif OS/2 Macintosh Win 3.1/95/NT OSF/Motif OS/2 Macintosh Supported Databases DB2 for AIX Informix-Online Oracle 7.1 ADABAS D Oracle 7.1 SQL Server 6.0 ADABAS D
2 of 44
Role of Basis Administrator
SAP R/3 System Administrator SAP R/3 Administrator
SAP R/3 Security Coordinator
SAP R/3 Database Administrator
SAP R/3 Correction and Transport Administrator
What is client server?
3 of 44
R/3 System Architecture
SAP based the architecture of R/3 on a three-tier client/server model/
Logical Grouping of layers
4 of 44
The Presentation Layer

Those SAP R/3 software components that specialize in interacting with end-users form the Presentation Layer.
The Application Layer

Those SAP R/3 software components that specialize in processing business applications form the Application Layer.
The Database Layer
Those SAP R/3 software components that specialize in the management, storage and retrieval of data form the Database Layer
Three tired client server Architecture [ Logical View ]
Communication
5 of 44
The Presentation Layer collects user input and creates process requests. The Application Layer uses the application logic of SAP programs to collect and process the process requests. The Database Layer stores and retrieves all data.
Physical Distribution of R/3 Logical Layers
Presentation Layer components reside in:
Application Layer components reside in:
Database Layer components reside in:
Presentation servers: Systems capable of providing a graphical interface.
Application servers: Specialized systems multiple CPUs and vast amounts of RAM.
Database servers: Specialized systems with fast and large hard drives.
Physical Distribution of R/3 s Three Layered Client server Architecture
6 of 44
Presentation Layer components are installed across many PCs.
The Application Layer components are installed across one or more highend servers. The Database Layer components are installed on one high-end 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:
7 of 44
Introduction To SAP R/3 Basis ----------------------------------------------------------
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
Centralistic
Computer A
Presentation Layer Application Layer Database Layer
8 of 44
Computer A Computer A-1 Computer A-2 Computer A-n
Distributed Presentation
Computer B
Computer A Computer A-1 Computer A-2 Computer A-n
Two tier Client/Server
Computer B
9 of 44
Three tier Client/Server

Computer A Computer B Computer C
Computer A-1
Computer B-1
Computer A-2 Computer A-n
Computer B-n
Multi-tier, cooperative Client/Server

Computer A Computer A-1 Computer A-2 Computer A-n Computer B-1 Computer B
Computer C
Computer C-n
Computer B-n
10 of 44
Introduction To SAP R/3 Basis ----------------------------------------------------------Computer A Computer A-1 Computer A-2 Computer A-n Computer B-1 Computer B-n
Computer B
Computer C
Computer C-n
Distributed Applications?
PS PP MMINV
MMPUR
GL
CO SDSHP
MMINV
SAP R/3 Database Administrator
One central system is not always optimal for unifying business processes with integrated applications
11 of 44
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
12 of 44
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
13 of 44
Introduction To SAP R/3 Basis ----------------------------------------------------------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 D (Dialog) V (Update) B (Background) S (Spool) E (Enqueue) M (Message) Request Type Dialog requests Requests to update data in the database Background jobs Print spool requests Logical lock requests Routes messages between application servers within an R/3 system Funnels messages into and out of the R/3 system
G (Gateway)
14 of 44
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.
15 of 44
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
16 of 44
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.
17 of 44
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.
18 of 44
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.
19 of 44
Introduction To SAP R/3 Basis ----------------------------------------------------------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.
20 of 44
Work Process Multiplexing and SAP Transactions
21 of 44
Locks in R/3 at the Business Process Level
22 of 44
Requesting a Lock From the Enqueue WP
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 SAPLUW)
When
23 of 44
Asynchronous Update
Updating Log Records
24 of 44
Background Processing
The R/3 Instance
25 of 44
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.
26 of 44
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
27 of 44
R/3 Memory I: Local Memory for Work Processes
28 of 44
R/3 Memory II: R/3 Buffers
29 of 44
R/3 Memory III: Extended Memory
30 of 44
R/3 Memory IV: Heap Memory
31 of 44
R/3 Memory V: Roll Memory
32 of 44
R/3 Memory VI: Paging Memory
33 of 44
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. 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 A
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.
34 of 44
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
35 of 44
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.
36 of 44
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.
37 of 44
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.
38 of 44
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
39 of 44
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.
40 of 44
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.
41 of 44
Allocation Sequence for Non-Dialog WPs
42 of 44
Memory Management Parameters
43 of 44
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 work processes abap/heap_area_total: Defines the limit for the total amount of heap memory allocated to all work processes
44 of 44

Introduction To Sap Basis PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Introduction To Sap Basis PDF

Transféré par

Droits d'auteur :

Formats disponibles

Introduction To SAP R/3 Basis -----------------------------------------------------------

Materials Management Production Planning

Finance and Controlling

Sales and Distribution

SAP R/3 Basis Software Hardware and Operating System

Compiled By: Ashwin Vavaiya

Introduction To SAP R/3 Basis -----------------------------------------------------------

What platforms does R/3 support?

Compiled By: Ashwin Vavaiya

Introduction To SAP R/3 Basis -----------------------------------------------------------

Role of Basis Administrator

SAP R/3 System Administrator SAP R/3 Administrator

SAP R/3 Security Coordinator

SAP R/3 Database Administrator

SAP R/3 Correction and Transport Administrator

What is client server?

Compiled By: Ashwin Vavaiya

Introduction To SAP R/3 Basis -----------------------------------------------------------

R/3 System Architecture

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

Logical Grouping of layers

Compiled By: Ashwin Vavaiya

Introduction To SAP R/3 Basis -----------------------------------------------------------

The Presentation Layer

The Application Layer

The Database Layer

Three tired client server Architecture [ Logical View ]

Compiled By: Ashwin Vavaiya

Introduction To SAP R/3 Basis -----------------------------------------------------------

Physical Distribution of R/3 Logical Layers

Presentation Layer components reside in:

Application Layer components reside in:

Database Layer components reside in:

Presentation servers: Systems capable of providing a graphical interface.

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

Compiled By: Ashwin Vavaiya

Introduction To SAP R/3 Basis -----------------------------------------------------------

Presentation Layer components are installed across many PCs.

Compiled By: Ashwin Vavaiya

Introduction To SAP R/3 Basis ----------------------------------------------------------

Compiled By: Ashwin Vavaiya

Introduction To SAP R/3 Basis -----------------------------------------------------------

Computer A Computer A-1 Computer A-2 Computer A-n

Computer A Computer A-1 Computer A-2 Computer A-n

Two tier Client/Server

Compiled By: Ashwin Vavaiya

Introduction To SAP R/3 Basis -----------------------------------------------------------

Three tier Client/Server

Computer A-2 Computer A-n

Multi-tier, cooperative Client/Server

Compiled By: Ashwin Vavaiya

SAP R/3 Database Administrator

Compiled By: Ashwin Vavaiya

Introduction To SAP R/3 Basis -----------------------------------------------------------

Compiled By: Ashwin Vavaiya

Introduction To SAP R/3 Basis -----------------------------------------------------------

SAP Application Server Architecture & System Kernel

Compiled By: Ashwin Vavaiya

Understanding the Types of Work Processes

Compiled By: Ashwin Vavaiya

Introduction To SAP R/3 Basis -----------------------------------------------------------

Dialog Work Process execution sequence

Compiled By: Ashwin Vavaiya