Skip to Content

Business Planning and Consolidation version for Netweaver has some additional features that we can leverage while setting up security in BPC. In this blog we will discuss how security concept in BPC7NW is in some ways a little different than the traditional security concept in SAP and how we can use more ways to build secure BPC applications.

Basics of BPC security:

In BPC7NW, the security is defined within BPC. The Netweaver security is not invoked and the BPC user interacts with Netweaver through service user. Thus the security for BPC namespace infoobjects is governed from within BPC. (for more discussion on BPC namespace, please see  http://www.sdn.sap.com/irj/scn/weblogs;jsessionid=(J2EE3414700)ID1897954850DB00258195100095085303End?blog=/pub/wlg/11279)

There are four basic steps to set up security in BPC. These are:

  • Adding users
  • Assign users to teams
  • Assign task profiles to users or teams
  • Assign member access profiles to users and teams

Adding users and grouping users into teams in order to assign security to the group instead of each user may be intuitive enough for many traditional SAP users. Task profiles determine various tasks that you can perform within BPC. Depending on our business needs we can create new task profiles or just modify existing profiles.

Member access profiles is where we can define either read access or read/write access or no access to the dimension members in BPC for each application.

image 

.

We can define multiple member access profiles each with a different set of access authorizations and a BPC user can be assigned multiple member access profiles. This gives a lot of flexibility to define and manage access to the dimension members. However this also creates some challenges in resolving the conflicting access issues that we should be aware of. Let us consider these conflicts and also talk about ways to resolve them.

 

Potential conflicts while using multiple member access profiles:

Member Access profiles are fairly simple to understand and construct, but they may not be very trivial to resolve when there is conflicting information. If each user has a single member access profile then there is no conflict. A potential conflict may arise when a user is assigned two or more member access profiles and the access authorizations in those profiles are opposite to each other. For example, what if in one member access profile a user has “Write” access to a member, and in another profile the same user has “Deny” access to the same member. Does the user have Write or Deny access? The way this conflict is resolved within BPC security is by following two simple rules. These are:

  • WITHIN one member access profile, it is always possible to apply more specific security at a lower level in the hierarchy and the least privileged access wins
  • ACROSS multiple member access profiles, the one with the “greatest” access (or least restrictions) wins

While applying these rules, the system looks at one dimension at a time, cycling through all assigned member access profiles. By cycling through all dimension restrictions, the dimension value in the record being tested will effectively only be limited by the least restrictive rule. This serial ‘dimensional’ approach does not take into consideration any other dimension in the record or the member access profile. Thus, though we define the member access profiles for a set of dimensions, the default conflict resolution takes place by considering one dimension at a time.

Let us take an example to clarify this scenario.

Let us consider that a member access profile (say MAP1) is set up as follows:

Category =       Plan –               Read/Write

Time =             2009.OCT –     Read/write

Time =             [ALL] –            Read only

The idea here is that the user should be able to read the plan values for all time periods but write to only 2009. OCT month plan values.

Now consider that there is another member access profile (say MAP2) that is set up as follows:

Category =       Forecast –                    Read/Write

Time =             [ALL] –                        Read/Write

The idea here is that the user should be able to write forecast values to all periods.

Now, if these profiles are assigned to two different users there is no issue. However if they are assigned to the same user, then there is a conflict. Clearly, the administrator of the security intends to RESTRICT writing of values to Plan category for time other than 2009.OCT. However what happens is that if the user who has both these member access profiles assigned, enters a Plan value for say 2009.SEP, it gets saved according to the rule of least restrictions by dimension – in this case the time dimension. This is not what the administrator might have intended. Hence we have to be aware of this fact while defining the member access profiles and assigning multiple member access profiles to the same user. Member access profiles are very simple to administer and manage but if we want the ‘matrix’ type security, which traditional SAP users might be more familiar with, we have to use other tools in addition to the member access profiles to resolve such conflicts.

 

Alternatives to resolve such potential conflicts:

There are many ways to augment security provided by the member access profiles and achieve the ‘matrix’ security. These include the use of following approaches:

  • Member access profiles to provide the read authorization and partial write back control
  • Use BPC validations and leverage validation Badi to control the writing of records. More information about BPC validations is available at: http://www.sdn.sap.com/irj/scn/weblogs;jsessionid=(J2EE3414700)ID1897954850DB00258195100095085303End?blog=/pub/wlg/14726
  • Work status – Use work status in conjunction with the member access profiles. The combination of member access profiles and work status alone may serve the purpose in many situations
  • Excel based logic – Last but not the least, the Excel based validations and macros can be very handy in providing some basic validations for writing the records through input schedule.

 

With the all this ammunition at our disposal we can surely make any complex BPC configuration secured like a fortress.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Venkat K
    Hi Pravin,

    It’s a very good blog. Could you please help me by answering below questions?

    My business case (requirement) is:

    We have 40 different cost centers (Entity type dimension) and 40 different users. Each user is supposed to have access to ONLY ONE specific cost center. The “Task profile” will be the same for all the 40 users.

    I can only think of two options here:

    Option 1:
    Create 40 MAPs, 40 Teams and 40 Users. Assign 40 Teams to 40 MAPs on one-to-one basis and assign 40 Users to 40 Teams on one-to-one basis.

    Option 2:
    Create 40 MAPs, 40 Users. Assign 40 Users to 40 MAPs on one-to-one basis.

    Which option among the above do you suggest ? Or do you think of any other options ?

    Another big question I have is: Can I create a single team with all 40 MAPs, and assign all 40 users to that Team and still restrict (map) the users to the desired MAP ??

    Any thoughts will be helpful,

    (0) 
    1. Pravin Datar Post author
      Thanks Venkat. Both options are feasible. Obviously option 2 has less config work than option 1 but option 1 is better practice simply because it gives you more flexibility. If you create teams, you can add more users in the team in future and also move the users around within teams. Say  two users want to interchange cost center authorizations for whatever reasons, you don’t have to change MAP; just modify teams. Say if one user leaves or a new user joins in him/her place, you just add/delete the user in the teams if you are using option 1.
      To your other question, you can surely create a team and create MAPs by users. Obviously in that case, you are not using teams and essentially going with your option 2.
      Regards
      Pravin
      (0) 
  2. Vinod Swarnapuri
    Praveen, Very well written and simple to understand blog. The examples you have given made it easier to understand.

    Also, Very good list of the alternate solution to resolve the security conflicts.

    Thank you!
    Vinod Swarnapuri

    (0) 

Leave a Reply