8.2 Understanding Element Correlation Methods

Correlating different types of elements from various sources can be accomplished using different methods. Consider the advantages and expected results when selecting a method of element correlation.

8.2.1 Understanding Rule-Based Correlation

The rule-based correlation method uses SCM to copy element structures provided by CMDB sources with the Data Integrator, providing rule-based correlation in the SCM Generation policies to correlate structural data and monitoring sources (BSM).

This method involves creating service configuration definitions, as described in Section 8.3, Creating Service Configuration Definitions. The SCM modeling policies are used to generate rules that match and associate elements originating from different sources. As an example, a CMDB source can contain a list of hosts, and a list of applications that depend on hosts. The modeling policies correlate each host to a monitoring source, such as IBM Netcool Omnibus or CA Spectrum, associating element conditions and alarms with the resulting model. A potential drawback is that the SCM definitions used to generate these models can become large and unwieldy because each type of element requires a different set of rules to perform the correlation.

8.2.2 Understanding Class-Based Correlation

An alternative correlation method uses element class. Using this method, SCM generates an element structure by copying a BDI definition data source to the service model, and based on class, the Operations Center correlation engine automatically associates elements of specific classes. This approach uses element class relationship templates to perform correlation. The advantages of using class-based correlation:

  • Simplifies the SCM definition by eliminating multistep definitions to generate correlation rules for different element types.

  • Does not require relationship data to be stored as persistent information for each element. This can dramatically reduce the element and relationship storage requirements for a Operations Center implementation.

Many use cases exist, but a simple one involves correlating elements with same name but different classes. For example, assume that service model elements with the server class should be correlated with same-named elements with the hosts class, in a branch of the Elements hierarchy.

To accomplish this correlation, create a Class Relationship template for the server class, then select a branch in the Elements hierarchy that should be automatically correlated. This template includes a DName match template, similar to the Dynamic correlation FIXED policy in SCM (for more information, see STEP 6: Select Element Correlation Options).

A sample result is creating a server class element named deptserver11 in the Service Models hierarchy that automatically generates a static relationship with an element named deptserver11 in the Elements hierarchy. Element conditions and alarms are also correlated.

Class Relationship templates are defined as part of the Metamodel class element properties. For details on creating the templates and common use cases, see Defining Class Relationship Templates.