Basic Architectural Concepts SAP BASIS

The SAP R/3 system uses some widely known terms to which SAP gives specific meanings. This section includes some of those terms, needed for a clear understanding of the architecture of SAP Basis, now the SAP Web Application Server.


Generally, a transaction is an operation that lets a user make changes to a database. The overall SAP R/3 system must be seen as a business transaction processing system. This means that the whole data flow that runs across application modules is executed using transactions. In the SAP systems, a transaction is a sequence of related steps. These logically related steps, known as dialog steps, are screens in which data are introduced, causing the generation of other events. There is a special transaction monitor, the SAP dispatcher, which takes care of handling the sequence of those steps.

The final task of a transaction is to modify the information that ultimately goes into the database. The database is not updated until a transaction has finished. For the sake of consistency, if the transaction has not finished, all changes are still reversible. The transactions usually contain two phases: an interactive phase and an update phase. The interactive phase may be at least one step, but can have many. This phase is responsible for preparing the database records that can update the database. The update phase may have no steps or many. This phase processes the previously prepared records and updates the database. Many users have the ability to access the same information, so, in order for the transactions to be consistent, there is a lock mechanism engaged during the time it takes to process the transaction.

All the transactions in the SAP R/3 systems have an associated transaction code. A fast and useful way to move around the SAP R/3 system is by typing the transaction code directly in the command field of a SAP R/3 window. The available transaction codes are held in table TSTC. To see this table, from the main screen menu, select the following options from the SAP standard menu: Tools | ABAP Workbench | _Development | Other Tools | Transactions. Or, type SE93 in the command field. Then press F4 or click on the possible list arrow (the small icon to the right of the field) and just click the enter icon in the dialog box, or input wildcards (for example, S*, Z*, etc.) in the Transaction code field. Note that by default the number of entries to be shown is limited to 200. Chapter 4 deals with the basics of using and moving around the SAP R/3 system both with menu options and with transaction codes. A fast way to specify table entries is by using transaction SE16 (Data Browser) and entering the table name in the input field.

Dialog Step

A dialog step is a SAP R/3 screen that is represented by a dynpro. A dynpro, or dynamic program, consists of a screen and all the associated processing logic. It contains field definitions, screen layout, validation and processing logic, and so forth. A dialog step is controlled exactly by a dynpro. The processing logic means that the dynpro controls what has to be done before the screen is displayed (process before output or PBO) and what has to be done after the user finishes entering information (Process After Input or PAI). When users are navigating in the SAP R/3 system from screen to screen, they are actually making dialog steps. A set of dialog steps makes up a transaction.

Logical Units of Work (LUWs)

Conceptually, a logical unit of work (LUW) is defined as an elementary processing step that works as a locking mechanism to protect the transaction's integrity. A LUW is a set of dialog steps within a transaction, and all of those steps must be correctly completed to go ahead with the transaction logic. If there are errors before the end of the transactions, the current LUW is canceled, but not the previous ones. Within the SAP system, three conceptually different types of transactions may be distinguished:

  • A database transaction, known as LUW or database LUW, is the period of time in which the operations requested must be performed as a unit. This is known in the database world as an all or nothing operation. At the end of the LUW, cither the database changes are committed (performed) or they are rolled back (thrown away). As you can see in Figure, there are four database transactions (database LUWs) corresponding to the period of time from the beginning of a new database operation to the DB-commit operation.
  • An update transaction or SAP LUW is the equivalent to the database concept for the SAP systems. It means that as a logical unit, these SAP LUWs are either executed completely or not at all. Generally, a SAP LUW can have several database LUWs. The special OpenSQL command, COMMIT WORK, marks the end of a SAP LUW and the beginning of a new one. In Figure , the SAP transaction or SAP LUW comprises all the database operations until the COMMIT WORK statement; in this case, it is made up of four database LUWs.
  • A SAP transaction or ABAP transaction is made up of a set of related tasks combined under one transaction code. This concept is related more to the programming environment, in which an ABAP or SAP transaction functions like a complex object containing screens, menus, programming logic, transaction code, and so forth.

Example of SAP LUWs

Example of SAP LUWs


A client is defined as a legally and organizationally independent unit within the SAP Web AS or SAP R/3 system, for example, a company group, a business unit, or a corporation. Client records are stored in common tables. The MAND T field distinguishes records for particular clients. At the beginning of the SAP Web AS technical phase of the implementation, right after installation of the software, one of the first things that usually must be done is to copy one of the standard clients included in the package. With the copied clients, customers can make tests, can use them for training, or can start real customization.

SAP comes with three standard clients: 000, 001, and 066. Client 000 contains a simple organizational structure of a test company and includes parameters for all applications, standard settings, configurations for the control of standard transactions, and examples to be used in many different profiles of the business applications. For these reasons, 000 is a special client for the R/3 system because it contains the client-independent settings. Client 001 is a copy of the 000 client, including the test company; if this client is configured or customized, its settings are client dependent. It does not behave like 000. It is reserved for the activities of preparing a system for the production environment. SAP customers usually use this client as a source for copying other new clients.

Client 066 is reserved for SAP access to its customers' systems to perform the EarlyWatch service that enables SAP to open a diagnostic service with clients. The SAP systems include tools for creating, copying, transferring, resetting, deleting, and comparing clients. When the loads of individual clients differ, the buffer manager of the application service is able to respond and allocate resources appropriately. The client is the first field when logging on to the system.

Logon screen with client field (Copyright by SAP AG)

Logon screen with client field (Copyright by SAP AG)

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status