Analysis Authorization Migration Question

Question

Analysis Authorization Migration Question
This is detail Question
1)     I am testing Analysis Authorization Migration in NW2004s SP9 and have applied all OSS notes that are relevant to SP09 and are coming in SP10.
2)     We have 2 Info object flagged as Authorization relevant 0COMP_CODE and 0COSTCENTER
3)     We have Object level security set-up in BW 3.x system and for a role we have specified values like 0COMP_CODE has value 1000, 1800. “:”. In the same role we have specified 0COSTCENTER value 130001 to 180001, “:”  and hierarchy node.
4)     When we migrate to Analysis Authorizations, using RSEC_MIGRATION, this program creates 2 Authorizations ZCOCODE00 & ZCOSTCTRH00. Both of them have 0COMP_CODE and 0COST_CENTER Objects.
5)     ZCOCODE00 authorization gets value 0COMP_CODE values 1000, 1800. “:” and 0COSTCENTER Value “:”.
6)     On the same line ZCOSTCTRH00 gets value 130001 to 180001, “:”  and 0COMP_CODE “:”.
1st Question:
1)     Why does it create 2 Authorizations?
2)     During Checking it does not pass the authorizations, because it seems to me that it fails in Optimization process.
3)     I manually merge the authorizations in “ONE” object then authorization check passes.  In other word if I combine ZCOSTCTRH00 & ZCOCODE00 then Query authorization check passes.
Any one is struggling on this.
Please note, I am doing Migration so that it updates existing Profiles (Roles now from SP9).
Any comments will be very help full.
Pankaj Gupta

Answer 1

Hello Pankaj
There are some basic misunderstandings on your side.
Let me try to clarify:
First we should distinguish between migration of authorizations and of what a query does with them.
You had 2 auth objects before migration (in 3.x).
Of course, they must be migrated to 2 new analysis auths.
There is no general possibility to combine authorizations to a single one as the may appear in different roles and users. Moreover this would kill performance and finally, nobody would recognize the origin.
Only in very restricted cases one could think of a combination of auths which come out of migration. But, then people loose overview about what goes on.
Before the corrections in note "Migration IV" the : had not been inserted but now it is for good reasons.
Now, accept for the moment that you receive 2 auths.
Then, you cannnot (must not) combine the 2 resulting authorizations!
<b>Authorization 1</b>
COMP_CODE : 1000, 1300, “:”
Cost Center : “:”
<b>Authorizations 2</b>
Comp_Code “:”
Cost Center : 3100001-31999999; “:” plus a Hierarchy Node.
This means that e.g. combination
COMP_CODE 1000
COST_CENTER 3100001-31999999
<u>is not allowed!!!</u> Therefore, they must not be combined!
Also, the query and its optimization is comepletely independent of the migration. And here, during query run time the auths cannot be combined. It is no failure!
Moreover, the merging optimization is just a performance optimizaiton and has nothing to do with whether the query result is authorized or not.
If you combine them manually you have authorized different combinations.
Well, now you may wonder why you get 2 auths at all which leads to a "no auth" result in the query execution.
The reason is, that in 3.x where you got a result with your 2 auth objects the modeling was wrong.
If you want to authorize any combination of characteristic values, you should combine these characteritics together in one auth object, not in 2!
(In BI7.0 it works like that but not in 3.x)
But you defined 2 which may be valid even in several other InfoProviders independently and not even at the same time. Moreover, the auth objects may come from different roles and may be assigend to different users which then have completely different auth content. In general it is not possible to combine different auth objects or to find out those special situations which nevertheless allow for such optimizations. If you re-do a migration with more objects and users you could even receive different results which is also not satisfying.
Therefore, instead, the mechanism was introduced to insert a : auth to those characteristics that are auth relevant (and checked now with 7.0) but not in the currently processed auth object.
In you special case it may have made sense to combine them but not in general. And a migration can only try to work as general as possible.
For your application you may combine the 2 auths manually if you want to allow also the crossover combinations
COMP_CODE 1000
COST_CENTER 3100001-31999999
Best regards
Peter John
BI Development