Executing Impact Analysis to Determine Potential Restrictions for Business

As part of the Software Update Manager upgrade procedure, the report RSUPG_RUN_IMPACT_ANALYSIS is called in the phase RUN_IMPACT_ANALYSIS_STBX_ZDO on the shadow instance. This phase uses the file ZDIMPANA.ZIP and requires Software Update Manager Toolbox. The phase RUN_IMPACT_ANALYSIS_STBX_CHECK verifies if the file is provided in the Software Update Manager download directory and the Software Update Manager Toolbox is present.

If the file cannot be found, the phase RUN_IMPACT_ANALYSIS_STBX_CHECK will stop with the following error message: A2EESUPG_IMPANA 224 Zip file for Table Statistics was not proveded in the download directory.

In case of any finding, Software Update Manager will stop in the phase RUN_IMPACT_ANALYSIS_ZDO with the error Batchjob RSUPG_RUN_IMPACT_ANALYSIS on shadow system failed. The following errors were detected in the log files:. The log file IMPANAUPG.<SID> can be found in the SUM/abap/log directory.

While Software Update Manager continues with the upgrade, the Impact Analysis findings will be checked in detail. This can be done by utilizing the dialog version of the Impact Analysis in transaction SUMTOOLBOX. After completion of the phase RUN_RSPTBFIL_ZDM_CLASSIFY, the tool can be called either in the original system or also on the bridge subsystem in case you are already rolled over to the bridge subsystem.

Since the Impact Analysis has been moved into the Software Update Manager Toolbox, the user-interface has been harmonized, unified, and simplified. Depending on which system the Impact Analysis tool is started, the input files may differ as shown in the following image.

In general, the section File Selection has two mandatory input fields:

• Table classification data holding the information about how tables are handled by Software Update Manager during the ZDO procedure.
• Table statistics from the productive system holding information like table change rates, table size, and database triggers.

The following three scenarios are covered:

1. Execution of the Impact Analysis on the system where a ZDO upgrade procedure is active:

   a. The table classification data is retrieved from the database table in the system holding this information.

   b. The table statistics are retrieved from the ZDIMPANA.ZIP file stored in the download directory.

2. Execution of the Impact Analysis on the system where a ZDO upgrade procedure is active, but usage of a new table statistics file:

   a. The table classification data is retrieved from the database table in the system holding this information.

   b. The table statistics are uploaded using the SAP GUI. This can be beneficial if you want to follow the best practice described in unit 4's lesson, 'Best practices to run the Impact Analysis'.

3. Remote Impact Analysis: Execution on any other system in the same landscape (for example, development system):

   a. The table classification data was exported using the Software Update Manager Toolbox from a system where ZDO has been completed. The output file PUTTB_SHD.ZIP is uploaded using the SAP GUI.

   b. The table statistics are uploaded using the SAP GUI.

The dialog screen of the Impact Analysis is split into five sections:

1. File Selection: In this section, the relevant data to run the Impact Analysis is provided. Further details have been described in the section above.
2. Header: The header shows information like the export date, source system ID, the number of evaluated days, and if during the exported time software changes like import of transports are included.
3. Overall Summary: Here, the overall numbers like total number of cloned tables, read-only tables, and additional database space for cloned tables are provided. Additionally, the total change volume for all tables in the system and the online replication volume for cloned tables per day is shown. This number helps to get a better understanding about the ratio of the tables that will be cloned compared to the total number of changes in the system.
4. Impact Analysis Findings: It summarizes and aggregates the issues. In addition, gives an estimate on the required database free space for the clone tables.
5. Result table in ALV grid: It shows the findings on severity, category, and table level.

The results shown in the ALV grid are grouped by category and severity:

• Category
  • Read-only: The most critical and important category which always has to be checked in detail. These tables are used in production as per the provided statistics but will become read-only on the bridge subsystem.
  • Triggers: In case database triggers are present in the (production) system, potentially, a reload is required or the trigger needs to be dropped. For more information, see the lesson, 'SLT Database Trigger Handling in ZDO' in unit 3.
  • Cloned: This category informs you about very large tables that will be cloned.
  • Smart-switch: These tables will be cloned but are very frequently changed in production. All clone tables will be renamed in the phase EU_SWITCH_ZDM that requires an exclusive lock. The more changes a table has, the more difficult it is to acquire an exclusive table lock.
  • Comp. view: Tables getting a new non-key field can be kept as shared. The bridge sees only the old fields using a compensation view. During the upgrade, the new field will be added in the phase PARCONV_UPG. To add a new field, an exclusive table lock has to be acquired.
• Severity
  • Green: The finding is uncritical. Usually, no further action is required.
    Note

    By default, entries having the severity green are hidden. Choose the green button in the menu bar of the ALV grid to also show these entries.
  • Orange: No immediate action needs to be taken as it just reminds about a certain message that is a heads-up, for instance to show that a table will be smart-switched.
  • Red: These message have to be checked in further detail with the business teams. Potential risk for productive business operations.

The File Selection of the Impact Analysis provides the option to not only upload the table statistics (that is, ZDIMPANA.ZIP) through SAP GUI, but also to upload the Software Update Manager table classification data (that is, PUTTB_SHD.ZIP). Here is the process flow for running the Impact Analysis remotely.

By providing both files to the Impact Analysis in Software Update Manager Toolbox, the analysis can be run on any other system in the landscape having the same software version level. This can be beneficial in case the latest version of Software Update Manager Toolbox was not applied prior to the ZDO upgrade procedure in the sandbox system.

The required file having the Software Update Manager table classification data can be exported in the system that is upgraded using ZDO when the phase RUN_RSPTBFIL_ZDM_CLASSIFY is completed.

Tables that will be read-only for the bridge subsystem can lead to limitations for certain business processes. Hence, it is crucial to check every finding in detail together with the responsible functional team in your company. Ideally, each table can be mapped to the relevant business process. Only by having this information will it be possible to decide if the business will be able to continue their day-by-day work during the ZDO procedure on the bridge subsystem, or if a critical business process will be blocked when operation on the bridge subsystem.

To identify the business processes, the SAP Basis team should involve the functional team as early as possible. It might be helpful to get further details on the read-only tables using transaction SE11. There, you can navigate further to the package and software component information through the Attributes tab. Additionally, the Delivery and Maintenance tab shows you if the table is, for instance, an application table (A) or customizing table (C).

123
TABL POWL_QUERY will become read-only, but has 4,2 changes/day on ref. system S4H
TABL UCONFILLCUST will become read-only, but has 1,0 changes/day on ref. system S4H
TABL EKET will become read-only, but has 1.216,6 changes/day on ref. system S4H

• Table POWL_QUERY: This table belongs to the Personal Object Worklist functionality. When running the functional validation in a non-productive system, all processes using POWL should be carefully tested by the functional and testing teams.
• Table UCONFILLCUST: This table is a customizing table for Unified Connectivity. Since customizing is locked during the upgrade, no business user should be affected.
• Table EKET: This application table is centrally and widely used by purchasing business processes (application component MM-PUR). If this table will be read-only, it is likely that many business users will be impacted. Hence, this can become a showstopper for the ZDO project. In such cases, SAP Support should be consulted. Additionally, it is always worth to check if, in SPDD, a wrong decision was taken which would lead to a table conversion. Tables that will be converted will always be read-only in ZDO.

ZDO is able to keep the SLT replication active during the ZDO upgrade procedure. The message shown in the Impact Analysis is different, but this is dependent if SLT triggers should be kept active during the bridge time or switched off.

For all tables having an SLT trigger, but one that will not be cloned, nothing will happened and no further action is required.

1
TABL STXL SLT replication has to be paused or suspended before rollover to bridge (REQ_USER_ROLLOVER_PREP)

• As per the table statistics, SLT replication for this table is active in production but the current ZDO upgrade where the Impact Analysis was started, does not run with an active SLT scenario.
• If you would choose that SLT replication is turned off when upgrading the productive system, the replication for all tables would have to be paused or suspended before the rollover to the bridge subsystem happens in the phase REQ_USER_ROLLOVER_PREP.
• In case SLT is used productively, it is recommended to also set up the non-productive systems to be able to test the replication during the test upgrade cycles using ZDO.

1
TABL STXL SLT replication requires initial reload after rollback (REQ_USER_ROLLBACK_FINAL)

• As said, the SLT replication can be kept active when performing a ZDO upgrade. However, for cloned tables an initial load in SLT is required as the database trigger will no longer be available after the switch to the target release which happens between phases REQ_USER_ROLLBACK_PREP and REQ_USER_ROLLBACK_FINAL.
• Involve the responsible team that takes care for the replication scenario. When performing the ZDO upgrade in the productive system, the colleagues should be ready to start the initial load for the cloned tables.

1
TABL STXL will be copied, but has size of 153,005 GB on ref. system S4H

• In general, very large application tables should not be cloned as the structural changes delivered for such tables have been validated by SAP. However, there might be exceptions where cloning a table cannot be avoided as the structural change is critical and must be delivered.
• In this example, the table STXL has a size of 153 GB which is still not too big. The error shown in the Impact Analysis is more a heads-up than a critical finding.
• As a rule of thumb, if tables that are very huge like bigger than 250 GB, it should be checked why those tables will be cloned. Potentially, a wrong decision in SPDD was taken the database object is inconsistent.
• Raise an incident using SAP ONE Support Launchpad for component BC-UPG-DTM-TLA in case you need support.

12345
TABL COVRES will be smart-switched, but has 14,5 changes/second on ref. system S4H
TABL STXL will be smart-switched, but has 30,2 changes/second on ref. system S4H

TABL BKPF will get comp. view, but has 13,9 changes/second on ref. system S4H
TABL /AIF/STD_IDX_TBL will get comp. view, but has 16,7 changes/second on ref. system S4H

• The two tables COVRES and STXL in this example will be cloned but are very frequently changed. All clone tables have to be renamed in the phase EU_SWITCH_ZDM for which an exclusive table lock is needed.
• Followed by BKPF and /AIF/STD_IDX_TBL that will be kept as shared but new fields have to be added to the table. To hide the new fields for the bridge subsystem that runs on the source release, a compensation view is used. In the phase PARCONV_UPG, the fields will be added. Similar to renaming a table, the alter table statements also requires an exclusive lock in the table.
• Such findings are similar to the category cloned tables, more a heads-up than a real error.