How ServiceNow Discovery uses sys_object_source

Carlos Guidugli · ‎07-20-2022

Hi,

Noticed that in our environment we have more than 50 million records on the sys_object_table. I understand how SCCM uses the table but it is not clear how ServiceNow discovery uses it. While SCCM uses the ID field as a key to find the target CI, discovery have fixed ID as "ServiceNow". So, does discovery uses it only to compare the last scan?

Another question, is it safe to remove entries from this table?

References:

https://docs.servicenow.com/bundle/sandiego-servicenow-platform/page/product/configuration-managemen...

https://docs.servicenow.com/bundle/quebec-it-operations-management/page/product/discovery/task/t_Cha...

Ken K1 · ‎02-24-2023

The sys_object_source contains the Source Native Key which is used for record correlation in SG-SCCM. This is different than in the original SCCM integration. As of this writing, the Source Native Key on sys_object_src contains a concatenation of SCCM resource id and the sys_id of the *connection alias in ServiceNow*. This changed in the 3.x SG-SCCM code updates from 2.x. When SG-SCCM runs it uses this value to correlate the source system (defined by the connection record) and the record from the source system (SCCM). If those values match, SG will pull over all the values through a transform load. If they do not match, it will drop into the IRE to do matching. So if the Source Native Key were empty, IRE would match on Serial for example and insert/ update the Source Native Key for that related record.
Correlation ID is no longer used for the integration as I understand it. So you might want to remove that from your IRE (CI Class Manager> Class). This change was made so that environments with more than one SCCM environment could co-exist without collission.

There is a risk by not understanding this and its not well documented when MIGRATING from one SCCM to another SCCM.
If these two conditions are met, then you will clobber your CI data and it is very very difficult to recover and maintain relationships with existing records (like assets).

Condition 1: The SCCM team re-uses or has overlapping resource id ranges between the "old" and "new" systems and the same data is not associated with same resource id from the old system. This is like changing the primary key on a record and will point to a completely different resource configuration. e.g. something that used to be a desktop record, could be a server record.

Old range: 160000 - 200000
New range: 159000 - 190000

Overlap : 159000 - 190000 (~31,000 records overlap)

Condition 2: You reconfigure the existing connection alias rather than create a new connection and associate it with SG-SCCM. This has the effect of telling SG-SCCM the "old" system and "new" system are identical.

If these two conditions are met, SG-SCCM will over-write all of the Source Key matched data from the new SCCM into the existing ServiceNow record. So a computer that might have been a Desktop could be overwritten with Server data. The recovery is very difficult because all of the IRE attributes (serial, name, mac) are all overwritten with the values from SCCM for the record.

When migrating It is critical to create a new connection ID vs. reconfigure an existing one for the new SCCM system and update SG to use it to avoid this issue.

View solution in original post

Rahul Priyadars · ‎07-20-2022

CARLOS

I do not see much GA docs on this topic.

I will suggest you to open a HI case and confirm the same.

I see lakhs of entries for Service Now Discovery Source also.

Regards

RP

Carlos Guidugli · ‎07-25-2022

Unfortunately support did not give any useful answer but I'll try again. Thank you

Shreya Jain1 · ‎08-25-2022

Did you find out how ServiceNow Discovery uses "sys_object_source" table?

Regards,

Shreya

Carlos Guidugli · ‎08-29-2022

From what I could read and check, sys_object_source is used by integrations like SCCM and ServiceNow features like discovery. SCCM uses a correlation id to map to a CI. But discovery do not use any ID to find a CI. From what I could read it seems discovery search for the CI reference only to retrieve the last discovery date.

Since this table works like an indexing, it is safe to delete contents. I am testing deleting records where last scan is older than 3 months using table cleaner. So far, no issues.