LESSON 2 : SAP ARCHETECHERE AND DESIGN

  SAP ARCHETECHERE AND DESIGN

Previously we have discussed regarding SAP Navigation in the first lesson.Here we are going to discuss regarding system architecture an design.

SAP SYSTEM KERNAL :

In SAP terminology, a service means a service provided by a software component and this component can consist of a process or a group of processes 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).

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).

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.

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.

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").

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).

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.

The start of an SAP transaction is also the start of an SAP - LUW. SAP - LUWs are completed either by a "COMMIT WORK" in the ABAP code, or by the completion of the corresponding asynchronous update (second part of the SAP - LUW). As explained previously, each dialog step in an SAP - LUW is processed by one work process, as is the case for the DB - LUW. Each database change is executed in its own DB-LUW.

The asynchronous updating usually used in an SAP - LUW allows the system to temporarily collect changes made by users and then, at the end of the dialog phase (in the second part of the SAP - LUW), make the necessary changes to the database in a separate update work process. To ensure data consistency, the resulting database change (which includes every “dialog step change”) is executed in only one final DB - LUW.

Background work processes are designed for periodic tasks such as reorganization or the automatic transfer of data from an external system to the R/3 System.

Background processing is scheduled in the form of jobs. Each job consists of one or more steps (ABAP reports, external programs, or other operating system calls), that are processed sequentially.

You can also set priorities (from "C" to "A") so that certain jobs are prioritized.

Job processing is not generally triggered immediately (immediate start). Instead you specify a start date and time when you schedule the job. It may also be necessary to start jobs periodically, for example, system control jobs repeated on a fixed cycle. Using the program SAPEVT, you can trigger a job start at the operating system level.

The background scheduler is responsible for automatically triggering the job at the specified time.

The background scheduler is an ABAP program that regularly looks in the scheduling table for jobs to be executed and then ensures that they are executed (RDISP/BTCTIME, default 60 s).

Spooling refers to the buffered transfer of data to output devices such as printers, fax devices, and so on. In distributed systems, networked administration is necessary for this output.

The R/3 System spool mechanism can supply print requests to printers and external spoolers both within a local network as well as across wide-area networks (WANs). The spool mechanism works with the local spool system on each server.

Spool requests are generated in dialog mode or during background processing and are then set in the spool database with details about the printer and the print format. The data itself is stored in the TemSe (TEMporary SEquential object) database.

When data is to be printed, a print request is generated for a spool request. This print request is processed by a spool work process.

Once the spool work process has formatted the data for output, it returns the print request to the operating system spool system.

The operating system spool takes over queue management and ensures that the required data is passed to the output device.

An instance is an administrative unit that combines R/3 System components providing one or more services. The services provided by an instance are started or stopped together. You use a common instance profile to set parameters for all the components of an instance.

A central R/3 System consists of a single instance providing all the necessary R/3 System services.

Each instance has its own SAP buffer areas.

The message server provides the application servers with a central message service for internal communication (for example, trigger update, request and remove locks, trigger background requests).

The dispatchers for the individual application servers communicate through the message server, which is installed once in each R/3 System (it is configured in the R/3 System profile files).

Presentation servers can also log on to an application server through the message server. This means that you can use the message server performance database for automatic load distribution (logon load balancing).