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 searches the specified 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 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 this App by making sure that performance history data is available for the ‘Performance History’ RFC Destination. See the ‘Prerequisites’ section below for details.

Prerequisites

The App requires RFC Destinations for the current (As-Is) and target (To-Be) SAP HANA systems, and an RFC Destination for the system from which to obtain performance history data. It also requires access to the Test Repository to be searched to find test assets that match impacted used standard code.

The ‘Heal Tests’ functionality of the App supports Tosca Test Repositories only, and requires Tosca version 13.3 or above.

Before running the SAP HANA Upgrade Analysis App for the first time, you will need to make sure that performance history data is available on the RFC Destination selected for the ‘Performance History’ 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 Retrieving Performance History Data help topic for details.

DevOps Categories

Development, Testing.

Running the App

To run the SAP HANA Upgrade Assessment App, select the App from the ‘Apps’ screen and create an App variant. Complete the Variant screen fields as follows:

SAP Systems

Set the ‘As-Is’ field to the RFC Destination for the As-Is HANA system.
Set the ‘To-Be’ field to the RFC Destination for the To-Be HANA system.
Set the ‘Performance History’ field to the RFC Destination for the system from which performance history data has been obtained.

SAP Test Integration

Set the ‘Test Repository’ field to the Test Repository to be searched to find matching test assets.
Set the ‘Test Search Paths’ string list to limit the search for test assets to one or more project folders in the specified Test Repository. Each path should begin with the Subject folder, and a backslash (\) should be used to separate path components, for example Subject\Release1.
Set the ‘Create test execution?‘ switch to specify whether the matching test assets will be used to create test execution lists in the specified Test Repository. The test execution lists will be stored in a time-stamped folder named LiveCompare_<YYYY-MM-DD HH:MM:SS>.
Set the ‘Execution Name‘ field to the name of the test execution to create. If this parameter is not set, a time-stamped name of the form LiveCompare_<YYYY-MM-DD HH:MM:SS> is used as the default.
Set the ‘Execution Path‘ field to the path of an existing folder in which to store the test execution, for example Execution/TestExecutions. If this field is not set, the test execution will be created in the default Executions folder.
Set the ‘Execute tests?‘ switch to specify whether test execution lists will be run in the specified Tosca Test Repository. If this switch is set to ‘Yes‘, the ‘Create test execution?‘ switch should also be set to ‘Yes‘. Executing tests requires Tosca to be configured using ‘DEX’.
Set the ‘Create test requirements?’ switch to specify whether test requirements will be created for matching test assets that do not already have requirements in the specified Tosca, qTest or ALM Test Repository. Requirement names have the format LiveCompare_Most-at-risk_Gaps <YYYY-MM-DD HH:MM:SS> <Object Name - Object Description>.
Set the ‘Requirements Path’ field to the name of the root requirements folder to be used in the specified Tosca Test Repository. If this field is not set, ‘Requirements’ is used as the default.

Heal Tests

Set the ‘Create test requirements?’ switch to specify whether the App will identify sick modules and test case in the specified Tosca Test Repository.
Set the ‘Modules Root Path’ field to the path of the root Modules folder in the specified Tosca 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 specified Tosca 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 Smart Impact 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 programs and transactions that depend on SAP objects with significant differences on the As-Is and To-Be systems. Each used transaction or program is listed (in the TCODE or PROGRAM column), followed by the SAP object that impacts it (in the OBJECTTYPE and OBJECTNAME columns), and the comparison status of the impacting object on the As-Is and To-Be systems. The impacting object name is shown as a hyperlink which allows a detailed comparison report to be displayed. The user who last changed the program or transaction 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 upgrade (in the TYPE and NAME columns), and the objects that impact them (in the FOUND_TYPE and FOUND_NAME) columns. The search depth at which each impacting object was found is also shown.

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

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.

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.

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.

Standard

This spreadsheet lists used standard programs and transactions on the As-Is system that will be impacted by screen 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 CHANGE score for a program or transaction is calculated as follows:

(Different + In1 + In2) / Total number of component screens * 100

In1 is the number of component screens that exist on the As-Is system only. In2 is the number of component screens that exist on the To-Be system only. Different is the number of component screens that are different on each of the systems.

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 score as follows:

FREQUENCY = min(5, max(0, length(USAGE) – 1))

DAMAGE =

0 if CHANGE is less than 10.
1 if CHANGE is between 10 and 29.
2 if CHANGE is between 30 and 49.
3 if CHANGE is between 50 and 69.
4 if CHANGE is between 70 and 89.
5 if CHANGE is greater than 90.

WEIGHT = FREQUENCY + DAMAGE

RISK =

L if WEIGHT is between 0 and 7.
M if WEIGHT is equal to 8 or 9.
H if WEIGHT is equal to 10.

The Standard report allows you to verify which standard SAP programs have had user interface changes introduced, and helps to provide an idea of the testing resources required for the upgrade. The report should be broken down by Application Area and given to the appropriate Functional Leads to review.

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

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.

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