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

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

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.

What Are Different Types of Internal Tables and Their Usage

What Are Different Types of Internal Tables and Their Usage

Standard Internal Tables

Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition.

This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to
the number of table entries.

Sorted Internal Tables

Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique, or non-unique, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables.

This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognized before they are inserted. The response time for access using the key is in logarithmic relation to the number of
table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key.

Hashed Internal Tables

Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition.

This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and
using internal tables that are similar to database tables.

Index Tables

Index table is only used to specify the type of generic parameters in a FORM or FUNCTION. That means that you can't create a table of type INDEX.

Internal tables are not DB tables. Standard and Sorted tables in combined are basically called as Index tables and there nothing else. Here is the hierarchy

ANY TABLE
|
--------------------------------
| |
Index Tables Hashed Table
|
--------------------------------
| |
Standard Table Sorted Table

SAP R/3 ABAP Introduction

Systems Application Production Release / Three Tire Architecture

Leading ERP's -> Enterprise Resource Planning
Oracle Applications
Oracle Manufacturing
Oracle HRMS
Oracle Finance

High End ERP's -> MNC's.
For MNC's -> SAP R/3, Oracle Applications, People Soft.

Mid Range ERP's - > Small & Medium Scale Company's.
For Small & Medium Scale -> BOAN, RAMCO, JDEDWARDS

Languages Designed by ERP's

SAP R/3 -> ABAP
Oracle Applications -> SQL
People Soft -> People Code

ABAP -> Advanced Business Application Programming

SAP R/3 -> ABAP Language
In this we have 17000 predefined tables.
In this we have 1300 predefined applications.

ABAP Language functionality is
For Modifying predefined applications &
Creating new applications.

SAP R/3 -> BDC

Concept of BDC can transfer the data from Non-SAP to SAP using ABAP BDC.
BDC stands for Batch Data Conversation.

SAP R/3 -> Reports
ABAP Reports is for designing Reports under SAP R/3.
i.e., Extracting Data from data base.

SAP R/3 -> Scripts
ABAP Scripts Provides interface between SAP R/3 and Business Partners.

Prerequisites for SAP R/3
-----------> SQL Statements
-----------> Table Creation in Oracle
-----------> Object Oriented Concept

Hardware Profile
160 GB Hard Disk
1 GB RAM
PIV On Words
Installation Time 42 Hours

In SAP R/3 Leading & Successful Versions
-----------> 4.0 A
-----------> 4.0 B
-----------> 4.5 A
-----------> 4.5 B
-----------> 4.6 A
-----------> 4.6 B
-----------> 4.6 C &
-----------> 4.7 Also called as 4.7 EE (Enterprise Edition)

4.7 is the Latest version of SAP R/3.

In real time environment maximum implementations using 4.6C and 4.7.

Available software’s in SAP R/3
-----------> IDES
IDES is authorized institutes (For Institute Purpose).
IDES stands for International Demo Educational System.

-----------> Production Software
Production Software is for Organizations.

History of SAP R/3
SAP R/3 is the product of SAPAG (AG stands for LTD)

* SAPAG is a German based organization.
* SAP R/3 is released in 1992.
* SAP R/3 can work based on RDBMS.
* ABAP Language designed based on ' C ' Language.

Advantages of SAP R/3
* Platform independent.
* Even it’s a Database independent.

Under SAP R/3 Projects
--------> As an ABAP Programmer

1. Life Cycle Implementation
* Also called as End-To-End Implementation.
* Implementing SAP R/3, all new implementations are the part of "Life Cycle Implementation".

2. Upgradation
* Upgradation is upgrading version to version.
i.e., 4.0 A to 4.7

3. Support
* Support means modification in existing objects.

ABAP Methodology
Using this method we developed in SAP R/3.
Methods are
-------> Accelerator SAP
-------> SAP Solution Manager

SAP R/3 -> RFC

* RFC Stands for Remote Function Call.
* RFC Provides interface across SAP R/3 Systems.

SAP R/3 -> BAPI's

* BAPI's stands for Business Application Programming Interface's.
* It provides interface between SAP R/3 with Non-SAP front ends.

SAPAG
/ \
SAP R/3 New Dimensional
\
-> SAP-BI or BW (Business Warehousing Product)
-> SAP-Netweaver (Web Based)
-> ECC ( Enterprise Central Component)
7.0 is the latest version of ECC.

SAP Memory Management and SAP Instance

SAP R/3 Communication Protocols and Interfaces contexts and thus avoid the overhead caused by heavy roll−in/roll−out tasks of previous releases. User context is defined as the user data which is kept by the system between dialog steps to continue the processing of the transaction. These data contain such things as authorizations, field information, internal tables, runtime environment management information, and so on. Roll−in is the process of making the data available to the work processes when they need it.

With the extended memory management functions, all user contexts of an application server are held in main memory and are shared by all work processes. In previous releases, the user contexts were in the roll files and had to be copied from one place to another when user sessions were handled by different work processes. With the new memory management, those previous copy functions (copying user contexts to roll areas) are handled by just reassigning pointers in main memory.

With this technique there is a significant improvement in performance, since context switching is a very frequent task when attending to interactive users. In order to observe the real improvements, the system needs more memory and swap space than previous versions.

With SAP releases prior to 3.0, the user context area used by the dialog processes was limited to the size of the roll area. The new memory management allows the size of this area to be extended as the size of user contexts increases. All the data in the user context is directly accessible .

Work processes memory allocation. SAP, and not the operating system, takes care of page management for the user contexts which are held in shared memory because SAP's strategy is for openness and thus it is platform−independent.

This shared memory is technically implemented using an unnamed mapped file. In UNIX systems, this means that the address space is mapped onto the operating swap space. For more information on memory mapping, refer to the operating system manuals or online help.

To tune and configure memory management, make sure that your system meets all requirements regarding memory and swap space. SAP automatically sets some default parameters depending on your particular configuration. There are some utilities available for monitoring the operation of the memory management to later fine−tune it.

The Concept of a SAP Instance

An instance is an administrative entity that groups together R/3 components which offer one or several services. These offered services are started or stopped together. All instance components are configured using a common instance profile. For more information on SAP profiles please refer to the section entitled .

A centralized SAP R/3 system would be made of a unique instance. Another feature which distinguishes the instances is that every SAP instance has its own buffer area, which means that it allocated its own main memory space.

SAP distinguishes between central instances and dialog instances. Every SAP system has just one central instance, which contains all basic services such as the message server, gateway, update, enqueue, dialog, spool, and background right from installation. Dialog instances, as defined, only contain a set of basic services such as dialog and background work processes from the time of installation.

Administrators can later customize all the services and their server locations by using SAP instance profiles. A central system can be further configured to a distributed system, creating additional instances offering additional services. The usual way of configuring the system right out of the box is to have just one instance per computer; however, providing your systems have enough main memory and processing power, you can install additional instances, which have some advantages.

Building the Client/Server SAP R/3 System

Once all the processes and components which make up the SAP system are known, we can see how all these pieces come together to form a whole client/server R/3 system.

The starting point is a server system (hardware point of view) with the required memory, disks, network controller cards, and operating system.

On this first server, add the relational database management system with its corresponding database processes. At this moment, you have the database server. The database is, of course,
installed on the disks connected to this computer server.

Now, add basic R/3 services (work processes). We have added a printer to this system to get a connection between the SAP spool work process and the host spool system.