sap architechere and design

Published: 31st January 2008
Views: N/A

SYSTEM KERNAL :

In SAP terminology, a service means a service provided by a software component (software-oriented view). This component can consist of a process (compare work process) or a group of processes (compare application server) and is then called a server for that service.

Software components that use this service are called clients. At the same time, clients can also be servers for specific services.

A server often also means a computer (host) on which software components that provide specific software.

The fundamental services in a business application system are presentation services, application services, and database services.

In a one-tier R/3 System configuration, all processing tasks are performed on one server, as in classic mainframe processing.

Two-tier R/3 System configurations are usually implemented using special presentation servers that are responsible solely for formatting the graphical user interface. Many R/3 System users use Windows PCs for example as presentation servers. An alternative two-tier configuration (not shown) is to install powerful desktop systems and to use these for presentation and applications also (two-tier client/server).


This type of configuration is particularly useful for processing-intensive applications (such as simulations) or for software developers, but due to the additional administration requirements is usually used for test purposes only.


In a three-tier configuration, separate servers are used for each tier. Using data from the database server, several different application servers can operate at the same time. To ensure that the load on individual servers is as even as possible and to achieve optimal performance, you can use special application servers for individual application areas such as distribution or financial accounting (logon and load balancing).

Interpreter and ABAP Interpreter are presented here. Another topic is data exchange with the
database.

The central process in the R/3 application layer is the dispatcher. Together with the operating system, the dispatcher controls the resources for the R/3 applications. The main tasks of the dispatcher include distributing transaction load to the work processes, connecting to the presentation layer, and organizing communication.


User screen input is received by the SAP presentation program SAP GUI, converted into its own format, and then sent to the dispatcher. The processing requests are then saved by the dispatcher in request queues and processed according to "first in / first out".

The dispatcher distributes (dispatches) the requests one after the other to the available work processes. Data is actually processed in the work process. The user that sent the request through the SAP GUI is usually not assigned the same work process, because there is no fixed assignment of work processes to users.

Once the data has been processed, the processing result from the work process is sent through the dispatcher back to the SAP GUI. The SAP GUI interprets this data and generates the output screen for the user with the help of the operating system on the frontend computer.

During initialization of the R/3 System, the dispatcher executes the following actions, among others:

it reads the system profile parameters, starts work processes, and logs onto the message server (this service will be explained later).

Today, large amounts of data are usually administered using relational database management systems (RDBMS). These systems store the data and the relationships between the data in two dimensional tables, which are known for their logical simplicity. The definitions of the data, tables, and table relationships are stored in the data dictionary of the RDBMS.

Within ABAP, SAP OPEN SQL is used to access application data in the database, independent of the corresponding RDBMS. The R/3 database interface converts the open SQL statements from the ABAP statements into the corresponding database statements. This means that application programs written in ABAP are database-independent. Native SQL commands can be used in ABAP.

When interpreting open SQL statements, the R/3 database interface checks the syntax of these statements and automatically ensures the local SAP buffers in the shared memory of the application server are utilized optimally. Data frequently required by the applications is stored in these buffers so that the system does not have to access the database server to read this data.


In particular, all technical data such as ABAP programs, screens, and ABAP Dictionary information, as well as some business process parameters usually remain unchanged in a running system, making them ideal buffering candidates. The same applies to certain business application data, which is accessed as read-only.

The operating system views the R/3 runtime system as a group of parallel, cooperating processes. On each application server these processes include the dispatcher as well as work processes; the number of work processes depends on the available resources. Work processes may be installed for dialog processing, update, dialog free background processing and spooling.

n In addition to these work process types (dialog processing (D), update (V: for the German

"Verbuchung"), lock management (E), background processing (B), spool (S), the R/3 runtime

system provides two additional services for internal and external communication (below are the restrictions on the number of work processes):

. The message server (MS or M) communicates between the distributed dispatchers within the R/3 System and is therefore the prerequisite for scalability using several parallel-processing application servers.

. The gateway server (GW or G) allows communication between R/3, R/2 and external

application systems.

. Dialog: Every dispatcher requires at least two dialog work processes

. Spool: At least one for each R/3 System (more than one allowed for each dispatcher)

. Update: At least one for each R/3 System (more than one allowed for each dispatcher)

. Background processing: At least two for each R/3 System (more than one allowed for each dispatcher)

. Enqueue: Only one enqueue work process is needed for each system

n The lock mechanisms in today's relational database systems are usually not able to handle business data objects (such as customer orders) that affect several database tables. To coordinate several applications simultaneously accessing the same business object, the SAP System provides its own lock management, controlled by the enqueue work process.

n In order for the system to execute lock requests, you must first define a lock object in the ABAP Dictionary. The lock object contains tables whose entries are to be locked. A lock object consists of a primary table. You can also define additional secondary tables using foreign key relationships (the name of a user-defined lock object must begin with "EY" or "EZ").

n You can specify the lock mode ("S": shared lock or "E": exclusive lock) for a lock object. An exclusive lock (mode "E") can only be set if no other user has set a lock ("E" or "S") on the data record. The same user can request additional "E" or "S" locks within a program call sequence (call chain).

n If a lock object is activated, the system generates an ENQUEUE and a DEQUEUE function module.

These function modules are called ENQUEUE_ and DEQUEUE_ and are used in ABAP code to lock and unlock data.

check the complete article at

http://abapprogramming.blogspot.com/2007/06/abap-lesson-2-sap-archetechere-and.html

Report this article Ask About This Article


Loading...
More to Explore