Preempting asset or CI duplication during automated creation
Before creating any generic, the asset-CI reconciliation task performs several searches to ensure there are no existing authorized CI or asset matches that have been missed. The searches prevent duplicating an existing asset or CI by creating a generic CI or asset unnecessarily.
First, the asset-CI reconciliation task checks the original authorized CI or asset to see if there is a link to a discovered counterpart (a deployed asset or an actual CI) with a DIS GUID that can be used to find any corresponding asset or CI. Second, the reconciliation task checks the original authorized CI or asset to ensure it contains enough link rule data (attributes and values) to find any matching asset or CI that might exist. In the second case, during asset-CI linking the CI or asset to be matched must include all the attributes and associated data (with no blanks) specified in at least one link rule that the asset-CI reconciliation task is configured to use.
Scenario for duplication
Consider this scenario, which results in an unintended duplicate being generated during automated creation: an authorized CI, AIX-Server, is created in the product database through the purchasing process or by importing it using the integration framework. AIX-Server does not have complete information (in this scenario, a serial number) until the discovered data from its actual CI is imported into the product later from the TADDM discovery tool.
Meanwhile, automated linking is enabled, so the asset-CI reconciliation task will try to link the authorized CI to its corresponding authorized asset, if there is one.
The asset-CI reconciliation task uses the following link rule:
CISPEC.COMPUTERSYSTEM_SERIALNUMBER=ASSET.SERIALNUM
This rule states that if the serial number of the original authorized CI, AIX-Server, is identical to the serial number of an existing authorized asset, that CI and asset represent the same IT resource, and should be linked. The asset-CI reconciliation task is active and running. But at this time, the original CI, AIX-Server, does not have a serial number. So there is no serial number available (that is, not enough information) for the reconciliation task to use to find a matching asset—which, in this scenario, actually does exist.
In this case of insufficient information, you do not want the reconciliation task to duplicate the existing asset by creating a generic one. Here is what will happen if it does: When discovered data for the actual CI is eventually imported, the authorized information for the AIX-Server CI will be updated with the discovered serial number. When the reconciliation task runs again, this time it will find that existing AIX-Server asset with the matching serial number. Now you have duplicate assets—the newly found asset with the matching serial number and the generic asset that was created in a previous reconciliation task run.
How the reconciliation task preempts duplication
To avoid such duplication, the asset-CI reconciliation task checks the original authorized asset or CI to ensure it has sufficient attribute data (with no blanks) for the link rule to use before making any attempt to link the resource to a target or create a generic. In the other words, before creating a generic asset or CI, the reconciliation task makes sure that the original resource has enough information to ensure duplicate prevention, based on the reconciliation link rules.
The validation process is this: the asset-CI reconciliation task examines each of its link rules, one by one. For each link rule, the reconciliation task makes sure that the authorized asset or CI being matched to a target has sufficient link rule attributes and values to actually find the target CI or asset, if it exists. The authorized asset or CI to be matched must have all the attribute data from at least one link rule in the asset-CI reconciliation task before the reconciliation task attempts any automated linking using that rule.
Unless such attribute data is found, the reconciliation task cannot create a generic. Instead it writes a warning message to the SystemOut.log file (if the cron task logger is active and set to WARN level), stating that there was insufficient information available to create a generic.