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.
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.