Transactions in SAP Netweaver

Active Global Support

Table of Contents

Transactions

Lock Management in SAP Systems

Update Processing
Transactions

Transactions are processing units grouped to provide a specific function. They have four
principal characteristics. The initial letters of these characteristics together form the
acronym ACID:

Atomic means that a transaction is either fully successful or does not have any
effects at all. If a transaction-oriented system goes down, you need to ensure that
inconsistent, partial results are not stored.

Consistent means that the system status changes from one that is accurate and
consistent in business terms to another that is also accurate and consistent in
business terms.

Isolated means that the changes made within a transaction can only be seen by
other transactions, even those that run simultaneously, after the final confirmation
(.Commit.).

The results of a transaction are durable because after the final confirmation they
are stored permanently in the database
Database Transactions

A database transaction is, in accordance with the ACID principle, a

non-divisible sequence of database operations, at the beginning and
end of which the dataset on
the database must be consistent.

1. The beginning and end of a database transaction are defined by a

commit command (.database commit.) to the database system.

2. During a database transaction (between two commit commands), the

database system itself ensures that the dataset is consistent.

3. The database system itself takes on the task of restoring the dataset
to its previous state after a transaction has terminated with an error
(.rollback.).
SAP Transactions

An SAP transaction is defined as a non-divisible business process that

must either be executed completely or not at all. SAP transactions are
implemented as sequences of logically related dialog steps that are
consistent in business terms. Every user dialog step is represented by
one screen image.

1. Are implemented as sequences of logically related dialog steps that

are consistent in business terms (e.g. contains debits and credits).

2. Every user dialog step is represented by one screen image.

Relationship between database transactions
and SAP transactions
An SAP Transaction is not necessarily executed within one single dialog work process, in fact it
make take many. Within a transaction that changes data on the database, the user requests
database changes using the displayed individual screens.

. Once the transaction is complete, the changes must result in a consistent database status. The individual
dialog steps can be processed by different work processes (work process multiplexing), and each work
process sequentially handles dialog steps for unrelated applications..
Table of Contents

Transactions

Lock Management in SAP Systems

Update Processing
Lock Management in SAP Systems

Business objects must not be changed simultaneously by

different users if consistency is to be maintained.

Because an SAP Transaction is a business process of 1 or

more logical database transactions there is a risk of data
inconsistency, if only the database lock administrator is
used.
To ensure data consistency within an SAP system, you
must ensure that data records cannot be accessed and
changed by more than one user at any one time. To do this,
the SAP system has its own lock management concept –
enqueue work process
Fundamentals of Enqueue Processing in SAP
Systems

The SAP lock

concept works on
the principle that
SAP programs make
lock entries for data
records to be
processed in a lock
table. Lock entries
can only be made if
none already exist
for the table entries
to be locked.

While locked, all

other access to
change that table is
denied.
 Requesting and Releasing Locks in the
Enqueue Work Process
If the dialog work process that is handling the
user request and the enqueue work process
are not running on the same SAP Web
Application Server, then these two work
processes communicate by means of the
message server

The enqueue work process

administers the logical locks on
SAP transactions using a lock
table in the main memory of
the SAP Web Application
Server on which the enqueue
work process is running.
Requesting and Releasing Locks in the
Enqueue Work Process (2)

In order for the system to execute lock requests, the lock object must be defined in the ABAP
Dictionary. The lock object contains tables whose entries are to be locked. A lock mode can be
defined for a lock object. Here, we distinguish between exclusive locks and shared locks.

Write locks (lock mode .X.); are only assigned if no other locks exist for the data records
required; no additional locks are then permitted for these entries.

Extended write locks (lock mode .E.); are only assigned if there are no locks on the data
record yet. Only the lock owner can cumulatively assign further write locks.

Shared locks (lock mode .S.); further shared locks, but no write locks can be requested for
this object.

Optimistic lock (lock mode .O.)- available since SAP Web Application Server 6.40. The first
lock types are pessimistic locks. The optimistic locks are intended for the case that data is
displayed in change mode without being changed as well. If any changes are made, the
conflict with possible changes that have been made at the same time is only determined and
resolved during saving.
Table of Contents

Transactions

Lock Management in SAP Systems

Update Processing
The Principle of Asynchronous Updates

Alongside dialog work processes, at least one update work process is

configured on every SAP system. Update work processes carry out
updates, that is, they change the entries in database tables.

To ensure data consistency, the data in an SAP transaction must be

updated either completely or not at all. If a runtime error occurs during part
of the update, all critical database changes made by the update need to be
recalled (rollback.).

Since all changes made by an SAP transaction need to be retractable until

the final confirmation, all these changes must be bundled into a single
database transaction. This ensures that rollback requirements are met.
The Principle of Asynchronous Updates (2)

Asynchronous updates solve the problems caused by the different interpretations of

transaction at database level and at SAP level. Bundling all updates for one SAP transaction
into a single database transaction ensures that the data that belongs to this SAP transaction
can be rolled back completely.

Update (V)
only done at
COMMIT
WORK
The Update Process

If a user wants to change a data record in an SAP transaction, he/she first calls the
corresponding transaction (dialog), makes the appropriate entries on the screens, then finally
initiates the update process by saving the data. This process triggers the following steps:

1) The program locks the data record for other users. The program does this by
addressing the enqueue work process (using the message server if appropriate). The
enqueue work process makes the relevant entry in the lock table or (if another user has
already locked the data) informs the user that the data record cannot currently be
changed.

2) If the enqueue work process succeeded in writing the lock entry to the lock table,
then it passes the lock key it created to the user, the program reads the record to be
changed from the database and the user can change the record on the screen image of
the SAP transaction.

3) In the active dialog work process, the program calls a function module using CALL
FUNCTION ... IN UPDATE TASK and writes the change request to database update
tables. These are also called VB* tables, because their names begin with .VB.. They act
as temporary memory and store the data to be changed until it can be collected and
written to the target tables in the database (in a single database transaction).
The Update Process (2)

4) At the end of the transaction (for example, when the user saves the data, possibly
after completing other dialog steps), the program initiates the close of the transaction
with the statement COMMIT WORK. The work process that is handling the active dialog
step triggers an update work process.

5) On the basis on the information transferred from the dialog work process, the update
work process reads the log records that belong to this SAP transaction from the VB*
tables.

6) The update work process passes the changes marked and collected in the VB* tables
to the database as a change request and evaluates the database response. If the
changes were successfully written to the target tables, the update work process triggers
a database commit after the last change to the database and deletes the entries from the
VB* tables. If an error occurs, the update work process triggers a database rollback,
leaves the log records in the VB* tables and marks them as defective.

7) The lock entries in the lock table are reset.

Terminations During Data Updates

If an error occurs during an update, then processing of the active update component
terminates. Users can be automatically notified by express document when an update
terminates.

If a dialog work process terminates when writing data to the VB* tables, the tables will contain
data that will not be updated. The system can delete these entries automatically the next time
you start the system. The application tables remain unchanged.

An asynchronous update may terminate for a variety of reasons. If, for example, several
attempts are made to enter the same data record (using insert) in a table, this triggers the
exception condition .Duplicate Key. in the coding because an entry already exists in the table
under this key. Therefore, the corresponding data record cannot be written to the database
table more than once.