AS ABAP Work Process Overview

There are 5 types of Work Process:

Dialog Work Process (DIA): Every user request is processed by Dialog Work Process. Normal response time of a Dialog Work Process is 6 ms. Every instance should have a minimum of 2 Dialog Work Processes and can be increased to more as per requirement.

Background Work Process (BCK): All long running batch jobs and reports where user interaction is not required are taken care by Background Work Process. Every instance should have a minimum of 1 Background Work Processes and can be increased to more as per requirement.

Update Work Process (V1, V2): All udpate related request are taken care by Update Work process. This is of two types, Synchronous updates (V1) and Asynchronous updates (V2). Every instance should have a minimum of 1 Update Work Processes and can be increased to more as per requirement.

Enqueue Work Process (ENQ): Enqueue work process implements lock mechanism. When two users are trying to update same data in a table then Enqueue work process locks that table for other user and releases it when first user saves an commits it. Every instance should have 1 Enqueue Work Processes and cannot be increased.

Spool Work Process (SPO): All print related requests are handled by Spool Work process. Every instance should have a minimum of 1 Spool Work Processes and can be increased to more as per requirement.

Work Process Architechture:

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 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.


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.