SAP R/3 Architecture explained

What is SAP R/3 architecture? Explain SAP R/3 architecture in detail SAP r/3 is a three layer architecture

+ -

Note: Don`t be panic to read and understand below, the below is the complex and detailed explanation, you will understand this in next lessons

As name suggests SAP R/3 has three layers
  • Presentation Layer
  • Application Layer
  • Database Layer

SAP R/3 Architecture in detail

SAP R/3 Architecture

Presentation Layer

Presentation layer is the first layer of R/3. This is the top layer of the system. Presentation layer presents the end user how an SAP system looks at the front end for performing transactions (operations of end user).

This layer consists of GUI’s (Graphical User Interface), an interface which connects the system and the end user to perform transactions. GUI’s are installed in the system to use the application. Each and every end user system has a GUI application. If there are 100 end users in an organization, all the end users will be accessing SAP through a GUI installed in their systems. GUI’s may be a Windows application / Java application / an HTML application. With the help of these GUI applications, the end users operate on SAP.

Application Layer

The Application Layer is the middle layer of R/3 architecture. This layer is the heart of SAP R/3 products. This layer consists of the application. All Transactions of the end user are performed in this layer. An application in the Application Layer consists of 5 components.

  • Dispatcher
  • Gateway
  • Buffering
  • Work Process (WP)
  • Message

SAP R/3 Architecture

Component 1: Dispatcher

The Dispatcher acts as an interface between the application layer and the presentation layer. The requests of the user from the presentation layer enter the application via a dispatcher. After the request is processed, the response to the user is given back through the dispatcher.

Component 2: Gateway

The Gateway is another type of an interface. This interface connects the application in the application layer with the RDBMS (database) in the database layer. Here, during the process of the transaction, the request for added / delete / search / retrieval of data, to/ from the RDBMS flows via the Gateway.

Component 3: Buffering

The Buffering (or a buffer) is the temporary storage area for data in order to perform transactions with those data. Usually, data are stored as Tables in RDBMS. Transactions are performed in an area called Work Process (WP). Frequently changing tables (data) are stored in the buffer and transactions are processed with data from the buffer. It does not directly process with data from the RDBMS. Eg., the data regarding Currency of nation as stored in the Buffering area of the application since the value of a currency changes everyday.

The transaction time for each transaction when processing via buffering is 0.2 milliseconds. While, the transaction time for each transaction when processing directly via RDBMS is 6 milliseconds. Hence, to increase the performance, almost all transactions are processed via buffering and not directly via RDBMS.

Component 4: Work Process (WP)

The Work Process is the actual transaction processing area in an application. Work Processes execute the dialog steps of application programs, i.e., it actually processes the transactions. The work process (WP) consists of 3 components.

  • Dialog
  • ABAP processor
  • Database Interface

SAP R/3 Architecture

Dialog: Dialog is also called as Screen Processor. From a programming point of view, user interaction is controlled by screens. A screen consists of flow logic. The screen flow logic controls a large part of the user interaction. The R/3 Basis system contains a special language for programming screen flow logic. The screen processor executes the screen flow logic. Via the dispatcher, it takes over the responsibility for communication between the work process and the GUI, calls modules in the flow logic, and ensures that the field contents are transferred from the screen to the flow logic.

ABAP Processor: The actual processing logic of an application program is written in ABAP – SAP’s own programming language. The ABAP processor executes the processing logic of the application program, and communicates with the database interface. The screen processor tells the ABAP processor, which module of the screen flow logic should be processed next.

Database Interface: The database interface provides the following services:

  • Converts Open SQL into Native SQL of the application.
  • Establishing and terminating connections between the work process and the database.
  • Access to database tables.
  • Access to R/3 Repository objects (ABAP programs, screens and so on).
  • Access to catalog information (ABAP Dictionary).
  • Controlling transactions (commit and rollback handling).
  • Table buffer administration of the application server.

Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They allow you to access data irrespective of the database system that the R/3 installation is using. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data. The tasks of the Data Definition Language (DDL) and Data Control Language (DCL) parts of Standard SQL are performed in the R/3 System by the ABAP Dictionary and the authorization system. These provide a unified range of functions, irrespective of database, and also contain functions beyond those offered by the various database systems.

Native SQL is only loosely integrated into ABAP, and allows access to all of the functions contained in the programming interface of the respective database system. Unlike Open SQL statements, Native SQL statements are not checked and converted, but instead are sent directly to the database system. Programs that use Native SQL are specific to the database system for which they were written. R/3 applications contain as little Native SQL as possible. In fact, it is only used in a few Basis components (for example, to create or change table definitions in the ABAP Dictionary).

Types of Work Processes

The services offered by an application server are determined by the types of its work processes.

  • Dialog Work Process:

Dialog work processes deal with requests from an active user to execute dialog steps.

  • Update Work Process:

Update work processes execute database update requests. Update requests are part of an SAP LUW (Logical Unit of Work) that bundle the database operations resulting from the dialog in a database LUW for processing in the background.

  • Background Work Process:

Background work processes, process programs that can be executed without user interaction (background jobs).

  • Enqueue Work Process:

The enqueue work process, administers a lock table in the shared memory area. The lock table contains the logical database locks for the R/3 System and is an important part of the SAP LUW concept. In an R/3 System, you may only have one lock table. You may therefore also only have one application server with enqueue work processes.

  • Spool Work Process:

The spool work process passes sequential datasets to a printer or to optical archiving. Each application server may contain only one spool work process. Here Spool Numbers are generated and actions are performed according to the order of spool number.

Component 5: Message

Message is used for Internal Communication between applications in the application layer. It uses "Idoc" to exchange information. Idoc, short for Intermediate Document, is a SAP document format for transferring the data for a business transaction. Idoc is similar to XML in purpose, but differs in syntax. Both serve the purpose of data exchange and automation in computer systems.

Learner Questions


No Questions by learners, be first one to ask ..!!

    Please Sign in to ask a question

    Was this lesson helpful to you? Yes No 84 People out of 85 think this lesson helpful


    Lesson Navigation

    ←Previous Chapter
    Next Lesson → SAP ABAP Consultant