Advanced Configuration Monitoring capabilities within SAP Focused Run comprise the application Configuration & Security Analytics (CSA) with Validation, Changes, Search and Store Browser and Configuration & Security Analytics Administration. The Administration provides information about the Collector Framework for CSA.

The Capabilities are available after the setup (Single System Integration, SSI) has been done. CSA detects and records common technical changes in a managed system. A change tracking is performed during upload of the extracted configuration information.

On managed system side the configuration data is collected and transferred via Simple Diagnostics Agents (SDA) to the SAP Focused Run system. There the data is compared with the previous snapshot to identify changes. Data is stored in HANA database tables (starting with CCDB_DATA_) comprising the Configuration and Change Database (CCDB). For the general architecture and data flow of the application see also the below picture.

Figure: CSA data collection

The Configuration and Security Analytics (CSA) application provides configuration items and support different views on them:

• Validation checks the configuration items against a defined policy, e.g. whether the setting for the password length fits to the security requirements
• Changes displays the changes over time
• Search allows to find items across huge landscapes 
• Store Browser displays available configuration data

Validation

Validation provides a reporting to understand how homogeneous the configuration of systems is. Using centrally stored configuration data in SAP Focused Run to perform a validation of many systems using a sub set of the collected configuration data defined by the selected policy (see also the below figure):

• Validation shows the results of a validation based on rules of a policy (policies are maintained in the policy management including check id and description).
• Different aggregation levels are provided
  • Systems
    Aggregation on system level
  • Checks
    Aggregation on Single Policy and Check Id
  • Systems / Checks
    Matrix result by System and Check Id
• Drilldown to item level available for each aggregation
  Details on item level can be displayed for each aggregation type
  

Figure: Validation of systems

Exemptions for Policies

In Exemption for Policies application the exemptions of the rules defined in the policies can be specified. There are two kinds of exemptions: One exemption re-defines the validation outcome for a check id for assigned systems for a period. During this defined period the combination of system and check is not validated. The other exemption prevents a check id from becoming active at all before a due day is reached which is system independent. The validation application applies the exemptions by default but offers also to run the validation without the exemption.

The application supports a basic manual process. The following Information is stored when defining an exemption:

• Policy - Select a XML policy from drop-down box.
• Check - Select a check Id from drop-down box
• Exemption - Specify name of the exemption (length: 20 characters)
• Description - Provide a free text including all required references for documenting the exemption
• Valid from - Filled when selecting a data range as validity period of the exemption
• Valid to - Filled when selecting a data range as validity period of the exemption
• Due date - Filled when selecting a due date for the validity of the exemption
• Saved by                      Filled automatically when saving
• Saved at day                Filled automatically when saving
• Saved at time               Filled automatically when saving

To add or remove systems to an exemption you can use the same filter criteria as for scope selection.

The field “Description” is recommended for creating the references required from a process perspective (e.g. ticket numbers or URL link to relevant records). Exemptions always refer to a policy. Checks with identical check ID in other policies are not covered. Exemptions are limited to active policies. They cannot be applied to catalog policies.

At this point the exemption feature is implemented to allow a validation reporting that takes into account known and accepted non-compliances. Like the complete CSA application it is not meant to be an audit-proof tool by itself. Moving towards such more advanced use-cases likely requires integration with software products designed for managing compliance.

Policies – Customer – Assignment

In Policies – Customer – Assignment it is possible to restrict the visibility of policies to customers.
If no customer network is assigned, a policy is visible to users of all customers that are authorized for the policy (authorization object SRSM_CV_TS). As soon as one or more customer networks are assigned to a policy the policy is only visible for users that are authorized for an assigned customer network and the policy.
The assignment is done by selecting a policy and then in Edit mode selecting the customer networks followed by pressing ‘Restrict'. Thus, a policy can be blocked e.g. during developing phase for the end users.
If afterwards the policy is supposed to get released for all customers, just press ‘Remove Restriction'.

Configuration Validation Alert Management

The target of Configuration Validation Alert Management is to define settings for alerts based on validation results. The selected policy is defining the rules for the validation. These policies consist of checks describing rules to validate configuration items either as compliant or non-compliant. Alerts for non compliant results on system, config store, check or item level are pushed to ‘Alert Management' of Advanced Event & Alert Management. A setting consists of an ID and description, a policy and an information for which systems an alert should be created. The systems are selected via the standard system scope dialog. For the frequency Hourly, Daily or Weekly is accepted. Finally, an alert definition can be set to active (ON) or not active (OFF).

Notification and Outbound assignment can be done per system in CSA Administration using ‘Configuration' of systems.

In Alert Management the generated alerts are assigned to the Monitoring Use Case ‘Configuration & Security Analytics' which can be selected in the Scope Selection screen.

Changes

Changes provides an overview of the changes that have been applied to the managed systems. It also displays the number of changes per system, store and day. It reports changes of configuration items of a system (for example, OS, DB, ABAP parameters, Java parameters, transport requests, and Support Packages). Changes helps to keep track of the changes in the solution landscape. The 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 Focused Run. With this information, changes enable to identify the adjusted items. Changes displays the number of detected changes for a technical system in scope (see also the below figure):

1. The overview displays a list of systems sorted by changes and a chart that groups the systems according the number of changes.
2. Drill down into changes for a system
3. Drill down into changes for a config store
4. Drill down into change history of an item
5. Change the time frame selection (date range)

Figure: Changes

Changes are a common starting point for analyzing issues in the solution landscape. Imagine that something worked yesterday, but it is not working anymore today. The first question would be what changed in between?

Changes is the tool to analyze issues like this. The tool starts with an overview of the overall changes which have been applied to the landscape. You can use the timeframe selection, to limit the timeframe to the point when the problem occurred first.

Search

Search finds configuration items by an entered string. The search is done by looking for field contents that fit exactly, except when the wildcard * is added. The wildcard * stands for any characters. If the character * should be found as a character the back slash must be placed in front of it for escaping. E.g. sap* finds all items having the string sap followed by some additional characters stored. Search will find the user SAP*, if sap\* is used as search string.

If just one character is unknown, use the? for it, e.g. sap? finds strings that are four characters long and start with sap.

The result is displayed in a table having a common structure, because items of config stores having different structures (columns) might be found.

ConfigItemKey holds the collected keys and Value the collected data fields of an item. Type of event provides information whether the item is still unchanged which means INITIAL or has got ADDED or UPDATED after the very first snapshot. The History of Item displays the current and the previous value with its time stamp (column Element History).

‘Switch table view' displays the items of the selected config store in a table which creates a column for each key and value fields. It is also possible to display the history of an item by selecting the row of the item.

The search has the following features:

• Search allows to search for item names and values in CCDB. Search output can be filtered per store
• The search result provides a common view for all items. A column view of a single store is possible
• Drill down into change history of an item
• HANA search supports OR to combine patterns and supports wildcard *
• \* searches for the character *

Store Browser and the Role of Config Stores

The single configuration details of systems connected to the SAP Focused Run 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 Focused Run system. There are various kinds of Config Stores dependent on the source of the data: Property, Table, File, XML and Event.

In the example below, you can see the content of the Config Store SAP_KERNEL which contains details on both the currently implemented kernel attributes as well as the change history of the kernel. The Store Browser has the following features:

• Store Browser displays all technical systems having config stores
• Store Browser displays for a technical system all available config stores
• It's possible to drill down into the config store content and into the item history
• Timestamp shows the last extraction date. “Valid since” shows since when item is unchanged
• A config store is always referenced to a landscape element

Since SAP Focused Run 3.00 FP01, there is the 'Trend Analysis' available which can be started by a dedicated tile from the launchpad.

With release 2.00 FP03 the 'Validation Storage' has been introduced which allows the scheduling of policies for instance for keeping validations results as a source for this trend analysis.

Functionalities of the Trend Analysis

• Selection of Single and Composite Policies for analysis
  (Prerequisite sees below)
• Selection of managed systems by regular scope selection
• Selection of time range
• Automatic time aggregation calculation based on time range
• Calculation of the validation result trend based on
  • Percentage of Non Compliant or Compliant items
  • Absolute numbers of Non Compliant or Compliant items
• Trend result with slope value
• Graphical trend representation per Composite Policy and Single Policies
• Drill down to trend analysis per policy and system
  • Trend Calculation on system level
  • Slope value calculation allows sorting to find most impacting systems
  • Graphical overview and detailed graphics by displayed systems
• Drill down to item result per policy and system
  • Check item validation result history
  • Filter for 'All Items', 'Most recent', 'Changed Items' and 'Added items'

Policy Prerequistes

• The Single or Composite Policy must be scheduled to make sure the validation results have been periodically saved in the validation storage
• The policy must have the status 'Generated'
• Only end user policies (version = '0000') are allowed

The Policy Management contains the Policy Maintenance and the Policy Catalog. Both areas are separated by a dedicated page. Here, the validation rules are defined and managed.

The Policy Management can either be started by a tile in the launchpad or via a link from the CSA Application.
 

Policy Maintenance

Since SAP Focused Run 3.00 Feature Pack 01, the policy maintenance consists of two types of policies: The regular 'Single Policies' and the new 'Composite Policies'.

Policy type: Single

The validation rules are stored in a XML file which is called 'Single Policy'.   

The rules are organized via checks which are identified by an ID and a description. Each check refers to one or multiple stores containing the configuration data to be checked. Each rule can consist of a compliant and a non-compliant rule. Finally, the XML policy definition must be generated which means that it is transferred to a SQL statement which is used for the validation of the items. Thus, validation can apply the policy to many systems in one run.

• A policy consists of multiple checks
• Each check has an ID and a description and can define a compliant and a non-compliant rule
• Join-combinations of rules are supported
  
• The compliant and non-compliant rule itself are defined using a sub-set of a HANA SQL where condition
  
• The check rules are using the column names of the stores 

You can either maintain the xml definitions directly in the policy maintenance editor or transfer it via copy & paste from an external XML editor of your choice. 

For details about policy definitions refer to Syntax Rules and Policy Check Examples .

Policy type: Composite

A Composite Policy allows to combine multiple Single and/or Composite Policies recursively. Its definition consists of references to other policies and therefore acts like a bracket around them.

Composite policies can be used as regular (Single) policies within the CSA environment: Selection of policy at the validation, Validation Alerting and by other use cases like the Operation Control Center.

Depending on the size and the number of connected managed systems it is recommended to schedule a composite policy for a precalculation. Here, the referenced policies inherit the scheduling of the composite policy. 

• Combine multiple policies into one Composite Policy
• Central scheduling using a Composite Policy
• Setup smaller single policies to simply its definition
• Use of Composite Policies within Operation Control Center for improved and steady performance

CSA Container (since SAP Focused Run 3.00 FP 01)

Next to the option to write policies onto a regular transport request there is the option to export or import either multiple Single Policies or a Composite Policy to or from a container on the frontend. Here, the container is technically a xml file containing the chosen policies.

The export can be started by the menu 'Others' => 'Export to CSA Container' for single and composite policies.

The import of a CSA container is started by using the button 'Configuration' next to the title of the page. Here, expand 'Import CSA Container' and select the corresponding file. Before the import starts there is a dialog showing the result of a comparison between the already available policies and the policies contained in the selected file. Here, you can select which container entries are to be imported.

• Policy movement between systems of different landscapes
• Manual backup of policy definitions
• Simplified import of provided SAP Service Content on GitHub.

Policy Catalog

The Policy Catalog allows an easy deployment of ready-to-use XML policies without having any detail knowledge on syntax or structure of a policy.

The idea of the Policy Catalog is to upload policies from an external data source, select the relevant checks and transfer them into active policies that are then used for validations and reporting. It can be useful if you want to provide a kind of policy check repository inside your organisation.

It is possible to manually change a check that had been initially created through a catalog policy. In this case it is necessary to change the check id, so that the Policy Catalog recognizes the change and does not overwrite the rules at next update.

Working with the Policy Catalog comprises the following steps:

1. Upload a tested xml policy from local file or from a remote URL into catalog policies. When uploading from GitHub, make sure that the policy is displayed in “Raw” format.
2. Select an active policy for your validation context. The policy must have been created and generated in Policy Management application before.
3. Manually select check items from catalog. Only complete checks can be selected.
4. Merge selected check items into the active policy.
5. Repeat these steps (if you want) to merge checks from multiple catalog policies into one active policy or if you need the same check be merged into multiple reporting policies.
6. Go to Policy Management and generate the changed reporting policy.

For updating a policy after having changed it in the catalog, the following steps apply:

1. Upload a new version of the policy to the Policy Catalog
2. Select the previously used active policy
3. Merge checks into the active policy. Checks will be updated from the catalog policy based on the check id.

CSA Administration is launched via the FRUN launchpad. The systems view groups the collectors according systems. The collectors view lists the collectors and hosts and for which systems the selected collector is responsible. A collector is related to a host.

CSA Administration offers next to the application the links to ‘CSA – Template Management' and ‘CSA – Processing'.

Systems

The System status screen displays a table of selected systems and their status from CSA point of view. On top of this table the numbers of systems which collectors are working ‘Correct', have ‘Warning' or ‘Error' or are ‘Delayed'. There is also an information how many systems in ‘Total' involved or have a ‘Downtime' currently. In the application you can find the following information:

• Check amount of errors per system. Select system with status „Error
• Identify the collector item which caused the error and select it
• The Extractor/ Processor error message is displayed and can be analyzed

Collectors

The data push is controlled by collectors running in the Simple Diagnostic Agent (SDA). The page 'Collectors' allows to get details about this CSA data collector. In general, there is one collector per host running for CSA.

Each collector sends a periodic health ping allowing to report its status by the traffic light in column 'Load Status'. Each collector does get a specific configuration which is deployed to them. The configuration status is reflected by the columns ‘Changed at', ‘Sent at' and ‘Confirmed at'. The ‘Version' and ‘Started at' are related to an agent.

• CSA collector status per host
• Find all managed systems using a specific host for data collection
• Status of configuration deployment from CSA point of view

Cross status

This feature allows to analyze one specific collector item in the whole connected landscape. Select a collector item and click on 'Display' to get a list of this single collector item for all managed systems.

• Analysis of the status of a specific collector item in the managed system landscape
• Get an overview how stable a collector item works
• Find similar problems of one specific collector item

CSA Processing

Started by the link 'CSA Processing' at the CSA Administration.

The CSA Processing helps the administrator to get an overview of the workload and times related to the data processing for CSA in SAP Focused Run. It enables the administrator to identify potential bottle necks and special situations. The views are arranged in ‘Inbound', ‘Inbound Queue Reader', Inbound Queue Processor, ‘Local Batch Collector' and ‘Log'.

The Processing dashboards offer several statistical information regarding the performance of configuration data collection. The graphical statistics display (see also the below figure):

• Number of Inbounds
• Average Write Runtime
• Number of Processed Packages
• Processing Workload
• Wait Times
• Application Data Processing Times
• Transferred Data Volume

Figure: Administration - CSA Processing

Template Configuration

Started by the link 'Template Configuration' at the CSA Administration.

The template configuration is the central place for defining which data is collected on the managed systems and pushed to the SAP Focused Run system into the Configuration and Change Database (CCDB) of the Advanced Configuration Monitoring (ACM).

It consists of two pages, the 'Template Management' and the 'Store Customizing'. 

Template Management

The collectors and the data to be extracted is controlled by template collector items. The template management is the tool for displaying and maintaining these collector items.

In general, the template management is reserved for SAP experts. The collector items delivered by SAP are following the naming pattern 'S<NNNNN>'. Enhancements and corrections of these collector items are delivered either by a feature pack itself or by the Rapid Content Deployment in a format of a package which always contains all SAP collector items as a version.

Custom collector items can be created by the naming pattern 'Z<NNNNN>' and are treated as individual items. This is possible since SAP Focused Run 3.00 FP00 by using the wizard functionality during the creation. A manual creation and maintenance is restricted to SAP experts because of the complexity of the xml definition. In contrast to SAP items, custom items can be written to a transport request.

Besides the semi-automated custom creation using the wizard, there is also a description available how to create collector items for specific needs at the page Best Practices .

• SAP collector items can be updated via the Rapid Content Deployment
• Custom collector items are transportable
• A wizard allows the creation of specific custom collector items (since SAP Focused Run FP00)

Store Customizing

There are collector items allowing to configure the data to be loaded by a so called store customizing. Customizing is possible only for small number of stores belonging to managed systems of type ABAP only.

In the xml definition of such collector items they are referring to store customizing data by the parameters CUSTOMIZING_TYPE and CUSTOMIZING_ID.

This tool allows the maintenance of this store customizing data which is identified by a customizing type and an id. Each type represents a specific table format which is required by a specific data extractor. For each type there can be multiple contents maintained which are identified by an id which is a three-digit number. Here, the numbers between 000-099 are reserved for SAP.