No more Duplicate CIs please

[Henrik Jutterst]

I'm looking for a way to stop creating Duplicate records of a CI based on rules in IRE.

I've created duplicate CIs with the same name in the Windows class.


I was hoping to find a setting so that I get a error message from IRE if there is a duplicate CI that is beeing inserted or updated, but I'm not sure if there is such a setting?

 

CMDB View says this:
20 Windows Servers that are duplicates.

The settings I have switched back and forward are these:

 

So, tell me - is there a setting for preventing a user/integration to submitting duplicates and what does it look like?

Here's a toping regarding this: https://community.servicenow.com/community?id=community_blog&sys_id=3efc66a5dbd0dbc01dcaf3231f96193b

Looking at this post it says:
"When duplicates are detected, the CI payload still may or may not be written to a record in the CMDB.   This depends on the system property named glide.identification_engine.skip_duplicates.   This is an internal system property in the sys_properties table.   By default, the skip_duplicates property is set to true (default value).   This means that if duplicate CIs are detected by the IdentificationEngineScriptableApi function, the CI payload will overwrite the oldest duplicate CI.   That is the CI with the oldest date/time in the updated field.   If skip_duplicates is set to false, then the CI is rejected and none of its fields are written to the CMDB."

Nope. Not getting that result when adding a new CI after a new CI..

[Henrik Jutterst]

Yes I did create the CIs manually.

Is there a way to trigger IRE for manual created records?

I really don't want to go through the hassle and build something custom for user input scenario. We have some users that will create CIs manually but I'm looking for IRE to step up here and assist.

[vNick]

Unfortunately I don't see how you can plug-in the IRE processing to standard CI forms as they are just going to go straight to the table API in all likelihood.  I would have to see if the new UIs are going to inject IRE processing for CI data pages.

[Henrik Jutterst]

Thank you so much for answering @vNickNOW . I've read your articles some times regarding "Getting Started: CMDB Health Automation" and really appreciate you taking the time to write those!

One question though: In your article that I mentioned above, you never refer to the table called [reconcile_duplicate_task] when managing Duplcates. Is that still the case or should I modify the script to also handle records in that table?

Script mentioned in your post to handle Duplicate CIs:

// Find all duplicate records associated with the current task
var grResult = new GlideRecord ('duplicate_audit_result');
grResult.addQuery ( 'follow_on_task', current.sys_id );
grResult.query();
var cis = [];
while (grResult.next())
	cis.push(grResult.getValue('duplicate_ci'));

// Query for the duplicate records, and order in reverse chronological order
var grCi = new GlideRecord ( 'cmdb_ci' );
grCi.addQuery ('sys_id', 'IN', cis.toString());
grCi.orderByDesc ('sys_created_on');
grCi.query();
grCi.next(); // Skip the CI that was created first
while (grCi.next())
	grCi.deleteRecord();

[vNick]

Hello - the reconcile_duplicate_task table is the one that the workflow is actually triggered from and what I'm referencing in the first "addQuery" when looking up the "follow_on_task"... that's the reconcile_duplicate_task table.

The duplicate CI remediator does a great job of merging data and handling relationships more elegantly than my brute-force example here that just deletes and hope things cascade (not a good strategy in reality).  However, the remediator does not have programatic access due to so many inputs required so hopefully you'll come with a strategy for handling more gracefully.  I'm sure the community could benefit from whatever you may come up with.

[Henrik Jutterst]

Thank you for the shared feedback.

In this particular case we have many Duplicate tasks that only have 2-5 CIs in the task, and since the manual process is painfully slow to run, your batch solution might be a temporary solution to the issue.

CMDB is such a crucial backbone in the platform so I was looking for a quick fix at this moment and then set sort of a baseline for the coming Duplicates.

If you know of any more graceful way to solve the issue, feel free to link to it. But yeah, there seem to be a lack of examples here.