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.

OPTION 1:

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

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.

OPTION 2:

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.

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.

CONCLUSION:

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?

Thanks!!

Sammukh