Help understanding how sys_object_source is used in IRE identification/reconciliation

[Claire Ashdown1]

Question about the CMDB IRE and how sys_object_source is used, specifically with the SCCM SGC. https://docs.servicenow.com/bundle/vancouver-platform-administration/page/integrate/cmdb/reference/h... makes it sound like that sys_object_source is used for identification lookup only because of the Hardware Rule identifier that applies OOB to the cmdb_ci_computer table. However, in my testing with some customizations to the identifiers for cmdb_ci_computer such that the identifier looking up on sys_object_source isn't used for cmdb_ci_computer anymore, I'm still seeing identificationAttempts to sys_object_source with a MATCHED result when I run identification simulation for a JSON payload. Rather than saying sys_object_source is used for identification lookup for the reason that documentation page says, is it more accurate to say stuff using the IRE and going through IntegrationHub ETL all just use sys_object_source all the time, regardless of identification rules?

Many thanks for your help and clarification.

[Claire Ashdown1]

Hi Venni,

So just to clarify, in the documentation you shared, where it says (emphasis mine): "The CMDB identification process relies on identification rules to uniquely identify CIs. When possible, CIs can also be uniquely identified using source_name and source_native_key values provided in the sys_object_source_info section of the payload, and the Source [sys_object_source] table. If identification is successful using that method, then it is not necessary to apply matching algorithms that rely on identification rules, which is a slower identification method."

Even though "The CMDB identification process relies on identification rules to uniquely identify CIs" is listed first, the fact that identification "can" use sys_object_source actually occurs first in the identification process? So the identification process doesn't actually rely on identification rules, it uses identification rules only if the sys_object_source fails to return a match. That's what the final sentence of that paragraph sounds like, but just trying to make sure I understand correctly (emphasis mine): "If identification is successful using that method, then it is not necessary to apply matching algorithms that rely on identification rules, which is a slower identification method."

Am I understanding the documentation correctly? Many thanks for the clarification.

[VenniMakarainen]

Correct, sys_object_source is used first if related info is present for IRE to process.

 @CMDB1 referred to potential stale entries which is also discussed in this article: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1500531

Also, a scheduled job to clean up sys_object_source was noted in the comments of this post -> the job is also discussed in this article: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1198927

[CMDB Whisperer]

Thanks for the links. 

Unfortunately, as is often the case with ServiceNow KB articles (for some unknown reason), they are sometimes (arbitrarily it seems) only visible to those with an active Support account, which so many very technical users and stakeholders don't have, because those support accounts are not provided to all users in a company, and are typically allocated only to developers and platform administrators.  Not sure what the rationale would be to hide knowledge from users who don't have a Support contract.  It would be great if ServiceNow would rethink this policy and provide KB access rights to all users.  In the meantime, if ServiceNow employees post links to KB articles it would be great if access can be verified first, or simply print to a PDF and share the attachment.  Thanks for considering my feedback!

[VenniMakarainen]

Please, submit any ideas through our Idea portal (I know, requires access to Now Support as well):
- https://support.servicenow.com/ideas?id=ideas_list&sysparm_module_id=enhancement_requests

Customers govern their users' access to Now Support and can work internally to review required resources. I'll not share any article as an attachment for two reasons:

1. I need to respect our internal policies (if something is accessible via a login only, I should not help skip this)

2. Our articles on Now Support are governed, an attachment here is not. Any article updated to a new version would not be reflected to the point-in-time capture of that article. Much better to lean on to the source directly when possible.

I appreciate the feedback though, we do not live in a perfect world.

[CMDB Whisperer]

I only recently gained access to Support so I will use your suggestion and submit to the Ideas portal, though from previous experience I am not sure when or if it will get reviewed.  Thanks for the response and candor.