Saving Workbooks in Roles

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.

BEX - Save Workbook In Role
BEX - Save Workbook In Role

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.

7 thoughts on “Saving Workbooks in Roles

  • July 14, 2011 at 6:01 pm
    Permalink

    Hello Aninda,

    Great site, thanks for putting this all together!

    I was wondering if you would know if there is a way to disable the “publish” functionality within the BEx Query Designer in BW 7.01? It appears that although a “reporting” user who has no authorization to save queries (only has S_RS_COMP ACTVT 03,16,22) can still open the Query Designer through the Analyzer and still publish a query to what ever role they have listed in S_USER_AGR. I am using S_USER_AGR because the reporting users should still be able to create workbooks and save them to the menu roles.

    thank you,
    Lindsay

    Reply
    • July 15, 2011 at 4:09 am
      Permalink

      Hi Lindsay,

      Thanks! Unfortunately, SAP security doesn’t distinguish between saving queries and saving workbooks to role. And publishing to roles is just another way of saving to roles. I don’t think there is any way to restrict publishing queries without affecting the ability to save workbooks to roles. You might try to put in some security in S_USER_AGR so that users can only save to certain roles.

      Also this is just a thought, since I don’t have access to a live BW system now. Try removing activity 22 from S_RS_COMP. This should stop you from assigning queries to roles but not sure if it will impact workbooks as well. Best of luck! Please tell us what you end up doing.

      Regards,
      Aninda

      Reply
  • December 23, 2011 at 4:51 am
    Permalink

    Hi Aninda,

    Could you please explain what is a query view and is it possible that a query view created by one user be ustilized or executed by other user.I have a authorization issue with one user created a query view and other is trying to execute the query view.

    Reply
    • January 1, 2012 at 2:36 pm
      Permalink

      Hi Bhargava,

      Till your comment, I had not come across query views and the security requirements for them. So thanks for posting your question. But unfortunately, I am not familiar with all the features. I will post an update if I find anything new.

      Regards,
      Aninda

      Reply
  • November 6, 2012 at 9:27 am
    Permalink

    Hi All,

    I have a issue with a request to restrict users to only be able to create/save views with a name that starts with X.

    I have put display(03) and execute(16) for all the other view that the roles should allows users to view on S_RS_COMP. and added an additional object S_RS_COMP with full access and put a X* in the reporting component ID. The user can still save views with any name of their choice.

    IS it possible to restrict authorizations on views?

    Reply
    • November 25, 2012 at 11:52 pm
      Permalink

      Hi Mamaj,

      I have never restricted on views so cann’t give you a correct answer. Why don’t you look around a bit and see what you find.

      Thanks,
      Aninda

      Reply
  • May 23, 2014 at 12:37 am
    Permalink

    Hi,

    Thanks for the info.
    It woule be great in case you could some stuff on Hierachial Authoizations in SAP BIW.

    Best Regards,
    Tanu

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *