sap - hr - basic.doc

7/27/2019 SAP - HR - Basic.doc

1/9

SAP (System, Application &

Product)

SAP (System Application and Product) is the name of the biggest European German

Software company as well as the name of software itself.The company wasfounded in 1972 by the five IBM employees.

SAP R/3 Software has been developed using ABAP/4 as a programming language.

SAP is the ERP (Enterprise Resource Planning) system that aims to integrate all the

different modules (SD, MM, CO, HR etc.) in the company. The integration results in

consistency of data throughout the system and the company as a whole.

SAP R/3 is one of the main product of SAP, where R stands for Real Time and thenumber 3 relates to three tier application architecture (Data base, Application

Server and Client). Most of the business in todays world runs on SAP R/3 system.

About 80% of the companies implemented this software.

Internet communication Manager(ICM)-set up connection to internet.Supports protocol HTTP,SMTP.


2/9

Dispatcher distributes the requests to the work processes. If all the processesare occupied then the requests are stored in dispatcher queue.

ABAP Work Process executes the ABAP code.

SAP gateway makes the RFC interface between SAP instances available.

Message server exchanges the messages and balances the load.

ICM uses the threads to parallelize the load that comes up.

THREE TIER ARCHITECHTURE

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 usuallyinstalled on a users workstation. To start it, the user double-clicks on an iconon the desktop or chooses a menu path. When started, the presentation

server displays the R/3 menus within a window. This window is commonlyknown as the SAPGUI, or the user interface (or simply, the interface). Theinterface accepts input from the user in the form of keystrokes, mouse-clicks,and function keys, and sends these requests to the application server to beprocessed. The application server sends the results back to the SAPGUI whichthen formats the output for display to the user.

Application Server


3/9

An application server is a set of executables that collectively interpret theABAP/4 programs and manage the input and output for them. When anapplication server is started, these executables all start at the same time.When an application server is stopped, they all shut down together. Thenumber of processes that start up when you bring up the application server isdefined in a single configuration file called the application server profile.

Each application server has a profile that specifies its characteristics when itstarts up and while it is running. For example, an application sever profilespecifies:

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/4program can start an executable on the presentation server, but an ABAP/4program 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 requestsfrom the application server. These requests are passed on to the RDBMS(Relation Database Management System). The RDBMS sends the data back tothe database server, which then passes the information back to theapplication server. The application server in turn passes that information toyour ABAP/4 program.

There is usually a separate computer dedicated to house the databaseserver, 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. Thisis the most common configuration for large systems, and is common inproduction.

In the distribution presentation configuration, the application and databaseservers are combined on one computer and the presentation servers runseparately. This is used for smaller systems, and is often seen on adevelopment system.

In the two-tier client/server configuration, the presentation and applicationservers are combined and the database server is separate. This configurationis used in conjunction with other application servers. It is used for a batchserver when the batch is segregated from the online servers. A SAPGUI isinstalled on it to provide local control.

When all servers are combined onto a single machine, you have a centralconfiguration. This is rarely seen because it describes a standalone R/3system with only a single user.


4/9

Defining an R/3 System

The simplest definition of an R/3 system is one database. In one R/3system, there is only one database. To expand the definition, R/3 isconsidered to be all of the components attached to that one database. OneR/3 system is composed of one database server accessing a single database,one or more application servers, and one or more presentation servers. Bydefinition, it is all of the components attached to one database. If you haveone database, you have one system. If you have one system, you have onedatabase. During an implementation, there is usually one system (or onedatabase) assigned to development, one or more systems designated fortesting, and one assigned to production.

The term R/3 system landscape denotes a description of the number ofsystems within an SAP installation and how they are designated, such asdevelopment, test, or production.

Defining an R/3 Instance

When you hear someone say the word instance, most of the time, that personwill be referring to an application server. The term instance is synonymouswith application server.

The term central instance refers to the database server. If an applicationserver and database server both reside on the same machine, the termcentral 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 processesproviding services to the R/3 system.

Application Server Architecture

All requests that come in from presentation servers are directed first to thedispatcher. The dispatcher writes them first to the dispatcher queue. The dispatcherpulls the requests from the queue on a first-in, first-out basis. Each request is thenallocated to the first available work process. A work process handles one request ata time.

To perform any processing for a users request, a work process needs to addresstwo special memory areas: the user context and the program roll area. The usercontext 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 userthat is logged on the R/3 system. It holds information needed by R/3 about the user,such as:

The users current settings The users authorizations


5/9

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, itis freed. It is used during program processing, and its importance is describedfurther in the following sections.

Understanding a Roll Area

A roll area is memory that is allocated by a work process for an instance of aprogram. It holds information needed by R/3 about the programs execution, suchas:

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 theprogram. If two users run the same program at the same time, two roll areas willexist-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 torefer 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 isused.

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

processing.

Understanding a Dialog Step

Dialog step is used by Basis consultants as the unit of measure for system responsetime.

A dialog step is the processing needed to get from one screen to the next. Itincludes all processing that occurs after the user issues a request, up to andincluding the processing needed to display the next screen. For example, when theuser clicks the Enter key on the Change Vendor: Initial Screen, he initiates a dialog

step and the hourglass appears, preventing further input. The sapmf02k programretrieves the vendor information and displays it on the Change Vendor: Addressscreen, and the hourglass disappears. This marks the end of the dialog step and theuser 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.


6/9

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 theyform 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 thebeginning of the dialog step, the roll area and user context are rolled in to the workprocess. 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 thework process. This enables the work process to access the data in those areas andso 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. Theprogram is now only occupying memory, and not consuming any CPU. The user islooking 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 dispatcherallocates that request to the first available work process. It can be the same or adifferent work process. The user context and roll area for that program are againrolled in to the work process, and processing resumes from the point at which it wasleft off. Processing continues until the next screen is shown, or until the programterminates. If another screen is sent, the areas are again rolled out. When theprogram 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 programswill be active in work processes at any one time. When they are not occupying awork process, they are rolled out to extended memory and only occupy RAM. Thisconserves 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 Windowsevents. The events that generate a lot of messages such as key presses, focuschanges, 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 otherWindows programs. For example, in ABAP/4, you cannot validate the contents of afield when the user presses the Tab key. You must instead wait until the userinitiates a dialog step.

Discovering How the Data Is Sent to the Presentation Server


7/9

The messages exchanged between the presentation server and the applicationserver are in an SAP proprietary format. The SAPGUI accepts the screen informationsent from the application server and formats it appropriately for the platform it isrunning on. This enables different end-user hardware platforms to connect to asingle 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 theappropriate 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 ofABAP/4. One is the full-blown ABAP/4 data processing language and the other is avery specialized screen processing language. Each is processed by its owninterpreter.

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 inTable 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 betweenapplication servers within an


8/9

R/3 system

G (Gateway) Funnels messages into and outof 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 eachclient-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 lengthwill 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 thisprogram 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. Thereare five rows in the table, but the program writes out only those rows where mandtequals 800. If the user were to log on to client700 and run the same program, threerows 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 intodistinct 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 foryou 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 anenhancement to the billing system. Jim is modifying the update transaction and Janeis creating a new report to go with Jims modifications.

Jane sets up data for her test run, executes her report and obtains output. Jim worksin the next cubicle, but due to his antisocial tendencies is blissfully unaware that his


9/9

transaction uses the same tables as Janes report. He runs his transaction andupdates the data. Jim got what he wanted, but Jane then modifies her code and runsher program again. Her output differs from the last run, and the differences manynot result from her changes, but rather they may result from Jims changes. Whatwe have here is a failure to communicate.

If the tables used by Jim and Janes programs were client-dependent, they couldeach log in to separate clients, set up independent sets of data, and test theirprograms without ever talking to each other. They could perform all of their testingin 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 andthe R/3 system will take care of the rest. When records are added to the table, thesystem automatically moves the current logon client into the mandt field when therecord is send to the database. Their Open SQL select statements will only returnrows where the client number in the table is equal to the their current logon clientnumber. The Open SQL database statements insert, update, modify, and delete alsoprovide automatic client handling.

If the tables involved are all client-dependent, there can be more than one group oftesters working at a time in one test system. Two teams of testers can testdivergent functionality in the same set of programs at the same time provided theylog on to different logon clients. The updates done by one team will not change thedata belonging to the other team.

A training client could also exist on the test system. The students could log on toone client and the testers could log on to another. Both would run the same set ofprograms, 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 iscommon to have fromthree to six clients in the development and test systems, butrarely will you see more than one client in production.

sap - hr - basic.doc

Documents