Derived Roles in BI

[Former Member]

I have created dervied roles in BI.

Idea is to Update the Parent role with Menu and derive to child roles.

I am having 0BI_ALL on Parent Role and which is inheriting to the child up on the making the menu changes and updating the parent role.

In every child role, i have added with needful AA(Analaysis Authorizations) i.e replacing 0bi_all.

I dont want 0bi_all to come into child role upon generation of parent role. Plz let me know,how this can be achieved.

I appreciate your advices and thoughts.

[Former Member]

If you haven't done already you need to turn field BIAUTH into an org level.

Do a search on PFCG_ORGFIELD_CREATE for more info on how to do this.

[Former Member]

Thanks much for speedy response.

We already have built the roles.

I suppose following steps should be okay .

1. update the biauth as org field thru program - PFCG_ORGFIELD_CREATE

2. Updated the Roles to be generated and transport them.

3.Before transporting them to Q and P, I will make sure changes BIAUTH been made org filed in all the systems.

Please put your thoughts here, if you have any.

Edited by: AdminQ on Nov 12, 2009 8:34 PM

[Former Member]

That is the process that I would follow.

When changing the org level in Prod, I would recommend doing it when things are quiet and you have the transport ready to import.

[Former Member]

Conversion of standard authorization objectu2019 field into an org filed is not recommended. You have do lot of security analysis and implications before you go for this option. In general this option is recommended for custom transactions and its authorization objects.

Sometimes manual operations are mandatory to have a uniform security controls. Of course, you can use CATT or ECATT for any mass changes.

[Former Member]

Rpoojari,

Can you please explain why you don't think creation of an organisational level is a good thing? What exactly is the risk?

If you are following the derived role principle and your design supports it then it is a very effective tool which which save time and simplifies things.

[Former Member]

Alex

i fully agree with you.

[Former Member]

Though Rpoojari did also say:

> You have do lot of security analysis and implications before you go for this option.

...which I would agree with.

Creating Org Levels for just about any old field you don't want to maintain more than once is not recommended in my books either.

Cheers,

Julius

[Former Member]

What would be the exact impact. Please explain further., so that i can take needful steps.

[Former Member]

If you think about it in the context of the authorisation concept then you need to identify that you want the value to be maintained in all of those fields in a role.

In your case, all BI7 implementations I have seen or worked on have had that field made into an org level. Without doing this, you will not be able to maintain your current role concept. You would need to disassociate all your derived roles from the master roles.

[Former Member]

What I meant is that you will meet the limit for the authorization field, and if it is an org. level then PFCG will not generate a 2nd or more authorizations within the same role. You will be forced to create a new role, or try a copy and then never touch it again tactic (the org. levels).

But at the time of posting my above comment, I did miss the fact that this was a derived role for BI analysis authorizations .

I will take a closer look into that. Sounds usefull.

For performance reasons, have you ever tried to re-generate the profiles and authorizations in production? Someone was asking me about this a while back, due to a proliferation of org. fields they had created. It sounded possible, if the roles were built squeaky clean and the parent very well maintained with lots of discipline.

I tested it on some small roles and it works okay, but I am sure there are "gotchas" in it somewhere...

Cheers,

Julius

[Former Member]

Hi Julius,

I find it very useful in the BI context. Especially if you look at the auth object and how you can use it.

Often the analysis auth roles are separated (if following the split concept between report roles and data roles) and having the field as an org level can speed thing up. Obviously if you are using derived roles, it can make it even easier if that is the way the design works.

Now you come to mention it, I did work at one place where we could regen in production for a good number of roles. Of course, the check indicator config was virtually immaculate....

On another client we had a problem with the admins regularly changing roles in prod and they would not change. We stopped them by accident. We created an org level but didn't transport the org level. This was in 4.5 days so you could still transport the role (open in prod and role looks bad but profile is OK). If they tried to regen the roles in prod then it would knacker the roles so they stopped. I would imagine that they have it fixed now and their roles completely out of sync...

[Former Member]

I am currently working on a project with 190 BUKRS (and 3825 KOSTL...)...

Well thought out naming conventions and Excel macros for replication of templates is the only way I can see -> at least in the ECC system (phase 1) and any re-use of the ECC access within the BW analysis authorizations (phase 2)... which is also cool and makes life even easier.

Composite roles have been ruled out completely as they don't need much access (it is all web apps), but they have to be kept apart.

I guess it depends on the requirement, and expected proliferation of the org values and how well prepared the system and role design is for this.

Cheers,

Julius

[Former Member]

>

 (and 3825 KOSTL...)... 

You have my sympathy!

[Former Member]

>

> Well thought out naming conventions...
> 

I hope to be able to bring it down below the single role limit... and then re-use the ERP authorization data on the BI side.

312: It's my lucky number!

Cheers,

Julius