Skip to end of metadata
Go to start of metadata

Introduction

This document describes the use of Configuration Validation using special customizing and features:

*Selective read of data and filtering
*Using outdated Config Stores
*Validation instance or node type depending Config Stores

Where can I find Configuration Validation?

Configuration Validation can be found in the Work Center Change Management in 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. There are different types of Config Stores. For the important once a screen shot is added.

Property type Config Store

E.g. ABAP_INSTANCE_PAHI with one key field:


This Config Store is assigned to an instance. Each instance has its own ABAP_INSTANCE_PAHI. It contains system and instance depending parameters like DIR_SORTRMP with value /usr/sap/SI7/D88/data and also parameters with values like EM/TOTAL_SIZE_MB. Imaging you would compare the parameter DIR_SORTRMP one by one with other systems parameter. The result would be that it does not fit; it would be valuated as NON compliant. Because of this the configuration validation offers to create a target system and assign operators to the parameters and also delete parameters.

Table type Config Store

These Config Stores have one or more key fields and one or more data fields, e.g. J2EE_COMP_SPLEVEL or ABAP_COMP_SPLEVEL with two key fields:

INI type config store


Two key fields and one data field. Very similar to table type

Event type Config Store

Timestamp, n key fields and m data fields. E.g. ABAP_TRANSPORTS with one key field:

XML type Config Store

XML format, no key field. E.g. Config Store saposcol:

This Config Store is assigned to a host. Each host has its own saposcol. It contains host depending items like its name and IP address and information about CPU and RAM and the operating system.

Text type Config Store

Plain ASCII text file, no key field, e.g. ABAP_INSTANCE_PROFILE:

Selection and filtering in Configuration Validation

The Configuration Validation uses two types of restriction of the data: The selective read of the Configuration Items of the Config Stores and the filtering of the result that is transferred to the frontend.

The selective read can only be used for Config Stores with exact one key field. If more than one key field are involved it cannot be used because of the operators used in the target systems. An operator like ‘Ignore’ for the first key field would otherwise not be able to find all possible hits.

Thus it is only used for property Config Stores, for table Config Stores with exact on key field and for the event stores ‘ABAP_TRANSPORTS’ and ‘J2EE_TRANSPORTS’. Event stores additionally are optionally read using a time range restriction. As most of the table stores have more than one key field the selective read cannot be used for most of them.
It cannot be used for XML, Text and INI stores. For these Config Stores all items are read.

If the selective read can be used it is checked whether there is a restriction entered in the variable screen for the ‘Configuration Item’. If only one Config Store is selected, it is applied and only the configuration items that fit to the restriction are transferred to the report. In the field ‘Use selective Read of CIs‘ of the variable screen a ‚X‘ must be accepted / entered which is the default value.

If selective read can be used, but there is no restriction on Configuration item in the variable screen, the restriction is done using all configuration items of the Config Stores of the ‘virtual’ target system which is used as Reference system.

E.g. according the next variable screen the items of the Config Stores of the ‘virtual’ system MA_DIVS VIRTUAL would be used to select the items of SI7 and SD7 for the validation:


The result using the following variable screen:


would only read one Configuration item (parameter) of the Config Store ABAP_INSTANCE_PAHI:


Deleting the default value ‘EM/TOTAL_SIZE_MB’ in the ‘Navigation Block’ will not change the result area.

If the same report is executed using the same restriction, but without the ‘Use selective Read of CIs‘ flag ‚X‘ the initial result would be the same. The run time is expected to be higher, because all items of the Config Stores are read and valuated. Afterwards the OLAP layer filters only the item ‘EM/TOTAL_SIZE_MB’. If now this default filter is removed using the trash icon, all items are displayed. The default filter is not used in the report ‘0TPL_0SMD_VCA2_TRANSPORTS’ to enable the pattern filter.
The default filter is also used for the Compliance column to exclude items that are not relevant for the report result.

Initial result


Result


Example for pattern filter using the report 0TPL_0SMD_VCA2_TRANSPORTS.
Imaging the system SI7 is the productive system and you would like to know the transport requests created in SI7. Optionally: You are interested only in those that had been modified (created, changed or deleted) the last month. Therefore the ‘Transport Requests in Date Range’ fields are entered.

Variable screen:


Result:


Due to the default filter for ‘Comparison system’ on Compliance System no data is displayed. Open the Navigation Block and remove this filter using the trash icon and all items (transport requests) that fit to SI7* and the time range are displayed.

Navigation Block:

Result:

Using outdated Config Stores

The configuration validation uses only data of Config Stores that have got the last successful update not more than 7 days ago. This information is stored in the field STORE_TO and can be found in the CCDB Administration. Select one Config Store and find it under the ‘Details’ tab strip, section Store Attributes as Data to. Config Stores with data ‘older’ than these numbers of days are displayed in reporting with an item ‘OutDated_ConfigStore’.

You can adjust the number of days accepted using the function module
DIAGST_CONFIG_SET

in single test:

NAME

CONFIGVAL_STORE_VALIDITY_DAYS

SET_VALUE

<number of days; integer value>

If you would like to accept 10 days the input parameters are:


If you enter 0 as SET_VALUE the configuration validation cannot use the configuration items anymore, it will instead display ‘OutDated_ConfigStore’ for all Config Stores with store_to information. For Config Stores which do not a have the store_to information, the items of the virtual targets system which was entered as reference systems are used to be displayed without an item value and Compliance ‘Item not found’.

The Configuration Validation reports are enabled to use the OLAP cache. If the requested result is stored there and not older than half a day, it is used and you get the former result. Thus delete the OLAP cache, if would like to have this new result immediately:
Logon the BW client, use transaction RSRCACHE, Cross AppServer ‚Cluster‘, Press ‘Delete’.


Validation of instance or node type depending Config Stores

In the former release called Ehp1 the virtual target system accepted a Config Store name only once. However, for instances and nodes there are several Config Stores of the same name. The configuration validation uses only one of these Config Stores, if several are offered by the reference system. Examples are the Config Store ‘ABAP_INSTANCE_PAHI’ which is for each ABAP instance of a system collected and some of the items will a different value for the central instance and the dialog instance. For JAVA instances the ‘ClusterManager.properties’ Config Store which is collected for each node could be an example.

In the current release 7.10 the target systems can accept Config Stores of the same name and store class and other keys, but different instance and/or node type optionally. The complete key used for a Config Store is: STORENAME, STORE_TYPE, LANDSCAPE_CLASS, INSTANCE_TYPE, NODE_TYPE, COMP_ID, GROUP_SOURCE, GROUP_NAME, STORE_CATEGORY, STORE_MAINALIAS, STORE_SUBALIAS and TECH_SYSTEM_TYPE. Other keys like COMPV_ID, STORE_TPL_ID are not taken into account; the STORE_PATH is not used exactly, but checked for differences: Two differences in the parts of the path are accepted.

The configuration validation uses according the default setting one of the Config Stores of the same key, which is the Config Store of instance type ‘Central’. For the node type dependent Config Stores there is no example in SP01, because the Config Stores of the node type ‘dispatcher’ and the node type ‘server’ have different classes. If they would have the same class the Config Store of the node type ‘dispatcher’ would be used.

If you would like to use a Config Store of instance type ‘Central’ for the central instance related Config Store and a Config Store of instance type ‘Dialog’ for the dialog instance related Config Stores, the setting has to get an update.

Use the function module DIAGST_CONFIG_SET in single test:

NAME

CONFIGVAL_COMP_DIF_INST_TYPES

SET_VALUE

 

If the original behavior should be used again, enter X as SET_VALUE.

For node depending Config Stores use the same function module, but the

NAME

CONFIGVAL_COMP_DIF_NODE_TYPES

SET_VALUE

 

should be used.

Please note: If the value is different from X the target system has to have a Config Store for both types, one for the instance type ‘Central’ and one for the instance type ‘Dialog’ , one for the node type ‘dispatcher’ and one for the node type ‘server’, because afterwards only the config stores are valuated which are fitting related to the type information.

Please decide and set the value of the parameter . Switching of the setting can give different results of the validation.

Screen shot of node depending Config Stores of the same name:

The complete Config Store key is displayed by the CCDB viewer. Use transaction CCDB or the url ‘http://<SolManserver>:<port>/sap/bc/webdynpro/sap/wd_ccdb_admin?sap-language=EN’. Display the details:

Java Dispatcher Node

Java Server Node

This example shows that the current release cannot compare these two Config Stores, because they have different classes.

Secured Config stores

Some of the Config Stores contain information about security relevant settings, e.g. AUTH_CHECK_USER and MS_SECINFO.

Users that are no authorized for these Config Stores get the messages ‘PERMISSION DENIED’ like:


For most of the users this is may be not the expected result, but it is the proper result. They are not supposed to get the information of these Config Stores. However some users should have the authorization to get the information to do steps to reduce security risks.

Please assign the authorization

Authorization-Object

AI_CCDB_SC

CCDB Store Content

ACTVT

03

Display

CONT_AUTH

* or SECURITY

 

to these users which is contained e.g. in the role SAP_SV_SOLUTION_MANAGER.

You can find the list of all secured Config Store by calling function DIAGST_GET_STORES in transaction SE37. Enter a system id into field SID (or leave this field empty), enter PROTECTED = Y and DISPLAY = X and execute the function. You may reduce the list of displayed columns to show these fields only: GROUP_SOURCE, GROUP_NAME, STORE_CATEGORY, STORE_TYPE, STORE_NAME.

In case of missing authorization you get the result "No Applicable Data Found" after execution of a configuration validation query for a secured configuration store.

Note: The embedded BW of the SAP Solution Manager is called via RFC which in turn performs a callback via RFC. Therefore either your user respective the technical user which is running this callback requires the authorization.

Show table RSADMIN using transaction SE16 for object SMD_COMPLIANCE_DESTINATION to check which callback RFC destination is used. Usually RFC destination SM_<SolutionManager-client>CLNT<SolutionManager–ProductiveClient>_CALLBACK is used. Then you can show this RFC destination in transaction SM59 to identify the callback user. Usually the user BI_CALLBACK is used.

If you run BW in the same client like configuration validation then you can use symbolic RFC destination NONE instead. In this case it's your own use who require the authorization.

You can maintain table RSADMIN using report SAP_RSADMIN_MAINTAIN.

The BI_CALLBACK user is created as a technical user in transaction SOLMAN_SETUP. This user is relevant for reorganization of BW - data in the SAP Solution Manager and configuration validation:

Secure Configuration Guide - SAP Solution Manager 7.2 SPS 5

Overview: All Users Created in Basic Configuration in Transaction SOLMAN_SETUP
https://help.sap.com/viewer/32c80055a2be46749480cebbc5df88c9/7.2.05/en-US/541325bf3c736626e10000000a42189c.html

Technical User BI_CALLBACK
https://help.sap.com/viewer/32c80055a2be46749480cebbc5df88c9/7.2.05/en-US/3886cfc5f82d467fa4f13d247ca423f0.html

 

The Config Store STANDARD_USERS is also a secured Store, it lists the special SAP users and whether the initial password was changed. The SAP note 1234799 describes the content of this store and how it had been validated in the former release. To get the same handling a target system with this Config Store has to be used as reference system. The content should have one line: 



Using this target system as reference system SAP Standard users for which the password had not been changed are valuated with Compliance ‘No’.

Views and bookmarks

The Configuration Validation offers to save and reuse the navigation status of the report. The views are user specific, called local views. Only the user that had created the view can see and use it. On the other hand a user can create bookmarks and make them available for all users. Both objects do not store the results. If a view of an ‘operators validation report’ is used the variable screen is displayed and the user can adjust the restrictions. Views of a ‘configuration report’ accept the restriction done before for the report and no variable screen is displayed. Bookmarks use the restriction that had been done before creating the bookmark; no variable screen is displayed by default.

Views

In our example the report 0TPL_0SMD_VCA2_NCOMPL_CI_REF had been used. Using the navigation block the characteristics Instance and Instance name had been drilled down, the characteristics ‘ConfigStore Name’ and ‘Last Check [UTC]’ had been removed from drill down.
Use the ‘Save View’ function and press the ‘new’ icon marked in the screen shot:


In the Save View screen enter a Description e.g. BP_1 and press ‘Save’


The variable screen will ask for a new selection.

Next time when the same user has executed the same report from the ‘Query View Selection’ drop down box the save view can be used:

Bookmarks

For creating a bookmark please use the context menu of the BW report:


This action creates the URL with the BOOKMARK_ID:


Copy the complete URL and create the new ‘Configuration Validation’ Bookmark. In tab strip ‘Report Execution’, Bookmarks, press the new icon:


Paste the URL generated before as ‘Bookmark URL’ and enter a name and – optionally other attributes. Save:


Now this additional Bookmark is available for all Configuration Validation users. By default no variable screen is displayed and the report is reading the Config Stores and displaying the result.

If the user should have the option to change the restriction and the variable screen should be displayed, attach the string ‘&VARIABLE_SCREEN=X’ to the bookmark URL:


Using this bookmark URL the variable screen will be displayed with the restrictions that had been entered before creating the BW bookmark.

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

  • No labels