Work process types in SAP AS

Types of Work process in SAP AS are:

The dispatcher distributes the request to the work processes.
1. DIALOG Work process
2. BACKGROUND or BATCH Work process
3. UPDATE Work process
4. ENQUEUE Work process
5. SPOOL Work process

Dialog work processes full fill all requests for the execution of dialog steps triggered by an active user. Every dispatcher requires at least two dialog work process.We can alter the number of Dialog work processes using the following parameter rdisp/wp_no_dia.
Dialog work process will take 75 - 150 MB of Physical Memory,we can increase dialog number up to 100 depends on RAM size.

Background work processes executes programs that run long time and recurring without interacting with the user. You need at least two background work processes for each SAP system.We can alter the number of Background work processes using the following parameter rdisp/wp_no_btc.

Spool work processes pass sequential data flow on to printers. At least one spool work process is required for each SAP system. It is possible to configure more than one spool work process for each dispatcher. Wecan alter the number of Spool work processes using the following parameter rdisp/wp_no_spo.

Update work processes executes update requests. Similarly to spool work processes, you need at least one update work process per SAP system.

We can alter the number of Update work processes using the following parameter rdisp/wp_no_vb.

There are two processes that are related to the update process

UPD - update process for making U1 (time-critical) database changes
UP2 - update process for executing U2 (not time-critical) database changes.

The Enqueue work process administers the lock table in the shared memory. The lock table contains the logical database locks of the ABAP runtime environment of the SAP system. Only one enqueue work process is needed for each system.We can alter the number of Update work processes using the following parameter rdisp/wp_no_enq.

Memory allocation sequence to non dialog work processes in SAP

What is the memory allocation sequence to non-dialog work processes (background, update, en-queue and spool work processes in SAP?
What are the SAP parameters used to define initial roll area, extended memory, heap memory, roll area ?
What is the memory allocation sequence to non dialog work processes in Windows NT?

Memory allocation sequence to dialog work processes is same in SAP for all the platforms.
However memory allocation sequence to non-dialog work processes is bit different based on Platform. In Windows NT, memory allocation sequence for non-dialog work processes is same as that of dialog work process memory allocation sequence in other platforms.
Memory allocation sequence to non dialog work processes in SAP as below (except in windows NT):

1. Initially memory is assigned from the Roll memory. Roll memory is defined by SAP parameter ztta/roll_area and it is assigned until it is completely used up.If the roll memory is full then 
2. Heap memory is allocated to the non-dialog work process. Heap memory is available until one of the following occurs : 
3. Either the limit of the heap memory for non-dialog work processes is reached (defined by the SAP parameter abap/heap_area_nondia) or the entire heap memory of all work processes of an SAP application server reaches its limit which is defined by parameter abap/heap_area_total. 
4. Operating system limits of allocating memory 
5. The swap space in the host system is completely used up. However this situation should not occur often which results in severe performance issues.

Please check swap space requirements for various platforms and please define swap space optimally to avoid this issue.
If all the above mentioned heap memory is completely used up then a non-dialog work process can use the SAP extended memory defined by SAP parameter em/initial_size_MB.

Memory allocation sequence to dialog work processes in SAP

What is the memory allocation sequence to dialog work processes in SAP? 

When does a work process go to PRIV mode? 

How to avoid or minimize work process going to PRIV mode ? 

What are the SAP parameters used to define initial roll area, extended memory, heap memory, roll area ?

Memory allocation sequence to dialog work processes in SAP :

Initially,a defined roll area is used.This roll area is defined by the SAP parameter ztta/roll_first.

Usually ztta/roll_first is set to 1 in SAP so that only necessary amount is allocated to roll memory.

If the memory from the initial roll area(i.e. ztta/roll_first) is not sufficient for the user context then comes 
extended memory.
Extended memory is used until the extended memory is full or until the user quota is reached Extended memory is defined by the parameter em/initial_size_MB and the user quota for dialog work process is defined by the parameter ztta/roll_extension_dia.

If this memory is also not sufficient, then The rest of the roll area is used. This roll area is defined by SAP parameter ztta/roll_area.

Once this is also fully occupied then
The system is forced to use local heap memory (Private memory). Then the work process goes into PRIV mode

Heap memory is available until one of the following occurs :
Either the limit of the heap memory for dialog work processes is reached (abap/heap_area_dia) or 
the entire heap memory of all work processes (abap/heap_area_total) for an application server reaches its limit.

Operating system limit for allocation of memory
The swap space in the host system is used up or the upper limit of the operating system address space is reached.

The memory allocation strategy for dialog work processes, aims to prevent work processes from allocating R/3 heap memory and thus entering PRIV mode.
When a work process enters PRIV mode, it remains connected to the user until the user ends the transaction. 
Most of the time, we should try to avoid the situation of work process going into PRIV mode for better performance of the SAP system. This can be done by optimally defining abap/heap_area_total parameter.

R/3 Architecture

SAP R/3 is the one of the main product of SAP,Where 'R' stands for Real Time and 3 stands for 3-Tier (Presentation layer ,Application layer and Database layer).

When a request from Presentation Server first comes to the Application Server, it directs the request to the dispatcher.The dispatcher, which is the Central process of the SAP Web Application Server, manages the resources for the applications written in ABAP in coordination with the respective operating system. The main tasks of the ABAP dispatcher include the distribution of the transaction load to work processes, the integration of the presentation layer and the organization of communication transaction.The requests are first saved in the queue by the dispatcher and then processed according to the principle of “first-in, first-out.” The dispatcher distributed the request one after another to the available work processes. A work process handles one request at a time. Data is actually processed in the work process, although the user who created the request using the SAP GUI is not always assigned the same work process.

Dispatcher —Acts as a bridge to connect different work processes with the respective users logged on to the SAP R/3 system. The requests received by Application servers are directed first to the dispatcher, which enrolls them to a dispatcher queue. The dispatcher then retrieves the requests from the queue on a first-in, first-out basis and allocates them to a free work process.  

Gateway —Acts as an interface for R/3 communication protocols, such as a Remote Function Call (RFC).RFC is the standard SAP interface used to communicate between SAP systems.  

Shared Memory —Represents the common memory area in an Application server. All work processes running in an Application server use shared memory. This memory is used to save the 
contexts (data related to the current state of a running program) or buffer data. Shared memory is also used to store various types of resources that a work process uses, such as programs and 

table content. 

Required Knowledge for SAP Basis

Required Knowledge for SAP Basis

First of all, we should take a step back and answer the question; what is a SAP Basis Administrator and what duties they have to do?
On top of everything else the main task is to make sure the SAP systems running optimal efficiency. But what does it mean? The SAP system has a 3 Tier architecture, I will not go into too much detail here, but you need to know how what the different layers are and how they interact with each other to make the system run.

SAP BASIS Training Course – Get It Now!

Let us consider a standard SAP transaction. It first goes through the client layer (SAP GUI or your Internet Browser) which is executed on workstation (running windows or any other OS), then you have the application layer where the SAP Instance is running which runs on a windows or UNIX server. Then finally the DB layer which could be Oracle, Sybase, SQL server, … database instance running on any kind of operating system too.

So, in order to have your SAP system working well, you must be sure that each layer runs well together which further involves the configuration and monitoring of the communications between those layers too!

With this in mind, to be SAP Basis Administrator means you have to be able to make sure all those layers are working and communicating with each other. This means you need to know how to administrate many operating systems (AIX, HP-UX, Solaris, Windows…) and many databases (Oracle, SQL Server, …). In addition to those “generic” skills, you still have to administrate SAP itself (The application layer).

I don’t want to dig into what it meant by administrating operating systems or databases, but I will detail a little more what this means in relation to an instance of SAP.

SAP System Administration

Administrating the application layer (The SAP Instance), means:
1.Understanding and adjusting SAP system parameters
2.Monitoring and scheduling of batch jobs
3.Applying system and application patches (called Support Packages)
4.Moving system objects through the various client and system landscapes (e.g. from development to 4.production) via the SAP transport system
5.Security management, and many other tasks.