Lesson Overview
In this unit, you learn how your (dialog) requests are processed by the SAP
system, step-by-step. The process for a dialog transaction that consists of several
screens is also outlined.
Lesson Objectives
After completing this lesson, you will be able to:
• Outline the processing flow for a dialog step in the SAP system
• Describe the concept of work process multiplexing
Business Example
You want to be able to understand how dialog processing functions in the SAP
system.
Distribution of User Requests to Dialog Work
Processes
Each SAP Web Application Server has its own dispatcher. The dispatcher is
the link between the work processes and the users logged on to the SAP Web
Application Server (or rather, their SAP GUIs). Its tasks include distributing
all the user requests it receives to the dialog work processes on the SAP Web
Application Server.
Every time a user sends a (dialog) request to the SAP system (resulting in the
hourglass being displayed), this request is sent to the SAP Web Application Server
that the user is logged on to. On the server, the request is first placed in a request
queue for dialog requests. Requests in this queue are distributed by the dispatcher
to available dialog work processes on a “first in, first out” (FIFO) basis.
The dialog work process selected by the dispatcher first "rolls in" the user context
(that is, the dataset that contains both the current processing status of an active
program and data that characterizes the user). It 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 to the dispatcher, rolls the context
102 © 2005 SAP AG. All rights reserved. 2005/Q4
TAW10_1 Lesson: Dialog Processing in the SAP System
back out to the shared memory, and is now available again for a new user request
from the request queue. Finally, the dispatcher returns the result to SAP GUI, and
the new screen is displayed for the user.
Note: Memory management and the roll-in/roll-out process:
The memory management system differentiates between main memory
areas that are available exclusively to one particular work process, and
memory areas that can be used by all work processes. The memory
space used exclusively by a work process stores session-specific data
that must be kept for longer than the duration of a work step. This data
is automatically made available to the process at the start of a dialog
step (rolled in) and saved at the end of the dialog step (rolled out). This
data includes data that characterizes the user (user context), such as
authorizations, administrative information, and other data for the ABAP
and screen processors that has been collected in previous dialog steps
for the active transaction. There are also additional memory areas for
all processes in the shared memory for, among other things, the factory
calendar and screen, table, and program buffers.
The execution of dialog transactions is characterized by the following :
• A program dialog step is assigned to one specific dialog work process during
execution.
• The individual dialog steps for a program consisting of several screens can
be executed by different dialog work processes during program runtime.
This is called work process multiplexing.
• A dialog work process sequentially processes dialog steps for various users
and programs.
The following graphic illustrates this:
Unit 3: The System Kernel TAW10_1
Figure 55: Work Process Multiplexing
Structure of a Work Process
As components of SAP Web Application Servers, work processes execute dialog
steps for application programs. In addition to internal memory, a work process has
a task handler that coordinates the actions within a work process, two software
processors (see below), and a database interface.
SAP application programs differentiate between user interaction and processing
logic.
The user actions are technically realized using screens, also called dynpros (from
dynamic programs), which consist of a screen image and the underlying flow
logic. The screen processor executes the screen flow logic of the application
program, calls processing logic modules, and transfers field content to the
processing logic. The screen flow logic itself is further divided into PBO (Process
Before Output), which is processed before the screen image is sent, and PAI
(Process After Input), which is processed after a user interaction on the screen.
The PAI part of a dialog step logically belongs to the preceding screen image,
while the PBO part logically belongs to the subsequent screen image (see “Work
process multiplexing” graphic).
The actual processing logic of application programs written in SAP's programming
language, ABAP, 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.
TAW10_1 Lesson: Dialog Processing in the SAP System
Figure 56: Processing flow for dialog steps
If, during a dialog step, data needs to be exchanged with the database or the
buffers, then this exchange takes place through the database interface, which
enables access to database tables, ABAP programs, the ABAP Dictionary, and
screens, among other things.
Hiç yorum yok:
Yorum Gönder