The document discusses logical unit of work (LUW) concepts in SAP, including: 1) LUWs regulate consistent data transitions and usually end with a database commit; 2) SAP uses both database LUWs and explicit ABAP LUWs; 3) Database LUWs automatically commit after each screen which can cause inconsistencies, so SAP bundles them using ABAP LUWs; 4) Update techniques like delayed subroutines allow separating user dialogs from database updates while maintaining data consistency.

1. ABAP workshop
Logical Unit of Work (LUW)
Lock Concept and Enqueue
Data Clusters
Authorization Checks

2. Topics
• Logical Unit of Work (LUW)
• Lock Concept and Enqueue
• Data Clusters
• Authorization Checks
2

3. LUW, Lock Concept and
Enqueue
• Background: Let us start with the legendary ATM example for
transferring money from a Saving to Checking bank account. Can anyone
explain what this ATM example is? We very well know the need for having
consistent data status before and after this bank transfer.
• The Consistent Data Storage is usually done using the LUWs and Locks
– Logical Unit of Work (LUW)
A LUW is a non-separable sequence of transactions (SQLs) that
regulates the chronological transition from one consistent state to
another, and usually ends with a database commit.
– Lock Concept
Lock prevents unwanted access or update to data during an LUW.
• LUWs are of two types
– Database (implicit)
– ABAP (explicit)
• LOCKS are also of two types
– Database Locks
– SAP Locks
3

4. Database (implicit) LUW
• Is executed by the database system
• Is a non-separable sequence of database operations
that end in a database commit
• Is either executed completely by the database
(commit) or not executed at all (rollback)
• When completed, returns the system to consistent
status and a new database LUW is opened
• Is normally not sufficient for consistent data storage
in SAP environment (why? see next slides)
**This is for NON SAP Environment – see subsequent slides for SAP Environment **
update, Program
Program delete
etc ends
starts
Commit or Rollback
Database LUW
4

5. SAP Work processes
Work processes execute the individual
dialog steps of ABAP application
programs
5

6. SAP Work processes
With each new single screen, the current work process is released
on the application server and also on the database server - this
automatically initiates an implicit database commit.
Since user dialog wait for (slower) user actions, releasing the work
processes on the server(s) ensures efficient use of server resources 6

7. Why SAP LUWs?
• Every ABAP program that is currently active requires a work
process, and each work process is logged on to the database as a
user and starts/ends a database LUW
• A work process cannot execute more than one database LUW in
parallel
• More than one work process cannot influence a single database
LUW
• An ABAP program (among other reasons, including the scheduling
algorithm used or waiting for a resource) can be rolled out of the
work process to make space for other waiting processes
• Therefore an ABAP program is frequently linked with more than
one work process over the course of its total runtime
• In our ATM example the debit and credit statements of the
accounts could happen to be in different work process. But as
mentioned two or more work processes cannot influence a single
database LUW
7

8. Why SAP LUWs? (continued)
• The debit could get committed in the first work process’
database LUW and the credit could get committed in the
next work process database LUW
• But, if the second work process fails for some reason, it will
be too late to undo the first as would have already been
committed by then
• Therefore, in SAP environment it is not sufficient for
consistent data storage by just relaying on the database
LUW
• For a program that extends over several work process and
therefore several database LUWs (and most of them do),
the changes should not be committed until the program
ends. This functionality is provided by the SAP LUWs
• The database LUWs are generally bundled and then
executed as a single database LUWs during the final work
process of the SAP LUW.
8

9. SAP Architecture
SAP Web Application Server
Work Processes beyond
programmers control
9

10. 10

11. LUW – More Info
• Implicit DB commits are always initiated
whenever the program has to wait, as in
the following cases:
– When the system sends an SAP screen
– When the system sends a dialog message
– Whenever there are synchronous and
asynchronous RFC calls (Remote Function
Call)
– Statements CALL TRANSACTION <t_code>
or SUBMIT <program>.
11

12. LUW – More Info
• Due to the above-mentioned, implicit DB
commits, changes that belong to an SAP
LUW may not be placed in different dialog
steps. The reason is because these steps
would thus not be within a DB LUW.
– Dialog step = program processing after a
screen.
12

13. LUW – More Info
SAP LUW is
within a DB LUW
- is required for
consistent data
storage
As seen before a DB commit is issued when the system sends a SAP screen
(picture shown again to signify its importance) Due to implicit DB commits,
changes that belong to a SAP LUW belong to ONE dialog steps (program
processing after a screen, say within the PAI of ONE screen followed by the
PBO of the next screen) Also, see Delayed Subroutines & alternate methods.
13

14. LUW – More Info
14

15. LUW – More Info
Variables, Internal Tables, etc
15

16. LUW – More Info
• Any business transaction is NOT necessarily processed
by a single SAP LUW
– Example: The entire process from receipt of a customer order up
to the issue of an invoice, for example, is split up into individual,
logical parts. Each part corresponds to an SAP LUW. The
definition of SAP LUWs depends on the entire process and its
modeling.
• Changes that belong together from a logical point of view
are considered a single SAP LUW
• If there is an error during processing of an SAP-LUW, it
should be possible to return to a consistent database
status that existed before the beginning of the SAP-
LUW. So that this is possible, the SAP-LUW must be
processed within a DB-LUW
16

17. SAP LUW Commands
• The following statement completes the
current SAP LUW and opens a new one
– COMMIT WORK [AND WAIT]
• The [AND WAIT] clause makes the process
synchronous (waits for completion of
commit) before continuing with the rest of
the program
• The following command ends a LUW
without saving changes
– SAP ROLLBACK or ROLLBACK WORK
[note: The ROLLBACK WORK statement does not
affect the program context; all data objects (variables,
internal tables, etc) remain unchanged (NOT reset)] 17

18. Update Techniques
• We have learned that Bundling database updates into a
single dialog step (usually the last) ensure that your
database changes are processed using the "all or
nothing" principle. Therefore we have to wait until the
last dialog step to actually issue all the database
statements
• What if you do not wish to wait until the last dialog step
(PAI of last screen) before you wish to issues these
update (update/delete/insert/modify) statements? Is this
possible?
• Yes, it is possible using the following techniques
• Delayed Subroutines
• Local updates
• V1 and V2 Updates
18

19. Update Techniques
Update techniques allow you to separate user dialogs from the database changes. Both
are executed by different programs, which generally run in different work processes.
19

20. Delayed Subroutines (continued)
• Database updates from dialog mode (using
Delayed Subroutines) can be executed in
bundled form by using the special subroutine
technique PERFORM ON COMMIT
Syntax: PERFORM <subroutine> ON COMMIT.
• The PERFORM ON COMMIT registers the
specified subroutine for execution. This will not
be executed until the system reaches the next
COMMIT WORK statement
20

21. Delayed Subroutines (continued)
• If the database updates are "encapsulated" in
the subroutines, they can be separated from the
program logic and relocated to the end of the
LUW processing
• Each subroutine registered with PERFORM ON
COMMIT is only executed once per LUW. Calls
can be made more than once (no errors); the
subroutine, however, is only executed once
• Nested PERFORM ON COMMIT calls are not
allowed (release >= 4.6)
21

22. Delayed Subroutines (continued)
• The COMMIT WORK statement carries out all
subroutines registered to be executed, one after
the other, and triggers a database commit
• If there is an error, you can terminate processing
from the respective subroutine with a type A
dialog message and the previous consistent
database status can be restored
• Subroutines called using “PERFORM ON
COMMIT” must have no interface (No screen
data can be accessed, only data from variables)
22

23. Delayed Subroutines (continued)
The COMMIT WORK statement carries out all subroutines (x, y, etc)
registered to be executed, one after the other, and triggers a database commit
23

24. Not using Delayed Subroutines
Reprinted for comparison
24

25. Delayed Subroutines (continued)
Data Flow
25

26. Delayed Subroutines (continued)
No screen data can be accessed, only data
from variables
26

27. Local Update
• In local updates, the update functions are run in
the same dialog process used by the dialog
program containing the dialog program
• Processing of the dialog program is continued
when the update has been complete
(synchronous)
• To have update modules executed locally, you
must use the statement SET UPDATE TASK
LOCAL before you write the respective requests
• In the local update mode, change requests are
not written to the database table VBLOG, but
kept in main memory
27

28. Local Update
28

29. Local Update
• Close the written requests with the statement
COMMIT WORK, and these will be processed in
the same dialog work process
• After the local update has been successfully
processed, a DB commit is initiated explicitly and
the dialog program is continued
• If there is an error and a termination message is
dispatched by one of the update modules, the
system executes an automatic DB rollback to
discard the changes in the current LUW and the
dialog program is terminated by the display of a
termination message
29

30. Local Update
• Due to the missing IO accesses, this is
quicker than for synchronous or
asynchronous updates. The disadvantage,
however, lies in the exclusive use of a
work process. Therefore, local updates are
only appropriate in batch mode
30

31. Update Modules (V1/V2)
• Another technique that has the effect of delaying their
own execution until the ABAP command COMMIT
WORK is by using special functions called Update
Modules (V1/V2)
• To use this technique create functions of type V1 and V2
(See setup –shows functions attributes needed to be set)
• The type (V1/V2) of update module determines its
processing mode
• All V1 requests in the dialog program are executed as
independent DB LUW
• Only if V1 modules are executed successfully are V2
requests processed, also as independent LUWs
• The log table is VBLOG in the system [replace it with the
tables VBHDR, VBMOD, VBDATA, and VBERROR]
31

32. Update Modules
Setup V1/V2 Function Module 32

33. Update Modules
33

34. Update Modules
34

35. Update Modules
35

36. Update Modules
CALL FUNCTION 'UPDATE_SFLIGHT' IN
UPDATE TASK
EXPORTING
carrier = wa_sflight-carrid
connection = wa_sflight-connid
date = wa_sflight-fldate.
36

37. Update Modules
• You create update requests from the dialog
program by calling the respective update
function module
• Use the IN UPDATE TASK addition
• This means that the function module is not
executed immediately, but is written to the log
table, together with the input data, as an
execution request
• All of the update flags in an SAP LUW are stored
under the same update key ("VB key")
• The update key is a unique worldwide
identification code for an SAP LUW
37

38. Update Modules
• Only when the system finds a COMMIT WORK
statement will it create a header entry for the
requests that belong together (log header), and
then the unit is closed
• The log header contains information on the
dialog program that wrote the log entries, as well
as information on the update modules to be
executed
• After the log header has been created, the
system informs the dispatcher process that there
is an update package for processing
38

39. Update Modules
• The locks created from within the dialog
program using _scope = 2 (default) are
transferred to the V1 update task at COMMIT
WORK (AND WAIT)
• At the end of the V1 update, they are
automatically deleted
• Therefore, lock entries must not be explicitly
removed either in the dialog program (too early)
or in the update module (unnecessary)
39

40. Update Modules
• V2 update modules are used for database
changes that are linked to the V1 changes
(main changes) but do not necessarily
have to be executed in the same DB LUW
(for example, updating of statistics)
• V1 modules can be either restartable or
non-restartable
• The V2 update always runs without SAP
locks
40

41. Update Modules
• If there has been an update error, these can manually
restart requests that were created by restartable update
modules using transaction SM13
• This is done after we clean up the application error in
question
• V2 update modules can always be restarted for
processing if there has been an error
• The classification collective run for V2 modules is a
special type of V2 update. [Corresponding requests are
not executed directly after the V1 update, but only after
the collector program RSM13005 (generally planned
ahead) has been called]
41

42. Update Modules
• You must not use the explicit ABAP statements COMMIT
WORK and ROLLBACK WORK in the update module
(V1/V2)
• If you have locks set in a dialog program that works with
the update technique and these locks have been set
using _scope = 2 , you can pass these on to the update
task at COMMIT WORK. After this, they are no longer
accessible by the dialog program
• You do not need to release the locks explicitly in the
update modules since they are automatically released by
a basis program at the end of the update process [in
addition as mentioned before, do not release the locks in
the dialog program as they are passed to the update
module when using _scope = 2]
42

43. Discarding Requests
Generation Phase
43

44. Discarding Requests
- Generation Phase
• To discard the current SAP LUW during the
generation phase,
– use the ABAP statement ROLLBACK WORK or
– send a type “A” dialog message
• Both procedures
– delete all previous update flags,
– delete all previously set locks,
– discard all of the updates executed in the current DB
LUW
– discard all of the form routines registered using
“PERFORM ON COMMIT”
44

45. Discarding Requests - Processing
Phase
45

46. Discarding Requests Processing
Phase
• If you want to trigger a database rollback in the update
module, issue a type “A” dialog message. In this way,
the processing of the current SAP LUW will also be
terminated.
• Do NOT use ROLLBACK WORK Command (within
Update Module) to terminate [or even COMMIT WORK]
• The log entry belonging to the SAP LUW is flagged as
containing an error. The termination message is also
entered in the log.
• You can examine the log entry using transaction SM13.
• The system sends an express mail to the relevant user,
telling him or her that the LUW update was terminated.
46

47. Synchronous versus Asynchronous
• A asynchronous - return control back to calling program
prior to database commit/roll back - COMMIT WORK
• An synchronous - don't return control back to calling
program until database commit/roll back - COMMIT
WORK AND WAIT
• Since their execution is delayed and control is passed
back to the calling program (before the completion of the
called functions,) the entire process for both the following
is often called an asynchronous process.
– CALL FUNCTION '<function name>' IN UPDATE TASK [update
module (V1/V2)]
– PERFORM <subroutine name> ON COMMIT [Delayed
Subroutines]
47

48. Synchronous versus Asynchronous
• In asynchronous updates, the dialog program and
update program run separately
• The dialog program writes the change requests to the
log table and closes the LUW with a COMMIT WORK
• The update initiated by the COMMIT WORK now
processes the change requests
• The dialog program is continued; the system does not
wait for the update to end
• The update program runs in a special update work
process. This can be on an application server other than
the one used for the R/3 System
48

49. Asynchronous Update
49

50. Synchronous Update
Synchronous update that is triggered by COMMIT WORK AND WAIT
50
Field sy-subr can be used to find the success/failure

51. SM13
View the updates that failed
Notification that users can be setup to get if the update fail
51

52. SM14
Transaction SM14 is used to administrate the update system.
52

53. SM14
53

54. Lock Concept
• There may be only few things worse than having two
users changing the same data simultaneously. The
results can be problematic at best and disastrous at
worse. SAP R/3's locking mechanism can protect data
when more than one user is accessing it
• The SAP R/3 system protects data if multiple users
attempt to change it simultaneously. This guarantees
data correctness and consistency even when a large
number of users are connected to the SAP system
• What makes this all happen is an additional SAP locking
mechanism that enables you to synchronize concurrent
read or write requests for a particular set of data. The
purpose is to prevent writing data that is being read by
someone or restricting data from being read that is
already in the editing mode
54

55. Database Locks
• When accessing database using SQL, the
database sets implicit physical database
locks, these locks remain until the
database LUW. The modifying statements
INSERT, UPDATE, MODIFY and DELETE
and the SELECT with the FOR UPDATE
clause setup the exclusive locks
• These implicit database locks do not
suffice for setting SAP LUW locks. SAP
locks are used for this purpose
55

56. SAP Locks
• They are based on lock objects that are defined in ABAP Dictionary
• They permit locks of single or several rows of a single database
table
• They also permit locks of rows of several database tables linked by
foreign key dependencies
• SAP locks must be enabled for the duration of SAP LUWs.
Therefore various work processes, and if applicable, changing
application servers must be able to handle these locks
• If a database table is used in various transactions make sure SAP
locks are used in critical data select and update areas to avoid
data been overwritten by different transactions - all running the
same time
• If you think a SAP lock is not required because the database table
you are using is being used by just one transaction, think again.
Two or more users using the same transaction and data could be
overwriting each others committed data
• Not able to reproduce any production data error that occurs
occasionally? The problem could be the lack of SAP locks in your
application design!
56

57. Creating SAP Locks
• Custom lock objects should start with E before the possible prefix
of the customer namespace (Z) [Example: EZ_RESERVATIONS]
• The creation of lock object generates two lock function modules
whose names consist of the prefixes ENQUEUE_ and DEQUEUE_
and the name of the lock object [Example: ENQUEUE_EZ_RESERVATIONS &
DEQUEUE_EZ_RESERVATIONS]
• The Lock Parameter that is setup include the key fields of the
table for which (key) values can be passed when the function
module is called
• The ENQUEUE_<lockobject> sets an SAP lock by writing entries
into the central lock table
• Parameter passing can inform the function module whether a
READ or WRITE lock should be set
• If a READ lock set by a program, no other program can set the
WRITE lock, however additional READ locks can be set
• To check whether a LOCK is set, simply try to lock and object.
Exception implies that lock has already been set by another
program
57

58. ENQUEUE work process
(server)
• ENQUEUE work process (or the ENQUEUE logical
server) manages the central lock table of the
entire system in its memory. The function
modules to set and delete locks are executed in
this work process
• A SAP installation can contain only one application
server with an ENQUEUE work process
• If we have multiple application servers
environment, various program running in various
application servers including the one that has the
ENQUEUE work process need to communicate with
this central area to set and delete locks
• Transaction SM12 – show current locks in the
system
• Lock → Read → Change → Unlock is the correct order
58

59. Lock Command
CALL FUNCTION ‘ENQUEUE_EZ_RESERVATIONS’
EXPORTING
mode_reservations = ‘X’
reservation_id = p_resid
EXCEPTION
foreign_lock = 1
system_failure = 2
OTHERS = 3.
mode_reservations = ‘X’ implies WRITE lock
Unlock command works similarly using the
DEQUEUE_EZ_RESERVATIONS function.
59

60. Lock Command (ENQUEUE)
60

61. UnLock Command (DEQUEUE)
61

62. Locks Modes
• Shared lock S (Shared) Several users (transactions) can access
locked data at the same time in display mode. A request for
another shared lock is accepted, even if it comes from another
user. An exclusive lock set on an object that already has a shared
lock will be rejected.
• Exclusive lock E (Exclusive or Extensible or Mode-E) 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).
• Exclusive but not cumulative lock X (eXclusive non-cumulative or
Mode-X) Exclusive locks can be requested several times from the
same transaction and are processed successively. In contrast,
exclusive but not cumulative locks can be called only once from
the same transaction. Each further lock request will be rejected.
• Optimistic lock O (Optimistic) Optimistic locks initially behave like
shared locks and can be converted into exclusive locks.
62

63. Parameters in ENQUEUE Module
63

64. Setting/Releasing Locks (good)
64

65. Setting/Releasing Locks (Bad)
65

66. Buffering of Database Tables
• To decrease load on a database system, tables having many
reads and few updates may be buffered
• In SAP Buffering, buffering occurs (resides) in the shared
memory of the current application server
• When a table is defined, buffering attributes are setup by the
developer depending on the table usage
• Synchronization between the various buffers (of various
application servers) and the database is controlled by SAP’s
database interface
• Buffering improves the performance dramatically by a factor
of 50 to 500 in some cases
• Buffered table’s data may not be available to other
applications for up to 60 seconds, so tables that are updated
regularly should not be buffered
• Buffering is bypassed implicitly by number of variants of SQL
statements (distinct clause/aggregate functions/joins/order
by/etc)
• Buffered data is bypassed by explicitly by using the BYPASS
BUFFER clause so that database data can be accessed 66

67. Data Clusters

68. Data Clusters
• A Data Cluster is a group of data objects grouped
together for the purpose of storage in a storage
medium
• The storage medium can be persistent or
transient
• Data Clusters are not Generic unlike commonly
used (other) storage formats like Relational
Database and Files that are Generic
• Data Clusters are SAP proprietary format and can
only be edited by using ABAP statements
• Data between different ABAP programs can be
exchanged/passed using the Data Clusters
68

69. Storage Medium
• Various types of the storage medium
for data clusters are:
1) Byte String {DATA BUFFER xstr}
2) Internal Table {INTERNAL TABLE itab}
3) ABAP Memory {MEMORY ID id}
4) Database Table {DATABASE dbtab(ar)}
5) Buffer of the Application Server {SHARED
MEMORY dbtab(ar) [TO wa]}
69

70. Syntax
1) EXPORT {p1 = dobj1 p2 = dobj2 …} |
{p1 FROM dobj1 p2 FROM dobj2} |
(ptab) TO medium [COMPRESSION
{ON|OFF}]
2) IMPORT {p1 = dobj1 p2 = dobj2 …} |
{p1 TO dobj1 p2 TO dobj2} | (ptab)
FROM medium [conversion_options]
Static: p1, p2 ,.. are read and passed to data objects dobj1, dobj2,
etc
Dynamic: The parameter list is adopted from internal table (ptab)
that has 2 columns. First column having the parameter list and
second one having the list of corresponding data objects.
70

71. Static vs. Dynamic
EXPORT {p1 = dobj1 p2
= dobj2 …} | {p1 Internal table (ptab)
FROM dobj1 p2 FROM parameter
list
data
objects
dobj2} TO medium p1 dobj1
or p2 dobj2
EXPORT (ptab) TO p3 dobj3
medium p4 dobj4
Using Dynamic list does not clutter the command …
71

72. Storage Medium - details
• DATA BUFFER xstr
[The data cluster is written/taken from the elementary data
object xstring, which must be of the type xstring (Byte-string).]
• INTERNAL TABLE itab
[The data cluster is stored/read in the internal table itab. The
first column of itab has to be data type s (2 byte integer), the
second column of the type x (1 to 65,535 bytes). Depending
on the width of the second column the data is stored in
multiple columns if necessary. The first column contains the
length occupied in the second row.]
• MEMORY ID id
[The data cluster is written/read to the ABAP memory with
the stated identification id]
72

73. Storage Medium - continued
• Database Table {DATABASE dbtab(ar) [FROM | TO wa]
[CLIENT c1] ID id}
[The data cluster with identification id is stored in the database table dbtab and
stored permanently at the next commit – the structure or the table MUST be
similar to the database table INDX delivered by SAP. Fields MANDT type
CLNT,RELID type CHAR to store area (ar), Any Field type CHAR to store id,
SRTF2 type INT4 contains row numbers of stored data, any number of
components specified by [TO wa], CLUSTR and CLUSTD type INT2 and LRAW of
any length]
• Buffer of the Application Server
– {SHARED MEMORY dbtab(ar) [FROM | TO wa] [CLIENT c1] ID id}
– {SHARED BUFFER dbtab(ar) [FROM | TO wa] [CLIENT c1] ID id}
[All programs on the same application server have access to these shared areas.
The area ‘ar’ splits up the table logically into several areas. The work area ‘wa’
shows the structure of dbtab. For SHARED MEMORY we need to manually delete
the buffer to make space for the new data, SHARED BUFFER is automatically
cleared – the least used area deleted]
73

74. Conversion Options
ACCEPTING PADDING
[target fields can be longer than source fields, target structures can have more fields
than source]
ACCEPTING TRUNCATION
[source structures can have more fields than target]
IGNORING STRUCTURE BOUNDARIES
[substructures in structures are replaced by plain fields while IMPORTING]
IGNORING CONVERSATION ERRORS
[exceptions that cannot be handled are suppressed]
REPLACEMENT CHARACTERS rc
[here each inconvertible character is replaced by character contained in rc, without this
‘#’ is used as a substitution character]
IN CHAR-TO-HEX MODE
[the contents of the source fields are not converted to the code page (character sets)
of the target, but are literally placed byte by byte]
CODEPAGE INTO cp
[assign the identification of the code page for the exported data to the data object cp]
ENDIAN INTO endian
[convert the byte sequence to the required format (Big endian [B] or Little endian [L]
directly from ABAP_ENDIAN to be consistent with the ABAP setup – note: characters
that take up more than one byte can be dependent on the byte sequence)
74

75. Clusters Catchable Exceptions
• CX_SY_EXPORT_BUFFER_NO_MEMORY
– The EXPORT data cluster is too large for the application buffer
– Runtime Error: EXPORT_BUFFER_NO_MEMORY
• CX_SY_EXPORT_NO_SHARED_MEMORY
– The EXPORT data cluster is too big for the shared memory.
– Runtime Error: EXPORT_NO_SHARED_MEMORY
• CX_SY_FILE_AUTHORITY
– No authorization to access a file
– Runtime Error: OPEN_DATASET_NO_AUTHORITY
• CX_SY_FILE_IO
– The EXPORT statement was unable to write to the file.
– Runtime Error: DATASET_WRITE_ERROR &
EXPORT_DATASET_WRITE_ERROR
• CX_SY_FILE_OPEN
– The EXPORT statement was unable to open the file
– Runtime Error: EXPORT_DATASET_CANNOT_OPEN (catchable)
75

76. Clusters Non-Catchable Exceptions
• Blanks in file names are not allowed.
– Runtime Error: DYN_IMEX_DS_NAME_ERROR
• The object name in the cluster, that is, the contents of
the first column of itab, is empty.
– Runtime Error: DYN_IMEX_OBJ_NAME_EMPTY
• An object name (in the cluster) occurs twice in the first
column of the internal table.
– Runtime Error: DYN_IMEX_OBJ_NAME_TWICE
• The data object to be exported does not exist.
– Runtime Error: DYN_IMEX_OBJ_NOT_FOUND
• You attempted to export an object, interface or data
reference.
– Runtime Error: REFS_NOT_SUPPORTED_YET
76

77. Deleting a Data Cluster
DELETE FROM { {MEMORY ID id}
| {DATABASE dbtab(ar) [CLIENT c1] ID id}
| {SHARED MEMORY dbtab(ar) [CLIENT c1] ID id}
| {SHARED BUFFER dbtab(ar) [CLIENT c1] ID id} }
[This deletes the data cluster that was
stored in the ABAP memory, in a
database table or in the application
buffer]
FREE MEMORY ID id (memory only)
77

78. Data Clusters
Shared Objects (Memory Areas)
are now used instead of
EXPORT/IMPORT statements
with the SHARED BUFFER
and SHARED MEMORY
78

79. Authorization Checks

80. Authorization Checks
• Because of Data Confidentiality not all data can
be accessed by all users in a company, hence we
need Authorization Checks
• Because ABAP statements are not linked to
automatic authorization checks (except for ABAP
File Interface), if a program accesses critical
data, we need to a mechanism coded in the
program to provide access appropriately
• SQL statements within ABAP do not perform any
authority checks thereby creating high risk of
users accessing or modifying confidential data
• Authorization Object is a repository object in
which authorizations can be defined
• Authorization objects can be used for performing
the Authorization Checks in ABAP programs
80

81. Authorization Objects
• An Authorization Object is a Repository Object
and can be accessed using Transaction SU21 or
using context menu of package in Object
Navigator
• Authorization Object contains up to 10
authorization fields representing
– 1) Restrict FIELD access >> Key fields of database tables
(example: CARRID – is the user authorized to query/view the
field CARRID?) and/or
– 2) Restrict Screen MODE (Activities) Access >> Activities such
as display or changing data (Use field ACTVT for this with ’01’,
’02’, ’03’, ’08’ etc for screen in create/change/display/delete –
is the user authorized to access screen in UPDATE mode or
can he/she view just DISPLAY mode?) See table TACT or
TACTZ (custom) for list of activities
• Use Authorization Profiles instead of assigning
authorizations to users directly (for easy
maintenance)
81

82. Authorization Fields Error
Authorization Fields have to be created using SU20,
before these fields can be added to the Authorization Object (using SU21
82

83. Authorization
• Check against what? First we need to setup access to
user, i.e., set of permissible values for various FIELDS
in the Authorization Objects.
• To do this we need to define any number of instances
for a given authorization object. First we must define
an additional value set object for fields of the
corresponding authorization objects. This set is also
called as authorization.
• Authorization is an instance of an authorization object
in which all fields are filled with specific field values, in
accordance to the authorization concept (use
Transaction Code SU03).
• The authorization check is based on ‘AND’ combination,
i.e., all have to pass for an authorization check to pass
(exception is when we use the DUMMY instead of FIELD
value to be explained later.)
• Use Field ACTVT to choose write or read-only access.
83

84. Profile of a User
• Profile
ZPROFILETEST (Authorization Profile)
ZAUTHOBJCT (Authorization Object)
ZAUTHORIZE (Authorization)
TESTFIELD1 (Field)
H* - K*
84

85. Authorization Check Within ABAP
at critical parts of program
• Time to Check! Authorization Checks can be
performed at the critical parts of the program
using Authorization Objects if:
– If an ABAP program cannot be protected by automatic
authorization check at the program startup (either at
transaction level or ABAP program properties), or
– if not all the users that are authorized to execute the
program are allowed to perform every action in it.
• The command is
AUTHORITY-CHECK OBJECT auth_obj [FOR user]
ID id1 {FIELD val1} | DUMMY
…
ID id2 {FIELD val2} | DUMMY
85

86. Command - Example
AUTHORITY-CHECK OBJECT ‘ZAUTHOBJCT’
ID ‘TESTFIELD1’ FIELD ‘James’
ID ‘TESTFIELD2’ DUMMY
ID ‘ACTVT’ FIELD ’03’.
IF sy-subrc <> 0.
MESSAGE ‘No authorization’ TYPE ‘E’.
ENDIF.
• The authorization check is using the authorization object ‘ZAUTHOBJT’.
• [FOR user] is not used here, this implies the authorization check is for
default user – i.e., current user (value is in sy-uname).
• System checks to make sure that this user can access data with value
‘James’ in field TESTFIELD1.
• System does not check any condition for TESTFIELD2, because of
DUMMY supplied next to that ID.
• System checks to see if the user has access for activity DISPLAY (03)
mode.
• sy-subrc returns a 0 if the authorization check is successful.
• Since the name ‘James’ lies between ‘H’ and K’ [see authorization
setup with: H* - K*] the check should be successful. For name say
‘Ernst’ it will fail.
• If the check fails – the system just sets the sy-subrc – nothing else.
We have to program/code the appropriate action based on this
(exit/give message, etc). 86

87. Other Authorization(s) –
Executing a Transaction
• LEAVE TO TRANSACTION: When creating a
transaction code, specify the name of an
authorization object in the Authorization Object
field and click on the Values button to enter
values for the fields of the authorization object.
At Runtime the environment compares those
values with the values in the user master record,
before the transaction is stated.
• CALL TRANSACTION: The above security
mechanism does not work directly for the CALL
statement, therefore the check has to be
performed by the calling program using function
module AUTHORITY_CHECK_TCODE.
87

88. Other Authorization(s) –
Executing an ABAP program
• This security mechanism can be setup
using the properties of the executable
programs, module pools, etc. The field
Authorization Group may be entered in
the property screen of the program, this
field is linked to the P_GROUP field of
authorization objects S_DEVELOP and
S_PROGRAM. By combining values in this
field of the program properties with values
in the user master record, authorizations
for individual ABAP programs can be
setup.
88