Skip to end of metadata
Go to start of metadata

Introduction

This document describes the use of config stores of type xml for Configuration Validation. Two config stores of type xml are going to be used as examples. For host related information config store saposcol is available. It contains basic information about the configuration of the host used by a technical system. For J2EE technical system for each J2EE node a config store SAP_J2EEClusterNode exists. It contains basic information about the node configuration

Use Cases

a)      Host validation
Check “Operation Patch Levels” for hosts running Linux

b)      J2EE node validation
Check memory configuration of several J2EE nodes

Where can I find Configuration Validation?

Configuration Validation can be found in the Change Management Work Center, Related Links

Where can I find the used config stores and have a look at the data?

 Work Center Root Cause Analysis (RCA) > System Analysis > Change Reporting

The extraction of the data is scheduled as soon as a “Root Cause Analysis Set Up” has been performed for a system.

Preparation

Create a target system containing config store saposcol in target system maintenance using the Create UI.

Target System Maintenance > Create

Choose a technical system as source. Use one saposcol as source for the target system config store.

You need to specify a system id (8 characters) and a description before the target system can be saved

Target System Maintenance > Edit

In Target System Maintenance > Edit the content of a config store of type XML is displayed in its internal presentation.

  • Column XPath contains the full xpath of the element and the element name
  • Column Content displays the element content
  • Column Attributes displays the attributes of the element

Operators per element

It’s possible to specify compliance rules per element. As soon as an element is selected, field values and operators are displayed. There is always a line for XPath and Content. For each attribute an additional line (Field Name = name) is displayed.

What makes XML validation so cumbersome?

First it’s necessary to have a closer look at the structure of the saposcol xml file.

The config item information is modeled in two elements. There is a property element which contains a content telling the config item, e.g. propery name = “NumberofCPUs”. The actual value is model as a child as value element, e.g. value = 6.

To successfully validate the value element it’s not enough to specify the compliance rule on value element level, like

> Value of “Number of CPUs” is equal to 6

It’s also necessary to specify in the parent element which information should be used to identify the element, like

Operator “==” determines that this information is used to identify the element. In this example it’s not the element content; it’s an attribute which is used to distinguish the property elements.

Attention: The operator “==” uses 'contains pattern' for comparison. If the special characters # + * are part of the value you need to mask them with a preceding # if you want to check for equality. 

How does it work in detail?

Validation is only performed on leaf elements. It’s not intent to perform a validation on the entire xml. Only specific elements should be validated. If the leaf element cannot be considered as unique in the XML (considering the XPATH), it’s necessary to specify in the parent element those parts of the element further which allow to identify the leaf element by its parent elements.

Validation starts with the leaf elements of the XML of the target system. The leaf element is searched for in the XML config store of the comparison system. Once the element is identified (XPATH == XPATH and optional other “==” operators on content and/or attributes are used) the parent element of the element in the target system is compared with the parent of the element of the comparison system (XPATH == XPATH and optional other “==” operators on content and/or attributes are used). That is done until the root element is reached. If all parents match between the element of the target system and the element of the comparison system the element is considered as identified.

Last step is the validation of the leaf element using all operators and values to determine the compliance status of the leaf element.

Saposcol example in detail

The saposcol config store contains information about the operation system patch level (in XML notepad presentation), e.g. for Linux:

For Windows:

Let’s create a target system which allows validating if Linux is using kernel version: 2.6.16.60-0.76.8-smp using the property OpSysPatchSummary.

The Target System LINUXPTC should contain only one element to validate:

How to get there?

  • Create a target system using a saposcol config store of a technical system running on Linux.
  • Edit the config store in the following way
  • do two times:
    • Use the select all icon
    • Uncheck the desired leaf element (item underneath OpSysPatchSummary)
    • Delete all mark items

Background: It’s only possible to delete leaf elements in one delete step.

Compliance rule for value

The final config store should look like this:

Use for row Content in column Operator **{}Contains* (it performs a pattern search)
Use for row Content in column Value Low a pattern which contains the kernel version which should be validated. Use * as wildcards, e.g. *2.6.16.60-0.76.8-smp.

Rule to identify the parent element

An attribute needs to be used to identify the parent element clearly.

Use for row name in column Operator: == (it’s then used also when the parent elements are search for).
The value low can be used as it is: OpSysPatchSummary.

Output example

Using template 0TPL_0SMD_VCA2_NCOMPL_CI_REF and drilling down Host Name shows:

SAP_J2EEclusterNode example in detail

The store SAP_J2EEClusterNode contains parameters of J2EE Server Configuration and this store can be used to validate memory configuration of J2EE Server Nodes across different systems.

Create Target System for validation of J2EE Server memory configuration

To do this create a Target System using only this store. This store exists both for Server and Dispatcher Nodes. Click the button “Details” at the right side of the screen to make sure that the store for a Server Node is selected. Click the button “Create from selected Stores” to create a Target System

Provide the name for the Target System and save.

Edit the Target System

Delete all the leaf elements (we need only /MBean/attributes/VmParameters leaf element)

  • Use the select all icon
  • Delete all mark items using the "delete all marked items" icons

Maintain rules for configuration Items for this element. Delete unnecessary parameters. Replace system ID and Instance Name with the “*” and use the operator “Contains” for these parameters to ensure independency from the system specific values. The final configuration of the Target System should look like in the following example:

Execute validation report

Using template 0TPL_0SMD_VCA2_NCOMPL_CI_REF and drilling down Node Name shows:

To display validation details for a single Server Node please make a right mouse click on the line and select Goto - “Config. Validation – Items – Validation Details”

The results for single item validation are displayed to identify the exact deviation from the configuration baseline.

Validation of J2EE Server Configuration

The Configuration Item /MBean/attributes/SystemProperties can be used to validate J2EE Server Configuration (we have deleted it in the previous example to focus only on memory configuration).

 You can add this item to the Target System via the button  (“Add entries from the source system”).  From the pop-u menu select the /MBean/attributes/SystemProperties and click the button “Add selected entries to the Target System” at the top of the screen

After the Item is added to the Target System delete unnecessary parameters and replace System ID with the “*” to ensure independency from the system specific parameters:

Validation Output

Using template 0TPL_0SMD_VCA2_NCOMPL_CI_REF and drilling down Node Name shows:

To display validation details for a single Server Node please make a right mouse click on the line and select Goto > “Config. Validation – Items – Validation Details”

 

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

  • No labels