Change Diagnostics Capabilities

 Change Diagnostics capabilities within SAP Solution Manager comprise the application E2E Change Analysis and Change Reporting and Configuration Validation and the Configuration and Change Database as central configuration item repository

Why Change Diagnostics Capabilities?

Change Diagnostics Capabilities are available after a SAP Solution Manager Setup has been performed for a managed system. It detects and records common technical changes in a managed system. A change tracking is performed independent of a change management process (like introduced by CHaRM or QGM). It’s one of the core functionality of SAP Solution Manager.

How change tracking is performed?

Changes are tracked and stored using the configuration and change database (CCDB). The configuration and change database (CCDB) saves the configuration data of managed systems in configuration repositories, and allows tracing changes. The configuration data is collected daily by the extractor framework, and uploaded from the managed systems to CCDB.

What is Change Reporting for?

Change reporting is based on the data of the configuration and change database (CCDB) within SAP Solution Manager. Any change of configuration items and the configuration data itself is stored in the configuration stores of the CCDB. The configuration stores are part of the CCDB and contain all configuration details. Additionally, all detected changes are aggregated into SAP NetWeaver BW into the change analysis info provider to provide change statistics.
Change Reporting application is available in the Work Center ‘Root Cause Analysis’ in System Analysis.

Change reporting function provides information about which and when changes were introduced into a software system landscape. For example, information about the current and historical values of technical configuration parameters, transport requests, or software maintenance activities can be provided from monitored systems. Change reporting can be accessed from the Root Cause Analysis work center via System Analysis.
The change reporting function is the end-to-end solution operation standard to analyze, compares, and track changes in the software landscape. This ensures that all software changes remain transparent and traceable, which in turn increases the quality and availability of the software landscape. The change processes can be monitored continuously throughout the software application lifecycle.
Change reporting is a stand-alone function as well as part of change analysis: You can access it as described above, or when viewing change details using change analysis

What is a Config Store?

Ÿ The  single  configuration  details  of systems connected to the SAP Solution Manager are  stored  in  the containers  of  a  defined  type  called  ‘Config Store‘ in the Configuration and Change Database (CCDB) which is a part of SAP Solution Manager.  Ÿ The Config Stores are grouped depending on the type of configuration data. ŸAll the changes of single configuration item are tracked in CCDB. In the example below you can see the content of the Config Store ABAP_COMP_SPLEVEL which contains details on both the currently implemented Software Components as well as the change history of each component.

What is E2E Change Analysis for?

Change analysis is part of end-to-end analysis within root cause analysis. Change analysis is based on the data of the configuration and change database (CCDB) within SAP Solution Manager. Any change figures are stored in SAP NetWeaver BW, and the configuration data itself is stored in the configuration stores of the CCDB. The configuration stores are part of the CCDB and contain all configuration details. Change analysis uses change reporting data viewer to display detailed configuration data.
Change Analysis application is available in End-to-End Analysis

The change analysis function provides an overview of the changes that have been applied to the managed systems. It also displays the number of changes per system, change category, and day. You can access it from the Root Cause Analysis work center. It reports changes of configuration items of a system (for example, OS, DB, ABAP parameters, Java parameters, transport requests, and Support Packages) and serves as a central entry point for root cause analysis.
Change analysis helps you to keep track of the changes in your solution landscape. Your development system might behave differently than your production system. Or, J2EE instances of your productive system behave differently and you need to find out the reason. Therefore, regular snapshots of the configuration settings are taken and stored in the configuration and change database (CCDB) of SAP Solution Manager. With this information, the change analysis function enables you to identify the changes. The change analysis function provides the number of changes and automatically takes you to the change reporting data viewer for the details and history of a changed item.

What is Configuration Validation for?

Configuration validation enables you to determine whether the systems in your landscape are configured consistently and in accordance with your requirements. You can check the current configuration of a system in your landscape using a defined target state (target system) or compare it with an existing system.

What is the idea behind Configuration Validation?

Configuration Validation provides a reporting to understand how homogeneous the configuration of systems is. Using centrally stored configuration data in Solution Manager to perform a configuration validation
of a large number of systems using a sub set of the collected configuration data

Typical questions are:

• All systems on a certain OS level or DB level?
• Template configuration (SAP or DB parameter) applied on all systems?
• No kernel older than 6 month on all systems?
• Security policy settings applied? Security defaults in place?
• Have certain transports arrived in the systems?

What is the scope of Configuration Validation?

Configuration Validation can be used for following use cases:

• Security Compliance: Here compliance with the customer defined policy is checked such as gateway configuration, authority and users, security relevant instance parameters, etc.
• Transports: This section covers missing, failed transports requests and for example validation of  Production backlog
• OS / Host: Here the configuration of Operating System and Host is compared
• Database: Configuration of Database parameters and level is validated
• Software: ABAP / JAVA Software packages are validated
• SAP Kernel: SAP Kernel level compliance
• Customer: Customer defined configuration baselines are used for validation
• Reporting: Reporting on the software / SAP Kernel level and other configuratio items is done without validation

Introducing Target Systems

Configuration Validation provides you the possibility to use a Reference System containing the base line for the validation which is perform against a number of comparison systems. As Reference System the data of a managed system could be use to compare the configuration data of one existing system with the configuration data of several other existing system.It’s also possible to create a target system based on the collected configuration data of an existing system. The configuration data of such a target system could be edited to create a base line for validation independent of any current system setting.

Compliant or Non-Compliant Items

In a target system it’s possible to specify per config item a compliant rule. If the rule applies to the corresponding config item of a comparison system the config item get the status compliant in the reporting. Otherwise it gets the status non-compliant. In order to specify rules, you may use operators to specify the compliance rule the config item must follow to be compliant.

Use Operators to define rules in a target system

In SAP Solution Manager 7.1 are rules are transparent by using operators. Operators comprise the rule set used for validation for a config item. Operators are available for all config store types (Property, Table, Text, and XML)

Configuration Validation Reporting

Configuration validation enables you to determine whether the systems in your landscape are configured consistently and in accordance with your requirements. You can check the current configuration of a system in your landscape using a defined target state (target system) or compare it with an existing system.

Reporting

Configuration Validation allows you to report upon config items to provide you with an overview about specific config item settings in your landscape without performing a validation.

Using a real system as base line

Configuration Validation allows you to perform a validation using as base line the config items collected for a managed system. In this case the complete configuration of the real existing system is compared against the compared systems. One of the relevant use cases for such a comparison is the validation after Roll Out phase. 

In this use case a new release is created from implementation of Software Packages and SAP Notes, Kernel update, parameter adjustments, custom own transports, etc. The system which contains all these changes is used as a reference system vor after-Roll Out validation. And the goal is to check how do the compared systems match the reference one.
That is an example of such a validation report restricted to ABAP Instance parameters check.

Using a target system as base line

Configuration reporting allows you to use a target system as base line for the validation. In this case we are not interested in validation of the complete list of possible configuration items. Only a certain part of validation parameters depending on the use case is important.

For example in case of security compliance we are interested for validation of ABAP Parameters, ABAP Notes, User Authorization, GW Configuration, Kernel Level. For validation of failed transports we need only ABAP_TRANSPORTS store. Because of this we need to restrict the configuration items to be validated. Such a restricted reference system adjusted for one or another use case is called Target System and stored not in the Configuration Change Database (CCDB) but in a separate database table and can be adjusted or extended at any time.
In the below validation report example you can see that the reference system with the name "BP_BADTR" with only store ABAP_NOTES is used to find failed transports across systems SI7, SQ7, ST7. 

In the column "Config.Item Value" you can see the return code of import of ABAP Transports of the compared.