Search The SAP Consultant

Friday, November 18, 2005

SAP Application server – The Concept

Today I would like to have a look at the SAP application server architecture and how does it work. As you know when we want to work on SAP, as the first step we log into the SAP Application server using SAP GUI. From that moment the SAP application server processes each dialog step executed by the user and responds back to the presentation server. If the dialog step has some SQL statements to be executed, the application server passes the request to the SAP database server.

In an SAP landscape there can be multiple SAP application servers on one SAP system. So you may wonder how SAP determines the application server into which the new user has to be directed. This is the job of SAP message server, which makes the communications possible between the application servers, presentation server and database server. So when a new user logs in, first he will be connected to the SAP message server. SAP message server will determine the suitable application server based on the work load of each instance and will direct the user to an instance with less work load. You can view the details of the message server by executing the transaction SMMS

The following diagram shows the main components of the SAP landscape.


Dialog step

Once the user has been logged into the application server, he can start executing the programs. Each program can have many dialog steps. A dialog step is nothing but the process that will be processed by application server between two screens of the transaction. For example when we post the general ledger entries using the transaction code FB50, we enter all the relevant data and press the ‘Post’ button. You can notice after you have pressed the button, the screen becomes inactive and the data will be sent to the application server. Once the document has been posted the screen will become active again with the confirmation. So the activities done by the application server between those screens is called a dialog step.


Application server components

The Basis is the runtime environment for the ABAP programs. We can start the SAP application server by typing ‘startsap’ on the cmd command. When we start the application server a collection of R3 system files will be executed and will wait for the requests from the presentation server. We have to note that even though ABAP programs are operating system, hardware and RDBMS independent, the SAP kernel and the Basis system are OS, hardware and RDBMS dependant. Now let me introduce the main components which make the application server

1. Dispatcher
2. Work processes
3. Gate way – this is the interface for R/3 communication protocols
4. Shared memory


Dispatcher

When a presentation server requests a dialog step to be executed, the request will be sent to the dispatcher of the application server on which the user has been logged in. dispatcher will add the request to the dispatcher queue. Then the dispatcher will allocate the requests to the available work processes based on first in first out basis. As I said before one program can have many dialog steps and all the dialog steps of a given program need not always be executed by the same work process. This gives certain amount of implications to the ABAP programming model.

Work processes

Do you remember that I have written on the previous post that ABAP programs are executed by software processors rather than directly by the CPU? Yes work processes within application servers act as the virtual processors. Each work process will have the following components.

Task handler.
Screen processor – which processes the flow logic of the program
ABAP processor – which processes the ABAP program logic
Database interface

There are different types of work processes which perform different types of tasks. Such as dialog work processes, background work processes, spool work processes etc. the number of work processes and the type can be controlled by changing the parameters on the application server profile. Application server profile is a configuration file located at each application server which would contain the parameters and the values of the server.

You can view the application server profile by executing the transaction RZ10. From the menu bar of the transaction RZ10 select the Goto à Profile values à Of a server. Then double click on the server name. The following parameters will specify the number of work processes.

rdisp/wp_no_btc
rdisp/wp_no_dia
rdisp/wp_no_enq
rdisp/wp_no_spo
rdisp/wp_no_spo_Fro_max
rdisp/wp_no_vb
rdisp/wp_no_vb2

The system administrator can use the application server profile and manage the number of work processes to optimize the system performance. For example the administrator can set more dialog work processes during daytime and more background work processes during nights.

You can use transaction SM50 to view the activities on the work processes. Press and hold F8 to see the activities.

When the application server has been started the work processes will register themselves with the database layer. In other words each work process will act as a database client and open a dedicated connection to the database.

One of the fundamental concepts in business application development is that the database changes should be consistent before and after a sql operation has been carried out. In database world, we call it as transaction; a transaction will execute the entire sql set or rollback to the initial stage. In SAP world it’s being called as Logical Unit of Work (LUW).

The work process will execute the entire SQL statements belong to a dialog step as a LUW, this makes sure that the database is consistent before and after a dialog step has been executed by a work process.

But now you know that the dialog steps belong to one program might be executed by different work processes which mean it would have multiple LUW. So there is a chance that the database may be inconsistent if the program terminates after certain dialog steps are executed and the rest are not. For this issue there are bundling techniques provided by ABAP. One of those is SAP LUW which bundles the dialog steps with the underlying SQL statements.

Shared memory

All the work processes on an application server shares a common shared memory space. I will discuss the concepts of user contexts and roll area on a later post. We had a maximum memory limitation with the 32 bit computer processors but with the introduction of 64 bit processors the memory limitations are not an issue any more.

I hope that the above explanations would have given a high level understanding about the SAP application server and its components. We can optimize the performance of SAP system by manipulating the number of the application severs on an implementation and the number of work processes and their types on each application server. Please feel free to send me your comments by clicking on ‘Comments’ button shown below.

1 comment:

prakash.sap said...

very informative, i am an abaper but this is an explanation in depth in simple language.. thanks.. prakash