cancel
Showing results for 
Search instead for 
Did you mean: 

GRAC BRM: Mass Role Derivation - Org Values within derived Role empty

Former Member
0 Kudos

Hi everyone,

Setting up the BRM, Mass Role Derivation i came accross the following problem.

The generated derived role contains no org-level values, which have been defined as follows:

The values are defined here:

Thanks for you support in advance.

Regards

Pourang

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Colleen,

the problem was caused for master roles which were imported to GRC.

Roles defined in GRC don't have this problem.

Thanks again.

P

Colleen
Advisor
Advisor
0 Kudos

ahh okay - good to know. Is this because the imported roles didn't have org maps?

Former Member
0 Kudos

Not really.

Am not sure, if you can map the imported roles to existing org maps.

If there is way I'd be gald to know

Pourang

Former Member
0 Kudos

Hi Pourang,

there is no standard way in BRM to do the mapping between the imported derived role and the org value map.

The only chance is to do the assignment directly in the table: GRACRLORGLVMPG.

Also described in the idea:

GRC 10 Mapping Existing Derived roles to Org Value Maps : View Idea

Hope this helps,

Regards,

Manuela

Answers (1)

Answers (1)

Colleen
Advisor
Advisor
0 Kudos

Hi Pourang

Organisational Maps is where you define what the values for a derived role would be

Fields would include items like BUKRS (company code), WERKS (Plants), EKORG (Purchasing Org), VKORG (Sales Org), etc

You define the maps here and then you reference them when you derive a role in NWBC

I recommend you refer back to some training material or see if the IMG help can assist you.

Regards

Colleen

Former Member
0 Kudos

Dear Colleen,

unfortunately either GRC300 Training Materials nor the IMG Help don't cover Org-Maps in details.

But maybe you could give me a hint, where i can provide the final org values to be put in the derived role.

Thanke you.

Pourang

Colleen
Advisor
Advisor
0 Kudos

Hi Pourang

I thought I did give you a hint You are right, I had a quick look at GRC300 and there's one tiny paragraph explaining what it's all about

Basic Configuration Steps for BRM - Governance, Risk and Compliance - SCN Wiki

The WIKI above has a screen shot of what I'm referring to. The piece you need to focus on is figuring out what belongs in a derived role

For example, if you are building a role for Finance Access that includes FB* transactions you are probably going to need Company Code (BUKRS), Business Area (GSBER), Controlling Area (KOKRS), etc.

If you happen to have 4 company codes in your system and you need to build a derived role for each, you will then need 4 organisational maps. You would then build each map based on BUKRS and then complete the other values.

Ideally, these maps should be completed with all the org values for your system whether your role needs it not. The idea is that you would build derived roles and reuse the maps. Then if you ever needed to add a new value (for example, you configure a new plant) you would update the map and then mass update all impacted derived roles. Much quicker than going to PFCG each time.

As far as where do you get those values from - that depends entirely on what your functional/configuration team have built. As part of security role design effort would be made to determine the derived values.

I'm not sure where you got your parameters from but you need to switch them over to your organisational values.

Regards

Colleen

Former Member
0 Kudos

Sorry Colleen,

thank you for taking time.

Obviously there is misunderstanding here.

My initial post was in regard of the fact, that the configured org-values in IMG are not populated in the generated derived roles. The derived roles just don't have any org values. The org-values are empty.

In your first mail you write, "Organisational Maps is where you define what the values for a derived role would be". 


     So I though you mean, those values are just examples and are not used in where the derived role is      being generated. So i asked, where the final values have to be maintained, when not in the map.


Your second mail tells me the values in the map are used: "The idea is that you would build derived roles and reuse the maps."


     Actually what I was expecting, but it obviously don't work for me.

     Look, the generated Role doesn't contain any value from the map, which was selected during the "Mass Role Derivation"



The configuration Steps from the guide are all done.

Even my own methodology and MSMP is working well.

Regards

Pourang

Colleen
Advisor
Advisor
0 Kudos

Hi Pourang

Apologies, you are right. I didn't realise you were configuring GRC role values and that you have organisational values for those items. I was really confused why you had GRC connector information in an org map (scratching my  head where you would get that from but makes complete sense now). Again sorry, it's quite late here and I have had a disconnect between my eyes and brain.

Are you able to show screen shots of what you configured for the role in NWBC screens where you derive the role and choose the org map. Also, is there any SLG1 logs? Also, can you include the screen shot for the top folder in IMG for "Org Level Mapping"?

MSMP doesn't impact the Org map here. The BRM MSMP would be for role content approval workflow.

Regards

Colleen

Former Member
0 Kudos

Hi Colleen,

no problem.

Here are the screens you requested.

Pourang

PS: don't forget about sleep

Colleen
Advisor
Advisor
0 Kudos

Hi Pourang

Did you see any logs in SLG1?

Also are the authorisations that reference the derived roles standard (brought in from SU24 default) or did you add them manually to the role?

Finally, what GRC version are you one and SP level? At the moment, I have a feeling you might need to raise an incident with SAP. I might be able to help a little bit more depending on your answers to the questions above.

Regards

Colleen

Former Member
0 Kudos

Dear Collean,

its a very current version  GRCFND_A V1100 0006.

Neither SLG1 Logs available nor Auth. Issus.


Its just grrrr 

Pourang

Colleen
Advisor
Advisor
0 Kudos

Hi Pourang

As it is current version of 10.1, I do recommend you raise an incident on this. Unfortunately, I've only configured 10.0 and that was some time ago.

I asked you if the object in the role was manual as I had written this note. I'm quoting is as I it was so long ago I cannot remember if I have copied it from SAP information or if it's my own words. Also, it's so long ago I cannot remember how I got this information (potentially I debugged or traced the code)


Note: If the parent role contains organisational fields that are only in the technical role due to a manually added object then this will cause problems with the role derivation based on leading org unit. The derived role organisational values cannot be directly maintained in GRC. When a derived role is created it will read in the SAP SU24 values and not the Parent role maintained authorisations – this is standard SAP PFCG functionality. As a result, the derived role information will not be included in the GRC repository. Do not manually add authorisation objects to role if the object contains an org field – always link via SU24

Regards

Colleen

Former Member
0 Kudos

Dear Colleen again,

The Objects are added manually.

What do they mean by "always link via SU24"?

This could be the problem.

Pourang

Colleen
Advisor
Advisor
0 Kudos

Hi Pourang

SU24 maps the transaction/etc to default proposals. I think GRC is actually using the SU24 data when it somehow derived the role.

Are you able to test building an imparting role by adding a transaction to a menu that contains the authorisation proposal in SU24? After doing that, then attempt to build a derived role. If that works then it's do with manual object.

I think that's why I wrote that note (sorry almost 2 years ago now and I' not on a GRC system at the moment). I think I had the issue as well and on testing found that the manual objects weren't considered as the SU24 data was being used (not entirely sure how). Though, I think it's the same with PFCG..... If you were to build an imparting role and put in manual objects when go to derive a role the manual objects will not appear in PFCG immediately (the derived role still reads the role menu and imports the default).; In PFCG derived role you have to "copy the authorisations: from the importing role which would then bring in the values.

GRC is doing the same thing. It is calling the BAPIs to mimic PFCG.

If you were to complete the derived role (propagate changes from parents) and then update org values again it would work. Alternatively, drive your build fro SU24 and avoid the situation altogether (SU24 is best practise for keeping security role build clean).

Sorry for the ramblings..it's getting late over here again

Regards

Colleen

Former Member
0 Kudos

Hi Colleen,

what you dont know, i am fully aware of SU24 concepts

I just don't know what they exactly mean by"always link via SU24"

I did create a Role, where the object is generated from the TCODE put in the Role Menu.

So there is no Object copied, modified or manully added to the Authorizations.

Than I imported and derived that Role in GRC. But its still the same ...

Org-Field Values of the dereived Role are empty and not populated from the map...

Need to go for SAP support.

Thank you a lot for your time and support. May SAP_ALL be with you allways

Pourang

Colleen
Advisor
Advisor
0 Kudos

Hi Pourang

"I just don't know what they exactly mean by"always link via SU24""

I mean drive all the security role build via role menu so it inherit SU24. It sounds like you have then test that already.

As you are on 10.1 your screens do look a little different to my notes. I do recall when I prototyped the derived roles that I had challenges with selecting the Org Map and actually incorporating it in the NWBC steps. It seemed I had an additional selection step to copy it over. However, your final step implies you were successful

Whilst waiting on SAP support you could try tracing it or debugging (if you have a developer available). As it's 10.1 recent SP it might be a bug

It'd be great if you could update us with the solution once you obtain assistance from SAP

May SAP_ALL be with you allways --NOOOO... May appropriately resricted security always be with us... I admit not quite the same ring to it


Good luck

Regards

Colleen

Former Member
0 Kudos

Dear Colleen

Thanks a lot for your support so far.

I'll let you know as soon as I know whats the reason.

Regards

Pourang