on 11-26-2011 5:42 PM
Hi Gurus,
Many of you have already completetd GRC 10.0 implementaion. One of the Key advantage of GRC 10.0 stated as "Changes can be transported".
While carrying out configuration settings under nodes SPRO -->GRC --> Common Component Settings --> Integration Framework and other Subsequent nodes in Access Control, we find many steps involve Connector, Connector Mappings, Actions related Settings which are connector dependent.
Further, there are relevant sub-nodes viz. User Defaults, User data sources, HR Triggers etc., which involve connector values as part of configuration steps.
We have created Back end test / Development related connectors and carried out the relevant configuration settings. We find that all these settings are getting collected in the transport request.
Once we move this transport request to GRC QAS / Production landscape all the back-end Test / Development /QAS related connector settings will also move. Further this will also call for defining back-end Production systems related Connector Settings in GRC Development System itself.
Looking forward for inputs with respect best practices for managing the GRC 10.0 config / workflow related transports across Dev / QAS / landscape.
Regards
Hemant
Hi Hemant
Regarding connector I dont think you can transport connect (which are nothing but RFC connection vis Sm 59 ) .All other setting related to connectors can be trasported .
But I m not sure if that will work as you dont have main connector transportable .
I still need to test this .
Thanks & Regards
Asheesh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hemmant,
You certainly can manage connectors via transports but you need to understand the dependency on the RFC master data as Asheesh refers to.
Whilst the SM59 RFC content cannot be transported, you can still transport the additional configuration maintained around it in the IMG.
There are a few options available to manage this but it depends on how complex your system landscape and basis standards are as to which might be the best fit.
I have a transport management white paper ready and waiting to go into the articles section but I cannot publish it until the SCN upgrade is complete.
Cheers, Simon
Hi Hemant
SAP has made a lot of the transport functionality in GRC10. I find that they hereby created a huge expectation with the customer, that in fact is not true.
For instance Exclusion Objects and Mitigation Controls are NOT transported. What about Organizations? Critical Roles and Profiles are also not transportable.
As for the Connectors - system specific parameters are transported. Therefore you end up having to delete the DEV and QA connectors in the PRD GRC system.
On this question, has anyone used CLM yet? It seems that only Functions and Risks will be extracted to CLM and then deployed in the other system (DEV to QA for example). Does CLM even work?
SAP provide not guidance on all of these important issues. I agree that it is about time that SAP takes some leadership and produce a proper best practise guide for this software. By the way, an offical sizing document from SAP is still to be delivered.
Thanks
Will
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Will,
We are also in the phase of building our GRC QA server.
Now from your post i found that we cannot transport "Mitigation Controls", "Critical roles" ,"Critical Profiles", "Organization details".
I am not sure how are we gonna upload each individual thing in GRC ??
Did you also do it manually.
Thanks in advance.
Regards,
Victor
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.