ABAP workshopLogical Unit of Work (LUW) Lock Concept and Enqueue

Data ClustersAuthorization Checks

2

Topics

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

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

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)

Database LUW

Program starts

Program ends

Commit or Rollback

update,delete etc

**This is for NON SAP Environment – see subsequent slides for SAP Environment **

5

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

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

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

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.

9

SAP Architecture

SAP Web Application Server

Work Processes beyond programmers control

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

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.

13

LUW – More InfoSAP LUW iswithin 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.

14

LUW – More Info

15

LUW – More Info

Variables, Internal Tables, etc

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

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)]

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

19

Update Techniques

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

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 COMMITSyntax: 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

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)

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)

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

24

Not using Delayed Subroutines

Reprinted for comparison

25

Delayed Subroutines (continued)

Data Flow

26

Delayed Subroutines (continued)

No screen data can be accessed, only data from variables

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

28

Local Update

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

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

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]

32

Update Modules

Setup V1/V2 Function Module

33

Update Modules

34

Update Modules

35

Update Modules

36

Update Modules

CALL FUNCTION 'UPDATE_SFLIGHT' IN UPDATE TASKEXPORTING

carrier = wa_sflight-carridconnection = wa_sflight-conniddate = wa_sflight-fldate.

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

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

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)

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

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]

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]

43

Discarding RequestsGeneration Phase

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”

45

Discarding Requests - Processing Phase

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.

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]

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

49

Asynchronous Update

50

Synchronous Update

Synchronous update that is triggered by COMMIT WORK AND WAITField sy-subr can be used to find the success/failure

51

SM13

Notification that users can be setup to get if the update fail

View the updates that failed

52

SM14

Transaction SM14 is used to administrate the update system.

53

SM14

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

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

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 avoiddata 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 yourapplication design!

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

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

59

Lock Command

CALL FUNCTION ‘ENQUEUE_EZ_RESERVATIONS’EXPORTINGmode_reservations = ‘X’reservation_id = p_residEXCEPTION

foreign_lock = 1system_failure = 2

OTHERS = 3.mode_reservations = ‘X’ implies WRITE lockUnlock command works similarly using the

DEQUEUE_EZ_RESERVATIONS function.

60

Lock Command (ENQUEUE)

61

UnLock Command (DEQUEUE)

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.

63

Parameters in ENQUEUE Module

64

Setting/Releasing Locks (good)

65

Setting/Releasing Locks (Bad)

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’sdatabase 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

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

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]}

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.

71

Static vs. Dynamic

EXPORT {p1 = dobj1 p2 = dobj2 …} | {p1 FROM dobj1 p2 FROM dobj2} TO medium

orEXPORT (ptab) TO

medium

Internal table (ptab)

…dobj4p4dobj3p3dobj2p2dobj1p1

data objects

parameter list

Using Dynamic list does not clutter the command

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]

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]

74

Conversion OptionsACCEPTING 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)

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)

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

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)

78

Data Clusters

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

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

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)

82

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

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.

84

Profile of a User

• ProfileZPROFILETEST (Authorization Profile)

ZAUTHOBJCT (Authorization Object)ZAUTHORIZE (Authorization)

TESTFIELD1 (Field)H* - K*

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 isAUTHORITY-CHECK OBJECT auth_obj [FOR user]

ID id1 {FIELD val1} | DUMMY…ID id2 {FIELD val2} | DUMMY

86

Command - ExampleAUTHORITY-CHECK OBJECT ‘ZAUTHOBJCT’

ID ‘TESTFIELD1’ FIELD ‘James’ID ‘TESTFIELD2’ DUMMYID ‘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).

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.

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.