Skip to Content
Author's profile photo Sammukh Gupta

Transport management of GRC Configuration

GRC 10.x being based on ABAP, we know that a lot of configuration can be built in the development GRC box and then moved along through the GRC landscape.

Lets take a typical landscape comprising of three GRC systems; development, quality and production. Usually, the quality and production boxes are closed for changes on them. During GRC AC implementation’s realization phases, all configuration of GRC AC is done on the GRC development box and all changes are then moved to quality and production.

Following are the basic requirements for the configuration of access control:

1. RFC connections to backend systems done by basis.

2. These RFCs to be used then into configuration settings; like: user defaults, PSS, BRF plus rules, etc.

Considering that a lot of configuration is attached to RFC names there needs to be a way to be able to efficiently manage the changes through the landscape.

For example in user defaults, we tag the defaults to an RFC name and a default ID is assigned to this record automatically. Which is then in-turn used in the BRF plus user default rule.

Now lets consider the following options for change management, each has its pros-cons. I would really like to get feedback and better understand which one is better considered across implementations. Or if there is much better alternative to balance efficiency and trace-ability.


Here we have the RFC named as per regular conventions <SID>CLNT<Client#>; example – ECDCLNT100. So, here we have the following connections:

2014-10-23 17_08_55-Presentation1.jpg

Each RFC from the GRC box to its ECC counterpart is named per its SID and client number.

Now in development GRC we build the user default configuration with ECDCLNT100 and tag different defaults to it. Everything works fine.

Then post-unit testing we move the configurations to Quality GRC box. Here in the Quality box, the config entry comes through the transport and is maintained as ECDCLNT100. Which is not present in the GRC quality! also the quality ECC is on a different RFC.

Thus, the user defaults does not work in Quality box. To fix it, the quality box is to be opened by basis and the entry fixed manually directly in the QA box. Now think of the effort of manual fix multiplied by the number of clients + exposure and risk of opening the clients for every little change related to RFC names.

The only seeming benefit here is that you get to use the regular RFCs and they are of standard naming convention that can/might be helpful for basis team members to track the RFCs by name.


Here we have GRC specific RFCs with same names across the landscape. The would ofcourse connect to the respective ECC client but their names would be same.

2014-10-23 17_09_14-Presentation1.jpg

ECC_GRC is the RFC for connecting GRC box to ECC box. This ECC_GRC sitting on GRC Development connects to ECC development, ECC_GRC sitting on GRC Quality connects to ECC quality and so on. The exact target entity can always be mentioned in the description of the RFC.

Now coming back to the user default configuration, in this option we tag the defaults to “ECC_GRC” in development system. And transport it to Quality box. And it works! No manual changes needed.

The only catch here is that the set of RFCs to backend systems needs to be created by basis on GRC development, quality and production boxes, which is a one time activity.


I have personally liked the option 2, since it brings down the change and maintenance efforts to minimum and eliminates client opening risks for small regular changes.

As a closure to this blog I request experts to share experiences and design of change management of configuration across the GRC landscape. If there are other options to use, if these options can be bettered?



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      Hi Sammukh

      thanks for starting this discussion 🙂

      For Option 1 - Use System/Client in convention..Things to Consider..


      Now think of the effort of manual fix multiplied by the number of clients + exposure and risk of opening the clients for every little change related to RFC names.

      Once you set up the RFC connections what sorts of changes do you see occurring if you used the naming convention for <SID>CLNT<client>? Risk can be mitigating by recording changes when the client is open and forcing it into a transport that cannot be deleted from the system.

      2.  Using the RFC name <SID>CLNT<client> - you would need to be careful how Basis is using this RFC connection elsewhere throughout the landscape. For example, if they have it as part of CUA (you may possible still use even with GRC) or Solution Manager connectivity. And depending on how they use it, do they have system users against the credentials or login? If they RFC is a trusted connection with current user then it might be a bit more flexible as the authorisation can be limited to the specific user.

      3. I've used this convention and took the approach with transport to do some manual client specific. As the connectors do not change unless there is massive changes, then I would transport all of the configuration and arrange each client to be opened and manually update the Integration Framework, Configuration Parameters and Data Sources (I think that's where the RFC is referenced**).

      4. Drawback for this option would be client refreshes and system copies. If you copy Production back to QA for example, you would need to go through and change the connectors back to the QA systems. This may not happen too frequently and could be handled as part of System Refresh tasks.

      **BRF+ rules could be configured to capture all environments or use a naming convention on them. But that is definitely something to be cautious with for system-specific rules. I wonder if it might be better to somehow derive the logical system from the actual connector to keep BRF+ rules as generic as possible.

      Option 2 - Using a Connector without System Name (GRC_ECC)

      What this one does not consider is if you are connecting to multiple clients on or multiple ECC systems. For example,

      • You might have a Sandpit, Master Configuration and Unit Test client on your Development box. Your connector can only connect to one of them.
      • Alternatively, you might have split architecture setup and have multiple ERP components within the same environment (i.e. you need to connect YEQCLNT200 and ZEQCLNT200 systems to ZGQCLNT200 box). Your connector for this option will not work.
      • Finally, if you have 2-tier GRC system (companies like to cut cost) and link to 3 tier ERP then you DEV and QA ERPs would probably be assigned to your DEV GRC - same example as multiple ERPs in the same environment.

      On a positive, this one would work quite nicely for client refreshes as you would just need to fix up SM59 definition to re-point to the specific system. The bind of GRC_ECC makes it clear the purpose of the RFC connection as well.

      My view

      I think the naming convention of the connectors comes back to overall system landscape strategy and this is bigger than GRC. You need to work with the System Architect or Basis person to figure out how RFCs should be named (RFC, ALE model, system setup, integration with SolMan, etc). I'm partly sitting on the fence as I don't think there is one specific way to do this without consider the landscape in its entirety.



      Author's profile photo Sammukh Gupta
      Sammukh Gupta
      Blog Post Author

      Hi Colleen,

      Thanks a lot for your valuable input!!!

      Once you set up the RFC connections what sorts of changes do you see occurring if you used the naming convention for <SID>CLNT<client>? Risk can be mitigating by recording changes when the client is open and forcing it into a transport that cannot be deleted from the system.

      Here I was thinking of changes like; change to a user default configuration (suppose changing the printer location). This would mean the change needs to be done individually in each client across the landscape and transports would not suffice.

      Most importantly, assume we have BRF plus rule for agents based on back end systems. The decision table containing RFC names as part of input and giving out agent IDs. Say the approver changes and the decision table needs to be fixed. Again, the change needs to be performed on each client individually across the system.

      Similarly any changes where the configuration is tagged to RFC names would result in the similar situation.

      Usually a quality / production client is set to closed and also no transports enabled for changes on them. So I am not sure how on such clients changes can be put into a TR. Kindly let me know if there is a way to do so.

      What this one does not consider is if you are connecting to multiple clients on or multiple ECC systems.

      Absolutely, you are correct! This approach will get complicated if there are multiple clients considered for connection. That's true! 🙂

      Also, along with the consideration of stable phase for a long term plan, I am thinking of during the project cycle. Consider Integration testing, Acceptance testing, etc where these kind of changes may recur where defects are to be fixed based on configuration items related to RFC names. Usually the basis teams are not very comfortable having clients opened for long duration. Therefore, it would call for repeated opening and closing of clients during these phases.



      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      Hi Sammukh

      As I mentioned, it is great to see this discussion and get people's thoughts so I'll throw out another scenario...

      You defined all RFC connectors in DEV and transport them through. To achieve this consider the following:

      • Set up all Connectors in DEV and transport through landscape
      • In RFC connection put dummy credentials so no risk of jumping from DEV to PRD unless required for another purpose
      • Manual Config step in each client for connector usage
        • Integration Framework for Logical System Mappings and connection types (only map that ones that apply) - in a nutshell you only transport first time or you set up manually when adding a new connector. This would determine if SUPM, PROV, etc.
        • Data Sources For authentication, etc (although it may be a non-event if the connector sat there as it cannot be used. You would not run your synch jobs)
        • ?? Any of scenarios that would impact connector usage
      • BRF+ rules, etc would need to cater for all scenarios
      • Schedule sync jobs for necessary connectors

      Would need to confirm if removing some of the Integration Framework mappings will have issue with the usage of the connector throughout the configuration.

      Downside, you are maintaining the ARQ User Defaults, etc for each connector - might be initial build effort to copy but could remain static. It might also create some flexibility for usage if you want to differentiate between testing.

      Post-processing activities would still be required for system copies.

      What do you think of that as another option?



      Author's profile photo Kevin Tucholke
      Kevin Tucholke

      I would definitely agree with Colleen as the best option for moving all via transport.  I have basically done the same thing, however I set up DEV just like PROD with all necessary connectors and connector groups (my installations are usually targeting all SAP systems from SBX to PROD).  I will create the configuration, but what I do is have all SM59 RFC destinations created, but when placing the IP address or hostname, I point it to a respective box (i.e. all connectors in DEV point either to DEV or SBX, but the name of the RFC would be (SBX, DEV, QAS, PRD).  When I move this to QAS, then I have the SM59s created to SBX, DEV, QAS target systems.  To eliminate any confusion, I have the BASIS tech change the Description 1 on the respective connector to reflect what I would like to see.  For example, in my GRC QAS box, I might have PRDCLNT900 as the connector name, but it actually points to QASCLNT800, and then would have the description something like PRD - ECC (QASCLNT800).

      I do this as SM59 is not transportable in any ABAP system.  In this manner, my configuration is the same throughout all of my GRC landscape and I am utilizing the one piece of configuration that is not transportable anyway.  I have created an RFC spreadsheet that I use to document all of this data, as I also use different RFC User IDs to determine if the data I would see in a Non Prod system (QAS) is from my QAS GRC system or my PRD GRC system.

      This also give you the ability to test out scenarios based upon connector ID in all systems.

      HOWEVER:  One item to note, if you still have CUA in any of the mix, this will create a situation where this would not work due the fact that CUA uses the Logical System name from the physical system and not the SAP Access Control connector, and have not found a way to get around that as of yet.

      If the requirement is to transport all information, this is the best way that I have found to do this.

      Hope this helps.

      Kevin Tucholke

      Principal Technology Consultant

      SAP America