SCCM Integration failing after promotion

Cal Riley · ‎03-21-2023

Experts -

We have setup and successfully configured a working SCCM integration in our DEV instance. We recently promoted it to our test instance and the connection seems to still be working as it successfully grabs the data and loads it into the import set table for Computer Identity. However it never completes the transformation and so it never updates/inserts any records into the actual target tables (cmdb_ci_comptuter etc...). On top of this it is taking the scheduled job 8+ hours to try and run. Not sure what went wrong with the promotion or configuration of this in the test instance, as it is still working normally in the DEV instance. The only difference I am seeing is the sys_object_source table does not seem to be getting populated in the test instance - which to my understanding seems to store the resource id/target id relationship of where to map the data. Is there a way I can find out why this table is not being populated or find out why the transform job is not completing even though the data is imported and ready to go.

Please let me know of anything you can think of to help debug this!

Cal Riley · ‎03-24-2023

Thanks for the article Rahul, as I responded to someone else, it seemed the partial_payload and sys_object_source not being populated as expected was the symptom of the problem. So it was very much related to what is in the article. It seemed my problem originated from this system property being toggled glide.required.attribute.enabled. This caused the IRE to malfunction and just populate the partial_payload tables instead of the sys_object_source.

View solution in original post

Rodrigo Poma · ‎03-21-2023

https://docs.servicenow.com/en-US/bundle/utah-platform-administration/page/integrate/cmdb/reference/... per this documentation, it appears that the sys_object_source records are created in the system whenever the SCCM SG Connector identifies a CI. This logic would be very behind the scenes, and I would doubt that anything you did directly would break this. My guess is that some update you committed from your development instance is causing this issue, and it may be a good test to back-out your update set that includes this build, and verify that the SG Connector functions OOB with the configured connection. That way we know it is an update that is causing the issue and you may be able to identify it.

Cal Riley · ‎03-24-2023

Thanks for the response Rodrigo. This was very insightful and I can tell you have quite the experience in this area (makes sense coming from a mega expert) so I appreciate your efforts. Even though this was not the exact problem/solution for me, it did help me dig deeper and diagnose the problem! The partial_payloads being populated was due to a system property that was toggled (we're still not sure when this was toggled). After toggling this glide.required.attribute.enabled property then it worked again and the partial payload tables are no longer being used, and the sys_object_source table is being populated as expected. Thanks again for the article have a great day!