cancel
Showing results for 
Search instead for 
Did you mean: 

Update GRC Rule Set in DEV, QUA & PRD systems

Former Member
0 Kudos

Hi All,

I need to make some amendments in Rule Sets for a few custom transaction codes.

I want to understand what is the best practice to do such updates, while keeping the systems in landscape in sync.

I am using GRC AC 10.0, three system landscape. Where GRC DEV is linked to ECC DEV, GRC QUA to ECC QUA and GRC PRD to ECC PRD.

Regards,

Piyush.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Piyush,

In order to modify the rule set with addition of some entries (either by adding or removing), unless you generate the rule sets (SoD with new changes), this will not be reflecting in your current environment. Then you would need to cross check if the modification is in place with correct mapping of Functions-Actions-Permissions and then post verifying, you can transport to your follow on GRC environment.

You can refer:

You need first to download the existing rule sets --> make the changes as per the business need and then upload the modified rule set.

Rule Set customization is accomplished via either of these ways:

  1. Direct modification of functions and risks in NWBC via WorkCentre: Setup ->Function/Access Risks/Rule Sets
  2. Mass modification of functions in NWBC via WorkCentre: Setup ->Function ->Mass maintenance.
  3. Mass modification of functions and risks via GRAC_DOWNLOAD_RULES and GRAC_UPLOAD_RULES.

Hope this helps, let us know for any more help.

Regards,

Ameet

Answers (2)

Answers (2)

Former Member
0 Kudos

Thanks all for the inputs!! It was quite helpful.

1. After single modification to a function I created a transport via SPRO -> Transport SOD Rule, but it contains the entire data i.e. Rules, Functions etc. So I assume it is transporting the entire data from GRC DEV to QUA and PRD.

     Q) I would like to understand if there is a possibility to transport only the changes made to the      function(s) and not the entire data?

2. Also I find that the transport has got target system connector entries (ECC DEV) in it (eg. table GRACFUNCACT).

     Q) So if we move this transport to further GRC QUA and PRD systems, above table will be get      updated with connector entries of DEV system overwriting the existing connector entries of QUA &      PRD.

Note: Configuration scenario, GRC DEV is linked to ECC DEV, GRC QUA to ECC QUA and GRC PRD to ECC PRD.

Colleen
Advisor
Advisor
0 Kudos

Hi Piyush


     Q) I would like to understand if there is a possibility to transport only the changes made to the      function(s) and not the entire data?

You can technically do this by editing the transport in SE01/SE09 and changing the values for the table entries to the ones you are after


2. Also I find that the transport has got target system connector entries (ECC DEV) in it (eg. table GRACFUNCACT).

This comes back to how you defined your rule set. Did you use logical system or actual connector? If you had used logical system then you would have a GRACFUNACT entry for connector as something like ECC_LG (ECC Logical System). It is not an SM59 RFC connection. Within the Integration framework you would map the connector to the group (so in DEV you would mapp ECC_DEV, in QA you would map ECC_QA and in Prod you would map ECC_PRD). Therefore, GRACFUNCACT (and GRACFUNCPRM) would be the same data across all GRC systems.

If you used actual connector you would need to maintain an entry per system for each function to action. Or you would not transport your rule set.

Regards

Colleen

Former Member
0 Kudos

Thanks Colleen!!

But still I am still not clear on logical and actual connectors. Can you please explain a little.

I have defined connectors using SM59 RFC connection. If this is actual connector how can I create a logical one?

Thanks & Regards,

Piyush,

Colleen
Advisor
Advisor
0 Kudos

how did you define your integration frame work when you assigned connectors to groups?

Former Member
0 Kudos

Hi Collen,

I have a similar question but let me explain my scenario.

I have mapped my target connector to logical group SAP_ECC_LG and  my customize connector group.

I need to know if this is okay if we have to customize ruleset for my target connector  as I dont get any entry in table GRACFUNCPRM or GRACFUNCACT for my target connector against standard functions.

Also , what logical system should i select when I attempt to append standard ruleset through rule upload functionality if I decide to continue with this approach.

Basically, I am trying to understand the scenario in which we will  have entries created in these tables for standard functions against my target connector along with SAP_ECC_LG, SAP_R3_LG and so on.

Please advise with your expert comments .

Thanks

Colleen
Advisor
Advisor
0 Kudos

Hi Sushant

You can customise the rule set or build your own. Your decision

I think you need to step back and put pen to paper as you come you with your design. Which logical system you map to your connector comes back to knowing what the component is. You can look at downloading the ruleset and then compare to two logical systems to see the differences.

The rule set is just a starting step

As far as updates to the tables goes, only the logical connector will appear in them if that is what you have built. Generating the rules and running risk analysis leverages the integration framework in which you mapped the connector the logical system. Using the logical system allows you to transport you change through the landscape.

Regards

Colleen

madhusap
Active Contributor
0 Kudos

Hi Piyush,

The best practice is to make changes 1st in Development system and then transport it to Quality and Production systems. You can test properly in Dev and then you can upload or transport to production.

Download, Modify and Upload the Access Risk Analysis Rule Set in SAP Access Control 10.x.

Rules can be transported in IMG -> GRC -> Access Risk Analysis -> SoD Rules -> Transport SoD Rules (or using program GRAC_TRANSPORT_ACCESS_RULES).

It is never recommended to make direct changes into production system. You need to re-generate the rules after transport.

Please check this note as well

1596574 - Rule ids are different in rule generation between systems

Regards,

Madhu.

Colleen
Advisor
Advisor
0 Kudos

Hi Madhu


It is never recommended to make direct changes into production system. You need to re-generate the rules after transport.

I have done that for a client site as they had a 2-tier landscape. My reason for recommending it is that I see the rule-set as a form of master data. Although it can be transported, you can still maintain.

However, I had Workflow enabled for Functions and Risks to force approval for changes. Therefore, I wanted to keep workflow approval data in Production as Development would be used to configure and test MSMP WF activities.

The DEV environment was used more for prototyping and testing. Therefore, there was a regular refresh process to download ruleset from Production and upload to DEV (i.e if needing to do testing for GRC functionality).

For rule regeneration, I would schedule the job to run regularly.

Regards

Colleen

madhusap
Active Contributor
0 Kudos

Hi Colleen,

Yeah you are right, I should have mentioned if you don't have Workflow enabled for Functions and Risks.

Actually I have joined a project recently and the first issue reported was that none of the SOD rules are working in production which were working earlier.

When tried to check the issue, what we found is that, support team was Downloading the rules from production, making the changes and updating them back with any new functions or risks.

What exactly happened was they are copying the data to excel file and after making required changes copying back to text files and loading them into the system.

In Function Permissions file after copying to excel the leading ZERO for activity fields got removed and they updated back without leading ZERO and issue was happening because of that.

May be keeping that in mind I suggested not to change directly in production

Thanks for the information and as always learning something from your discussion.

Regards,

Madhu

Colleen
Advisor
Advisor
0 Kudos

Hi Madhu


What exactly happened was they are copying the data to excel file and after making required changes copying back to text files and loading them into the system.

If they are doing this via SPRO mass load transactions, then that will bypass WF. I would only grant those transactions via FF Id so you still have a log of them being used.

It all comes back to a design and to think through how the rule set is maintained.

Regards

Colleen

santosh_krishnan2
Participant
0 Kudos

Hi Colleen,

To your point, I have a question.  I've got workflows working and risk maintenance is working and tested.  Client wants to make risk changes in Dev and transport to QA and Prod.  They want the risk maintenance workflow to send notifications from production for changes made in dev ... which isn't something I believe is possible.

Per your note above, it would seem that they should treat their rule set as master data and make the changes in production via the workflow approval.

What is your experience with making changes in dev and using the risk maintenance workflow so that the workflow is actually managed from production?

I know what you're thinking ... but my client has a lot of requests where they want things to work like it did in 5.3 and so I have to figure out what is possible and what is not.

Thanks,

Santosh