On third day of my training I learned about the client-server architecture and the details of R/3 system architecture. A brief of all is given as under.
Understanding Client/Server
Here we see Program 1
asking Program 2 for some information. Program 1 is the client and
Program 2 is the server. Program 2 serves Program
1 with the information it requested. This is different than a main program
calling a subroutine and returning. A program that calls a subroutine transfers
control to the subroutine and cannot perform any processing until the
subroutine returns control.
With client/server,
the client and server programs are independent processes. If the client sends a
request to the server, it is free to perform other work while waiting for the
response.
When the client and
server programs both run on the same computer, the configuration is referred to
as single-tier client/server. (A tier is
the boundary between two computers.) When they run on different computers, the
configuration is referred to as two-tier client/server.
A program can
function as both a client and a server if it both requests
information and replies to requests. The client/server configuration enables
the R/3 system to spread its load across multiple computers. This provides the
customer with the ability to scale the processing power of the system up or
down by simply adding another computer to an existing configuration, instead of
replacing a single computer that performs all of the processing.
R/3 System Architecture
SAP based the
architecture of R/3 on a three-tier client/server model.
The R/3 system architecture.
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 we 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 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.
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 our 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.
Program Buffer and the Roll Area
Programs are buffered on the application server in a program buffer. When a user makes a request to run a program, a search is done in the program buffer for it. If it is found, and if it has not been modified in the database, the buffered copy is used. If not, or if the copy in the database is newer, the program is reloaded.
A separate copy of the program is not made in memory for each user who executes it. Instead, all users execute the same copy of the program. The differentiating factor is a separate memory allocation called a roll area.One roll area is allocated per execution per user per program. The system uses the roll area to hold all information about the current execution of the program and all memory allocations. Information such as the variables and their values, the current program pointer, and the list output are all kept in the roll area. For example, suppose a user executes a program and a roll area is allocated. If, without waiting for it to finish, the user switches to another session and starts up the same program again, another roll area is allocated for the second execution of that program. The user has two roll areas, one for each execution of the program. If the user had instead run a different program, he would still have two roll areas, one for each program.
No comments:
Post a Comment