Executing Impact Analysis to Determine Potential Restrictions for Business

Objectives

After completing this lesson, you will be able to:

  • Analyze the output of Impact Analysis
  • Work with best practices for Impact Analysis
  • Interpret the results of Impact Analysis

Execution of Impact Analysis

This section shows how the Impact Analysis is executed.

One technical prerequisite of running the Impact Analysis is the completion of phase RUN_RSPTBFIL_ZDM_CLASSIFYThe evaluation can only be called when this phase has been passed.

The Impact Analysis of SUM has two different modes:

  • Batch mode in SUM phase RUN_IMPACT_ANALYSIS_ZDO
  • Dialog mode using SUM Toolbox: as part of the SUM Toolbox (transaction SUMTOOLBOX), the tool Impact Analysis is delivered

The results of the Impact Analysis in both modes of course are identical as long as the same ZDIMPANA.ZIP file is used as foundation for the analysis. However, the dialog version in SUM Toolbox generates the output in an easy to consume ALV grid which can be also downloaded into a spreadsheet.

Batch Mode in SUM Phase RUN_IMPACT_ANALYSIS_ZDO

As part of the SUM upgrade procedure, the report RSUPG_RUN_IMPACT_ANALYSIS is called in phase RUN_IMPACT_ANALYSIS_ZDO on the shadow instance. This phase uses the file ZDIMPANA.ZIP stored in the directory SUM/abap/save.

If the file cannot be found, phase RUN_IMPACT_ANALYSIS_ZDO will stop with the following error message: A2EESUPG_IMPANA 101 Cannot open file "/usr/sap/<SID>/SUM/abap/save/ZDIMPANA.ZIP". Please provide statistics according to SAP Note "0002402270".

Note
Make sure that the file is available and the file name is spelled correctly using capital letters like ZDIMPANA.ZIP.

In case of any finding, SUM will stop in 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 fileIMPANAUPG.<SID> can be found in the SUM/abap/log directory.

Hint
If SUM fails in phase RUN_IMPACT_ANALYSIS_ZDO with errors, you can proceed with the upgrade by choosing the option "Ignore phase errors and proceed to next phase" in the UI. However, assuming that this is the first sandbox iteration, checking the finding might take some time. Hence, the technical upgrade can continue while the findings are checked and interpreted. Make sure to follow-up on every single finding shown in the Impact Analysis result. Further details can be found in later in this unit.

Dialog Mode of the Impact Analysis in the SUM Toolbox

While SUM 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 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.

File selection

Since the Impact Analysis has been moved into the SUM Toolbox, the user-interface has been harmonized, unified, and simplified. Dependent 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 SUM 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 SUM/abap/save 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 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 SUM Toolbox from a system where ZDO has been completed. The output file PUTTB_SHD.ZIP is uploaded using SAP GUI.

    b. The table statistics are uploaded using SAP GUI.

Note
Further details on the remote Impact Analysis can be found below in the section, Remote Impact Analysis.

Dialog screen

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.
Caution
All results need to be checked carefully as these findings might lead to impacts on certain business processes during productive operations on the bridge subsystem.

Results shown in the ALV grid

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 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 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 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.

Remote Impact Analysis

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 SUM 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 SUM 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 not the latest version of SUM Toolbox was applied prior the ZDO upgrade procedure in the sandbox system.

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

Execute the Dialog Report of the Impact Analysis

Select Start Exercise to start the simulation.

Steps

  1. Log on to the sandbox system that is currently being upgraded using ZDO.

    1. Log on to the system with user DDIC_DEV. The password is already pre-filled.

  2. Start the Impact Analysis in SUM Toolbox.

    1. Enter transaction code SUMTOOLBOX in the transaction box.

    2. Double-click on the tool Impact Analysis in the navigation tree on the left hand side of the interface.

  3. Select the table statistics file from the local drive.

    1. Select the pencil button next to the input field Table statistics to open the file picker.

    2. Select the file ZDIMPANA - ADM330 - Demo.ZIP.

      Hint
      The table statistics file used by SUM has to follow the naming convention ZDIMPANA.ZIP. If you use the dialog report, the ZIP archive can have any file name.
  4. Start the Impact Analysis based on the provided input.

    1. Choose the Execute button to start the Impact Analysis.

    2. 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.

  5. Check the different sections in the output screen.

    1. File Selection: In this section, the relevant data to run the Impact Analysis is provided.

    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.

    4. Impact Analysis Findings: It summarizes and aggregates the issues. Furthermore, it 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.

Best Practices to Run the Impact Analysis

This section offers best practices for running Impact Analysis during a Zero Downtime Option (ZDO) project.

The Impact Analysis as part of SUM that runs in batch mode in phase RUN_IMPACT_ANALYSIS_ZDO evaluates one single data set provided with the file, ZDIMPANA.ZIP. However, it has been shown that it is beneficial to run the Impact Analysis with different timeframes to compare the results across multiple weeks.

This helps to identify tables that might be irrelevant or uncritical for the time when the upgrade is planned to run in the production system. Some tables that are set to read-only by the table classification might be used only for a single business process which likely does not run every day. The access to the table could also have happened by the import of a transport. In order to figure that out, it is highly recommended to run the dialog version of the Impact Analysis in SUM toolbox with different table statistics.

In the productive system, run the tool Export data for Impact Analysis in SUM Toolbox several times to download statistics of several weeks. Of course, you could also go on daily or even monthly level. However, the recommended aggregate is weekly data as this represents mostly the time when the bridge subsystem is used by business users.

Hint
Make sure that the system passed phase RUN_RSPTBFIL_ZDM_CLASSIFY already as this phase calculates the table classification result required by the Impact Analysis.

On the selection screen, keep the default selection for the table classification data, which retrieves the classification information from the local system table of the system which is upgraded using ZDO. Use the F4 help for the table statistics to upload the first exported table statistics file. In this example, four files have been exported earlier: ZDIMPANA_CW10.ZIP, ZDIMPANA_CW11.ZIP, ZDIMPANA_CW12.ZIP, and ZDIMPANA_CW13.ZIP. Re-run this step for each ZIP file and capture the output as screenshots and optionally also in a spreadsheet.

Based on the screenshots above, it might be not as easy to identify so-called false positive results. These are findings that are not shown up in every Impact Analysis result as some business processes change the table but are not run on a regular basis. To drill down into these entries, it is recommended to copy and paste the results into a spreadsheet.

Note
Create a new spreadsheet with the columns week, category, long text, and table name. Fill in the week manually. The remaining three columns will be filled by copy and paste from the SAP GUI output.

By creating a pivot table on top of the consolidated table that contains all four weeks, it becomes easier to identify potential tables like the table marked in red: T778L is a customizing table (Languages Supported in HR-PD) that will be read-only during the bridge run time. However, only CW12 contains this finding which points out that it correlates with a business process that probably runs only during the last weekend of the month (that is, 3/27/2022).

Note
Interpreting the results of the Impact Analysis is a very crucial and important task for a successful ZDO project.

Results of the Impact Analysis

This section contains recommendations for working with the result of Impact Analysis.

The results of the Impact Analysis are grouped by category and severity.

  • Category
    • Read-only: The most critical and important category that 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.
    • Cloned: This category informs 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 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 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, all entries marked with severity green are hidden from the result list. To show these entries as well, select the green icon in the menu bar next to the result list.
    • Orange: No immediate action needs to be taken as it just 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.
Note
All findings must be checked in detail. It is highly recommend to re-run the Impact Analysis with different table statistics. Additionally, consider to run the Impact Analysis in each cycle of your ZDO upgrade project. The Impact Analysis as a technical tool does not replace the functional validation in a non-productive system.

In the next section, typical examples will be analyzed and interpreted. Of course, these findings will not show up all in one upgrade. The findings described below are just examples. The result of the Impact Analysis are highly individual based on the source and target release of the upgrade.

Tables Set to Read-only

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, it will 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).

Code snippet
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
Expand
  • 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.
Caution
A finding, as described for table EKET, should be forwarded and checked with the application developers from SAP. For this, create a support incident using SAP ONE Support Launchpad for the respective application component.

Database Triggers

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.

Code snippet
TABL STXL SLT replication has to be paused or suspended before rollover to bridge (REQ_USER_ROLLOVER_PREP)
Expand
  • 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 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.
Code snippet
TABL STXL SLT replication requires initial reload after rollback (REQ_USER_ROLLBACK_FINAL)
Expand
  • 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.

Cloned Tables

Code snippet
TABL STXL will be copied, but has size of 153,005 GB on ref. system S4H
Expand
  • 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.

Smart Switched and Compensation Viewed Tables

Code snippet
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
Expand
  • 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 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 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.

Log in to track your progress & complete quizzes