Abap slide lock Enqueue data clusters auth checks


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Abap slide lock Enqueue data clusters auth checks

  1. 1. ABAP workshopLogical Unit of Work (LUW)Lock Concept and Enqueue Data Clusters Authorization Checks
  2. 2. Topics• Logical Unit of Work (LUW)• Lock Concept and Enqueue• Data Clusters• Authorization Checks 2
  3. 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. 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, ProgramProgram delete etc endsstarts Commit or Rollback Database LUW 4
  5. 5. SAP Work processes Work processes execute the individual dialog steps of ABAP application programs 5
  6. 6. SAP Work processesWith each new single screen, the current work process is releasedon the application server and also on the database server - thisautomatically initiates an implicit database commit.Since user dialog wait for (slower) user actions, releasing the workprocesses on the server(s) ensures efficient use of server resources 6
  7. 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. 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. 9. SAP Architecture SAP Web Application ServerWork Processes beyondprogrammers control 9
  10. 10. 10
  11. 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. 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. 13. LUW – More Info SAP LUW is within a DB LUW - is required for consistent data storageAs 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 (programprocessing after a screen, say within the PAI of ONE screen followed by thePBO of the next screen) Also, see Delayed Subroutines & alternate methods. 13
  14. 14. LUW – More Info 14
  15. 15. LUW – More InfoVariables, Internal Tables, etc 15
  16. 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. 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. 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. 19. Update TechniquesUpdate techniques allow you to separate user dialogs from the database changes. Bothare executed by different programs, which generally run in different work processes. 19
  20. 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. 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. 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. 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. 24. Not using Delayed Subroutines Reprinted for comparison 24
  25. 25. Delayed Subroutines (continued) Data Flow 25
  26. 26. Delayed Subroutines (continued) No screen data can be accessed, only data from variables 26
  27. 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. 28. Local Update 28
  29. 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. 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. 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. 32. Update Modules Setup V1/V2 Function Module 32
  33. 33. Update Modules 33
  34. 34. Update Modules 34
  35. 35. Update Modules 35
  36. 36. Update ModulesCALL FUNCTION UPDATE_SFLIGHT IN UPDATE TASK EXPORTING carrier = wa_sflight-carrid connection = wa_sflight-connid date = wa_sflight-fldate. 36
  37. 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. 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. 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. 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. 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. 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. 43. Discarding Requests Generation Phase 43
  44. 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. 45. Discarding Requests - Processing Phase 45
  46. 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. 47. Synchronous versus Asynchronous• A asynchronous - return control back to calling program prior to database commit/roll back - COMMIT WORK• An synchronous - dont 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. 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. 49. Asynchronous Update 49
  50. 50. Synchronous UpdateSynchronous update that is triggered by COMMIT WORK AND WAIT 50Field sy-subr can be used to find the success/failure
  51. 51. SM13 View the updates that failedNotification that users can be setup to get if the update fail 51
  52. 52. SM14Transaction SM14 is used to administrate the update system. 52
  53. 53. SM14 53
  54. 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/3s 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. 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. 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. 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. 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. 59. Lock CommandCALL 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 lockUnlock command works similarly using the DEQUEUE_EZ_RESERVATIONS function. 59
  60. 60. Lock Command (ENQUEUE) 60
  61. 61. UnLock Command (DEQUEUE) 61
  62. 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. 63. Parameters in ENQUEUE Module 63
  64. 64. Setting/Releasing Locks (good) 64
  65. 65. Setting/Releasing Locks (Bad) 65
  66. 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. 67. Data Clusters
  68. 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. 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. 70. Syntax1) 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, etcDynamic: 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. 71. Static vs. DynamicEXPORT {p1 = dobj1 p2 = dobj2 …} | {p1 Internal table (ptab) FROM dobj1 p2 FROM parameter list data objects dobj2} TO medium p1 dobj1 or p2 dobj2EXPORT (ptab) TO p3 dobj3 medium p4 dobj4Using Dynamic list does not clutter the command … 71
  72. 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. 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. 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) 74
  75. 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. 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. 77. Deleting a Data ClusterDELETE 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. 78. Data ClustersShared Objects (Memory Areas) are now used instead of EXPORT/IMPORT statements with the SHARED BUFFER and SHARED MEMORY 78
  79. 79. Authorization Checks
  80. 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. 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. 82. Authorization Fields ErrorAuthorization Fields have to be created using SU20,before these fields can be added to the Authorization Object (using SU21 82
  83. 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. 84. Profile of a User• Profile ZPROFILETEST (Authorization Profile) ZAUTHOBJCT (Authorization Object) ZAUTHORIZE (Authorization) TESTFIELD1 (Field) H* - K* 84
  85. 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. 86. Command - ExampleAUTHORITY-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. 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. 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