Skip to Content
avatar image
Former Member

Role design BI ehp1


we are planning bi secuirty - we are designing BI security for sales organization like billing,booking, sales out etc . we have proposed our design like -when user request ticket -he will provide to security team with end/power/super etc and Region, and Billing, Booking, sales out etc

once we get user request we are going to give one standard role with bisic tcodes(su53,sp02 etc), second end user/power/super role (Restricting infoareas, infocubes), Third billing/booking role (in this we give s_rs_auth analyis role )

and for hierarchy user maintained in the table . whenever user adds in se16 table he will get access to corresponding region (one of developer saying we

can maintain like this . still i have no idea how it works. if any body have worked like this please let me know.

Please suggest this kind of role maintanence is good or any other suggestions for overall design maintenance

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • avatar image
    Former Member
    Jun 26, 2010 at 03:34 AM


    What your friend has said is true. You ca nrestrict access thru table level. Your hierarchy design is like that.

    If you want to follow different method, then you will end up with more roles .

    Plus point : Especially in production go for custom tcode zse16,which gives the user particular table access only.

    How it works ?

    Just like a giving table access, for eg, ABAP wants to access to mara table.

    You will give access to se16,you restrict on auth group.

    i.e Se16


    Auth group : mention the auth group for mara table.

    You can check the mapping in table TDDAT.

    PS: We had similar problem,i.e we need to restrict users based on cost centers.

    For one user,one cost center. Just imagine if you have more users,how many roles u will end up...



    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member


      First you find out from your ABAers how many region you need to restrict. If it is less than 30 regions,then go with

      role base design concept.

      If regions are more,ABABer will create a table in that table once colum will be for users / second colum will be nodes and third colum will be users.

      So when user executes the query, based on run time variable .

      eg1: LEt say that user1 has access to region1, then at run time he gets a popup screen to enter he see tha data for region1

      Eg2: Let say user 2 ,should have access to region 1 to region 50 ? (consolidated data)

      if you follow eg1. then its tedious process for this user to enter 50 region one at a time.

      So best option is to maintain it in table. i.e In the table it self they will link which user has to access to which regions.

      So at run time you need out need to enter values for variable. See the word doc.

      PS: while creating a role for restricting query you have to include the variable, so that at run time the user will will get the correct region data.

      No need to give se16 access to the users.


  • Jun 26, 2010 at 06:15 AM


    Without knowing more about your setup I can't really comment on the design, though it is a very common concept used for BI and it won't cause any problems if you have a consistent approach to designing and implementing it.

    From what you are describing, it sounds like your developer may be using authorisation variables (a neat concept in BI) to provide authorisation based on some custom logic that they have developed. You should confirm with your developer that this is the case and to provide you their documentation on the solution as you will need to reflect the variable in your role build.

    Add comment
    10|10000 characters needed characters exceeded