4 - Part 1 - ABAP Transaction Management

SAP Development Community of Experts
The Development Soapbox
ABAP Transaction Management
Ian Maxwell (Ian.Maxwell@Accenture.com)

2008.03.25
1
SAP Transaction Management The Development Soapbox
This presentation addresses ABAP

Transaction Management, an area of
development that is often overlooked,
misunderstood, or incorrectly implemented
Transaction Management in ABAP includes:
Commit & Rollback logic
Enqueues
Database locks
Update tasks
If not implemented correctly it can
result in inaccurate and inconsistent
results
2
Transactions The Development Soapbox
A transaction is one unit of work on the

database
A transaction is considered to be All or
nothing, so if part of it fails then the
entire transaction fails
A transaction is started by either:
The start of an ABAP program
The end of a previous transaction
A transaction is ended by either:
Executing a commit
Executing a rollback
3
Transactions The Development Soapbox
A commit will cause all data that has

been requested to be written to the
database via SQL statements (Insert,
Update, and Modify) as part of the
transaction to be written
A rollback will cause the transaction to
be aborted and no data is written to the
database
So far straight forward and simple, but

now it starts to get a bit more confusing!
4
SAP Work Processes The Development Soapbox
In order to understand ABAP transaction

management it is important to understand
how the application server handles work
processes
There are a few main types of work
processes that this presentation will refer to:
Background Used for background programs
Dialog Used for foreground programs and RFCs
Enqueue Used to handle logical locking
Update V1 & V2 Used to handle asynchronous
updates
5
The application server is configured to

have a certain number of each type of
work process based on type of load that it
will be used for
Work processes are shared among
programs as a pool
Roll-In refers to when a program attaches to a
work process
Roll-Out refers to when a program detaches to
a work process
When an ABAP program is executed it
creates a session and it runs in either a
dialog or background work process
6
When executing in a background work

process the program will roll-in the session
at the beginning and roll-out the session at
the end. The work process is held for the
duration of the program
When executing in a dialog work process
the program will roll-in and roll-out the
session throughout the execution of the
program. This allows for any idle time to be
utilized by other programs running on the
application server (ex. While waiting for
user input)
7
Each SAP Work Each SAP Work

Process is Process has a
associated with a connection to the
process on the OS database
Process
Process
Process
Process
Process
OS
OS
OS
OS
OS
Programs running
in the background
connect to a Work
Process for the
Background
Background
entire runtime of
Process
Process
Process
Process
Process
Dialog
Dialog
Dialog
the program. If no Database
process is
available then the
job is put into a
waiting status
Foreground
programs attach
to work processes
only when they
Foreground Programs
Session
Session
Session
Session
Session
Session
Session
Program
Program
Background Jobs
require processing
ABAP
ABAP
(ex. They roll-out

Waiting
Active
their sessions
when waiting for
user input)
Program
Program
Program
Program
Program
Program
Program
Program
Program
ABAP
ABAP
ABAP
ABAP
ABAP
ABAP
ABAP
ABAP
ABAP
8
Commits - Implicit and Explicit The Development Soapbox
In SAP it is important to be aware that there are two

types of commits:
Implicit
Explicit
An implicit commit is one that is not directly
controlled by the developer but happens throughout
the runtime of an ABAP program, some examples of
when this is happens is:
Any time that a pop-up message appears (In a foreground
running program)
In dialog programming during any dialog step (i.e. every
time that a user action occurs)
The implicit commits are associated with when a
session either rolls-in or rolls-out. Because a work
process is shared among multiple sessions it must
commit its database transaction when a roll-out
occurs
A true database transaction can not span across a
roll-out and roll-in 9
An implicit commit can even happen when

using the classic ABAP debugger because
it is running in the same process as the
program being debugged. Youll notice
sometimes at the bottom of the screen
there will be a message indicating that a
commit has just happened. So be careful
because the debugger can inadvertently
effect the outcome of your program
An explicit commit is one that is actually
specifically indicated in the ABAP code
with the key word Commit Work or
Commit Work And Wait
10
This is most likely not what you would

Transaction 1 - An explicit intend for your program to do!
commit is performed
Transaction 2 The message statement in a
foreground dialog process triggers a roll-out
and roll-in of the process and therefore also
triggers an implicit commit
Transaction 3 An explicit
rollback is performed
Transaction 4 An implicit
commit is performed at the
end of the program
Start of program
SQL - Insert
Commit Work
SQL - Insert
Message Statement
SQL - Insert
Rollback Work
SQL - Insert
End of program
11
In order to ensure that implicit

commits do not cause any issues with
data integrety in your program the
following rules should be applied:
Dont rely on the implicit commit at the
end of the program, always put a
commit or rollback statement explicitly
If the program will be running in the
foreground then ensure that no
commands are used that will cause the
process to roll-out
12
A common problem is how to handle

logging messages for a batch
program that can run in the
background or foreground
By using a common routine to output
your messages, you can either have
them displayed to the job log when
running in the background and the
spool when running in the foreground
13
Form f_Message
Using else.
l_ID l_Number l_Type l_Text l_Var1 l_Var2 l_Var3 IF ( NOT l_ShowMessage is initial ).
l_Var4. Message l_text
Type l_Type.
Data:
else.
l_Message type string,
l_ShowMessage(1) type c.
l_Message = l_Text.
endif.
clear l_ShowMessage. endif.
clear l_Message. if ( not l_Message is initial ).
write:/ l_ID, l_Number, l_Type, ' - ', l_Message.
if ( ( l_Type = 'E' or l_Type = 'X' ) or endif.
( NOT sy-batch IS INITIAL ) ). EndForm.
l_ShowMessage = 'X'.
endif.
if ( l_Text is initial ).
IF ( NOT l_ShowMessage is initial ).
Message ID l_ID This routine can be used for the outputting
Type l_Type
Number l_Number of messages appropriately for the
With l_Var1
l_Var2 foreground and background. Besides
l_Var3
l_Var4. ensuring that an implicit commit isnt
else.
Message ID l_ID triggered it also prevents you from having
Type l_Type
Number l_Number
to hit enter through all of your logging
With l_Var1
l_Var2
messages
l_Var3
l_Var4
Into l_Message.
endif.
14
So what do you do if you are building a

program that involves the user interacting
with screens?
When building interactive programs (either
screens or a series of pop-up messages with
buttons for a user to choose) it is important
to not execute any SQLs that update the
database until you are at a point in the
program where you will have an
uninterrupted transaction.
Usually this is accomplished by holding all of
your data for updates in internal data
structures and then executing the SQL
statements and the commit statement once
the user hits the save button.
15
You must be very cautious when using user-

exits to modify how standard SAP works.
You should never put a commit or rollback
statement into a user-exit, otherwise you are
ending the current transaction at that point
and starting a new one
You should only put SQL statements that
update the database into user-exits where
they are being executed during save,
otherwise you may end up with inconsistent
data
If you need to update the database and you
can not ensure that implicit commits will not
occur, you should consider the use of Update
Tasks
16
Same Process Dirty Read The Development Soapbox
An interesting point with ABAP OpenSQL is that it

does a same process dirty read on the database
This means that within a process if you update a
table and then select from it within the same process
before commiting you will retrieve the updated
version. If selecting within a different process you
will see the original version.
Process 1
Select record
Update record
Select record
Select record
Commit Work
Original record 100XXXYY Foo

Updated record 100XXXYY
FooBar
Process 2
Select record
Select record
17
SAP LUW The Development Soapbox
In order to have a transaction span across multiple implicit

commits you need to utilize a concept SAP refers to as an SAP
LUW (Logical Unit of Work)
An SAP LUW can be made up of two types of mechanisms:
Update Tasks
Perform On Commit
SAP LUW
Implicit Commits
Explicit Commit
SAP
Process
Database
Database Commits (Each is a DB LUW) 18

Update Tasks The Development Soapbox
Update tasks have two main

purposes in SAP
To allow a user to continue their work
while the database is updated
asynchronously
To ensure that all updates are grouped
together into a single transaction
Update tasks allow you to have a
transaction that spans the implicit
database transactions that are ended
when the process rolls out
19
If you go to transaction
SM50 and view the
available work processes,
you will notice a number of
processes with types UPD
and UP2, these are update
tasks processes.
UPD processes are called V1 update processes

Updates are grouped together into a single transaction and are
executed in a specified order
UPD processes are called V2 update processes
Updates are individually executed each as their own transaction and
can be executed in any order
20
On execution of an explicit
Commit Work statement the
update task is triggered to
DIA - Dialog start processing
Work asynchronously while the
Process calling program continues
Start of program
Update Task"
Call function A using In
Update Task
Call function B using In
Update Task
Executed
Explicit Commit Work
..
..
..
..
UPD -
Update All functions that have been
Work put onto the update task
Process
Functions called using In queue are executed as a
Function A is executed
Function B is executed
Executed
Update Task have their input single transaction in the order
parameters stored in the that they were requested
update task queue for
postponed processing
21
Update Tasks Commit Work And Wait The Development Soapbox
On execution of an explicit
Commit Work And Wait
statement the update task is
triggered to start processing
asynchronously and the
DIA - Dialog calling program waits for the
Work
Process
V1 update task to complete
before continuing processing
Start of program
Update Task"
Update Task
Update Task
And Wait Executed

..
..
..
..
UPD -
Update All functions that have been
Work put onto the update task
Process
Functions called using In queue are executed as a
Function B is executed
Executed
Update Task have their input single transaction in the order
parameters stored in the that they were requested
update task queue for
postponed processing
22
The update task queue can be viewed via

transaction SM13, you can view all tasks
that are:
Pending
Currently being executed
Are in error
23
Update Tasks An explicit commit is required The Development Soapbox
Its important to remember that when using update

tasks you need to use an explicit commit because
the implicit commit wont trigger the update task
You should especially take this into account if you
are calling BAPIs because often BAPIs are calling
update tasks on your behalf
Updates contained in update
tasks do not got committed
based on an implicit commit
and therefore only the SQL
statements directly in the
DIA - Dialog program will get committed
Work
Process
Update Task"
SQL - Insert
update task
Call BAPI that calls an
SQL - Insert
Update Task
There is an implicit
commit at the end of the
program but no explicit
commit has been put in
24
Update Tasks Local update tasks The Development Soapbox
There is an ABAP command Set Update Task Local

This command will force the update tasks to be executed
locally within the calling program
The logic inside the function module is still only executed
once the explicit commit has been issued
This is a useful command to use when you are executing a
batch program that calls update tasks
Note that the update task must be set to local processing at
the beginning of each transaction (i.e. if you commit or
rollback, you need to set it local again)
The ALE system uses Set Update Task Local when it
processes IDocs. Therefore if in your IDoc processing
function you call BAPIs that use update tasks then they are
executed in the calling process
When using local update tasks, there is no difference
between Commit Work and Commit Work And Wait. Both of
these types of commits will not return until the update
tasks have been fully executed
25
Perform on Commit The Development Soapbox
The SAP LUW can be also be built using

Perform on Commit
When Perform on Commit is used to call
a form the routine is not executed until an
explicit commit is executed
This is similar to update tasks with the
exception of:
It is executed always in the same process as
the calling program
You can not pass variables (This must be
handled via global variables)
Each routine can only be executed a single time
as part of a commit
26
Why Locking? The Development Soapbox
The record for tracking the

balance should have been
locked!
User 1 User 2
(1) Check Balance: $4 (2) Check Balance: $4
(3) Deposit $1 Update (4) Deposit $10 Update
balance: $5 ($4 + $1) balance: $14 ($4 + $10)
$4 + $1 + $10 = $15
User 3 Something is wrong!
(5) Check Balance: $14
Were missing $1 in
the balance! 27
Why Locking? The Development Soapbox
User 1 User 2
(1) Lock Account Record (3) Lock Account Record

(2) Lock Obtained (4) Already Locked
(5) Check Balance: $4 (8) Lock Account Record (Retry)
(6) Deposit $1 Update (9) Lock Obtained

balance: $5 ($4 + $1) (10) Check Balance: $5
(7) Release Lock (11) Deposit $10 Update
balance: $15 ($5 + $10)
(12) Release Lock
$4 + $1 + $10 = $15
User 3 The balance is
(13) Check Balance: $15 correct!
28
Database Locks vs. Enqueue Locks The Development Soapbox
Database locks vs. Enqueue Locks

An enqueue is a logical lock managed by the SAP
application server and can span implicit commits
A database lock is implemented on the database
layer (ex. Oracle)
A database lock can not be held past a implicit
commit
Except in a few specific cases, you shouldnt use
database locks in SAP.
An example of where database locks are used in
standard SAP is in the updating of number range
objects to ensure that no two processes update
the number range counter at the same time
29
Database locks The Development Soapbox
Database locks are utilized via the OpenSQL statement

Select for update
The database lock is held until the next commit or rollback
statement
Any other process that tries to also do a Select for
update will be stopped and have to wait until the lock is
released by the first process
Process 1 Process 2
1
Select for update on record A 2 Process 2
Select for update on record A doesnt
3
Update record A complete the
4 select on record
Commit Work A until the lock
5
is released by
Select for update on record A
process 1
6
Update record A
7
Commit Work
30
Database Locks The Development Soapbox
Because database locks will wait until the

requested record is available it is important to be
cautious with possible deadlock situations
In deadlock situations that database will detect it
and kill one of the processes so that the other can
continue
Process 1 Process 2
Process 1 1
doesnt Select for update on record A
2
complete Select for update on record B 5
the select 3
Select for update on record B
on record B 4 Process 2
Select for update on record A killed due
X
until
process 2 6 to
is killed Select for update on record B detection
(which 7 of a
releases Update record A & B Update record A deadlock
8
the lock) Commit Work Commit Work
31
Enqueue Locks The Development Soapbox
An enqueue is a logical lock as

opposed to an a actual database lock
The records do not actually need to
exist in the table in order to use an
enqueue on it (ex. you can put an
enqueue on a new record that you
are going to insert)
In order to utilize enqueue logic it
must be explicitly put into all
programs that utilize the shared table
32
Enqueue Locks The Development Soapbox
Transaction SM12 can be used to

view all enqueue locks in the system
33
Enqueue Modes The Development Soapbox
Enqueue Modes
(s) Shared lock
Several users (transactions) can access locked data at
the same time in display mode. Requests from further
shared locks are accepted, even if they are from different
users. An exclusive lock set on an object that already has
a shared lock will be rejected.
(E) Exclusive
An exclusive lock protects the locked object against all
types of locks from other transactions. Only the same
lock owner can reset the lock (accumulate).
(X) Exclusive non-cumulative
Whereas exclusive locks can be requested several times
by the same transaction and released one by one, an
exclusive, non-cumulative lock can only be requested
once by the same transaction. Each further lock request
will be rejected.
34
Shared locks on Shared locks on a record

a record can be can be accumulated within
obtained across the same process
multiple
Process 1
processes
S S
Process 2
S
A exclusive lock
Process 3
can not be obtained
on a record if there
E are currently
shared locks on it
35
Exclusive locks on a
record can be accumulated
within the same process
Process 1
E E
An exclusive lock
Process 2
can not be obtained
A shared lock on a record if there
can not be E are currently
obtained if there exclusive locks on
are currently it
shared Process 3
exclusive locks S
on it
36
Exclusive locks on a
record can not be
accumulated within the
same process if it has been
locked as exclusive non-
Process 1 cumulative
X E
A exclusive lock
Process 2
can not be obtained
on a record if there
E are currently
excusive locks on it
37
Existing lock
(S) Shared (E) Exclusive (X) Exclusive Non-

Cumulative
Same process
(S) Shared
Same process
(E) Exclusive
Requested Lock
Same process
(X) Exclusive Non-
Cumulative
Different process
(S) Shared
Different process
(E) Exclusive
Different process
(X) Exclusive Non-
Cumulative
38
Enqueue Scope The Development Soapbox
When obtaining an enqueue lock you can set the

scope parameter to control ownership of the lock
The scope of an enqueue is defined as:
1 The lock belongs only to the dialog owner (owner_1), and
therefore only exists in the dialog transaction. The
DEQUEUE call or the end of the transaction, not COMMIT
WORK or ROLLBACK WORK, cancels the lock.
2 - The lock belongs to the update owner (owner_2) only.
Therefore, the update inherits the lock when CALL
FUNCTION IN UPDATE TASK and COMMIT WORK are
called. The lock is released when the update transaction is
complete. You can release the lock before it is transferred to
the update using ROLLBACK WORK. COMMIT WORK has
no effect, unless CALL FUNCTION IN UPDATE TASK
has been called.
3 - The lock belongs to both owners (owner_1 and owner_2).
In other words, it combines the behavior of both. This lock is
canceled when the last of the two owners has released it.
39
Enqueue Scope The Development Soapbox
Release Lock
Release Lock
1 1
3 3A
DIA - Dialog
Work
Process
2
Release Lock
3B UPD -
Update
Work
2 Process
40
Concurrent batch programs The Development Soapbox
In order to architect concurrent batch

programs where multiple instances of
the program are working on the
same set of data there are several
considerations
It is important to ensure that no two
instances of the program can work
on the same record(s) at the same
time
41
One option for concurrency is to logicaly split the data and

have each instance of the program work on a mutually
exclusive set
An example of this is to have a program work on a specific
range or grouping of customers
This is an easy approach to implement but there are some cons
to this method
Once running, you cant add in additional instances of the program
You need to be able to define in advance a way to logically group
the records
You might not achieve even load balancing depending on how the
records have been grouped (one instance may end up having to do
significantly more work then another)
An additional feature that is sometimes utilized with this
method is to have a preprocessing program that splits up the
records and tags them for processing by a specific instance of
the program
Execute on Execute on
Customer group Data Customer group
Z01 Z02
42
Another option for concurrency is to utilize

asynchronous RFCs
In this method a single driving program manages
a number of parallel processes via special RFCs
An example of this type of concurrency can be
seen in the standard SAP programs for processing
IDocs in batch
This is a powerful option but this presentation
wont go into the details of this method
Worker
Data
Driver
43
Another option for concurrency is to use a work list

A work list contains a database table with a list of all records to be
processed
Multiple instances of the processing program can be launched at
the same time and will
Additional instances of the processing program can be launched at
any time during the processing
All instances of the processing program will work until all the work
is done (They will end at approximately the same time)
An enqueue can be used to control the concurrent access to the
work list
Data Processing Work List

Program
Enqueue Server
44
A program utilizing a work list for concurrency

uses the following logic:
Select all records from the work list that have a status of
not processed
Loop through the work list records
Lock the current work list record
If the lock is obtained
Re-Select the record from the work list
If it still has a status of not processed
Process the record
Update the record in the work list to mark it as processed
Commit changes
Else
Do nothing (It has already been processed by another
instance of the program)
Release lock
Else
Do nothing (It is currently being processed by another instance
of the program)
45
ABAP Transaction Management The Development Soapbox
Questions
46

4 - Part 1 - ABAP Transaction Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

4 - Part 1 - ABAP Transaction Management

Uploaded by

Copyright:

Available Formats

SAP Development Community of Experts

The Development Soapbox

ABAP Transaction Management

Ian Maxwell (Ian.Maxwell@Accenture.com)

SAP Transaction Management The Development Soapbox

This presentation addresses ABAP

Transactions The Development Soapbox

A transaction is one unit of work on the

Transactions The Development Soapbox

A commit will cause all data that has

So far straight forward and simple, but

SAP Work Processes The Development Soapbox

In order to understand ABAP transaction

SAP Work Processes The Development Soapbox

The application server is configured to

SAP Work Processes The Development Soapbox

When executing in a background work

SAP Work Processes The Development Soapbox

Each SAP Work Each SAP Work

(ex. They roll-out

Commits - Implicit and Explicit The Development Soapbox

In SAP it is important to be aware that there are two

Commits - Implicit and Explicit The Development Soapbox

An implicit commit can even happen when

Commits - Implicit and Explicit The Development Soapbox

This is most likely not what you would

Commits - Implicit and Explicit The Development Soapbox

In order to ensure that implicit

Commits - Implicit and Explicit The Development Soapbox

A common problem is how to handle

Commits - Implicit and Explicit The Development Soapbox

Commits - Implicit and Explicit The Development Soapbox

So what do you do if you are building a

Commits - Implicit and Explicit The Development Soapbox

You must be very cautious when using user-

Same Process Dirty Read The Development Soapbox

An interesting point with ABAP OpenSQL is that it

Original record 100XXXYY Foo

SAP LUW The Development Soapbox

In order to have a transaction span across multiple implicit

Database Commits (Each is a DB LUW) 18

Update Tasks The Development Soapbox

Update tasks have two main

Update Tasks The Development Soapbox

UPD processes are called V1 update processes

Update Tasks The Development Soapbox

Update Tasks Commit Work And Wait The Development Soapbox

And Wait Executed

Update Tasks The Development Soapbox

The update task queue can be viewed via

Update Tasks An explicit commit is required The Development Soapbox

Its important to remember that when using update

Update Tasks Local update tasks The Development Soapbox

There is an ABAP command Set Update Task Local

Perform on Commit The Development Soapbox

The SAP LUW can be also be built using

Why Locking? The Development Soapbox

The record for tracking the

Why Locking? The Development Soapbox

(1) Lock Account Record (3) Lock Account Record

(6) Deposit $1 Update (9) Lock Obtained

Database Locks vs. Enqueue Locks The Development Soapbox

Database locks vs. Enqueue Locks

Database locks The Development Soapbox