Developer Impact Analysis

The Developer Impact Analysis workflow performs an impact analysis for developer changes on the specified SAP system. Transportable tasks are obtained from the E070 table on the analysis system; these provide the set of changing objects to be used by the analysis.

The workflow generates an Excel report which is emailed to the specified recipients. The report includes:

  • The objects, screens and users impacted by each changing object. A maximum of 10 impacted objects are reported for each changing object.

  • The most-at-risk objects that are recommended for testing.

A code quality analysis is performed for each impacted object that has associated ABAP code. If any impacted objects have ABAP Unit Tests in the specified system, the ABAP Unit tests are run, and their results are included in the workflow’s Excel report.

The workflow should be scheduled to run periodically. During each run, an Impact Analysis is performed for the transportable tasks from the analysis system that have not yet been processed.

By default, the Developer Impact Analysis workflow reports the following object types as used, impacted or most-at-risk.

Object Type Description
CLAS Class
FUNC Function Module
IDOC IDoc
PROG Program
SSFO Smart Form
TCOD Transaction
WAPA BSP Application

However, a user with Administrator privileges may customize these defaults as follows.

  1. Select the Administration > Configuration > Impact Analysis folder in the LiveCompare hierarchy.

  2. In the TypesToFind section, deselect the object types to be excluded from the used, impacted and most-at-risk results. Note that if no items are selected, all the above object types will be used as the default.

  3. Click ‘Save’ to save your changes.

These changes affect all subsequent runs of the Developer Impact Analysis workflow, but they do not affect any existing workflow results.

The workflow populates the Developer chart in the LiveCompare Dashboard.

Prerequisites

The workflow requires access to RFC Destinations for an Analysis system to which developer changes will be submitted, and a Performance History System from which performance history data will be retrieved.

The Create Object Links Cache workflow from the Prerequisites templates folder should be run to create an Object Links Cache database for the Analysis system.

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

The ChangingObjectsToIgnore External Data Source removes tables whose names begin with ENH or AGR from the set of changing objects. If required, these External Data Sources may be edited in the LiveCompare Studio using the ‘Replace Data File’ option.

LiveCompare should be configured to send emails. See the Integrating LiveCompare with your Email System section of the LiveCompare Installation and Configuration Guide for details.

Preparing the Workflow

The Developer Impact Analysis workflow should be run in a separate workspace for each system to be analyzed. To prepare the Developer Impact Analysis workflow, carry out the following steps.

  1. Create a new workspace whose name reflects the system to be analyzed, for example DIA - <Analysis System>.

  2. Select the Templates > Impact Analysis > Developer Impact Analysis template in the LiveCompare hierarchy and choose ‘Copy to Workspace’ from the context menu.

  3. Select DIA - <Analysis System> as the target workspace, and click Copy. A number of dependent templates will also be copied.

  4. Copy the Templates > Impact Analysis > Initialize Task Store workflow to the DIA - <Analysis System> workspace.

  5. If required, configure the Initialize Task Store workflow to set the date from which to retrieve developer tasks. See the template’s help file for details.

  6. Run the Initialize Task Store workflow in the DIA - <Analysis System> workspace.

Select the Developer Impact Analysis workflow in the DIA - <Analysis System> workspace, and configure the workflow as follows.

  1. Set the Analysis System RFC Destination parameter to the RFC Destination for your Analysis system.

  2. Set the Performance History System RFC Destination to the RFC Destination for the system from which performance history data has been obtained.

  3. Set the Comparison System RFC Destination to the RFC Destination for the system on which to compare the most-at-risk executables.

  4. Set the Compare Changing Objects? Boolean parameter to specify whether the most-at-risk executables will be compared on the Analysis and Comparison systems.

  5. Set the Email To String List parameter to a list of email recipients for the Developer Impact Analysis report. Each email address should be stored a separate string entry.

  6. Set the From String parameter to the EmailFromAddress value stored LiveCompare’s Configuration – Email screen. You may need to check this setting with a LiveCompare Administrator.

Scheduling Workflows

  • The Developer Impact Analysis workflows should be run using a schedule. The following workflows will need to be scheduled. To schedule a workflow, select it in the LiveCompare hierarchy and choose ‘Schedule Run’ from the context menu.

Create Object Links Cache

This workflow should be copied from the Prerequisites templates folder to each of your DIA - <Analysis System> workspaces. It should be configured to create an Object Links Cache database for the analysis system and then scheduled to run once each week. If possible, the workflow should be scheduled to run when no developer tasks are being performed on the analysis system (for example, outside office hours).

Developer Impact Analysis

This workflow performs an impact analysis for the most recent set of transportable tasks submitted on the Analysis system, and sends report links to the specified email recipients. It should be scheduled to run as required on a daily basis, for example several times each day, depending on how frequently you wish to review the impact analysis reports.

Workflow Results

The Developer Impact Analysis workflow generates an Excel report which includes the following spreadsheets.

Home

This spreadsheet lists changing objects (in the CHILD_TYPE and CHILD_NAME columns) and their associated task IDs and change types. Changing objects that do not impact other objects are also included. The UNIT_TESTS column is set to Y for changing objects that have associated ABAP unit tests.

The IMPACTED_OBJECTS column displays the number of impacted objects for each changing object. Click a link in this column to display the impacted objects in the Impacted Objects spreadsheet.

Click a hyperlink in the CHILD_NAME column to display an Object Differences report for the selected object.

Impacted Objects

This spreadsheet lists used impacted objects in the NAME and TYPE columns, and the objects that impact them in the CHILD_TYPE and CHILD_NAME columns. Details for the used impacted objects are listed in the DESCRIPTION, APP_AREA and DEVCLASS columns.

For each used impacted object:

  • The DYNP column lists the number of impacted screens for the object in the most-at-risk results. Click a hyperlink to display the object’s screens in the Impacted DYNPs spreadsheet.

  • The USAGE column lists the object’s usage count according to the available performance history data.

  • The USERS column lists the number of users of the object according to the available performance history data. Click a hyperlink to display the object’s users in the Impacted Users spreadsheet.

  • The CUSTOM column is set to ‘Yes’ for custom used objects.

  • The MAR column is set to ‘Y’ for impacted objects that are most-at-risk and recommended for testing. Each changing object will have no more than one most-at-risk executable. The BUSINESS_CRITICAL column is set to ‘Y’ for Business Critical executables, and to <blank> for objects that are not identified as Business Critical.

Impacted DYNPs

This spreadsheet lists each used object and its associated screens (including each screen’s descriptive text). If a hyperlink is selected in the Impacted Objects spreadsheet’s DYNP column, the Impacted DYNPs spreadsheet lists the used object’s associated screens.

Impacted Users

This spreadsheet lists each impacted object, and its usage count for each user according to the available performance history data. If a hyperlink is selected in the Impacted Objects spreadsheet’s USERS column, the Impacted Users spreadsheet lists the users of the associated object.

Unit Tests

This spreadsheet lists impacted objects with ABAP Unit Tests, and each Unit Test’s class and method. The TEXT column stores a description of the Unit Test’s result. The FAILURE, EXCEPTION, RUNTIME and WARNING columns indicate the number of failed tests, and the number of tests that generated exceptions, runtime errors or warnings.

Rule Break Summary

This spreadsheet provides a summary of the quality rules that were triggered for each impacted object with associated ABAP code.

Rule Break Detail

This spreadsheet provides details for each impacted that triggered one or more quality rules. The results are filtered so that only rules in the Error class are shown. In this spreadsheet:

The LINE_NUMBER column stores ABAP source code line number in which the violation was detected. For Web DYNPRO (WDYN) objects, methods are stored in include files, and the line number refers to the position of the source code line within its method. For other object types, if the INCLUDE column for the violation contains a value, the line number refers to a line in the INCLUDE file.

The SEQ column stores the ABAP source code line number in which the violation was detected. For Web DYNPRO (WDYN) objects, this column refers to a line number in the object’s INCLUDE file. This column may be used when sorting the Rule Break Detail dataset to display the violations for each object ordered by line number.

Test Data

This spreadsheet is not used.

Help

This spreadsheet provides help for each of the spreadsheet reports.

Running Developer Impact Analysis with the Smart Impact App

If the Developer Impact Analysis workflow is scheduled to run at the same time as the Smart Impact App, there may be a delay while the Smart Impact App updates an object link cache database that is required by the Developer Impact Analysis workflow.

To resolve this, a second RFC Destination that refers to the same SAP analysis system may be created in LiveCompare. The first RFC Destination may be used with the Developer Impact Analysis workflow, and the second RFC Destination may be used with the Smart Impact App.