Monday, 6 January 2014

Modifying Data in a SAP Database Table

Modifying Data in a SAP Database Table

When writing programs using open SQL, one has to bear in mind the concepts of authori-sation in an SAP system. An SAP system has its own security tools to ensure that users can only access data which they are authorised to see. This includes individual fields as well as individual records. The way authorisations are set up can also limit how data is used, whether a user can only display data or whether they can modify it. All the rules pertain-ing to this are stored as authorisation objects. These will not be examined in great detail here, but ordinarily users are assigned their own authorisation profile (or composite pro-file) against their user record, which for informational purposes is managed through transaction code SU01.
This profile then gives the user the correct rights within the program to then carry out their job and SAP delivers many predetermined user profiles with the base system. The system administrators can then use and enhance these to be applied to users. Once a user has one of these profiles, the system will tell them whether or not they can execute a transaction when they try to do this. For example, transaction SE38, the ABAP editor, could be tweaked so that while some users may be able to access it, perhaps they can only do so in display mode, or perhaps they can display and debug the code, but not change it themselves.
Where specific authorisations have not been implemented, programs can be made to carry out an authority check, using the statement AUTHORITY-CHECK. This must be used if a program or transaction is not sufficiently protected by the standard authorisation pro-files already set up in the system.
While, this will not be examined in great detail here (the topic is huge in itself), it is impor-tant to bear authorisations in mind when working in SAP.

No comments:

Post a Comment