ABAP Work Process and its Types

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.

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.

Gateway Server (GW or G)

 The gateway server (GW or G) allows communication between R/3, R/2 and external
application systems.