Service Graph Connector for Sccm - How is the unique key being set

[anfield]

Configuring the Service Graph Connector for SCCM (version 2.5).I am trying to find where the unique key (for each computer) is being set. It looks like the concept of coalesce is gone? We used to have the unique key set as the resource id, so I am trying to find out if this has changed in the new connector, and how it is being set?

Thanks

[#2 · Accepted solution]

Service Graph connectors all go through the IRE (Identification and Reconciliation Engine) which does not have a concept of coalesce, but rather uses the IRE rules for identication.  You can inspect the rules for each class through the class manager.  The "unique key" in this case is the source native key.  The source native key is populated through the IH-ETL mappings and changes by target class (for SCCM computers it is the resourceId).  You can see the source native key values in the sys_object_source table as the id field.

Here is a flow of how a record is inserted/updated

• 1st time running the integration
• A IRE payload is generated through the IH-ETL mappings (let's say a computer payload) and is sent to the IRE
• The IRE attempts to identify if the computer already exists in the CMDB via the identification rules defined in the class manager for that particular class (serial number lookup, serial number, name, mac addrees + name OOTB for computer)
• If the IRE finds a record the record is updated with the values passed in the payload & a record in sys_object_source is created with a source native key and a target sys id of the record updated
• If the IRE doesn't find a record a new record is inserted & a record in sys_object_source is created with a source native key and a target sys id of the record created
• Subsequent runs of the integration
  • A IRE payload is generated through the IH-ETL mappings and is sent to the IRE
  • If the source native key exists in the sys_object_source table for the given discovery source it will bypass the IRE and immediately update the record in the matching target sys id field.
  • Otherwise
  • If the IRE finds a record the record is updated with the values passed in the payload & a record in sys_object_source is created with a source native key and a target sys id of the record updated
  • If the IRE doesn't find a record a new record is inserted & a record in sys_object_source is created with a source native key and a target sys id of the record created

In this sense the "unique key" is only going to be used to identify a record after the system has already seen the record flow through the IRE.

Hope this helps, and if you are just learning about the IRE I would recommend reading up on it for more details.

[Community Alums]

Hello @jgates ,

We also want to do the same. The only additional part we want to do is we also want to check if the CI present in the Target field on "sys_object_source" has the correct serial number coming from SCCM.

If yes, update the Target record.

If no, then check the "Computer" table for that serial number and update the correct CI and then comeback to delete the record in "sys_object_source" with the previous record.

Can you provide any suggestions on this?

[#4]

Manish,

I'm not sure I understand your ask, or your use case.

• SCCM reports multiple different serial numbers.  The system serial number gets stored on the computer record, but there are other serial number types such as bios, baseboard, etc.
• Serial Numbers are used by the IRE for identification OOTB.  There are rules for both serial number lookup and the serial number on hardware.  These should take care of matching by serial number.
• If you are essentially asking for a way to never use the sys_object_source table and only go through the IRE you could run a post-import script to clear out the sys_object_source table where name = SG-SCCM.  But I'm not sure why you want to do this.  It will have adverse performance and the IRE already went through the work to identify using serial number.

[Pascal Vinke]

Hello @jgates ,

I've understand your text and the steps taken how the IRE inserts the source native keys into the instance. I've also taken the Service Graph Connector Essentials Training Course on Now Learning but I have still one question left:

How are duplicate serialnumbers handled? Within ServiceNow devices get imported into [sn_sccm_integrate_sccm_2019_computer_id]. All devices (in our case 26) have the same serial number "Default String" but of cause a different name and Resource ID.

• The IRE attempts to identify if the computer already exists in the CMDB via the identification rules defined in the class manager for that particular class (serial number lookup, serial number, name, mac addrees + name OOTB for computer)

For the first device a new CI entry + native key gets generated.

• If the IRE finds a record the record is updated with the values passed in the payload & a record in sys_object_source is created with a source native key and a target sys id of the record updated

For the second device the IRE finds the first device and starts updating this device instead of creating a new one, because it finds the serial number (that is not empty as it contains the string "Default String"). It also creates a new entry in the [sys_object_source].

So everything works as designed but I end up having multiple entries in the [sys_object_source] pointing to the same target device with different unique keys. Each scheduled import this device gets updated with the information from another device that has the same serialnumber.

How can I make sure that for each devices a unique device gets created? The Resource ID is not used in the IRE anymore to identify the device as it is not saved within the CI. I could change the priority of the name to be lower than the serial number so it gets used first. But as the source native key exists it won't look in there as the first import already has been made so I would have to import all CI's again or delete the [sys_object_source] to recreate the identifier entries.

Within the Identification Rules there are Related Entries which contain an entry for the table [SG-SCCM Computer Related] looking for the attribute "Resource ID". But it is clearly stated that they are not used "[...] to directly identify CIs"

Is there an obvious solution that I'm missing here?

With best regards
Pascal