Why does Discovery not use sys object source table like its intended to?

[Ravish Shetty]

Hi all,

We are running both agent based and agent less discovery and see that the ID field in sys_object_source table is either 'servicenow' or 'AgentClientCollector' as we see below

The issue we see is that when discovery runs again for the same CI, it will re run the IRE rules since it wont find a unique match for the CI in this table. Other integrations like Qualys populate unique ID field and this way the IRE does not get called all the time and ideally just once for a given CI.

Is this behavior of having a non unique value in the ID field out of box? It feels strange that ServiceNow's tool like Discovery itself doesn't make use of the sys_object_source functionality which can prevent performance overhead.

Thanks,

Ravish

[Ciageng]

Discovery does use the sys_object_source table, but its usage depends on the integration and the specific discovery source, as it's not always the primary or sole source of truth for identifying a CI's origin. Different discovery methods, such as Service Graph Connectors and patterns, interact with the Identification and Reconciliation Engine (IRE) which can populate sys_object_source with data from various third-party systems, including SCCM. However, the exact population depends on the specific sensor or pattern logic, and sometimes other fields are updated first, with sys_object_source added later or populated by the IRE.

[SK Chand Basha]

Hi @Ravish Shetty 

There is a system property to override this behaviour

If make it true , checks whether CI already exists discovered with matching criteria (discovery_source=ServiceWatch OR ServiceNow) and instead of re-discovering, link agent record to existing CI.