0

Database Dialogs II

Contents:
Basic Business Process
Database LUW
Bundling Database Changes
Lock Concept

SAP AG 1999

(C) SAP AG

BC400

12-1

0.2
Database Dialogs II: Unit Objectives

At the conclusion of this unit, you will be able to:

SAP AG 1999

(C) SAP AG

BC400

12-2

0.3
The R/3 Client/Server Architecture

Presentation

Application

Dispatcher

Work
process

Work
process

Work
process

Database
Database work processes

SAP AG 1999

The SAP R/3 System is based on a client/server architecture with three levels; database, application
server, and presentation server.
This architecture, which distributes user requests (user dispatching), leads to a high-performance,
cost-efficient multiple-user system.
It allows a large number of users with cheaper, comparatively slow desktop computers to take
advantage of a smaller number of work processes running on far quicker (and more expensive)
application servers. Each work process on an application server is also assigned to a work process on
a database server.
User dispatching assigns a work process to the individual clients at the presentation server level for
a fixed period of time. In turn, the application server work process uses a work process on the
database. After the system has processed the user input in a dialog step, the user, along with the user
and program context are rolled out of the work process. The work process is then free for another
user.
The three-tier architecture is considerably more scalable than a "fat" client, in which the presentation
and application server tiers run in a single layer. The three-tier architecture requires fewer database
shadow processes than the "fat" client architecture, reducing its costs.

(C) SAP AG

BC400

12-3

0.4
Basic Business Process

Basic
business process
Process
step 1

Process
step 2

...

Process
step n

SAP LUW

SAP AG 1999

An SAP Logical Unit of Work (LUW) contains a series of steps in a business process in the R/3
System that logically belong together.
The steps in the process chain of the business process must be logically related.
SAP LUWs work on an all-or-nothing principle: Either the system processes all of the steps, or none
of them at all.
The business process represented in the LUW must be basic. For example, the entire process from
customer order to billing is too big to be included in a single LUW. Instead, you would split the
process up into smaller, independent sections, each of which would form a transaction in the R/3
System. Exactly what constitutes a "basic" process depends on the business process and the way in
which you have modeled it.

(C) SAP AG

BC400

12-4

0.5
Database LUW

State of data changes insert, update, delete

Intermediate state

Consistent
state 1

Consistent
state 2

COMMIT
ROLLBACK

SAP AG 1999

A database LUW is an inseparable sequence of database operations that takes the database from one
consistent state to another.
Database LUWs are either completely executed by the database system, or not at all.
Database LUWs close with a database commit. It is only in the commit that the changes are firmly
written in the database. Until the commit occurs, you can undo your changes using a database
rollback.

(C) SAP AG

BC400

12-5

0.6
Aim: Bundling Database Changes in an
SAP LUW

SAP LUW

User dialogs
ABAP
Program

Database changes

DB LUW

SAP AG 1999

Using an SAP LUW to represent a business process in the R/3 System involves both user dialogs and
a database dialog. The purpose of a transaction is to make sure that the data exchanged between
program and user in the user dialogs is processed on an all-or-nothing basis in the database. This
means that all of the changes from the SAP LUW must be processed in a single database LUW.
Usually an SAP LUW is processed in more than one DB LUW.
The aim when programming a transaction is to bundle the segments of the database dialog in a DB
LUW.
You should aim to process the database dialogs as late as possible within the database LUW, and to
keep the database locks set for as short a time as possible.

(C) SAP AG

BC400

12-6

0.7
Implicit Database Commits

Dialog step

PBO

PAI

Implicit
COMMIT

DB LUW

PAI

PBO

Database
changes

Implicit
COMMIT

DB LUW

Explicit
COMMIT

DB LUW

SAP AG 1999

Implicit database commits are triggered when:

(C) SAP AG

BC400

12-7

0.8
SAP Lock Concept

Set successfully
Request lock

Time

Lock table

Object locked

SAP AG 1999

(C) SAP AG

BC400

12-8

0.9
SAP Lock Concept

Set successfully
Request lock

Lock table

Request lock
Could not be set

Time

Object locked

SAP AG 1999

(C) SAP AG

BC400

12-9

0.10
SAP Lock Concept

Set successfully
Request lock

Release lock

Lock table

Request lock
Could not be set

Time

Object locked

SAP AG 1999

(C) SAP AG

BC400

12-10

0.11
SAP Lock Concept

Set successfully
Request lock

Release lock

Lock table
Set successfully

Request lock
Could not be set

Request lock

Time

Object locked

Object locked

SAP AG 1999

A database lock only remains set for a single database LUW. They are therefore unsuitable if you
want to lock an object for an entire SAP LUW.
To allow you to set a lock for an entire SAP LUW, the R/3 System contains its own lock mechanism,
which is fully independent of the database locking system.
In the SAP lock concept, programs generate entries in a lock table for the table entries that they want
to use.
It is only possible to set a lock entry if the relevant table entries are not already locked. The return
code tells the program whether the lock has been set successfully. You can query the return code in
the program and react accordingly. If the table entries are already locked by another user, you can
display a suitable error message.
Before you can set locks, you must define an appropriate lock object in the ABAP Dictionary. The
lock object specifies the arguments that are used to lock table entries.
When you activate a lock object, the system generates an ENQUEUE and a DEQUEUE function
module.
The SAP lock mechanism only sets logical locks. It is therefore only effective if all application
programs comply with its principles.

(C) SAP AG

BC400

12-11

0.12
Example Program: Locking and Unlocking
REPORT SAPBC400TCD_ENQUEUE_DEQUEUE.
...
AT LINE-SELECTION.
PERFORM authorization_check USING wa_spfli-carrid '02'
CHANGING subrc.
IF subrc <> 0. MESSAGE e047(BC400) WITH wa_spfli-carrid. ENDIF.
CALL FUNCTION 'ENQUEUE_ESSPFLI'
EXPORTING carrid = wa_spfli-carrid
connid = wa_spfli-connid
EXCEPTIONS
foreign_lock
= 1
system_failure = 2
others
= 3.
IF sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
SELECT SINGLE * FROM spfli INTO wa_spfli
WHERE carrid = wa_spfli-carrid
AND connid = wa_spfli-connid.
MOVE-CORRESPONDING wa_spfli TO sdyn_conn.
CALL SCREEN 100.
CALL FUNCTION 'DEQUEUE_ ESSPFLI' ...

SAP AG 1999

In the example program it makes sense to set a lock entry, before the data record has been read from
the database and the screen processed.
You set a lock entry by calling an ENQUEUE function module for an appropriate lock object. You can
find out which lock objects are available for a database table from the table's where-used list in the
ABAP Dictionary. The "lock" and "unlock" function modules for the selected lock object require
only the ENQUEUE_<Name of lock object> and DEQUEUE_<Name of lock object> naming
conventions. In general, you need only pass the interface key fields. Default values are passed to all
the other parameters.

(C) SAP AG

BC400

12-12

0.13
Example Program: Database Updates
REPORT SAPBC400TCD_ENQUEUE_DEQUEUE.
...
MODULE user_command_0100 INPUT.
CASE ok_code.
...
WHEN 'SAVE'.
MOVE-CORRESPONDING sdyn_conn TO wa_spfli.
CALL FUNCTION 'BC400_UPDATE_FLTIME'
EXPORTING
iv_carrid
= wa_spfli-carrid
iv_connid
= wa_spfli-connid
iv_fltime
= wa_spfli-fltime
iv_deptime
= wa_spfli-deptime
EXCEPTIONS
OTHERS
= 1.
IF sy-subrc NE 0.
MESSAGE a149.
ELSE.
MESSAGE s148.
LEAVE TO SCREEN 0.
ENDIF.
ENDCASE.
ENDMODULE.
" USER_COMMAND_0100

INPUT

SAP AG 1999

The example program shows a simple database change, which affects only one database table. This
allows us to update the database directly from a dialog - that is, using the simplest technique. The
ABAP statements that update the database are all executed within a DB LUW. You must not include
a user dialog between two ABAP statements that update the database. NOTE: This includes error
messages. If an error occurs, the program should be canceled with an "abnormal end" message, so
that a roll-back automatically occurs. All the necessary calculations, consistency checks, and
database updates are encapsulated here in a function module. A function module call (without a
DESTINATION addition...) has no effect on the DB LUW.
More complex database updates are performed using update modules. For more information, see
BC414 Programming Database Updates.

(C) SAP AG

BC400

12-13

0.14
Database Dialogs II: Unit Summary

You are now able to:

SAP AG 1999

(C) SAP AG

BC400

12-14