Remediating De-duplication Tasks without running business rules in backend

seanbagdan
Tera Contributor

Hi All, 

 

We are attempting to remediate de-duplication tasks in our CMDB but are running into an issue with a custom business rule aborting the task. The custom business rule is old and we are looking to move to OOB, but this BR ensures that no duplicate names are allowed to be created in the CMDB. Some processes like discovery are excluded from this BR, hence the reason there are some dupes created from discovery. Is there a way to run the de-duplication workflow without using business rules in the backend? Thanks for any help here!

 

Sean Bagdan

3 REPLIES 3

Marshall Parker
Tera Guru

The OOB de-duplication workflow appears to be code that is not accessible for us to modify beyond the visible configuration [i.e. which tables to merge references, whether to update or delete a duplicated CI, etc..]

 

You mention that some processes don't go through this custom BR -- I would take a look at how that BR is designed and see if there is something you can do to adjust or remove it to allow the de-duplicator to work as-is.

 

As you are running the de-duplicator - are you trying to update the invalid CI & leave it in place with certain attributes, or are you deleting the invalid CIs?  Trying to understand why after a de-duplication you would be left with a duplicate record still.

Hi Marshall, 

 

I appreciate the response. I am attempting to archive the invalid CI after remediation, but the task is never able to complete due to the abort by the BR. It seems the task is not able to finish because the BR sees two entries with the same name and aborts. The error I get from the de-duplication task log is as follows:

Errors in updating duplicate CIs:

Operation against file 'cmdb_ci_db_mssql_instance' was aborted by Business Rule 'CI Name^77be0bf4870d5610a08fcbf5dabb351a'. Business Rule Stack:CI Name

If you are archiving the CI, hopefully you have a pattern of fields you can use to isolate this [maybe Install Status or Life Cycle Stage is a specific value, etc..]

 

Good news is you are being told exactly what BR is stopping this [CI Name .. the specific sys_id is also in that error code]

 

.. you could take a look at this BR and add an exclusion so that it does not check for archived items.

 

For example ..

if your archive method is to set Install Status = Absent [value=100]

Then the duplicate check in your BR could be set to look for a count of other CIs with the same name and an Install Status anything other than Absent