The users can log on to the SAP system using either the SAP GUI or a Web client (browser). When logging on via the SAP GUI, user requests are processed by the ABAP runtime environment, when logging on via a browser, processing can be done by the ABAP or the JAVA runtime environment, depending on the request.
Processing Requests by the SAP GUI
Users logon via the (ABAP) message server (load balancing) or they logon directly on the ABAP dispatcher, the work processes execute the user requests.
The processing of a user request in AS ABAP, as outlined in the graphic, involves different processes on all three layers (presentation, application and database layer):
Unit 3: The System Core TADM10_1
Figure 39: Processing a User Request
The screen entries of a user are accepted by the SAP presentation program SAP GUI (SAP Graphical User Interface), 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 activities.
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.
TADM10_1 Lesson: AS ABAP Processes
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.
Figure 40: Process Flow for Requests
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.
Unit 3: The System Core TADM10_1
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 SAP GUI and the user sees the new screen.
Database Interface of AS ABAP
Relational Database Management Systems (RDBMS) are generally used to manage large sets of data. An RDBMS saves data and relationships between data in the form of two-dimensional tables. These are known for their logical simplicity. Data, tables, and table relationships are defined at database level in the database catalog (the data dictionary) of the RDBMS.
Within the SAP programming language ABAP, you can use ABAP Open SQL (SQL = Structured Query Language, database query language) to access the application data in the database, regardless of the RDBMS used. The database interface, which is part of every work process of AS ABAP, translates Open SQL statements from ABAP into the corresponding SQL statements for the specific database used (Native SQL). This allows ABAP programs to be database-independent.
Note: ABAP Open SQL is a database query language based on the (ISO) SQL standard that also contains enhancements that are not included in the standard.
When interpreting Open SQL statements, the SAP database interface checks the syntax of these statements and ensures the optimal utilization of the local SAP buffers in the shared memory of the application server. Data that is 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 a number of business administration parameters, usually remain unchanged in an operational system and are therefore ideally suited to buffering.
TADM10_1 Lesson: AS ABAP Processes
Figure 41: Database Query Flow
Furthermore, native SQL commands can be used directly in ABAP, that is, without using the local buffers and without the database interface interpreting the commands.
You can do this by including the commands in an EXEC SQL. - END EXEC. bracket in the ABAP program. The ABAP Interpreter does not check the syntax of any commands within this bracket. If you use native SQL, you can no longer ensure the platform independence of the affected programs.