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 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.
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.
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 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.
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.
No comments:
Post a Comment