Request Processing in AS ABAP

Users in SAP use the SAP Frontend , called SAPGUI as shown below. The details of the system to login into has to be specified in the SAP Logon Pad.

 

 

1. User request processing.

 

• The screen entries of a user are accepted by the SAP presentation program SAPGUI , converted to an internal format and forwarded to AS ABAP. The (ABAP) dispatcher is the central process of AS ABAP. It manages the resources for the applications written in ABAP in coordination with the respective operating system. The main tasks of the ABAP dispatcher include the distribution of the requests to its work processes, the integration of the presentation layer and the organization of communication transactions.
• The dispatcher first saves the processing requests in request queues and then processes them according to the first in, first out principle.
• The ABAP dispatcher distributes the requests one after the other to the available work processes. Data is actually processed in the work process, whereby the user who created the request using the SAP GUI is not always assigned the same work process. There is no fixed assignment of work processes to users. To process user requests it is often necessary to read data from the ABAP schema of the database or to write to it. For this, every work process is connected directly to the ABAP schema of the database.
• Once the process is complete, the result from the work process is sent via dispatcher back to the SAP GUI. The SAP GUI interprets this data and generates the output screen for the user.
• The buffers help to speed up processing of user requests. Data that is often read but seldom changed (for example, programs or Customizing data such as clients, currencies or company codes) can be kept as a copy of the database content in the shared memory of the application server. This means that the data does not have to be read from the database every time it is needed, but can be called very quickly from the buffer. Each instance has its own buffers.

• Work processes execute the process logic of application programs. In addition to internal memory, a work process has a task handler that coordinates the actions within a work process, software processors and a database interface. The dynpro processor executes the screen flow logic of the application program, calls processing logic modules, and transfers field content to the processing logic. The actual processing logic of ABAP application programs is executed by the ABAP interpreter.
• The screen processor tells the ABAP processor which subprogram needs to be executed, depending on the processing status of the screen flow logic.
• The dialog work process selected by the dispatcher, performs a roll-in of the user context first. That is, the data that contains the current processing status of a running program as well as data that characterizes the user is made known to the work process. The work process then processes the user request, which may involve, for example, requesting data from the database or from the buffers in the shared memory. Once the dialog work process has processed the dialog step, the work process returns the result, rolls the user context back out to the shared memory, and is now available again for a new user request from the request queue. The result is transferred to the SAPGUI and the user sees the new screen.

 

 

2. Transaction processing.

• Transactions are processing units, that functionally belong together. They have four principal characteristics. The initial letters of these characteristics together form the acronym ACID.
- Atomic
- Consistent
- Isolated
- Durable
• Atomic means that a transaction is either fully successful or does not have any effects at all. If a transaction-oriented system goes down, you need to ensure that inconsistent, partial results are not stored.
• Consistent means that the system status changes from one that is accurate and consistent in business terms to another that is also accurate and consistent in business terms.
• Isolated means that the changes made within a transaction can only be seen by other transactions, even those that run simultaneously, after the final confirmation (Commit).
• The results of a transaction are durable because after the final confirmation they are stored permanently in the database.