The standard SAP authorization trace given by ST01 is not enough for troubleshooting security issues in BW reporting. A ST01 trace will show a basic reference for the two objects S_RS_COMP and S_RS_COMP1 to check access to the query and cube but nothing further than that. SAP provides a completely new authorization trace though the RSECADMIN transaction to troubleshoot analysis authorizations. The error log button gets us to the authorization trace screen.
Once we have “configured log recording” for the affected user, the system logs all OLAP data accesses made by the user.
Displaying the log data gets us into the following screen which shows the details of the security checks for the user.
The trace first displays the name of the InfoProvider and the query name that the user executed. Next, we have a list of characteristics in the cube for which user has non full (*) access as these need to be checked at a more detail level. Lastly we have the authorization checks for these characteristics with non full authorizations. Its this section of the trace thats typically the most helpful in troubleshooting authorization issues.
Though creating a report in SAP BW is typically much easier than creating one in ABAP, most reporting users are involved in actually running reports and interpreting the results rather than designing them. As a result the task of designing reports is often left to a select group of power users who are well versed in the knowledge of creating queries and formatting their outputs into suitable form for the use of other users. The output of one or more queries formatted in excel, which might include charts or higlight different data rows or columns, to facilitate their use for enterprise level reporting are called “workbooks”.
Once constructed, these workbooks, or even direct queries, need to be rolled out to the end users. Since the queries and workbooks are defined on InfoProviders, exploring the InfoProviders in BEX Analyzer would show all the reports defined on them. BW also provides a way of saving queries or workbooks into select folders by the power users as shown below.
Technically the folders are implemented as SAP roles without any authorization data. The folder roles are just placeholders to store queries/workbooks. Once the folder roles are assigned to the end users, they can just look into the folders roles assigned to them rather than having to search for the individual reports under the InfoProviders. This is beneficial as typically a InfoProvider will have a huge number of reports defined on them, many of which might not be applicable for all end users. Also, saving the important reports in roles saves the user from having to remember the InfoProvider on which a report is defined. In fact, we can take this scenario a step further by actually hiding the InfoProvider button from the open query/workbook dialog so that an end user can only access the reports which are specially designed for them. Hiding of the InfoProvider button is accomplished through the use of the S_RS_FOLD authorization object. Adding the object with a value of “X” to a user master ensures that the InfoProvider button is hidden from view in the open query dialog.
To save a query or workbook two authorization objects are needed to be present with the user – S_USER_AGR and S_USER_TCD. S_USER_AGR should have change access to the roles where the reports are going to be saved. S_USER_TCD needs the value RRMX.
Since the folder roles are modified by power users rather than the security administrators, a different transport strategy should be followed for them. In case, power users design reports directly in the productive environment, folder roles should only be transported to production once during the time of their creation. Any subsequent transport will wipe out all the new reports added to them. In the second case, a report is deigned in the development environment, tested and then moved to Production. In such a case, folder roles need to transported similar to any other authorization role.