An ABAP/4 program only occupies a work process for one dialog step. At the beginning of the dialog step, the roll area and user context are rolled in to the work process. At the end of the dialog step, they are rolled out.
During the roll-in, pointers to the roll area and user context are populated in the work process. This enables the work process to access the data in those areas and so perform processing for that user and that program. Processing continues until the program sends a screen to the user. At that time, both areas are rolled out. Roll-out invalidates the pointers and disassociates these areas from the work process. That work process is now free to perform processing for other requests. The program is now only occupying memory, and not consuming any CPU. The user is looking at the screen that was sent, and will soon send another request.
When the next request is sent from the user to continue processing, the dispatcher allocates that request to the first available work process. It can be the same or a different work process. The user context and roll area for that program are again rolled in to the work process, and processing resumes from the point at which it was left off. Processing continues until the next screen is shown, or until the program terminates. If another screen is sent, the areas are again rolled out. When the program terminates, the roll area is freed. The user context remains allocated until the user logs off.
In a system with many users running many programs, only a few of those programs will be active in work processes at any one time. When they are not occupying a work process, they are rolled out to extended memory and only occupy RAM. This conserves CPU and enables the R/3 system to achieve high transaction throughput.
ABAP/4 programs do not have the capability to intercept many common Windows events. The events that generate a lot of messages such as key presses, focus changes, and mouse movements are not passed to ABAP/4 programs. As a result, there is no way of performing some of the functions that are found in other Windows programs. For example, in ABAP/4, you cannot validate the contents of a field when the user presses the Tab key. You must instead wait until the user initiates a dialog step.
Discovering How the Data Is Sent to the Presentation Server
The messages exchanged between the presentation server and the application server are in an SAP proprietary format. The SAPGUI accepts the screen information sent from the application server and formats it appropriately for the platform it is running on. This enables different end-user hardware platforms to connect to a single application server. For example, an OS/2 PC and a Windows PC can both connect to the same application server at the same time.
Understanding the Components of a Work Process
Each work process is composed of the following:
A task handler
An ABAP/4 interpreter
A screen interpreter
A database interface
All requests pass through the task handler, which then funnels the request to the appropriate part of the work process.
The interpreters interpret the ABAP/4 code. Notice that there are two interpreters: the ABAP/4 interpreter and the screen interpreter. There are actually two dialects of ABAP/4. One is the full-blown ABAP/4 data processing language and the other is a very specialized screen processing language. Each is processed by its own interpreter.
The database interface handles the job of communicating with the database.