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.

Display and Control Work Processes 

Use

Work processes do the majority of the processing of the SAP System. They execute dialog steps in user transactions, updates, lock administration, etc.

You can also find the term Work Process in the glossary.

You can display a snapshot of the status of the work processes on the application server where you are logged on. (Choosing Administration → System Administration → Monitor ® System Monitoring → Process Overview or transaction SM50). You must refresh the display to get updated information. The information on this screen is described in the following section.

The process overview is intended primarily for information-gathering. For example, you can monitor processes to determine if the number of work processes in your system is adequate, to assess if the instance is working to full capacity, to gather information for trouble-shooting, or for tuning.

Integration

By choosing System monitoring → Servers, this displays the Overview of the SAP Application Server. Here, you can further display the work process overview for a particular server in the SAP System by clicking on the desired server name.

If system load is low, you may notice while using the Process Overview that your requests appear to execute in only a single work process. The dispatcher is trying to use one work process for as many dialog steps for one user as possible. This avoids having to reload the roll area for the user.

Features

The Process Overview displays the following information:

·  No: The internal ID number of a process. Used to identify messages that belong to a work process in the system log

·  Type: Work process types:

¡  DIA work process for executing dialog steps in user transactions

¡  UPD: Update process for making U1 (time-critical) database changes

¡  UP2: Update process for executing U2 (not time-critical) database changes

¡  ENQ for setting and releasing locks on SAP lock objects

¡  BTC for executing background jobs

¡  SPO for spool formatting processes

·  PID:  Process ID of the work process (on the operating system)

·  Status: Current status of the work process Possible statuses are:

¡  Running (executing a request).

¡  Waiting (idle and waiting for a request)

¡  Hold (held for one user) is not an abnormal state, but a work process can only serve a single user.

If too many processes are in Hold, then system performance suffers. You can then use the Reason field to identify holds that perhaps can be released.

¡  Stopped (aborted; Restart set to No).

·  Reason: If a work process is in Hold status, the reason is displayed. Typical reasons are: Debugging, CPIC activity, locks, updates, GUI (system waits for response from the SAPGUI front-end program, for example, for a remote function call (RFC)). For an overview of the possible parameters, refer to the F1 help.

You may also see PRIV (PRIVate use) as a reason for holding a work process. PRIV indicates that a work process is reserved for a single user for memory management use. The work process has exceeded the limit of the SAP memory that is used by other processes. The process is held as long as the current user requires local memory. For more information, see Private Memory in the documentation on SAP Memory Management.

If more than a certain percentage of work processes are in PRIV hold state, then PRIV transactions are automatically terminated if the user is not active in the transaction for a set period of time. You can set this time span in the SAP system profile.

·  Start:Indicates whether the process should be automatically restarted if a process ends prematurely. You can change the restart status of a process by choosing Process → Restart after error → Yes/No. Normally, leave Restart set to Yes.

If a work process aborts during its startup, the system automatically sets Restart to No. This measure protects against endless attempts to restart a process if a database system is not available, or another serious problem is affecting the system. After correcting the problem, you can change Restart to Yes so that the system starts the work processes.

·  Err: Indicates how many times a work process has aborted

·  Sem:Indicates the number of the semaphore for which a work process is waiting.

Normally, this field should be empty. If one or more semaphore numbers frequently appears, evaluate the performance of your system using the Performance Monitor.

·  CPU:Cumulative CPU time since the start of a work process. The time units are seconds and hundredths of seconds.

Calculating CPU time is onerous. Therefore, you must request this information using the CPU function.

·  Time:Indicates the elapsed time used by a work process for the dialog step that it is currently processing

·  Report: ABAP program or report that is currently being executed

·  Cl.: Client for the session that is currently being executed

·  User: User whose request is currently being processed

·  Action: Action that is being executed by the current program. The actions that are displayed are those that are recorded by the SAP performance monitor. The Performance Monitor must be active (SAP profile parameterstat/level = 1 (default)) for actions or database table accesses to be displayed.

·  Table: If the database is being accessed, this column shows the name of the table being accessed.

The menu offers the following functions:

• Control and Check Processes (Menu Option Process)
• Control ABAP Program (Menu Option Program/Mode)
• Process Work Process (Menu Option List)

·  Goto: Here you can display User Info to the user who is currently occupying the work process or Backtakes you to the last screen (same as the green arrow does).