SAP HANA Upgrade Analysis app

The SAP HANA Upgrade Analysis app performs an upgrade assessment for HANA to HANA version upgrades. It produces an overall project-level Dashboard report, and detailed reports to help with the following.

Fixing impacted custom code.
Prioritizing standard SAP testing.
Surfacing vulnerable integration points.

The app uses a Pipeline, and searches the specified Most-at-risk Search Test Repository to find test assets that match impacted used standard code. These may be used to create test executions or test requirements. Optionally, the app may be used to identify ‘sick’ test cases and modules in the specified Most-at-risk Search Test Repository. If the app’s Heal tests? switch is on:

Modules that refer to SAP screens that are different in the As-Is and To-Be SAP systems are stored in a virtual folder named Sick Modules - <timestamp>.
Test Cases that refer to one or more sick modules are stored in a virtual folder named Sick TestCases - <timestamp>.

A user with LiveCompare Editor privileges must prepare the app by making sure that performance history data is available for the Pipeline’s Usage System. See the ‘Prerequisites’ section below for details.

Prerequisites

The SAP HANA Upgrade Analysis app uses a Pipeline to identify:

The As-Is, To-Be and Usage systems to be used in the analysis.
One or more Most-at-risk Search Test Repositories that will be searched to find test assets that match impacted standard code.
A Most-at-Risk Gaps Test Repository, in which test requirements are to be created for most-at-risk objects that do not have matching test assets in the specified search Test Repository.

Before the SAP HANA Upgrade Analysis app is run, you must create a Pipeline that includes the appropriate systems. In the Pipeline:

The Analysis System field stores the RFC Destination for your As-Is system.
The Comparison System field stores the RFC Destination for your To-Be system.
The Usage System field stores the RFC Destination for your Performance History Data system.
The Most-at-risk Search Test Repositories fields store the Test Repositories that will be searched to find test assets that match impacted standard code. Each Most-at-risk Search Test Repository may have one or more search paths to limit the folders that are searched. Each path should begin with the Subject folder, and a backslash (\) should be used to separate path components, for example Subject\Release1.
The Most-at-risk Gaps Test Repository field stores the Test Repository in which to create requirements for most-at for most-at-risk objects that do not already have requirements in the Tosca, qTest or ALM Most-at-risk Search Test Repositories. Requirement names have the format LiveCompare_Most-at-risk_Gaps <YYYY-MM-DD HH:MM:SS> <Object Name - Object Description>.
The Requirements Path field the name of the root requirements folder to be used in the specified in the specified Tosca Most-at-risk Gaps Test Repository. If this field is not set, ‘Requirements’ is used as the default.
The Most-at-risk Hits Execution Test Repositories fields store the Test Repositories in which execution lists are to be created. For each most-at-risk hits execution Test Repository:
- Set the Execution Name field to the name of the test execution folder in which execution lists are to be created.
- Set the Execution Path field to the to the path of an existing Test Repository folder in which to store the test executions, for example Execution/TestExecutions. If this property is not set, the test execution will be created in the default Executions folder.
- Set the Execution List Path field to the path of an execution list to reuse when creating Tosca test executions, for example, Execution/MyTests/LiveCompare_2023-01-31 09:47:17/MyExecutionList.
- Set the Options field as appropriate to either create test runs, or to create and run test runs. Executing tests requires Tosca to be configured using DEX.

The ‘Heal Tests’ functionality of the app supports Tosca Test Repositories only, and requires Tosca version 13.3 or above. Note that only the first Tosca Most-at-risk Search Test Repository is searched to find sick modules and test cases.

Before running the SAP HANA Upgrade Analysis app for the first time, you will need to make sure that performance history data is available for the RFC Destination set as the Pipeline’s Usage System. Select the RFC Destination in the LiveCompare hierarchy and click the PHD tab. Select the source for performance history data, and if necessary the number of months of data to retrieve, then click ‘Update Data’. The performance history data may also be retrieved using a schedule. See the Retrieve performance history data help topic for details.

DevOps categories

Development, Testing.

Run the app

To run the SAP HANA Upgrade Analysis app, select the app from the Apps screen and create an app variant. Complete the Variant screen fields as follows:

Set the ‘Pipeline’ field to the Pipeline that includes your RFC Destinations and Test Repositories.

Heal Tests

Set the ‘Heal tests?’ switch to specify whether the app will identify sick modules and test cases in the specified Tosca Test Repository.
Set the ‘Modules Path’ field to the path of the root Modules folder in the Pipeline’s first Tosca Most-at-risk Search Test Repository. This is set to ‘Modules’ by default.
Set the ‘Test Cases Path’ field to the path of the root Test Cases folder in the Pipeline’s first Tosca Most-at-risk Search Test Repository. This is set to ‘TestCases’ by default.

Click ‘Run’. When the variant has completed, its results may be accessed from the App Cockpit screen.

App results

The SAP HANA Upgrade Analysis app generates a Dashboard report which includes the following charts.

Development - Fix your Custom Code

The Impacted Custom by Devclass doughnut chart summarizes the custom code objects impacted by the by upgrade, grouped by Development Class.
The Top BDC Transactions doughnut chart summarizes the top 5 BDC transactions from the As-Is system. For each transaction, the values indicate the number associated programs using either CALL TRANSACTION or CALL DIALOG statements.
The Impacted ENHO summary doughnut chart lists enhancement implementations impacted by the upgrade. The values indicate the number of impacting objects for each enhancement implementation.

Testing - Impacted Standard SAP

The Transactions vs Programs doughnut chart summarizes the standard SAP objects impacted by the upgrade, listing the number of impacted transactions and executable programs.
The Executables by Risk column chart groups the impacted executables by their risk category, either High, Medium or Low. The risk categories are calculated based on each object’s usage and percentage change value in the As-Is and To-Be systems.
The Test Coverage by Risk chart indicates the test coverage for each risk category. Hits are executables that have a matching test in the specified Test Repository. Gaps are executables that do not have a matching test in the specified Test Repository.

Integration - In Scope IDocs

The Standard v Custom IDOCs doughnut chart summarizes the standard and custom IDOCs impacted by the upgrade.
The Top Standard Segments doughnut chart lists the top 5 standard IDOC segments impacted by the upgrade. The values indicate the number of IDOC segments.
The Top Custom Segments doughnut chart lists the top 5 custom IDOC segments impacted by the upgrade. The values indicate the number of IDOC segments.

The Dashboard report also includes links to the following reports:

Development Report

This report includes the following spreadsheets.

Help

This spreadsheet provides help for each of the spreadsheet reports.

Impacted~Top Down

This spreadsheet identifies used custom executables that depend on SAP objects with significant differences on the As-Is and To-Be systems. Each used object is listed in the TYPE and NAME columns, and its usage count according to the available performance history data is listed in the USAGE column. The SAP object that impacts each custom executable is listed in the CHILD_TYPE, CHILD_NAME and CHILD_DESC columns. The impacting object name is shown as a hyperlink which allows a detailed comparison report to be displayed.

The comparison status of the impacting object on the As-Is and To-Be systems is shown in the STATUS column, followed by the custom executable’s Application Area description and Development Class. The user who last changed the custom executable is also shown.

Impacted~Bottom Up

The Impacted~Top Down and Impacted~Bottom Up reports list the impacted programs, functions, includes, structures and tables called by your used custom programs. It is important to understand how these objects will respond to the custom programs in the upgraded system.

Impacted Enhancements

This spreadsheet lists the enhancement implementations impacted by the used objects on the Performance History system (in the TYPE and NAME columns), and the objects that impact them at a search depth of either 1 or 2 (in the FOUND_TYPE and FOUND_NAME) columns. Click a hyperlink in the FOUND_NAME column to display a comparison report for the impacting object on the As-Is and To-Be systems.

BDC

This spreadsheet identifies custom objects that call SAP transactions using the CALL TRANSACTION statement, or dialog modules using the CALL DIALOG statement. Each CALL TRANSACTION or CALL DIALOG statement is shown, along with its line number in the source code, and the name of the called transaction or dialog module. The VARIABLE column is set to Y for transactions or dialog modules that are called using a variable.

This report shows that custom code can be dramatically affected by an upgrade. Standard SAP transactions are used by custom code. If a standard SAP transaction is changed following an upgrade, then the custom code that uses it will be affected and may fail at runtime.

Screens

This spreadsheet lists the screens that are different in the As-Is and To-Be systems, or that are present in one system only. The screen’s associated program is also shown. Click a hyperlink in the MODULES column to list any test modules that refer to the screen in the specified Test Repository. Click a hyperlink in the SCREEN_NUMBER column to display a comparison report for the screen on the As-Is and To-Be systems.

Sick Modules

This spreadsheet list modules in the specified Test Repository that refer to screens with significant differences on the As-Is and To-Be systems. The screens are either different in each system or present in one system only. The report includes the module ID, module name and module path from the specified Test Repository.

SPAU and SPDD

This spreadsheet identifies SAP objects on the As-Is system that have been modified, and are included in one or more imported support packs or transports. This report should be reviewed to identify support pack or transport objects that may need to be tested following an upgrade.

ADJUST_TYPE = SPDD: These objects have a type of ENQU, SHLP, TYPE, INTF, TABL, VIEW, DOMA, DTEL or TTYP. They may need to be adjusted using transaction SPDD.
ADJUST_TYPE = SPAU: These objects have types other than those where ADJUST_TYPE is equal to SPDD. These are repository (ABAP) objects that may need to be adjusted using transaction SPAU.

Click a hyperlink in the OBJ_NAME column to display comparison details for the selected object on the As-Is and To-Be systems.

Modified SPAU and SPDD objects will be reported in subsequent runs of the SAP HANA Upgrade Analysis app depending on how the SPDD and SPAU objects were changed:

If the objects were reset back to the original, they will not appear in future reports.
If the objects were kept and modified, they will continue to appear in future reports.

System Info

This spreadsheet includes details for the As-Is, To-Be and Performance History systems used in the analysis.

Testing Report

This report includes the following spreadsheets.

Help

This spreadsheet provides help for each of the spreadsheet reports.

Home

This spreadsheet lists used programs, transactions and BSP Applications on the As-Is system that will be impacted by screen and child object changes on the To-Be system following an upgrade. The report list each used program and transaction, with its usage count and percentage change score that is based on a comparison of its component screens. The CUSTOM column is set to Y for executables identified as custom according to the naming patterns used by the app.

The RISK column indicates the risk category assigned to each change, either L (Low), M (Medium) or H (High). It is calculated based on an object’s USAGE and CHANGE values.

Test Hit Details

This spreadsheet lists the used standard SAP objects that are impacted by the upgrade and have matching tests in the specified Test Repository. The matched token is listed, along with the matching test name and test path.

Sick Modules

This spreadsheet lists modules in the specified Test Repository that refer to screens with significant differences on the As-Is and To-Be systems. The screens are either different in each system or present in one system only. The report includes the module ID, module name and module path from the specified Test Repository.

System Info

This spreadsheet includes details for the As-Is, To-Be and Performance History systems used in the analysis.

Integration Report

This report includes the following spreadsheets.

Help

This spreadsheet provides help for each of the spreadsheet reports.

IDOCs

This spreadsheet helps to identify where customizations made to standard or custom IDOCs on the As-Is system may need to be applied to the To-Be system following an upgrade. This may be the case if SAP has made changes to the same IDOC as part of the upgrade release. The ORIGIN column indicates whether each IDOC is standard or custom.

IDOCs are made up of one or more segments, which are implemented as structures in SAP. The report lists the standard and custom IDOCs on the As-Is system, and the results of comparing their standard structures with the corresponding structures on the To-Be system. Click a hyperlink in the SEGTYP column to display the comparison details.

The IDOCs report should be provided to the Developers and Functional Leads assigned to the upgrade project. The leads should review the reports and check any IDOC segments with a comparison status of ‘Different’.

System Info

This spreadsheet includes details for the As-Is, To-Be and Performance History systems used in the analysis.

Obsolete Fiori Apps Report

This report lists used Fiori apps from the As-Is system that are not included in an External Data Source of current Fiori apps, obtained from S/4 HANA release 2021 FPS 01. The ID, name and type of each obsolete Fiori app is shown, as well as the number of users of the app, its top user, and its usage count according to the available performance history data.

Analysis Input Data

This Excel report contains a copy of the input parameters used to produce the app’s Dashboard report. The value of each input parameter is stored in a separate worksheet, which is named after the parameter whose value it contains.

Standard apps