Skip to Content
Technical Articles

SAP GRC 12 Upgrade – Best Practise, Housekeeping, Upgrade Approach & Plugin Updates

Introduction

The Mainstream Maintenance for SAP GRC 10.0 & 10.1 is officially ended on 31st December 2020. SAP recommends upgrade from GRC 10.0/10.1 to GRC 12.

I have recently performed the GRC upgrade (GRC 10.1 to 12) for one of the E&P customers. Following is the SAP Version details;

SAP GRC Access Control – 12.0

SAP Netweaver AS Abap – 7.52 SP07

Database – Oracle 12c (12.2.)

Operating System (OS) – SUSE SLES 12 SP5

It was the three-system landscape consisting of DEV, TEST & PROD integrated with the S/4 and BW as the plugin systems. The project lasted for around 4 months and the timelines were based on the GRC functionality (Fire fighter, Risk Analysis etc) implemented in the customer landscape. The SAP upgrade method chosen for this project was “In Place” due to the budget and time constraints. This article outlines the key areas to be focused before planning the GRC upgrade.

Best Practise

Impact Analysis – This is the key step that must be included while planning a major upgrade like SAP GRC. The sap Side Effect Notes (SEN) analysis can be downloaded at the time of generating the stack file through the Maintenance Planner (MP). The SEN are notes that should be implemented in order to fix issues introduced by other notes. The stack file is an XML file needed during the SAP upgrade. This file contains a description of the SAP Support Package Stacks.

2309475 – How-To generate Side Effects Report for Targets Calculated by Maintenance Planner

I would strongly recommend you to apply the solution notes captured in the SEN analysis even though it is not impacting you immediately after the technical upgrade. This is one of the good practises I implemented over the years while doing major SAP upgrades or patching.

SAP Housekeeping – This is one of the areas in major SAP release upgrades which is largely overlooked by the technical team. One of the best practises is to identify the largest tables in your database where the housekeeping can be done quickly through SAP standard reports. Since these are technical tables, it will be lot easier to take the decision for housekeeping in comparison with the business tables. This exercise will not only reduce the sap table size, storage footprints but also improved the runtime of the SAP upgrade. I would strongly recommend to involve your Basis team to perform the Database reorganization through the brtools option in case of SAP system running on Oracle database to reclaim the storage space and run the database update statistic job to keep the performance of the system intact.

Below are the key SAP GRC tables where the housekeeping can be easily performed

646681 – Reorganization of tables with BRSPACE

Downtime Optimization Approach

There are various blogs available which talk about nZDM. This should be your preferable option if you want to reduce the downtime window considerably. You may have to increase the SAPS (RAM & CPU) on a temporary basis to improve the upgrade performance. The SAP upgrade runtime can be fine-tuned with the ABAP, SQL and R3trans processes once the RAM and CPU is extended.

https://blogs.sap.com/2019/01/08/how-does-nzdm-for-sum-work/

https://blogs.sap.com/2019/10/11/downtime-optimization-approach-lets-talk-all-about-different-zeros/

Following options are currently available in SUM extraction phase.

1) Single System (longer downtime, no shadow instance running in uptime) – Not a recommended option and this option has been disabled from the latest SUM 2.0 SP9 (PL1).

2) Standard (standard configuration) – Downtime was long and uptime phases were short. You can choose this scenario if the long downtime is acceptable to business. It took 3.5 hours for the downtime phase whereas uptime phase (shadow import) took around 2 hours 45mins to complete. This will have a direct impact on the overall cutover plan.

3) Downtime-optimized (based on near Zero Downtime Maintenance (nZDM) – The capabilities of SUM enable significantly reduced business downtime for standard upgrades. In my case, the Downtime phase was reduced by 85% with nZDM approach and uptime shot by 65%.

Route to Live

This approach works in our case as the upgrade was technical in nature.

SAP Fiori for SAP GRC

This is an enhance feature introduced in SAP GRC 12.0 where the Netweaver Business Client screens for GRC Administrators can be replaced by Fiori-like screens. You must check the technical pre-requisites and accordingly install the add-ons as part of the upgrade tasks.

https://blogs.sap.com/2019/05/03/grc-12-fiori-launchpad-configurations/

Following SAP components are associated that needs to be installed on front-end gateway system to enable SAP Fiori functionality.

UIGRAC01 – Access control Components

UIGRPC01 – Process Control Components

You can refer below useful sap notes before planning the deployment of the SAP Fiori Add-on.

2956894 – How to check compatibility for SAP Fiori for SAP Access Control (UIGRAC01)

2654895 – FAQ: GRC Access Control 12.0 Installation Questions and Recommendations

2176696 – Uninstallation of the Fiori UI Component UIGRC001 100 from the Product version SAP FIORI FOR SAP GRC 1.0

Plugin Updates in Backend systems (ECC, S/4 & BW etc)

GRC 10.0 Plugin is not backward compatible with GRC 12.0 foundation. SAP strongly recommend upgrading the plugin as well. I would strongly recommend checking the old /VIRSA/* objects exist in your integrated systems (ECC, S/4, BW etc).  All the /VIRSA/ objects got obsolete and deleted as part of the latest GRC plugin updates. This has serious impact on several business processes, as some of the old /VIRSA/* objects might be in use in the SAP system. All this type of issues should be reported in your development or the POC system upgrade.

I would like to highlight the two key issues encountered while doing the GRC upgrade in my environments.

There are many SAP standard /VIRSA/* objects getting deleted as part of the latest plugin updates and SAP has not provided any reference notes or document for the /VIRSA/* object deletion.

You can fix the BAdI issue after following the sap note “2248395 – Risk Terminator implementation in 10.1 release in case of su01 and su10”. There are manual activities to be performed after the plugin updates in your integrated systems, but this might be a tedious activity and the suggestion is to disable the SAP BAdI ““BADI_IDENTITY_UPDATE” if it is not in used before the plugin updates.

For the exact support pack numbering between the GRC and the plugin systems, please refer to the spreadsheet attached in the sap note 1352498 – Support Pack Numbering – GRC Access Control.

There are several blogs published by various SAP experts on the GRC upgrade and hope this blog will give you insight information to plan your GRC upgrade efficiently. The issue occurred due to plugin updates in the backend systems have serious business impacts and may jolt your overall project planning. The suggestion is to check the old Virsa objects before the plugin updates and SAP BAdI as part of the impact analysis exercise. I am confident this blog will be useful for those who are planning the GRC upgrade this year. This is my first SAP blog and do not hesitate to give your honest feedback.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.