Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

BW Query Security

Former Member
0 Kudos

Hi,

I am looking for the best approach. I have already searched in SDN forums but did not find any useful information.

We have different groups of BW power users who would like to share (edit/execute) queries within their own groups. My approach was to create a role for each group with a unique query naming convention. This leads to 10 new roles for 10 such groups. Is there an exit variable or any other approach that can tapped in to minimize the number of roles?

3 REPLIES 3

Former Member
0 Kudos

If an user can only used those queries from the group that belongs, your approach is the best choice. Remember that you can set up BW security via:

a)Securing by InfoCube: One option for securing reporting users is to divide users into groups. This would work, for example, if the authorizations need to be checked only on InfoCube level. You can then create roles that allow you to run queries from the specified InfoCubes.

b)Securing by Query: Another option would be to use the InfoCube in conjunction with the query name. To do this, you will need a strict naming convention for query names so that security does not have to be updated each time query is created.

c)Securing by InfoObject: If you want two users to execute the same query, but to get different results based on their assigned division, cost center, or some other InfoObject, then you must secure down to the InfoObject level. This option is the closest parallel to the field-level security that is normally done in traditional SAP R/3.

Regards, Leandro

0 Kudos

Thanks Leandro, very much appreciate your comments.

But one issue I am seeing in my approach is: Since all the group roles will be exactly the same except for query naming convention, if a new infoArea or infoCube needs to be added then it should be maintained in each role. Could be a possible burden on the role maintenance side. I should probably work with the BW team to see a logical grouping of the Infocubes into an Infoarea so that we can avoid adding each infocube in the role.

0 Kudos

You must check the authorization objects S_RS_COMP and S_RS_ICUBE in order to update the access to InfoAreas and InfoCubes.

For an independent group of users you must maintain their own security roles in a separate way.

See ya,

Lean