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.

[CMDB Whisperer]

On one hand, your statement that sys_object_source is used regardless of identification rules is accurate, but on the other hand, I don't see where the product documentation states that the use of sys_object_source depends on the identification rules.  Can you specifically point out where the documentation is confusing you?

[Claire Ashdown1]

Hi CMDB Whisperer,

Thanks for the quick response! I am referring to this line from the SCCM data import process and source tables (servicenow.com) documentation: "The Hardware Rule identifier returns the resource ID of a computer from SCCM and stores it in the Source [sys_object_source] table." It makes it sound like the reason the resource ID is stored and used via the sys_object_source table is because of the Hardware Rule identifier, not just by virtue of how the IRE works. With my testing of the Computer Identity import that only maps to the cmdb_ci_computer table, and with the customization I am testing that does not use that OOB hardwware identification rule for cmdb_ci_computer, it seems like the IRE just uses sys_object_source no matter what, not because of the Hardware Rule identifier, but I wanted to double check that assumption because it seemed like that documentation I was consulting was communicating a conflicting message.

[CMDB Whisperer]

Thanks for clarifying.  I agree that a more accurate wording would be "The Service Graph Connector for SCCM returns the resource ID of a computer from SCCM and stores it in the Source [sys_object_source] table."  If you log on to the product documentation page you can actually open a case with ServiceNow and suggest this correction to the documentation.

I will also note that the sys_object_source table has been around for a while, and I have seen issues where old entries don't get cleaned up properly and this has caused identification issues.  There is a scheduled job out there that may clean up some of those entries, but I would recommend looking at that job and either modifying it or creating a separate job to ensure you are only using fresh entries.  Since the table is there to basically cache the results determined by the IRE, like any other cache the results can become stale and incorrect after a while.  While the use of this table can in theory speed up your CMDB identification operations, in my opinion it comes with a trade-off in accuracy if you don't keep that cache up to date as your identification attributes and identification rules may change over time.  You may want to basically make those object source entries expire after a while by creating a job that will delete them after a while, thus forcing the next identification attempt to reevaluate the identification rules.

[VenniMakarainen · Accepted solution]

Essentially, sys_object_source is a shortcut for IRE to look up matching CI using the incoming payload before applying any configured identification rules:
- https://docs.servicenow.com/bundle/utah-servicenow-platform/page/product/configuration-management/co...

If a match cannot be made through sys_object_source with a given payload, IRE proceeds to look up a CI using the identification rules.