Why should an SAP system be upgraded?
An SAP upgrade should never be done just for the sake of it. The decision has to come from the needs of the business. Before moving ahead, the organization must be clear about what the new version offers, what problems it can solve, and whether the added features truly bring value. Release notes of each version usually highlight these changes. At the same time, an upgrade must be carried out carefully, since a failed attempt could disrupt day-to-day operations.
Understanding SU25 in an SAP Security Upgrade
When an SAP system is set up for the first time or whenever an upgrade is performed, transaction SU25 plays a key role. This transaction consists of several steps, though not every step is required every time. SU25 is mainly used to either load the default SAP authorization values into the Profile Generator tables during the first implementation, or to update those values after an upgrade.
Step 1 – Filling customer tables
This step is about copying SAP’s default check indicators and authorization values (from tables USOBT and USOBX) into the customer-specific tables (USOBT_C and USOBX_C). It is mostly done during the very first implementation or when you intentionally want to overwrite the existing customer values with SAP’s defaults.
Step 2 – Adjustments after an upgrade
This step is broken into four sub-steps (2A–2D) and comes into play after moving to a higher release.
-
2A. Compare with SAP defaults – Here, the new SAP default values are written to the system tables, which then serve as the base for comparison.
-
2B. Identify differences – This compares the updated SAP tables with the customer tables and highlights mismatches. For example, a red indicator will show if a transaction uses different authorization objects compared to SAP’s new defaults.
-
2C. Roles check – This identifies the roles impacted by the changes above. Those roles need to be adjusted or merged again with the updated authorization objects. In expert mode, you can load the correct defaults, provided the roles were originally created with the relevant transactions in their menus.
2D. Changed transaction codes – Some transactions are replaced or combined into new ones in SAP S/4HANA. This step lists the old and new codes so you can update the roles accordingly. A double-click allows you to go directly to the affected role for editing.
It’s also advisable to cross-check with the table PRGN_CORR2, as the automated report may not catch every modification.
Step 3 – Transporting changes
After making adjustments in the earlier steps, this step ensures that all updates in the customer tables are properly transported across the landscape.
👉 In short, SU25 helps keep the authorization framework aligned with SAP’s new release standards, ensuring security roles and objects continue to function smoothly after an upgrade.
No comments:
Post a Comment