on 12-16-2014 11:36 AM
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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
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
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
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
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.