GRC
HR
SCM
CRM
BI


Blog

 

Performance - the never ending battle

by Jayne Gibbon

May 25, 2010

One of the top issues that many GRC Access Controls customers raise with support is performance, especially in the Risk Analysis and Remediation (RAR)  capability.  Depending on your data, the jobs in RAR can sometimes run for days.  While we can't get it down to minutes, there are various ways to significantly improve the performance of the tool.

First off, though, you have to understand how the application performs is dependent on the data it's trying to process.  At the core, RAR is strictly a reporting application.  Just like in ABAP, processing a million records will take much more time than processing 1,000 records.  In RAR, the variables that impact performance are:

 

  1. Total Number of Rules configured in RAR
  2. Total number of Users/Roles you're trying to analyze
  3. Number of authorizations that these users/roles have access to
  4. Number of violations generated by running the report

 

So a customer that has 500,000 users, but who has gone through remediation and has very few unmitigated risks will have a job that runs quite fast.  But a customer that has 1,000 users that all have sap_all level access will have a job that can run for days.

There is a lot of good information out there that can be reviewed to help speed performance.  Below is a listing of the various information sources you can use to help you configure your system appropriately.

 

  • Sizing guide: 

 

service.sap.com/~sapidb/0110003587000004...

 

Per this guide:  "Sizing is the process of translating business requirements into overall hardware requirements, such as the physical memory, the CPU processing power, and the network capacity needed to implement the SAP BusinessObjects Access Control Suite."

 

By setting up your system correctly to begin with, you will increase the speed at which processing can occur.

 

  • System tuning and configuration settings

 

The next step should be to ensure your system is properly tuned, both at the database, Netweaver and application layer.  There are many sap notes out there to help in this.  Below are the key ones that relate to GRC Access Control:

 

1313116          Performance issues when running Risk Analysis in RAR w/MaxDB

1121978          Recommended settings to improve performance risk analysis

1044174          Recommendation for CC 5.x running on Oracle 10G Database

1044173          Recommended Netweaver Settings for Access Control 5.X

986997            Risk Analysis & Remediation tuning for optimal performance

1310364          GRC AC 5.3 MaxDB additional indexes creating recommendations

723909            Java VM settings for J2EE 6.40/7.0

 

  • Business Process Expert Forum

 

www.sdn.sap.com/irj/sdn/bpx-grc

 

Under Key Topics - GRC Access Control - Access Control, review document called Access Risk Management Guide.  This goes through the process of how to structure your remediation of Access Control risks.

 

VERY IMPORTANT - The key with remediation is you need to start with single security roles, move to composite and then only do user level analysis once you've already remediated single and composite roles.  Too many customers try to run RAR report for users the second they install.  This is a recipe for disaster.  By following the process laid out in this document, it will both help your remediation process as well as improve performance.

 

  • Risk Analysis and Remediation configuration

 

So once the underlying system is properly tuned, there are best practices to be followed within RAR.  SAP Note 1034117 contains the best overall information on settings in RAR.

The key area is to include any critical roles and profiles in the Critical Roles and Profiles table in RAR and set the configuration option to exclude these.  This means sap_all or any other super user access roles should be excluded.

 

The reason for this is you know these roles have countless conflicts.  The fact is, these are managed on a separate process from normal end user access.  By excluding them from risk analysis, you alleviate a lot of processing time.

 

The other main consumer of processing times is to populate the offline databases.  Under Configuration - Risk Analysis - Additional Options, there is a configuration option called "Enable Offline Risk Analysis".  Setting this to YES has a significant impact on processing time, overall database size and memory usage.  If you do not plan on actually running any ad hoc analysis reports using Offline analysis, nor do you plan on using Data Mart custom reporting, you should set this configuration option to NO.  This will have a very significant impact to your processing time.

 

Hopefully these guidelines will help in tuning your Risk Analysis and Remediation jobs so that you can focus your time and effort on the most important piece which is Remediation and keeping your system clean.

 

Jayne Gibbon

Director GRC Support

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ