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.

[SwarnadeepNandy]

Hello @Claire Ashdown1,

The sys_object_source field is a reference field that points to the sys_object_source table, which contains information about the data sources that are integrated with ServiceNow. The sys_object_source field is used to track the origin of the data that is imported or updated in the CMDB. It is also used to prevent duplicate records from being created by different data sources.

The IRE module uses the sys_object_source field as one of the criteria for identifying and reconciling data from different data sources. The IRE module has a set of predefined identification rules that define how to match data from different sources based on certain attributes, such as name, serial number, MAC address, etc. The identification rules also specify which source has the highest priority or authority for updating the data in the CMDB.

The Hardware Rule identifier is one of the identification rules that applies to the cmdb_ci_computer table. It uses the sys_object_source field as one of the attributes for matching data from different sources. It also gives priority to the source that has the most recent discovery date. This means that if two sources have conflicting data for the same computer, the source that discovered the computer last will update the data in the CMDB.

However, this does not mean that the sys_object_source field is only used for identification lookup by the Hardware Rule identifier. The sys_object_source field is also used by other identification rules and by other tables that are related to the cmdb_ci_computer table, such as cmdb_ci_hardware, cmdb_ci_network_adapter, etc. Therefore, even if you customize the identification rules for cmdb_ci_computer such that the identifier looking up on sys_object_source is not used anymore, you may still see identificationAttempts to sys_object_source with a MATCHED result when you run identification simulation for a JSON payload. This is because other identification rules or tables may still use the sys_object_source field as part of their matching criteria.

In summary, the sys_object_source field is used for identification lookup by multiple identification rules and tables, not just by the Hardware Rule identifier for cmdb_ci_computer. It is also used for reconciliation and preventing duplicates by indicating the origin and priority of the data sources. You can find more information about how IRE works and how to customize it in these articles

Hope this helps.

Kind Regards,

Swarnadeep Nandy

[Claire Ashdown1]

Hi Swarnadeep,

This is very helpful information, thank you very much. The particular import I am exploring is the SCCM SGC Computer Identity import which only maps to cmdb_ci_computer (not using the hardware rule in my testing), cmdb_sam_sw_install (not available in the CI Class Manager to configure identification rules), and cmdb_key_value (not available in the CI Class Manager to configure identification rules). It sounds like from what you all are saying and from Identification and Reconciliation engine (IRE) (servicenow.com) that sys_object_source is used for identification first, and if a match is not found, only then are identification rules used.

[SwarnadeepNandy]

Hello @Claire Ashdown1,

Identification rules are used to find a match. It acts like coalesce value in your transform map. Identification rule decides if a CI should be created or not. Reconcilliation rule comes into play during update of the CI.

Within Identification rule you have priority as well.

Hope this helps.

Kind Regards,

Swarnadeep Nandy

[michaelward]

Quite helpful, but a follow-on question.  How is sys_object_source inserted/updated?  Is it as a result of ultimately calling the IdentificationEngineScriptableApi functions for insert or update?  I ask this because I have a situation where a Robust Transform (FlexeraOne scoped app) inserts hardware/computer CIs, but NOWHERE in its code does it call IdentificationEngineScriptableApi or CMDBTransformUtil, however we see sys_object_source records flagged as 'FlexeraOne'.  In addition, NOWHERE in their entity field mappings do they set a discovery source.  It would be helpful to know how sys_object_source is populated, OOTB, or with regard to IRE usage.