The authorization Log in RSECADMIN - SAP NetWeaver Business Wa...

http://wiki.scn.sap.com/wiki/display/BI/The+authorization+Log+in+...

Getting Started Newsletters Store

Welcome, Guest

Login

Register

Search the Community

SAP NetWeaver Business Warehouse / / Learning Map by Topic

The authorization Log in RSECADMIN

Added by Jerome Penaranda, last edited by Jerome Penaranda on Aug 18, 2014

Purpose
To describe how to read and analyze authorization issues with the Authorization Log in RSECADMIN.

Overview
The OLAP-authorization-check must not be confused with the basis-authorization-check traced in transaction ST01 or SU53. Analysis Authorizations are NOT based on the SAP Standard
Authorization concept. They use their own concept based on the BW reporting and analysis features. Hence the OLAP authorization-check cannot be traced via ST01 or SU53, you need to trace and
display the OLAP-authorization-log in transaction RSECADMIN.

Using the log

Call transaction RSECADMIN. Choose the "Analysis" tab page. Choose the function for the Authorization log (pushbutton in the middle). On the following screen, you can execute all required actions for
logging.
Switching on logging: Choose the pushbutton for configuring logging to switch on logging for the required users (in the list, you can see whether this function is already switched on).
Execute the action you want to check. As a rule, this is a query execution. However, you can also log all other actions that use the reporting authorization.
*Important:*We strongly recommend that you use transaction RSRT (or RSRT2) to execute queries. If required, create a BOOKMARK and log its execution. (See note 788393.)
The execution in the BEx Analyzer, in the Web or in the Portal may result in very complex logs that are difficult to understand.
When you have executed the action, go back to the relevant position in transaction RSECADMIN.
The selection criteria (in the field with this name) must be defined correctly if you want to display logs. The easiest option is to select by specifying a suitable time interval. The two user fields may then
remain blank. The time stamp is automatically set to the last ten minutes. Choose "Display" to display a log.
The log is optimized for a screen width of at least 927 pixels. If the window is narrower, you must scroll horizontally.
Do not forget to switch off logging after the test for the user. Unnecessary logging may impair performance and waste memory space.

Fast creation
Call transaction RSUDO, set the "With Log" indicator next to the user field and choose "Start Transaction". (Leave the transaction selector on "RSRT".) Execute the query in transaction RSRT. Then,
choose "Back" (F3) two times to go back to transaction RSUDO. Choose "Display Log". You are immediately transferred to the log.

Usage in a message
If you assume that there is a program error in the authorization code, you require a simplified example in your system so that a remote analysis can be executed. However, the processing time of a
customer message can significantly be reduced if this remote analysis is superfluous because a good authorization log is available. Use your simplified example to create a log and attach this log to the
message.
You can easily save the log locally as an HTML file by choosing "Save Document" in the display.
Note the following:
1. Log on to the system (only for log output) in English so that all employees of SAP Support can read the log.
2. Set the relevant switch to display the relevant parts of the log before saving. If required , create a short version and a long version of the same log.
3. In specific cases, several logs can be written. Search for the suitable log.

Simplifying the log

The RSECADMIN log may be very long and not very clear. Use every available method to simplify the log.
1. Variables filled from authorizations:
Remove authorization variables if possible. Use a query copy with fixed filters and the values that you expect for the variables (in this text). This simplifies authorization problems.
2. F4 Input help:
If possible, avoid using the F4 input help (not only for authorization-relevant characteristics) when you execute the query. This is to shorten the log.
3. Navigation (IMPORTANT)
Navigating steps in the query (for example, filtering or adding a characteristic for the drilldown) often cause the system to run the main part of the authorization check several times. As a result, the
authorization log is more difficult to understand. It is therefore very important that only one single action is logged each time.
In many cases, the problem cannot be reproduced using the initial query execution. If such a situation occurs, the function BOOKMARK in transaction RSRT is helpful in most cases. Note 788393
provides further information. Executing a bookmark that was previously saved results in the shortest-possible log.

Content of the RSECADMIN log

The log is displayed in HTML format. In the upmost part, various blocks can be switched on and off. However, you must choose the function for updating the display if changes are made to the switches.
Only then is the HTML page rebuilt. Caution: If the log is very long, it may take a while until the HTML page is built up.
The individual blocks are explained in the following. However, many texts are self-explanatory. These are not mentioned here.

1 of 3

11/2/2014 1:03 AM

The authorization Log in RSECADMIN - SAP NetWeaver Business Wa...

http://wiki.scn.sap.com/wiki/display/BI/The+authorization+Log+in+...

Header
Basic data of the execution is displayed:
Date and time of log creation; name of the executed query; which transaction was executed. In addition, the relevant user names are specified: Logon user and authorization-relevant user.

InfoProvider check
Authorizations are filtered at a very early stage for the validity of the relevant InfoProvider. This is displayed here.

Main part: Header: "Authorization check"

(in italics and highlighted in orange) First, you have to enhance the selections. Most of the texts are self-explanatory.
Subselection (technically SUBNR) 1 (highlighted in light orange)
Depending on the query structure, the full selection of the query is first split up into smaller parts (SUB numbers, SUBNR). As a rule, the SUB number corresponds with a structure element in the query. A
structure element is often a column in the query.
The SUB numbers are then checked separately and independent of each other. Some SUB numbers may be authorized whereas some may not be authorized.
For the simplification, a test query should therefore contain only one structure element if possible.
Note 1140831 explains the check for the colon authorization. The log contains the relevant link.
"In the following section, the remaining characteristics are checked in detail."
(Note 1233793 explains this part of the log in detail.) The line introduces the detail check for the selected characteristics. The table has a blue header line that begins on the top left with:
"Following Set Is Checked".
The first field "Following Set Is Checked", at the top left of the blue table is usually the most important: Here, you have the unchanged selected set as it is requested by the query. If you think there may be
an incorrect function in the authorization check, you should always check first whether this set is what you expect: Or is more data queried than should be the case?
An iterative check is then executed:
The selected set is first compared with the first authorization. If this authorization set covers the selected set, the check is completed successfully.
If a subselection (SUB number) is authorized, this is highlighted in green
If the authorization set does not cover the selected set completely, the remaining set that is not yet authorized is determined and displayed. The same check process begins with this remaining set
(remaining selection). However, now the second authorization is used. The following applies: If the second authorization set covers the remaining set, the check is completed successfully. Otherwise the
iteration process is repeated until the whole selected set is covered by the authorizations. Then the check is successful.
Or, all authorizations of the user have been processed, and there is still a remaining set. This remaining set is then not authorized: The check for this SUB number returns "No authorization".
Important:
You can see that the log may display an unsuccessful partial check in the first iteration steps while the check as a whole is successful. The result after the last step is the relevant one.
However, if a subselection is not authorized, the system displays the following lines:
"All Authorizations Tested"
"Message EYE 007: You do not have sufficient authorization" (in yellow).
"No Sufficient Authorization for This Subselection (SUBNR)" (in yellow).
Note that each selected characteristic may be authorized independently. However, it is always the combination of all selected characteristics that is relevant.
If a subselection is checked, the check is carried out for the next one, again with the heading:
Subselection (technical SUBNR) n (Highlighted in light orange)
The processing of all subselections is completed with the entry:
"Authorization Check Complete" (In italics and highlighted in orange)

Buffering the authorization data

This supplement must be switched on using the switch with the same name on top of the log display. The raw data of the authorization, its combinations and processing is displayed. (For more
information, see Note 1000004.) Caution: The output of this unfiltered raw data may result in a very long log. The block starts with the heading "Buffering the Authorization Data" and ends with "Buffering
the Authorization Data Completed". Both texts are displayed in italics and highlighted in orange.
"Buffering for InfoProvider <abc> and user <xyz>"
Here, you first specify for which environment the valid authorizations are determined. In most cases, there are two large blocks: one block for the relevant InfoProvider and one block for data that is
independent of an InfoProvider. The InfoProvider-independent block is important for the check of a query selection. The InfoProvider-independent authorization data is relevant for display attributes and
when a check cannot be assigned exactly to one provider.
Subsequently, status lines are issued. These are for the most part self-explanatory.
Important: A check for the global authorization 0BI_ALL is executed. If this authorization is found, the following line is displayed further down:
"There Are No Characteristics That Have to Be Checked".
If the global authorization 0BI_ALL is not found, this does not constitute an error. It only means that the (normal) detail check of the selection must be executed.
After the line "The Following Value Authorizations Were Found", there is a tabular list of all authorizations for single values and intervals of the user. The so called flat authorizations: The entries are sorted
by authorizations (TCTAUTH) and characteristics (TCTIOBJNM). The fields TCTLOW and TCTHIGH specify the lower and upper interval limit.
Under the heading "The Following Hierarchy Authorizations Were Found", there is a list of the hierarchy authorizations of the user.
The fields TCTAUTH and TCTIOBJNM again specify the authorization and characteristic names. The fields HIESID and HIEID have no significance in this context. The fields TCTHIENM und
TCTHIEVERS and TCTHIEDATE are three specifications that generally and precisely define each hierarchy of a characteristic in a BI system: Hierarchy name, version and date (valid-to).
The fields TCTNIOBJNM and TCTNODE precisely define the authorized node. TCTNODE is simply the technical node name.
TCTNIOBJNM specifies the node type.
1.

a. if TCTNIOBJNM = 0HIER_NODE, then a text node with the name <TCTNODE> is authorized.
b. If TCTNIOBJNM is blank, a hierarchy leaf with the given name is authorized.
c. If TCTNIOBJNM has the same name as the hierarchy-defining characteristic, a chargeable node is authorized.

CAUTION The node type is relevant for the authorization. For example: A hierarchy authorization for a text node cannot directly authorize a chargeable node with the same name.
Most of the following lines are self-explanatory.
The next block is: "Optimization of Authorizations:" (in italics and highlighted in light orange)
Here, the formatting of the authorizations is logged. This is difficult from a logical point of view and therefore explained in detail in Note 1000004.

Related Content

2 of 3

11/2/2014 1:03 AM