Troubleshooting reconciliation based on error messages

From the error message we can know that the class form is BMC.CORE:BMC_ApplicationService. The qualification used is <'Name' = $Name$> and value of the Name attribute is <Name = Apache HTTP Web server>.

The solution to this error involves identifying the duplicate CIs that use the attributes used in identification rules. For the example error message, you can perform the following steps to troubleshoot this issue:

1. Open the BMC.CORE:BMC_ApplicationService form in a browser.
   http://<midTierServer>:<port>/arsys/forms/<ARServer>/BMC.CORE:BMC_ApplicationService/
   The qualification used is <'Name' = $Name$> and value of the Name attribute is <Name = Apache HTTP Web server>
2. Search the BMC.CORE:BMC_ApplicationService form for the Name attribute with value equal to Apache HTTP Web server.
   The search may probably return more than one record.
3. Identify the attributes other than those existing in the identification rules to differentiate CIs and then add those attributes to the identification rule.
   You may also use the Data Analyzer tool to find the duplicate records. 
4. If there are genuine duplicate CIs which need to be removed, you must perform the following steps:
   1. Take a backup of the Remedy database or the class form data before purging the duplicate CIs.
      Once the duplicate data is identified with the help of the data or asset owner, the CMDB administrator can mark these CIs as deleted and then use the reconciliation engine job to purge them.
   2. From the multiple matching records, find the ones you want to retain.
      This can be based on, for example, the CreateDate, ModfiedDate, Submitter or any other attribute value that differentiates duplicate data from the original one. 
   3. Update the MarkAsDeleted attribute of these duplicate CIs to yes.
      You can perform this step manually, using Atrium Integrator, or a database query. 
   4. Use the reconciliation purge activity to remove the CIs that are marked as deleted from the dataset . 
      Before this step, you must verify the CIs which are to be purged. 

This error "ARERR [120092] The dataset ID and Reconciliation Identity combination is not unique" means that the same reconciliation identity cannot be assigned to another CI in the same dataset. This is expected behavior. To resolve the issue, you must find out why the reconciliation job was trying to assign the same reconciliation ID to another CI in the same dataset.

The class mentioned in the above error message is BMC.CORE:BMC_ComputerSystem. There are out of the box and custom identification rules for each class. 

The following example shows the BMC_ComputerSystem class identification rules.

The priorities shown in the example show the sequence in which the rules check for CI duplication in the target dataset (BMC.ASSET). The priority proceeds to the next available rule until it reaches the final one. 

Let’s assume that the following CI records are for BMC.CORE:BMC_ComputerSystem.

If we compare the above record table with the Identification rule for BMC_ComputerSystem class, the serial number is common for Dell and HCL laptops. Let us further assume that the fields for the Virtual and PartiionID attributes are NULL for Dell and HCL Laptop CI records. In this case, only the attribute Serial Number carries a value and this attribute shares the same number between these two CI records.

When the reconciliation job runs, the CI passes the first and second priority rule. After that, the job identifies the CI on the third rule based on the value of Serial Number considering that the isVirtual and PartiionID had NULL values. The job tries to assign the reconciliation ID OI-E7315F17CAC04E8AB89C2D5E8E924595 to the CI representing the HCL 200 Series Laptop in BMC.ADDM. This results in the error being logged.

Considering the above example, we must populate the correct values for the attributes such as isVirtual and PartitionID.

In other scenarios, you must identify the identification rule that may be causing the duplicate CI data in the source dataset or fix the source application configuration which is sending the CI data to the source dataset (BMC.ADDM in this example).

From the example error message, you can know that the Relationship Class record in BMC.CORE:BMC_HOSTEDACCESSPOINT could not be merged for the attribute MarkAsDeleted to No. The reason for the error is that you were attempting to set MarkAsDeleted to No for a relationship instance for which one or both endpoints are already soft deleted, that is, set to MarkAsDeleted. 

Example:

Relationship Endpoint Class records for BMC_IPEndpoint and BMC_ComputerSystem.

Relationship CI record for BMC_HOSTEDACCESSPOINT joining BMC_IPEndpoint and BMC_ComputerSystem.

If you try to set the attribute MarkAsDeleted to No for the previously mentioned relationship CI record, it will result in the following error message. 

ARERR[120141] Cannot set MarkAsDeleted to "No" on the relationship instance because one or both of the relationship endpoints are MarkAsDeleted.

This error occurs because you cannot set the value of MarkAsDeleted to No for the Relationship Class record in case the endpoints of relationship record MarkAsDeleted are set to YES. 

Set MarkAsDeleted to No on both endpoints of the relationship before setting MarkAsDeleted to No on the relationship instance.