Virtual Analysis Authorizations – Part 1: Introduction
In SAP NetWeaver BW release 7.3 a new Analysis Authorizations BAdI was introduced: BAdI RSEC_VIRTUAL_AUTH_BADI as part of Enhancement Spot RSEC_VIRTUAL_AUTH. The authorized values or hierarchy nodes can be determined dynamically during query runtime. It does not require any Analysis Authorization objects and PFCG Roles. Virtual Authorizations can be used to enhance any existing “classic” authorization model. I.e. you do not have to make an exclusive choice for one or the other, both classic and virtual can be used simultaneously and complementary.
I would like to share my implementation experience with virtual Profit Center and Cost Center authorizations. This introductory blog will discuss the rationale, a comparison between classic and virtual authorizations, and the different call scenarios for which the BAdI is processed. For the solution details please read my blog Virtual Analysis Authorizations – Part 2: Solution Details. All implementation details you can find in my document Implementing Virtual Analysis Authorizations.
Rationale
The main problem with a classic authorization concept is that it is less flexible in situations with a big user population, many authorization objects/roles and frequent changes. E.g. organizational changes impacting large parts of the organization and ongoing roll-outs with big increments in the user population.
Classic use cases for a more flexible and dynamic approach are Profit Center and Cost Center authorizations. Often we have to deal with hierarchy authorizations as well as value authorizations. There might exist multiple hierarchies which have to be authorized on many hierarchy nodes. The number of required authorization objects and roles is likely to become high.
As a consequence, you can expect TCD (Total Cost of Development) as well as TCO (Total Cost of Ownership) becoming too high.
Classic versus Virtual Authorizations
Before diving into the Virtual Authorizations, Iet’s try to compare the classic model with the virtual model.
Figure 1: Evaluation Matrix
The biggest draw-back of the classic model pops up in the efficiency with a big user population in combination with many authorization objects and roles. Here the virtual model shows its added value.
On the other hand, the virtual model is less transparent and clear compared to the classic model. Also in the area of compliance we do not have the out-of-the-box functionality compared to the classic model.
Different Call Scenarios
During query run-time the BAdI is called multiple times. This might be a bit confusing in the beginning when you start working with the BAdI. There are 3 call scenarios:
- Call scenario 1: InfoProvider-independent or cross-InfoProvider authorizations;
- Call scenario 2: InfoProvider specific authorizations ;
- Call scenario 3: Documents protected with authorizations.
Call scenario 1: InfoProvider-independent or cross-InfoProvider authorizations
Scenario 1 can be called multiple times. Importing Parameter I_IOBJNM is not initial and Importing Parameter I_INFOPROV is initial. Importing Parameter I_T_ATR might be filled with authorization-relevant Attributes of the respective Characteristic, if any.
In this call scenario the following authorization is processed:
- Authorization-relevant InfoObjects; e.g. I_IOBJNM = ‘0PROFIT_CTR’;
- Authorization-relevant Attributes; e.g. I_IOBJNM = ‘0WBS_ELEMT’ and I_T_ATR with ATTRINM = ‘0PROFIT_CTR’ *);
- Authorization-relevant Navigational Attributes; e.g. I_IOBJNM = ‘0WBS_ELEMT__0PROFIT_CTR’.
*) Display Attributes need full authorization; see also SAP Note 1951019 – Navigation Attribute and Display Attribute for BW Analysis Authorization.
Call scenario 2: InfoProvider-specific authorizations
Scenario 2 will be called once only. Importing Parameter I_IOBJNM is initial and Importing Parameter I_INFOPROV is not initial. You can determine the authorization-relevant InfoObjects using Function Module RSEC_GET_AUTHREL_INFOOBJECTS.
In this call scenario the following authorization is processed:
- Authorization-relevant InfoObjects; e.g. I_IOBJNM = ‘0PROFIT_CTR’;
- Authorization-relevant Navigational Attributes; e.g. I_IOBJNM = ‘0WBS_ELEMT__0PROFIT_CTR’.
Call scenario 3: Documents protected with authorizations
I did not experiment with scenario 3 yet. It can be called in the context of documents which are protected with authorizations. In this case, both Importing Parameter I_IOBJNM and Importing Parameter I_INFOPROV are initial.
Conclusion
In this introductory blog we discussed the rationale of virtual authorizations, a comparison between classic and virtual authorizations, and the different call scenarios for which the BAdI is processed. In my blog Virtual Analysis Authorizations – Part 2: Solution Details we will discuss the solution details. All implementation details you can find in my document Implementing Virtual Analysis Authorizations.
Hi Sander and thanks for sharing.
I have some difficulties to understand the benefits of virtual authorizations compared to classic ones combined with exit variables (authorized values are determined at runtime through an exit variable). The last seems to me easier to implement and offers the same advantages (?).
Am I missing something ?
Hi Frederic,
You are right: a classic Analysis Authorization object in combination with a Customer-exit OLAP Variable (processed at i_step = 0) is for sure an alternative for a more dynamic approach. However, I would like to draw your attention to a couple of disadvantages in the area of hierarchies:
As a consequence, you will have to find an approach if you have to authorize on multiple hierarchies. It will become even more complicated if you have to use different hierarchy properties.
This can be handled in a much more easy and transparent way with the virtual model as presented by me. And it can even be enhanced with the so-called Default Hierarchy functionality which I explained in my blog Virtual Analysis Authorizations - Part 2: Solution Details.
It will be dependent on your situation what to choose. In my opinion Virtual Analysis Authorizations is brand-new technology which complements and enhances the Analysis Authorization concept in a perfect way. It's a very powerful tool and as far as I am concerned, it deserves a chance to be discovered and explored !!
Best regards,
Sander
OK, thxs. I didn't catch this.
Hi Sander,
We tried implementing virtual authorization in our environment (following your detailed steps), as we have a requirement to provide different set of profit center authorization on different reports to same user.
However there seem to be no effect eventhough we passed the required hierarchy and variable values in the parameters c_t_val and c_t_hie. Any idea what could be the reason?
We currently have not provided any 0BI_ALL role to the user that we are testing with.
Best Regards
Pradeep
Hi Pradeep,
Although I don't know all details re. your specific implementation, let me try to give you some general advice.
1. In your BEx Query design, please always include Authorization Variables (type "processed by authorization") for any authorization-relevant Characteristics of the InfoProvider. The variable can be both "input ready" (the authorized values will be present as default values) or not (an implicit selection of all authorized values). You have to include such a variable in the Characteristics' Restrictions part (i.e. the global filter) of the BEx Query.
2. Please do not forget to include "aggregation" (colon) authorization for every authorization-relevant InfoObject.
3. If you are still facing authorization issues (i.e. the message "no authorization" at query run-time), please run the respective BEx Query using the RSECADMIN trace tool and analyze the authorization log carefully. Please also pay attention to other authorization-relevant InfoObjects.
4. You should not grant the 0BI_ALL object since it gives full authorization for every authorization-relevant InfoObject and consequently overrules any other authorization.
5. As a work-around try to simplify the authorization by creating a conventional AA object, extend it with all required authorizations as indicated by the authorization log as described under 3 and continue until the "no authorization" will disappear. This might give you the necessary insight in the required authorization. As a next step replace the conventional authorization by the virtual authorization. Do not immediately start with the highest complexity.
Best regards,
Sander
Hi Sander,
Thank you for the response.. Steps 1, 2, 4 & 5 have all been completed before we set out to try virtual authorizations based on your document. Let me try and explain my scenario in a bit more detail.
I'm trying to provide two financial reports to the end users (an Income statement and a product performance report). Both of these reports have profit center as a filter. On the income statement we would need to show details on all profit centers for a few users, but on the performance report we would like to restrict the details displayed to the same end user to a few profit centers (the products that he is responsible for).
This, we understand, can only be achieved using the technique you have specified. The end user who we are testing this scenario with currently does not have 0BI_ALL and has a custom object which has a few profit centers which is required in the product performance report. We are trying to dynamically populate the hierarchies and values (depending on the infoprovider being used) on the enhancement specified. The issue we are facing is that despite values and hierarchies passed on the output parameters C_T_VAL & C_T_HIE, the output still shows the entire hierarchy of profit centers that we have set up.
In short, we are not able to influence the output using the enhancement spot. The values for profit center are still based out of the authorization objects (aggregated if multiple objects are assigned to the same end user) maintained in RSECADMIN.
What could we be missing.. Hope this helps..
Regards
Pradeep