exp_0012 database dialogs ii

8/3/2019 EXP_0012 Database Dialogs II

1/14

0

SAP AG 1999

Basic Business Process

Database LUW

Bundling Database Changes

Lock Concept

Contents:

Database Dialogs II

(C) SAP AG BC400 12-1


2/14

0.2

SAP AG 1999

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

Database Dialogs II:Unit Objectives

Explain why you have to make database changes

to a business unit in a database LUW

Describe the SAP lock concept

(C) SAP AG BC400 12-2


3/14

0.3

SAP AG 1999

Application

Presentation

Database

Database work processesDatabase work processes

Work

process

WorkWork

processprocessWork

process

WorkWork

processprocessWorkWork

processprocess

Dispatcher

The R/3 Client/Server Architecture

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 anotheruser.

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


4/14

0.4

SAP AG 1999

Process

step 1

Process

step 2 . . .ProcessProcess

step nstep n

SAP LUW

Basic

business process

Basic Business Process

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


5/14

0.5

SAP AG 1999

Consistent

state 1

Intermediate state

Consistent

state 2

ROLLBACK

State of data changes -

insert, update, delete

COMMIT

Database LUW

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


6/14

0.6

SAP AG 1999

DB LUW

SAP LUW

Database changes

ABAP

Program

User dialogs

Aim: Bundling Database Changes in anSAP LUW

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


7/14

0.7

SAP AG 1999

DB LUWDB LUWDB LUW

PBOPBOPAI

PAI

ImplicitImplicitCOMMITCOMMIT

Dialog step

ImplicitImplicitCOMMITCOMMIT

Database

changes

ExplicitExplicitCOMMITCOMMIT

Implicit Database Commits

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 BC400 12-7


8/14

0.8

SAP AG 1999

Object lockedTimeTime

Lock tableLock tableRequest lock

Set successfully

1

SAP Lock Concept

(C) SAP AG BC400 12-8


9/14

0.9

SAP AG 1999



Could not be set

1

Set successfully

2

Request lock

SAP Lock Concept

(C) SAP AG BC400 12-9


10/14

0.10

SAP AG 1999



Set successfully Release lock

31

Could not be set

2

Request lock

SAP Lock Concept

(C) SAP AG BC400 12-10


11/14

0.11

SAP AG 1999

Object locked Object lockedTimeTime

Lock tableLock table

Set successfully

Request lock

Release lock

Request lock

4

3

Set successfully

1

Could not be set

2

Request lock

SAP Lock Concept

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


12/14

0.12

SAP AG 1999

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-connidEXCEPTIONS

foreign_lock = 1system_failure = 2others = 3.

IF sy-subrc 0.

MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNOWITH 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' ...

Example Program:Locking and Unlocking

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 lockobjects 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_ and DEQUEUE_ 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


13/14

0.13

SAP AG 1999

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

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


14/14

0.14

SAP AG 1999

You are now able to:

Database Dialogs II:Unit Summary

Explain why you have to make database changes

to a business unit in a database LUW

Describe the SAP lock concept

(C) SAP AG BC400 12-14

exp_0012 database dialogs ii

Documents