It can be difficult to comprehensively analyze and evaluate the complexity of standard software, enhancements, and custom developments of a mature IT system landscape using simple methods, such as tools that compare coding. The Custom Development Management Cockpit (CDMC) can provide this information and contribute toward your control over the growth and impact of custom code during an SAP code change, such as an upgrade. The CDMC is included in SAP Solution Manager 7.0 as part of the Support Tools Plug-in (ST-PI) since January 2009. To use the CDMC, you need to install ST-PI 2008_1 on all systems that are relevant for the analysis.

Upgrades and solution transition events usually have an impact on custom code. The user needs support to estimate, plan, prioritize, and effectively allocate the development efforts for upgrades and code changes. The CDMC can effectively support this process. To implement it, you need to complete several operational tasks, including change impact analysis.

How CDMC Works

The CDMC supports the upgrade process. After you perform the necessary prerequisites, you can perform the clearing and the change impact analysis that are both contained in the CDMC (Figure 1).

Figure 1

Functions of the CDMC analysis phases in detail

The clearing analysis helps you identify all SAP objects that custom repository objects use. You need to check these objects to ensure they are really obsolete. If so, you can delete them using SAP’s How-to Guide for Clearing. For the remaining objects, the change impact analysis classifies every SAP object on the basis of the impact level of change. Subsequently, you need to classify every custom object based on its relationship to the SAP objects affected by changes (Figure 2).

Figure 2

Steps of an upgrade change impact analysis (A system is the analysis system, R system is the reference system)

Take these four major steps to identify the impact of changes for custom developments (Figure 3):

1. Identify all SAP objects used by custom repository objects
2. Classify every SAP object on the basis of the impact level of change
3. Classify every custom object based on its relationships to SAP objects affected by the changes
4. Provide the impact for each custom object

You can also execute the upgrade change impact analysis without a prior clearing analysis, but it makes more sense to determine the impact of changes only for objects that are actually used.

Preparation

To use CDMC, refer to SAP Note 1318148 (SAP Custom Code Change Impact Analysis – Preparation), which contains preparation tasks that ensure the tool works correctly. You should apply the necessary corrections outlined in the note and ensure the ST-PI is in the correct version. The following notes contain other corrections you should apply:

• SAP Note 1348772 (CDMC Corrections - Composite SAP Note) 
• SAP Note 1456166  (Collective Note with all corrections for CA & UCIA in CDMC)

If transaction SMSY (maintain landscape) is maintained, the solution landscape along with the required Remote Function Call (RFC) connection should be available and checked for correctness. Otherwise, use transaction SM59 to create RFC connections. The statistical data from transaction ST03N on the productive system needs at least the most recent three months’ data or ideally the complete year. The expected effort to start the analysis (prerequisites fulfilled) is one day, while the expected effort to have the final results available is two days.

Global Settings in CDMC

Launch the CDMC with transaction CNV_CDMC. When you start the tool, the first thing to do is to go through the Global Settings in the CDMC Menu on the left side of the screen. Execute the Activate Statistics collection entry by clicking the execute icon next to Activate Statistics Collection in the Global Settings branch (Figure 3) or by clicking the Activate Statistics button in the toolbar.

Figure 3

Global settings for clearing and upgrade/change impact analysis

Select the relevant RFC destination for the productive system. Select an RFC destination that connects to the system with a user that has the correct authorizations as outlined in the preparation notes to collect the statistics from transaction ST03N (Figure 4). The collected data serves as the basis for the subsequent clearing analysis activities.

Figure 4

Statistics collection

For the change impact analysis, you have to maintain the average adjustment times for every customer object type. This is done by clicking the execute icon next to Maintain Adjustment Times in the Global Settings or by clicking the Maintain Adjustment Times button. There are no predefined values because the time it takes to adjust a specific object type is dependent on the development resources available. The times can be chosen for each object type individually (Figure 5) — for instance, one hour for Data Elements and four hours for programs. These times then appear on the result list and can be added together to create a first effort estimation for the adjustments necessary during the upgrade.

Figure 5

Maintain adjustment times

To create a clearing/usage analysis project, select the Clearing Analysis Projects branch in the CDMC Menu and click the create icon (Figure 6). A CDMC project is identified by a unique five-digit number that can be chosen by the person creating the analysis.

Figure 6

Create a CDMC project

Once the project is created, you can access it to obtain a set of action items that are grouped in a similar way as the SAP IMG. The following steps are involved in a clearing/usage analysis:

1. Project settings
2. Data collection
3. Analysis
4. Display results

5. Clearing

Project Settings

The first and most important step of a clearing project is the landscape setup. It is imperative that you correctly set up the landscape because you cannot make changes to it after the data collection has been started. For a clearing analysis, three types of systems are necessary (Figure 7):

• Statistics system
• Analysis system
• Control system

The control system is SAP Solution Manager. It serves as a central system to control all the activities and gather the results. While the analysis and control systems are also needed for the change impact analysis, the statistics system is for the one that is specific to the clearing analysis.

Figure 7

System landscape CDMC clearing analysis project

The statistics system (usually the production system) is where the collection of statistical data (e.g., executed transactions and programs) takes place. A job that is executed periodically (e.g., daily or weekly) transfers and condenses SAP standard statistics data and a short dump evaluation in a CDMC database table.                                 

The analysis system (usually the quality assurance system) is where all project-related analyses, including the selection of relevant objects, are performed in the background. The results are stored in a CDMC database table.                                             

The control system is where all activities in systems with other system roles such as the statistics and analysis systems are triggered via RFC connections.

Data Collection

The data collection phase has three activities:

1. Determine customer objects
2. Determine SAP modifications
3. Import statistics

The first step is to determine which objects in the analysis system are in the customer namespace. These objects are selected for subsequent analysis. The tool offers the functionality to exclude specific development packages. The second step determines which SAP standard objects have been modified. These objects are then selected for subsequent activities. The third data collection step imports the statistic data gathered from transaction ST03N in the statistics system.

Analysis

A clearing analysis is done in 11 steps. You can execute all of the activities under Analysis by clicking the execute icons next to them (Figure 8). The system then automatically performs the activities. You can monitor them by clicking the Activity Log icon next to the status indicator of the activity. You cannot see the final results of the analysis until the analysis has been confirmed.

Figure 8

Phases and steps of the clearing analysis

Step 1. Duplicate domains. The system finds duplicate domains in the customer namespace. A domain is considered a duplicate if one of the following statements applies to it:

• An SAP standard domain with the same attributes exists
• Another custom domain with the same attributes exists
• An SAP standard domain and another custom domain with the same attributes exist

This activity takes place in the analysis system. Domains are important to ensure consistency of field information. Having more than one domain for a given purpose may lead to confusion, unnecessary work, and data inconsistencies.

Step 2. Determine empty databases (empty customer tables). The number of entries in all the custom tables is determined in the statistics system. Tables with few or no entries are very unlikely to be in use. This activity scans all customer tables in the statistics system and does not depend on data collected in the data collection step of the project.

Step 3. Syntax check: In this activity, the statistics system is searched for custom objects that have syntax errors. A program with syntax errors is very unlikely to be in use.

Step 4. Transport frequency: This activity determines how often the selected objects have been transported. If an object has never been transported, it is likely to be not in use. A high number of transports for an object could indicate that this object contained a lot of errors requiring corrections and transports.

Step 5. Inactive customer objects: If an object does not have an active version, the object is not usable in the system. This activity lists those objects and considers the following object types: domains, data elements, database tables, structures, views, append structures, pool and cluster structures, matchcode objects, enqueue objects, search helps, table types, function modules, reports, includes, and classes.

Step 6. Extended runtime analysis: This activity provides the possibility of analyzing trace files from transaction ST12 regarding the use of customer or modified SAP objects.

Step 7. Top down analysis: This activity performs a recursive analysis of the objects that are the result of the statistics evaluation. A program analyzes the environment of these executable objects and compiles a list of all the objects they use. This is done for a number of iterations specified when starting the analysis. The default value is three. Since this is a purely static analysis, there is no information about dynamic calls such as user exits.

Step 8. Bottom up analysis: As a result of the system statistics evaluation, the system has a list of used transactions and executed reports. In this activity, a program finds out exactly where these executable objects are used and compiles a list of the relevant reports and transactions.

Step 9. Objects with no reference: The program for this activity does a where-used list check in all the analysis systems and determines the objects that do not have any reference. Objects with no reference might still be called dynamically so they cannot be considered obsolete.

Step 10. Enhancements: The system retrieves information about implemented enhancements such as user exits, Business Add-Ins (BAdIs), and business transaction events.

Step 11. Confirm analysis: When you execute this final activity by clicking the execute icon next to it, the analysis phase ends and no more activities can be executed. The system automatically transfers the data gathered in the preceding steps into SAP Solution Manager and prepares the results list.

Display Results 

After the analysis is confirmed, display the results by clicking the execute icon next to the Display Results activity (Figure 8). To better manage the results, you can display the list by development class (Figure 9).

Figure 9

Results of a clearing/usage analysis project

The results list offers a set of functions to display the results of the analysis and provides some functionality to process the results. However, it does not provide any guidance about explaining and understanding the results. One of the main questions we hear about clearing analysis is, “How many objects are obsolete?”

The results list includes used objects. This filter criterion shows all objects that are marked by the CDMC tool as used. For each marker the CDMC tool sets, you find an associated column in the list viewer. If you relate this number to the total number of objects, you can calculate the reduction in effort that the CDMC tool provides. That is because the objects that are marked as used can be excluded from further analysis. The evaluation shows which objects are obsolete and can be deleted.

It would be easy to take the results list and simply consider all objects that are not marked as used to be obsolete. However, because the analysis is purely static, dynamically called objects can be marked as unused. There may also be reports in the system for emergency situations. These are marked as unused based on the usage statistics but they shouldn’t be deleted. The bottom line here is that the results list is a base for further evaluation. The list offers a variety of standard filters you can apply to focus on specific objects for clearing, and you can also create custom filters with any combination of rows from the result list.

Clearing

The objects in the results list that are not marked as used require further evaluation. The results list allows you to assign each object to a developer, so it is an ideal tool for development managers to distribute the work in their teams during a clearing analysis. To assign a set of objects to a developer, the list has to be in edit mode, which you can do by clicking the edit icon (it resembles a pencil) on the top left side of the screen (Figure 9).

The individual objects are assigned to a processor. After this, the processor can directly jump into the system, perform a remote comparison, and analyze the object. The CDMC provides a guide for clearing. You should review this information before you actually delete the object.

When all the items are processed, a final statistic generates — again using filters on the processing status of the result list. It is important to understand that each clearing analysis project is only a snapshot at a given point in time and should be repeated with new statistical data on a regular basis to reflect use of new components.

Performing an Upgrade Change Impact Analysis

The creation of upgrade change impact analysis projects is similar to the creation of a clearing project. To do this, start transaction CNV_CDMC and select Upgrade Change Impact Analysis in the screen that appears. Then create the project by clicking the create icon on the top of the screen. Once you create the project, you can access it by clicking the execute icon next to it. It provides a set of action items that are grouped similar to the IMG. The following steps are available in a clearing/usage analysis:

1. Project settings
2. Analysis

3. Display and evaluate results

Project Settings

The first and most important step of an upgrade change impact analysis project is the landscape setup. For a clearing analysis, three types of systems are necessary:

• Analysis system
• Control system
• Reference system/knowledgebase

figure 10

System landscape CDMC upgrade/change impact analysis project

The analysis system and control system are already described above for the clearing analysis. The reference system is specific to the upgrade change impact analysis. The standard changes should already be done in the reference system. That means for an upgrade project, this system could be an upgraded sandbox. It does not need to have any customer modifications or even customizing. It is only used to perform an SAP standard code comparison. If this is not available, a knowledgebase can be used. This knowledgebase is an indexed set of tables with SAP changes for a specific change event, such as an upgrade. Usually a sandbox system is eventually created during the upgrade project, so we recommend using a reference system over a knowledgebase.

The second step is to maintain adjustment times. You can do this globally or on the basis of an individual project. It is useful to maintain adjustment times on both levels because, for example, the global setting provides a company-wide effort estimation of the adjustments necessary during the upgrade, while the project setting provides a more detailed effort estimation per development unit.

Analysis

The analysis phase of an upgrade change impact analysis project contains five activities. The most important are the first three:

1. Find used SAP objects. The system determines the SAP objects that are used by customer objects.
2. Find changed SAP objects. The system determines the SAP objects that have changed during the upgrade.
3. Perform a remote comparison. The impact of changes is determined based on SAP characteristics. These characteristics cannot be changed.
4. Customer batch input analysis. The system creates a list of all customer batch input programs that are affected by the change event.

5. Analyze external subroutine calls. The CDMC creates a list of all the custom programs that make external subroutine calls to affected standard SAP subroutines.

Display Results

The results list for the upgrade change impact analysis is slightly different from the results list of the clearing analysis. The filtering options for object types are the same. However, because the focus is on the impact of a change event, there are filter criteria for the impact.

Basically, everything that is marked with the green severity is not affected by the change event and you can exclude it from a detailed analysis. Usually, that is between 30% and 50% of the list. If an object has a severity that is either yellow or red, that means there are changes in the underlying SAP coding that could impact the object. It does not necessarily mean the object will stop working.

If you click the question mark in the reason column (Figure 11), a list of SAP objects used by the selected object is displayed. This list has a rating for each SAP object depending on the type of change. For example, it may be that there are 50 SAP objects used by a customer project. Thirty of those are marked green because they have not changed. Fifteen are marked yellow for a low impact change and five are marked red because of a significant change (such as the object’s removal). This means that the whole program gets a red rating. The severity is determined by SAP and cannot be changed. It is important to remember that this list is a starting point for developers. You can assign each object to a developer and this person can directly access the object in the system and change it if necessary.

Figure 11

Results of an upgrade change impact analysis

Kay Eidner

Kay Eidner graduated in economics and computer science at the University of Technology in Magdeburg. He has worked with and at SAP AG since 2000. He is currently working on IMS Development for SAP ERP HCM. His diverse areas of expertise include Java, ABAP, mobile technology, applications such as ESS, MSS, and DFPS, and several other focus areas in the context of SAP technology.

You may contact the author at .

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Oliver Kapaun

Oliver Kapaun graduated in economics and computer science at the University of Technology Darmstadt and has worked at SAP AG since 2002. Oliver is developing on-site services for MaxAttention customers. His areas of expertise include Java and ABAP technology, applications such as ESS, MSS, and MDM, and several other focus areas in the context of SAP technology.

You may contact the author at oliver.kapaun@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.