We'll also be publishing a how-to tutorial this week to help less experienced people modify these rules and configurations themselves. We need to move past this problem universally as there's so much great stuff just waiting beyond a few simple problems we've learned how to solve. It's all out of the box capabilities that already exist in the tools.
We rely on Global ID and we allow names of CIs to be changed in the other environments during the integration. For example, the SM Adapter is capable of changing the logical.name and retaining all other attributes.
Resulting in a Running Software CI record with a logical.name of "HostNode_RunningSoftware" in SM. We take this a step further and normalize the naming convention to match how UCMDB displays its Running Software CIs,"RunningSoftware (HostNode)"
We ensure that global ID is moving between each system. Global ID simplifies reconciliation in the downstream tools.
In SM, all other reconciliation is bypassed once a matching global ID is identified. (p.102, ServiceManagerAdapter9-x). To ensure the integration is using the global ID, we make sure the adapter is configured to move only the global ID during the integration. In the ServiceManagerAdapter/sm.properties on UCMDB we set "use.global.id" to "true".
If there is a global ID mismatch, we use the Global ID Pushback mechanism in UCMDB to realign the IDs, which occurs after a CI successfully reconciles in a population. The attributes we use match the reconciliation rules set by UCMDB. In most cases, it uses IP address, mac address and serial number to identify the CI for reconciliation. Even if attributes are missing, names alone are not used to identify a node and we use 100% reconciliation matches only (out of the box these are 66% for MAC).
We also configure all environments to not create duplicate records. This ensures that if duplicates are present in the upstream system, they will not create invalid records that in the downstream system.
To prevent this from SM, we use the Discovery Event Manager for ID: ucmdbNode, Table Name: joinnode is set to throw a warning and prevent creation of a duplicate record. You change this "Duplication Rule" from "rename" to "Return Error" and voila.
When updating data, we leverage the global ID. Links to undiscoverable data and most other relationships are established using Object, which can reconcile on global ID alone.
Additionally, jobs that are tasked to create relationships are only allowed to create relationships, so if an invalid CI is found on one end of the relationship, it will not be created in UCMDB.
Such as in the SM adapter, where the data type only permits relationships: <tql name="ESG SM Infrastructure Service Contact Population" xslFile="esg_infrastructure_service_contact_pop.xslt"> <request type="Retrieve" dataType="relationship" retrieveFileList="file.device"
Or in AM, where the actual relationship structure is defined: <entity class="generic_db_adapter.organization_ownership_node"> <table name="View_deviceDepartement"> </table> <attributes>
The main thing to keep in mind is that NAME is used as a primary source of reconciliation. That's fine when there's only ONE version of a device name. The moment there are two your systems automatically go about reconciling the contained and composite data and ultimately create duplicates, or worse, delete the wrong object because it has a partial match from MAC or a full match from NAME. Trying to clean up a duplicate without modifying the adapter and DEM rules in ITSM will result in a very big mess, very quickly.
We know, you know, because everyone runs into this problem.