SAP ARCHITECTURE

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.