Skip to Content
author's profile photo Former Member
Former Member

Publishing Queries to Roles

Hello Gurus,

I would like your take on the practice of publishing BW queries to roles? For an example there are 10 sets of queries and these 10 are published into a role for each company that exists. So in essence if there were 20 company codes we will have 20 roles containing 10 queries hardcoded with a company code. I spoke to our BW developer to get an idea as to why this is being done instead of restricting access through S_RS_COMP. Response was that this was done due to performance reasons (something to do with the queries linking directly to the infoprovider containing the information rather than going through all of the infoproviders). So, Rather than leaving the query open and the user entering the parameter themselves it was decided that the queries were to be hardcoded to cut down the time it takes for systems to display the results.

Anyone experience this issue before? My goal is to setup a derived role where the child roles are restricted by S_RS_AUTH for the company codes and query access through S_RS_COMP instead of being published to a single role. Before I do this I would like to figure out a way to move away from this practice without affect performance for end users.

By the way our users access these queries through the Bex Analyzer.

Thanks,

Wes

Add a comment
10|10000 characters needed characters exceeded

Related questions

3 Answers

  • Posted on Dec 05, 2011 at 11:40 PM

    Wes,

    Using derived roles in BW or S_RS_AUTH may not be the best design as field for S_RS_AUTH does not appear as org level. So you are not really going to have any advantage by going with derived role concept in terms of maintainence effort.

    With 10 queries - 20 Company Codes - you will not need 20 roles because of Company Code, just update the queries with appropriate authorization variable for company code and restrict users on company code. Just 20 company codes should not cause any performance issues

    Also with hardcoding the queries for each single company code - how are you resolving the scenario when user has access to more than one company code/ or global access.

    Regards

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Dec 07, 2011 at 03:44 PM

    Hello

    If your queries are based on a multiprovider, and each company is a different infoprovider, then yes we have better performance when we filter the by the infoprovider.

    But this filter can happen based on the authorizations.

    I assume that having an authorization check you will add one more step in the query execution, but you will have to manage only 10 queries, and the seconds that you will loose by the authorization check are minor to the whole query executable process.

    For sure best practise are the authorizations.

    Edited by: Yiannis Kasolis on Dec 7, 2011 4:46 PM

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Dec 08, 2011 at 04:58 AM

    The best thing you can do is to use roles and authorization features offered by SAP BW. Instead of creating 20 different queries for 20 different companies where you can hardcode it. This is very stupid thing to do. Instead you can create one single query for 20 companies and use 0COMP_CODE infoobject as the authorization variable in query itself.

    Using RSECADMIN you can create 20 authorization object and in each role include this company code and define the required value (company code).

    After this create 20 roles and use corresponding authorization object in each of them. Then using PFCG you can assign this single query to 20 different role and each and assign this role to individual company code users. It will solve your problems.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.