SAP ARCHITECTURE
SAP based
the architecture of R/3 on a three-tier client/server model. In a three-tier
client/server configuration, the presentation servers, applications servers,
and database server all run on separate machines
1.Presentation server
The presentation server is actually a program named
sapgui.exe. It is usually installed on a user’s workstation. 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
2.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
Contains of
profile:
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
3.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
Architecture of SAP R/3
Two elements
are needed:
Design:- Based on a modular multitier software
client/server principle
Architectural components: - The processes and
software modules which offer the services.
Note: - The
environment for the R/3 applications, built on the ABAP development workbench
and the ABAP repository
SAP R/3 is one of the main products of SAP,where R stands
for RealTime and the number 3 relates to three tier application
architecture(Data base,Application Server and Client).
The SAP
Business Suite consists of:
1.SAPERP
2.SAP
Industry Suite
3.SAP
NetWeaver
All the
applications from the SAP Business Suite are powered by SAP NetWeaver.
The features of the R/3 basis system
1.The client/server architecture and configuration
2.The use of relational database management
systems
3.Graphical user interface design for presentation
An SAP
system has only one database to store the application data. The database
Contains one
schema or in the extended version two schema (one for ABAP based
Application
data and another for JAVA based application data).
ABAP
For ABAP
based applications, you need the Central
Instance (ABAP-dispatcher, work processes and ABAP message server) to
complete an SAP system.
JAVA
For Java
based applications, you need a central
instance (JAVA-dispatcher and server processes) and the Central Services Instance (Message
Server and Enqueue) to complete an SAP system.
Note:Connectivity
between SAP NetWeaver Application Server Java and SAP NetWeaver AS ABAP is
available via SAP Java Connector (JCo).
WORKING
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:
·
User context
·
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.
Understanding
a Dialog Step
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
There are
four ways the user can initiate a dialog steps 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.
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
Dispatcher
The SAP Web dispatcher is located between the Web client
(browser) and your SAP system that is running the Web application.It forwards
the incoming requests (HTTP, HTTPS) in turn to the application server (AS) of
the SAP system. The number of requests that are sent to an AS depends on its
capacity. The capacity of an AS ABAP depends on the number of configured dialog
work processes
Work Processes
·
Dialog
work process
The Dialog work
process fulfils all requests for the execution of dialog steps triggered by an
active user. The dialog work process is not used for request which take long
time and which use more CPU. Every dispatcher requires at least two dialog work
processes. The dialog work process default time is 300 sec. If the dialog work
process does not respond in this time, it will be terminated. You can set the
maximum response time of dialog work process from transaction rz11 & set
the parameter rdisp/max_wprun_time to time you need. The no of dialog work
process can be changed by changing the parameter rdisp/wp_no_dia.
·
Spool
work process
The Spool work
process pass sequential data flows on to printers. Every SAP system requires at
least one Spool work process. However, there can be more than one per
dispatcher. The parameter to set the no of spool work process is
rdisp/wp_no_spo.
·
Background
work process
The background
work processes execute programs that run without user interaction. At least two
background work processes are required per SAP system. More than one background
work processes can be configured per dispatcher. Usually the background work
process are used for carrying jobs that take long time to finish, like client
copy, client transport etc.., Then no of background work process can be changed
by changing the parameter rdisp/wp_no_btc . There are two types of background
work process. They are A type and B type. A type background work process is
used for mission critical jobs. Background jobs of priority a have high
priority than B type back ground jobs.
·
Update
work process
Update work processes execute
update requests. You need at least one update work process per SAP system and
you can have more than one per dispatcher. The profile parameter rdisp/wp_no_vb
is used to control the no of update work process and rdisp/wp_no_vb2 for not of
update work process of type v2. There are two types of update work process.
They are v1 and v2. v1 update jobs have higher priority than v2 jobs. v1 jobs
are used for critical jobs. There must be at least one V1 update work process
in the SAP System. However there can be more than one.V2 modules describe less
critical secondary changes. These are pure statistical updates, for example,
such as result calculations.
·
Enqueue
Work Process
The Enqueue work process
administers the lock table in the shared memory. The lock table contains the
logical database locks of the ABAP stack. Only one Enqueue work process is
needed for each SAP system. This is present on the central instance. You can
determine or find an central instance by looking the various work process
present in it. For example, only the central instance contains Enqueue and
message work process. rdisp/wp_no_enq. It is not dynamically switchable.
·
Message
server work process
The SAP message server runs as a
separate process, mostly on the same host as the central instance. If an SCS
instance (SAP Central Services) or ASCS instance (ABAP SCS) is configured in
the system, the message server is part of this instance.
Only one message server can run
in each SAP system. It performs the following tasks in the SAP system:
■Central
communication channel between the individual application servers (instances) of
the system
■Load
distribution of logons using SAP GUI and RFC with logon groups
■Information
point for the Web Dispatcher and the application servers (each application
server of the system first’s logs on to the message server)
When an instance is started, the
dispatcher process contacts the message server so that it can announce the
services it provides (DIA, BTC, SPO, UPD, and so on). If the connection setup
to the message server fails, an entry is made in the system log (syslog).
If the message server stops
working, it must be restarted as quickly as possible to ensure that the system
continues to operate smoothly.
The following section explains
how to administrate, test, and monitor the message server.
· Gateway
work process
The SAP Gateway is made up of various processes:
Gateway Read Process
Gateway work process
(for SNA/DCAM only)
Gateway Monitor
These processes are described in the following
topics.
Gateway Read Process
Gateway read (gwrd, gwrd.exe) is the main
process in the gateway system.
It is started by the application server and checked
by it periodically.
It starts the work processes, and checks them
periodically. The gateway reader receives all CPI-Crequests. When connections are made via LU6.2, the
CPI-C requests are passed on to the corresponding work processes. For
connections via TCP/IP, the gateway reader deals directly with the
request.
Gateway work process
The gateway work process (gwwp, gwwp.exe) is
needed to set up a connection via LU6.2 or DCAM.
In this case the process is either started
dynamically by the gateway reader, or the request is passed to an active
gateway work process. A gateway work process can serve many connections.
Gateway Monitor
The gateway monitor (gwmon, gwmon.exe) is
used to analyse and administer the SAP Gateway.
You can start the monitor as required. When you
start it, you initially get a list of active CPI-C connections. You can call up
all the other monitor functions via a menu.
If you are looking to buy bitcoins online, Paxful is the best source for bitcoins as it allows buying bitcoins by 100's of payment methods, such as Western Union, MoneyGram, PayPal, Credit Card and even exchanging your gift cards for bitcoins.
ReplyDelete