Skip to end of metadata
Go to start of metadata

How to get one compliance result based on two different checks for a system?

As an example I use SAP note 1298433. It basically describes an issue an its dependency for a technical system of type ABAP between a parameter and a SAP Kernel version.

The validation report should answer the question if the systems are on a proper SAP Kernel version AND if the parameter is properly set.

I took the kernel version from 1298333. The parameter described in SAP note 1298433 is: gw/reg_no_conn_info. In this example I decided that the parameter is compliant if the value is greater 0.

Creating a proper target system

I created a target system with two config stores:

  • ABAP_INSTANCE_PAHI (contains the active parameter of an ABAP instance)
  • ABAP_NOTES (which allows to specify notes and its software dependencies)


Config store ABAP_INSTANCE_PAHI contains only one parameter. In this example gw/reg_no_conn_info is compliant if its value is greater zero.


Config store ABAP_NOTES contains 5 entries. For SAP kernel release 700, 701, 710, 711, 720 I specified the kernel patch level until the vulnerability/issue which is described in note 1298433 is given. So I used the validation note status later on in the reporting to understand if the system is running  a vulnerable SAP kernel or not even though the note is not a note which could be applied using SNOTE. I simply use the possibility of the software dependencies rules to calculate if the note would be obsolete because the kernel release is newer or that the note would be applicable because the software dependency is fitting into the vulnerable kernel release.


Aggregating validation results

BW template 0TPL_0SMD_VCA2_REF_CONFSTORES aggregates the validation results for several config stores into one compliance result.


Is Compliant = 0 than the compliant status of at least one config stores is "non-compliant". Only if both config stores are validated as compliant the aggregated validation result will be compliant.

It's possible to expand the hierarchy to recognize which part is not compliant. The 2nd hierarchy level is using the alias of the config store the next one the config store name.

Compliant Example

The hierarchy is expanded down to config item level. So for system SD7 the current parameter value of gw/reg_no_conn_info is 1 which is validated as compliant based on the rule above.

Note 1298433 is validated as compliant because the rule which describes a SAP Kernel dependency  is not meet. Unfortunately, it's not possible to drill down the current Kernel version. However, it's easy to use Matrix Reporting to get the numbers:

So SD7 it's running 720 patch 201 which is compliant based on the rules in above target system in config store ABAP_NOTES. Since both checks are compliant the aggregated compliant result is also compliant.

Non-Compliant Example

For BPX the parameter value of gw/reg_no_conn_info is 0 which is validated as non-compliant. Let's look at the current SAP Kernel version:
In the target system the non-compliance is described for 701 having a Patch Level < 171.
So both are not compliant which is aggregated overall to non-compliance.

One non-compliant result would make the overall result to non-compliant.

Query Properties

The query properties would allow to expand the entire hierarchy at once using the Display Rows as Hierarchy and Expand to feature.

Here you can also see what the different hierarchy levels display.

This page is part of the Application Operations Wiki. Notice that Application Operations itself is a use-case of SAP Solution Manager

  • No labels