Documente Academic
Documente Profesional
Documente Cultură
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.
Human Resources
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?
2 of 44
3 of 44
4 of 44
Those SAP R/3 software components that specialize in the management, storage and retrieval of data form the Database Layer
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.
Application servers: Specialized systems multiple CPUs and vast amounts of RAM.
Database servers: Specialized systems with fast and large hard drives.
6 of 44
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
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
Distributed Presentation
Computer B
Computer B
9 of 44
Computer A-1
Computer B-1
Computer B-n
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
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
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
G (Gateway)
14 of 44
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.
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.
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.
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
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
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
21 of 44
22 of 44
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
24 of 44
Background Processing
25 of 44
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)
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
27 of 44
28 of 44
29 of 44
30 of 44
31 of 44
32 of 44
33 of 44
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.
34 of 44
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
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
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
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
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
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
42 of 44
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