Académique Documents
Professionnel Documents
Culture Documents
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 was founded 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 the number 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.
Dispatcher distributes the requests to the work processes. If all the processes are 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.
Presentation Server
The presentation server is actually a program named sapgui.exe. It is usually installed on a users 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: 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 .
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.
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.
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.
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.
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
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.
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.
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 .
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 the ABAP/4 interpreter and the screen ABAP/4. One is the full-blown ABAP/4 very specialized screen processing interpreter. code. Notice that there are two interpreters: interpreter. There are actually two dialects of data processing language and the other is a language. Each is processed by its own
The database interface handles the job of communicating with the database.
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
G (Gateway)
R/3 system Funnels messages into and out of the R/3 system
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 Jims 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 Janes 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 Jims changes. What we have here is a failure to communicate. If the tables used by Jim and Janes 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.