A work process executes the individual dialog steps of user
requests. In other words, all the execution and processing of user requests is
done by work process and once a request
is allotted to the work process, it executes only a single dialog step and then
frees itself for handling other requests.
A Dialog step is referred to as the change of screen. A jump
from one screen to another is a dialog step.
Components of a Work Process
There could be ‘N’ number of work processes in an Application
server. Each Work Process has 3
different components which it uses to process the request.
In ABAP application programming, there is a difference
between user interaction and processing logic. The user interactions are handled by Screen processor whereas the processing
logic which might require DB interactions etc is performed by ABAP Processor.
The Screen Processor
executes the Screen Flow Logic which consists of large part of user
interactions. The screen processor also handles the communication between work
process and SAP GUI and it also handles the field transfer from screens to flow
logic.
The ABAP Processor
executes the processing logic of the application program and also establishes
connection between the work process and DB by communicating with the DB interface.
The screen processor informs the ABAP processor about the Screen modules to be
processed.
The DB Interface
The DB interface is responsible for connecting and disconnecting
the work process and the database. It also provides services like access to
database tables, repository information etc.
Types of Work Processes
There are 5 types of Work Processes. Please note that the
structure of each work process remains same irrespective of its type. The various
types of work processes are helpful in optimizing the use of resources of
Application server. The dispatcher allots the requests to work process based on
its type.
Work Process Type |
Request Type
|
|
Dialog
|
D
|
Dialog Requests
|
Update
|
V
|
Update Requests to Update Database Records
|
Background
|
B
|
Requests which runs in background
|
Spool
|
S
|
Spool Printing requests
|
Enqueue
|
E
|
Logical Lock Requests
|
Dialog Work Process (D):
Every user request to execute dialog step is processed by Dialog Work Process. By default the response time of a Dialog Work Process is 300sec, after that it gets terminated. Every SAP instance should have a minimum of 2 Dialog Work Processes and can be increased to more as per business requirement. Services with long running Dialog steps (which require more time for processing) should not be loaded to Dialog work processes as it will affect the system performance as a single work process will be allotted to a single a single service and thus other work process would have to handle multiple user requests.. Services with dialog processing time more than 300 sec should be run in background.Background Work Process (B):
All long running batch jobs and reports where user interaction is not required are executed by Background Work Process. Every instance should have a minimum of 1 Background Work Processes and can be increased to more as per requirement. Background work processes are designed for periodic tasks such as reorganization or the automatic transfer of data from an external system to the R/3 System.Update Work Process (V):
All the database update related requests 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 (E):
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. It administers the lock table in shared memory
which contains the logical databases lock. Only 1 Enqueue Work Process in
Application server is sufficient enough to do this job. In order to execute lock requests we must first define a lock object. A lock object is defined in ABAP dictionary which consists of table entries which are to be locked. As per the standard all the user defined lock mechanisms must begin with the name 'EY' or 'EZ'. When we activate a lock object system automatically generates Enqueue and Dequeue function modules which we can use in our ABAP programs to use lock mechanism functionality.
Spool Work Process (S):
Spooling refers to the buffered transfer of data to output devices such as printers, fax devices, and so
on. All printing related requests are handled by Spool Work process. Every ABAP Application server can have only 1 Spool Work Processes and it can’t be increased to more. Spool requests are generated in dialog mode or during background processing and are then set in the spool database with details about the printer and the print format. The data itself is stored in the TemSe (TEMporary SEquential object) database.
on. All printing related requests are handled by Spool Work process. Every ABAP Application server can have only 1 Spool Work Processes and it can’t be increased to more. Spool requests are generated in dialog mode or during background processing and are then set in the spool database with details about the printer and the print format. The data itself is stored in the TemSe (TEMporary SEquential object) database.
In addition to the above work processes the R/3 application server also has two additional services for communication within R/3 system and between Non-SAP or other SAP systems. They are:-
Message Server (MS or M):
The message server (MS or M) communicates between the distributed dispatchers within the
R/3 System and is therefore the prerequisite for scalability using several parallel-processing
application servers.
R/3 System and is therefore the prerequisite for scalability using several parallel-processing
application servers.
Gateway Server (GW or G)
The gateway server (GW or G) allows communication between R/3, R/2 and external
application systems.
application systems.