Authorizations trace

Purpose
Which authorization checks are called when a transaction, a report, a function module etc? Well in transaction SU24, SAP has provided a list over which object could be relevant in different transactions, function modules etc. Though this has been developed in order to provide default values for the profile generator, it also a god starting point for investigating which object could be relevant in given business scenario. However it will not tell you which object are checked in the concrete business scenario / Business scenario step. And for your own development or for third party solutions SU24 probably wont provide much help either. In order to gain an overview over which authorization checks are called when execution a business scenario / business scenario step its often a good idea to do an authorization trace. This is called though transaction ST01. The example below is based on a SAP 4.7 IDES system.

Preparing for the Trace

In order to limit the trace file to the business scenario steps in question its a good idea, in another session, to prepare the functionality we would like to trace. That is, if it isnt an entire transaction call we would like to trace, then call the transaction code, and proceed until the step from where you want to do the trace. e.g. if you want to investigate which authorization object are called when executing a workitem from the SAP Business Workflow, then call of the SAP Business Workflow inbox (transaction SO01) first and navigate to the workitem in question, before activating the trace.

Authorization Trace
An authorization trace is triggered from transaction ST01

In order to start a trace check Authorization check. In order to avoid executing the trace for every user/transaction executed in the system, limit the trace. This is done from the menu Edit -> Filter -> Shared

A Filter can, in 4.7 be created for a process, user, transaction or report. In this example a filter is created for the SAP User mortenn. Thus writing all authorization checks for this specific user to the trace file (Make sure that this user arent performing other tasks while tracing).

If youre not tracing with a filter, all authorization checks will be written to the trace file.

To activate the trace push the trace on button.

You are now ready to perform the business scenario steps you would like to trace.

Please notice that, if these steps are performed by a user, without full authorization, we may not be able to finish all the steps in the business process, and all relevant authorizations checks may not be performed and written to the trace file, on the other hand you will be able to see the exact return code for each authorization cheeks.

On the other hand, if the trace is performed by a user with full authorization, you wont get the return codes for users with a limited role.

Which approach to use, depends of the business scenario step, and the purpose of the trace.

Analyzing the trace file

Immediately after performing the business steps we wanted to trace, we should switch of the trace by pushing the Trace off button , hereby avoiding polluting the trace file with irrelevant data.

In order to analyze the trace Analysis button

Now we are able to restrict the trace records well like to analyze, please pay attention to the

username.

Check Authorization check, you dont need the others. When we press execute well the selected records from the trace file.

In the trace you are able to see which authorization has been checked and the return code of these checks. You can se the values checked, for each authorization object, in the column text.

In the above example all authorization object has been checked with the return code 0, meaning that the authorization check has passed.

The following return codes are used:

0 = Authorization check passed 1 = No authorization 2 = To many parameters for authorization check 3 = Object not contained in user buffer 4 = No profile contained in user buffer 6 = Authorization check incorrect 7, 8, 9 = Invalid user buffer

Please notice that all authorization check doesnt have to pass in order for the transaction / application to work as required. In granting authorizations you should always check the documentation of the authorization object in question in order to decide whether or not this object is required.

Furthermore please notice that authorization groups, except the authorization group check for tables (S_TABU_DUIS) only are checked, if the required object contains a value. Authorization checks for authorization groups are therefore not recorded in the authorization trace.

The major transactions for Trace Options in SAP are :1. 2. 3. 4. 5. System Log (SM21). Dump Analysis(ST22). System Trace(ST01). Performance Trace(ST05). Developer Trace(ST11).

SYSTEM LOG(SM21)
a) Can be used to detect and correct errors in our SAP system and its Environment. b) SAP application servers record events and problem in system logs.

c) Every SAP application Server has a local log that contains the messages output by this server. Local System Log :- /usr/sap//D*/log/SLOG Central System Log:- /usr/sap//SYS/global/SLOGJ central system log feature - Available in Unix ,not possible in Windows and Iseries. profile parameter (RZ10) :rslg/local/file :- local log file rslg/central/file:-Central file Invoked by tools-->Administration-->Monitor -->System Log or Call transaction SM21.

2)Dump Analysis(ST22)
a) If unpredictable errors occurs during run-time when you call an ABAP program , a run-time error that generates a short dump can occurs. b) By default, short dump are stored in the system for 14 days. c) You can delete short dumps in accordance with a time specification using the reorganize function ,which you call by choosing Goto -->Reorganize . d) one can save a short dump without a time limit using the KEEP function ,which one can choose from detail view under short Dump -->KEEP/RELEASE. Characteristics of Dump Analysis:1) If a run time error occurs ,a short dump is generated.You can use transaction ST22 to analyzer this short dump. 2) Dump data is stored in the database. 3) Dump data can be reorganized. 4) Individual short dump can be flagged for retention.

System Trace (ST01)

to record the internal SAP activities ,such as authorization checks,database access ,kernel functions and RFC calls. The system trace is used for analyzing: a) Authorization checks b) Kernel functions c) Kernel modules d) DB accesses (SQL Trace) e) Accesses to table buffers f) Lock operations (client-side).

PERFORMANCE TRACE(ST05)
The Performance trace is used for analyzing: a) Database calls b) Lock management calls c) Accesses to table buffers d) Remote calls of reports and transactions e) Individual trace records f) SQL statements.

DEVELOPER TRACE(ST11)
Developer traces are recordings that contain technical information and that are used if errors occur.

a) Can be read by using Transaction AL11. b) Browse to directory usr/sap//d*/work. c) Developer trace can be viwed at dev_* files. d) Can be accessed in Transaction: SM50. Process Trace Display File.