Idea ID 1668590
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">
<attribute name="\x00" value="servername" compare-type="regexp" />
- 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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.