SAP ABAP custom developments, enhancements, and even modifications are normal in companies today. Users want to benefit from SAP standard software functionality and adjust the system to meet company-specific needs and business processes. Over time, these changes become a major hurdle when different versions of coding must be supported. Custom code life cycle management (CCLM) can provide this information and contribute toward control over the growth of different versions.

CCLM is introduced with SAP Solution Manager 7.1 and describes a process that supports companies in successfully managing their developments. Companies can benefit from full transparency and baseline information of custom code objects. This information can include master data, such as the name of the object, development class, or author, together with transactional data, such as version, usage, and quality data. The data volume is moderate and customizable because not all data is taken over from a managed satellite system, since only executable and customizable objects are essential.

Upgrades and solution transition events usually affect custom code. The user needs support to estimate, plan, prioritize, and effectively allocate the development effort for upgrades and code changes. During an upgrade, the company needs to perform a modification adjustment to have their developments implemented in a new environment. The change impact analysis performed during the upgrade in the Custom Code Development Management Cockpit (CDMC) puts the company developments in this new context and provides detailed information if further activities for a certain development are needed. A historical inspection of the custom code used provides data for an analysis to identify unused custom code (clearing analysis) that can be fed into a clearing project.

The custom code library is designed to be the central component of the CCLM and the single source of truth for custom code object information. Enforcing consolidation of custom code and the assignment of responsibilities of custom code objects are the major benefits within the company. In addition, an overview about the number of custom code objects is displayed, and the development costs as well as the maintenance effort for custom code objects can be maintained and used to accelerate undertaken activities.

Process Flow of CCLM at a Glance

The major process steps within CCLM are depicted in Figure 1. To have CCLM running productive in SAP Solution Manager 7.1, you have to perform certain initial steps, highlighted in light blue (see the key on the bottom-right of the figure). You can use a corresponding configuration service from SAP to set up the CCLM application.

Figure 1

CCLM process flow

Use transaction CCLM and upload the library definition from an XML file that is provided by SAP in a technical introduction service. Then define the library key along with the library name, schedule the data collectors, and collect the requested data into the library.

The XML file for the library definition provides the schema for the data collection phase. Data collection is a recurring step that happens periodically in the background depending on the scheduling of data collectors. The schema is a management information structure and contains objects and their attributes as well as all information regarding cardinality of attributes or maintenance possibilities.

Data that cannot be collected automatically needs to be assigned manually. Manual steps are required to fill in information such as the current life cycle status, relevant contracts, and responsible owners related to custom code objects. This information permits a detailed reporting over the already existing automatically collected attributes.

The CCLM architecture is open and allows you to maintain additional attributes. Finally, reporting can be carried out and appropriate measures can be scheduled. Major activities can be a clearing project or consolidation project to delete custom developments and the respective development class.

General Architecture and CCLM Sitemap

Figure 2 illustrates the general architecture of CCLM in SAP Solution Manager 7.1. The central part is the custom code library (in gray), in which the master data of the custom code objects together with the transactional object-related data resides. The flexible library definition allows one or more library instances with master data and transaction data running in SAP Solution Manager 7.1. The library is controlled via a Web Dynpro ABAP user interface with the administrative views for Custom Code Objects, Library Definition, Custom Code Analysis, and Reports (in light blue). The Settings view controls the data extraction process. We’ll describe the Settings view and the other remaining views in later sections in more detail.

Figure 2

CCLM architecture

The solution directory or repository is used to retrieve information about the solutions and the managed systems within solutions. The component SMSY/LMDB is used to get product and product version information about the managed systems. The extractor framework as well as the SAP NetWeaver Business Warehouse (SAP NetWeaver BW) content is necessary for BW reporting of master data and transactional data of custom code objects.

You can call many data collectors from the managed systems. The current version of CCLM uses the CDMC collectors for custom code objects, the code inspector for quality information, as well as data collectors from ST-PI/API plug-ins to retrieve data from the satellite systems. Data collectors from the ST-PI/API plug-in are used by SAP EarlyWatch Alerts to determine the workload of custom code objects. The CloneFinder results are not included in this version, but are planned to be considered for the second release or feature pack of CCLM.

Overview

The starting page of transaction CCLM contains several sections, including Settings, Library Definition, Objects, and Reports for quick navigation located in the navigation panel in the upper-left part of the screen (Figure 3). When you click the link next to the navigation panel, the related functionality is displayed in a view along with the corresponding information for quick navigation. The Refresh link in the lower-right corner reloads the data and refreshes the sections in the screen, and the calculated numbers are updated.

Figure 3

CCLM Overview screen

The Settings section of the Overview page contains information about the status of the data collection activated for managed systems. The link for My Systems or My Active Systems is selectable if a solution was chosen previously in transaction CCLM and depends on settings the user performed. Next to the All Systems and All Active Systems links, the number of connected managed systems is maintained in parentheses.

The Library section provides a link to the Active Library as well as information about Inactive Libraries that can be loaded for test purposes. This function will be more important for future releases in which more than one library can be active (e.g., if SAP objects are collected).

The Objects section leads to the maintenance view for objects in the custom code library. These are the original custom code objects, along with their duplicates. The duplicates themselves are different objects from the original objects, but carry the same name and object identifiers. Their object definition is located in another development system. In addition, the links to customer maintainable objects (e.g., Contracts and Owners) are supplied.

You can collapse each section (right and left side of the context menu) or hide it by clicking the respective icons (option menu) on the title row of each section.

Settings, Schedule Data Collection, and Going Productive

The Settings view in Figure 4 provides a list of systems that are subject to data collection. Additional information such as system ID, installation number, and product information is shown next to the system name. The number of systems in the main list depends on the selected preconfigured solution. The buttons on the main list allow maintaining a check box (in the Lead System column) that defines the dedicated lead systems. Only lead systems update the attributes for custom code objects. An additional check box (in the Local Obj… column) is provided to dedicate a system as the lead system for local objects such as $TMP.

Figure 4

CCLM Settings screen

The approach extracts all custom code data from the development system as a lead system without local objects in development class $TMP, which cannot be transported into test or productive systems. In productive systems, it is important to know which local objects exist and are executed. Therefore, it is recommended that you set the check box for local objects in productive systems in contrast to development or test systems.

Nevertheless, productive systems should not be set as the lead system, because some standard attributes (e.g., development class or master language) will be consolidated in the development system first and become reflected in production at a later point in time. Furthermore, the development system is the initiating system for the deletion of custom code objects and the lead system for such objects.

Furthermore, the setting of a lead system is important in conjunction with setting the deleted attribute (not shown) for a specific custom code object in the library, since for such objects no data can be found in the data collector. The data collector of custom code objects cannot find deleted objects and as a result the deleted objects are not updated in the library automatically. A dedicated report (e.g., RAGS_CC_SET_DELETED_FLAG) can be scheduled and executed with various import parameters (e.g., retention periods and system values) to maintain the deleted flag. An adequate technical solution includes data from the central transport repository as the single source of truth for object changes to find deleted objects automatically, which is planned to be included in future.

The details of the selected systems are shown in the main list in the upper part of the screen in Figure 4. The technical report name is identical for all managed satellite systems while the job name is generated with the dedicated system ID and installation number. The period type indicates the duration of the execution next to the start date and start time along with a traffic light-based rating for each job executed (in the lower part of Figure 4).

The ratings of the jobs are as follows:

• Red — Job was canceled
• Yellow — Job was not yet scheduled
• Green — Job was successfully scheduled, is still running, or was executed successfully

During the runtime of the job, the Remote Function Call (RFC) destination is determined with the system ID and installation number.

The RAGS_CC_GET_OBJECTS report collects the custom code objects from the managed system itself, while the others are fetching related data such as quality data, workload data (usage statistics from transaction ST03N), and SAP NetWeaver kernel logging data. The weekly and monthly workload statistics are extracted from SAP EarlyWatch Alert data. If the SAP EarlyWatch Alert is scheduled, no call to managed systems is necessary because the data is in SAP Solution Manager already. This is a clear advantage in terms of runtime. In addition, it is possible to navigate into transaction SM37 by clicking the job name where you can verify and change job details such as status, duration, and the next scheduled start date and start time.

Library Definition and Shaping Up the Metadata Structure

The library definition contains collections of objects, attributes, and relationships between objects and attributes. Only one active library can run productively, but the library definition can be modified instantaneously with the Download button on the main list. This is particularly interesting if additional attributes for custom code objects should be maintained for existing search helps and attributes such as Role or Organization. Companies can reuse the attributes from other applications. The library metadata is designed to be extendable. That ensures companies a management information structure that is open to changes and that can be extended. The extension can be by new objects, attributes, and relationships between objects and attributes (Figure 5). The first version of CCLM allows only new maintainable attributes for existing objects.

Figure 5

CCLM Library Definition screen

Objects 

The view of custom code objects contains the actual results in Figure 6. All collected custom code objects as well as their duplicates are listed for further maintenance and reporting purposes. A duplicate is the same object from its technical attributes, but created in another source system.

Figure 6

CCLM Objects view

In addition, the maintenance of additional attributes of custom code objects is provided via buttons in the upper part of the screen. The user can create maintainable objects such as owner and contract. You can change and delete both objects via the Change and Delete buttons in the top part of the screen. You need to define this functionality in the library definition phase, and assign it for references and maintainable attributes. Selecting one or more objects in the main object list enables you to add a reference or an attribute. A pop-up screen appears, and provides all necessary information for both of each.

The details area (in the lower part of the screen) illustrates the standard attributes that are filled automatically. An additional tab with maintainable attributes allows creating, changing, or deleting a single attribute.

Two filter areas allow refining the object list. The standard filter area refines for Object, Object Class, Object Name, and change dates (Figure 6). However, to find objects with dedicated attributes, a combination of filters is required. Examples for attributes are Criticality, Severity, and Distribution Rule, or standard attributes such as Author, DevClass, Object, or SourceSystem. A maximum of five filters on different attributes is possible and can be adjusted on the filter area above the main list. For performance reasons, you can configure a maximum number of items returned, such as between 200 and 500, in the customizing settings for performance reasons.

Incorporating SAP NetWeaver BW to Gain Analytical and Reporting Capabilities

The standard Reports view is always accessible to the user and provides the dashboards and scorecards created by the company in SAP NetWeaver BW. The view provides a generic access since the reporting requirements vary from company to company. The view offered is reused from the Business Process Operations and Job Schedule Management views. It is possible to check in all reports created by the Web Application Designer.

Detailed ad hoc reporting is planned to be included in the next release. Companies will be able to easily gain immediate reporting data on usage, quality, and versions (for example) without an SAP NetWeaver BW installation and activation.

Veit Eska

Dr. Veit Eska studied physics at the University of Rostock and the Institute of Atmospheric Physics in Kühlungsborn, where he wrote a doctoral thesis on applied physics. He joined SAP in 1998, where he worked in the technical core competence team on the development of service tools for creating services such as SAP EarlyWatch alert. With regard to SAP Solution Manager 7.1, he is the product owner, architect, and developer of the custom code life cycle management (CCLM) platform.

You may contact the author at veit.eska@sap.com.

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