Rel. 4.

6a - 3/2/00 BC400

1
Database Dialogs II

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

 SAP AG 1999

(C) SAP AG ABAP Workbench Basics 12-1

Rel. 4.6a - 3/2/00 BC400

1.2
Database Dialogs II: Unit Objectives

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

 Explain why you have to make database changes

to a business unit in a database LUW
 Describe the SAP lock concept

 SAP AG 1999

(C) SAP AG ABAP Workbench Basics 12-2

Rel. 4.6a - 3/2/00 BC400

1.3
The R/3 Client/Server Architecture

Presentation

Application
Dispatcher

Work Work Work

process process 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 ABAP Workbench Basics 12-3

Rel. 4.6a - 3/2/00 BC400

1.4
Basic Business Process

Basic
business process

Process Process Process

step 1 step 2 ... 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 ABAP Workbench Basics 12-4

Rel. 4.6a - 3/2/00 BC400

1.5
Database LUW

State of data changes - Intermediate state

insert, update, delete

Consistent Consistent
state 1 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 ABAP Workbench Basics 12-5

Rel. 4.6a - 3/2/00 BC400

1.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 ABAP Workbench Basics 12-6

Rel. 4.6a - 3/2/00 BC400

1.7
Implicit Database Commits

Dialog step
PBO PAI Database
PAI PBO changes

Implicit Implicit Explicit

COMMIT COMMIT COMMIT

DB LUW DB LUW DB LUW

 SAP AG 1999

 Implicit database commits are triggered when:

A dialog step ends
An error dialog occurs
You call a function module in another work process (RFC).


(C) SAP AG ABAP Workbench Basics 12-7

Rel. 4.6a - 3/2/00 BC400

1.8
SAP Lock Concept

Set successfully

Request lock Lock table

Object locked
Time

 SAP AG 1999

(C) SAP AG ABAP Workbench Basics 12-8

Rel. 4.6a - 3/2/00 BC400

1.9
SAP Lock Concept

Set successfully

Request lock Lock table

Request lock

Could not be set

Object locked
Time

 SAP AG 1999

(C) SAP AG ABAP Workbench Basics 12-9

Rel. 4.6a - 3/2/00 BC400

1.10
SAP Lock Concept

1 3

Set successfully Release lock

Request lock Lock table

Request lock

Could not be set

Object locked
Time

 SAP AG 1999

(C) SAP AG ABAP Workbench Basics 12-10

Rel. 4.6a - 3/2/00 BC400

1.11
SAP Lock Concept

1 3

Set successfully Release lock

Request lock Lock table

Request lock Set successfully

Could not be set Request lock

2 4

Object locked Object locked

Time

 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 ABAP Workbench Basics 12-11

Rel. 4.6a - 3/2/00 BC400

1.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 ABAP Workbench Basics 12-12

Rel. 4.6a - 3/2/00 BC400

1.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 ABAP Workbench Basics 12-13

Rel. 4.6a - 3/2/00 BC400

1.14
Database Dialogs II: Unit Summary

You are now able to:

 Explain why you have to make database changes
to a business unit in a database LUW
 Describe the SAP lock concept

 SAP AG 1999

(C) SAP AG ABAP Workbench Basics 12-14