Work
Processors
Work
processes execute the individual dialog steps in R/3 applications. The next two
sections describe firstly the structure of a work process, and secondly the
different types of work process in the R/3 System.
Screen Processor
In ABAP application programming, there is a difference between user
interaction and processing logic. From a programming point of view,
user interaction is controlled by screens. As well as the actual input
mask, a screen also consists of flow logic, which controls a large part of the
user interaction. NetWeaver AS ABAP contains a special language for programming
screen flow logic. The screen processor executes the screen flow logic.
Via the dispatcher, it takes over the responsibility for communication between
the work process and the SAPgui, calls modules in the flow logic, and ensures
that the field contents are transferred from the screen to the flow logic.
ABAP
Processor
The actual processing logic of an application program is written in ABAP
- SAP’s own programming language. The ABAP processor executes the processing
logic of the application program, and communicates with the database
interface. The screen processor tells the ABAP processor which module of the screen
flow logic should be processed next. The following screen illustrates the
interaction between the screen and the ABAP processors when an application
program is running.
Database Interface
The
database interface provides the following services:
· Establishing and
terminating connections between the work process and the database.
·
Access
to database tables
· Access to Repository
objects (ABAP programs, screens and so on)
· Access to catalog
information (ABAP Dictionary)
· Controlling
transactions (commit and rollback handling)
· Table buffer
administration on the ABAP application server.
The
following diagram shows the individual components of the database interface:
The
diagram shows that there are two different ways of accessing databases: Open
SQL and Native SQL.
Open SQL statements are a subset of Standard SQL that is fully
integrated in ABAP. They allow you to access data irrespective of the database
system that your installation is using. Open SQL consists of the Data
Manipulation Language (DML) part of Standard SQL; in other words, it allows you
to read (SELECT) and change (INSERT, UPDATE, DELETE) data. The tasks of the
Data Definition Language (DDL) and Data Control Language (DCL) parts of
Standard SQL are performed in NetWeaver AS ABAP by the ABAP Dictionary and the
authorization system. These provide a unified range of functions, irrespective
of database, and also contain functions beyond those offered by the various
database systems.
Open SQL also goes beyond Standard SQL to provide statements that, in
conjunction with other ABAP constructions, can simplify or speed up database
access. It also allows you to buffer certain tables on the ABAP application
server, saving excessive database access. In this case, the database interface
is responsible for comparing the buffer with the database. Buffers are partly
stored in the working memory of the current work process, and partly in the
shared memory for all work processes on an ABAP application server. Where
NetWeaver AS ABAP is distributed across more than one ABAP application server,
the data in the various buffers is synchronized at set intervals by the buffer
management. When buffering the database, you must remember that data in the
buffer is not always up to date. For this reason, you should only use the buffer
for data which does not often change.
Native SQL is only loosely integrated into ABAP, and allows access to
all of the functions contained in the programming interface of the respective
database system. In Native SQL, you can primarily use database-specific SQL
statements. The Native SQL interface sends them as is to the database system
where they are executed. You can use the full SQL language scope of the
respective database which makes all programs using Native SQL specific for the
database system installed. In addition, there is a small set of SAP-specific
Native SQL statements which are handled in a special way by the Native SQL
interface. ABAP applications contain as little Native SQL as possible. In fact,
it is only used in a few components (for example, to create or change table
definitions in the ABAP Dictionary).
The database-dependent layer in the diagram serves to hide the
differences between database systems from the rest of the database interface.
You choose the appropriate layer when you install NetWeaver AS ABAP. Thanks to
the standardization of SQL, the differences in the syntax of statements are
very slight. However, the semantics and behavior of the statements have not
been fully standardized, and the differences in these areas can be greater.
When you use Native SQL, the function of the database-dependent layer is
minimal.
Types of Work Process
Before you start NetWeaver AS ABAP, you determine how many work
processes each ABAP application server will have, and what their types will be.
Since all work processes have the same structure (see preceding section), the
type of work process does not determine the technical attributes of the ABAP
application server but the type of tasks to be performed on it. The dispatcher
starts the work processes and only assigns them tasks that correspond to their
type. This means that you can distribute work process types to optimize the use
of the resources on your ABAP application servers.
The
following diagram shows again the structure of an ABAP application server, but
this time, includes the various possible work process types:
Dialog Work Process
Executes dialog programs (ABAP)
OR
Dialog
work processes deal with requests from an active user to execute dialog steps
(see also Dialog
Programming).
Update
Work Process
Asynchronous database changes (is controlled
by a COMMIT WORK statement in a dialog work process)
OR
Update
work processes execute database update requests. Update requests are part of an
SAP LUW that bundle the database operations resulting from the dialog in a
database LUW for processing in the background.
Background Work Process
Executes
time-dependent or event-controlled background jobs
OR
Background
work processes process programs that can be executed without user interaction
(background jobs).
Enqueue Work Process
Executes
locking operations (if R/3 transactions have to synchronize themselves)
OR
The
enqueue work process administers a lock table in the shared memory area. The
lock table contains the logical database locks for NetWeaver AS ABAP and is an
important part of the SAP LUW concept. In NW AS, you may only have one lock
table. You may therefore also only have one ABAP application server with
enqueue work processes. Normally, a single enqueue work process is sufficient to
perform the required tasks.
Spool Work Process
Print formatting (to printer, file or database)
OR
The
spool work process passes sequential datasets to a printer or to optical
archiving. Each ABAP application server may contain only one spool work process.
Role
of Work Processes
The types
of its work processes determine the services that an ABAP application server
offers. The application server may, of course, have more than one function. For
example, it may be both a dialog server and the enqueue server, if it has
several dialog work processes and an enqueue work process.
You can
use the system administration functions to switch a work process between dialog
and background modes while the system is still running. This allows you, for
example, to switch an SAP System between day and night operation, where you
have more dialog than background work processes during the day, and the other
way around during the night.
