Enhance the normalization rules engine

Idea ID 1668590

Enhance the normalization rules engine

Normalization rules are very useful as they alter the result vector before being sent to the server on each probe. The resut vector is enriched/normalized on each probe in a descentralized manner so the server receives the desired form or the result vector.

The workaround currently used is to alter the CI data from discovery with the help of enrichments. This can have server side performance and that data will pass thorugh the reconciliation engine twice: 1st time comming from discovery and the 2nd time after being altered by an enrichment. This causes a lot of overhead and can be avoid with normalization rules if we have the case of a simple triplet.

The restrictions of the normalization engine are clear in http://cmshelpcenter.saas.hp.com/CMS/10.22/ucmdb-docs/docs/eng/doc_lib/Content/dfm/adap_config_c_rules_syntax.htm for 10.22

Points in this rule which are not supported now by the current normalization engine and should be available:

example, servername is a custom attribute

<ns2:normalization-rule ci-type="file_system" id="9666">

            <rule-input>

                <attribute name="\x00" value="servername" compare-type="regexp" />

            </rule-input>

            <rule-output>

                <attribute name="servername">

                    <value>$root_container</value>

                </attribute>

            </rule-output>

        </ns2:normalization-rule>

  • We can’t use as rule-input an attribute which isn’t in the result vector. Here we use servername attribute which is never modelled via Jython scripts so it will never be in the result vector of discovery.
  • We can’t use a regular expression for a null value of an attribute
  • We can’t assign in the rule-output a parameterized value to an attribute. In our example, we can’t clone an attribute value on the same attribute.
  • We can’t reuse attributes in any form (we can use only static values)

The question would be what is the impact on probe side.

Tags (1)
3 Comments
Micro Focus Contributor
Micro Focus Contributor

Hi, Did you look into using the data validators: http://cmshelpcenter.saas.hp.com/CMS/10.22/ucmdb-docs/docs/eng/doc_lib/UCMDB_docs.htm#dfm/probe_setup_c_data_val_content.htm ?

It  allows one to create a script that can look at the content of the resulting object state holder vector and modify attributes as needed (as far as I can see most, if not all requested capabilities can be covered by this feature). So my suggestion is for the customer to evaluate this feature to see if can be used instead. The only downside is that it is not a rule (data), but requires scripting (code).

Micro Focus Contributor
Micro Focus Contributor
Status changed to: Waiting for Votes

The idea has received an initial review to ensure adherence to our idea submission and community guidelines. More information may be needed at this stage and we expect the community to help prioritize the idea with comments and voting.

 

Current suggestion is to use the data validators.

Valued Contributor.. Valued Contributor..
Valued Contributor..

Data Content Validation is the correct way to go. Since UCMDB 11 the piezo library is included, which provides some helper functions to search and manipulate data in the result vector.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.