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

anfield · ‎11-19-2021

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

Report Inappropriate Content · ‎11-19-2021

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

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.

View solution in original post

Report Inappropriate Content · ‎05-31-2022

This is a tricky one that has happened a few times. A source is reporting a literal value for a serial number that is not a valid serial number. As a result multiple records are being condensed into a single record in the CMDB due to the IRE identifying the record by that invalid serial number.

There is a common operation "Cleanse Serial Number" that has an array of invalid serial number literals. I would recommend that you modify this array to include your invalid serial number literal of "Default String". You can find it by replacing <your_instance_here> with your instance name from the following url: https://<your_instance_here>/nav_to.do?uri=sys_rte_eb_operation_type.do?sys_id=a829d4f20f715410d041436eef767ef1

Once you have added that you will need to clear out the sys_object_source table where the target sys id is the computer record in the cmdb with the invalid serial number. This is necessary otherwise the IRE will bypass the identification rules and use this lookup of source native key to target sys id. Then you can run the integration and it should not pass that serial number so you will not get compression of data.

Vivek kumar10 · ‎11-14-2023

Hello Pascal Vinke,

Have you found any solution for that I am also getting the same issue

kiran kumar m1 · ‎01-14-2025

Do we have to define the IRE rules or they are predefined ?

anfield · ‎01-14-2025

Theyre predefined at the class level.

kiran kumar m1 · ‎01-15-2025

Hi @anfield is there any document regarding this how they are classified at class level ?