Issue
- This article focuses on how to enable CI identification and Reconciliation debugging and view the CI payload to the IRE and check the issues with the payload on demand
- For the latest information on this topic, see https://docs.servicenow.com/csh?topicname=ire.html&version=latest.
Note - If the issue is with discovery or other apps where the import set is not involved then directly start from step 1
- Step #0: Preparation Step (Applies to Import Sets Only)
Many Import Sets contain thousands or tens of thousands of records, which generate too much output with IRE debugging enabled. The best approach is to take an existing Import Set that triggers the IRE issue, pick out a small number (max 5) records that demonstrate the issue, and have them reprocessed in a separate Import Set (these steps should be done by Integrations):
-
- Step #0a: Open the Import Set that triggers the IRE issue. In the context (grey bar) menu click "Insert and Stay". We will be using this Import Set for reprocessing to obtain the specific IRE payload.
- Step #0b: Now go to the list view of the relevant Import Set Staging table, (for example if the issue is with Computer record imports in SG SCCM it would be https://<instance-name>.service-now.com/sn_sccm_integrate_sccm_2019_computer_id.do) and open the staging record which experiences the issue.
- Step #0c: Populate the "Set" field with the newly created Import Set number (from Step #0-1), then in the context (grey bar) menu click "Insert and Stay".
Note: You may need to modify the form layout to expose the "Set" field.
-
- Step #0d: If multiple staging records are required, please repeat steps 0b and 0c.
Follow the rest of the steps in this article, at Step #2 you will open the Import Set you created and click 'Reprocess' followed by 'Transform'.
- Step #1: Enable IRE debugging for the CI payload (*Caution: This causes extensive logging and should not be left on*).
- Check if the property "glide.cmdb.logger.source.identification_engine" exists in the sys_properties list. If not create one with the type String.
- For this property set the value to *
- This will allow all IRE logs to show up in SYSLOG (System Logs) table.
- Step #2: Run the specified data source job (like Discovery, Import Set, integration, etc) so the system will trigger the CI identification.
- Step #3: Once the CI is identified, go to System Logs and look for the source as "identification_engine".
- Step #4: Within the above logs with source as "identification_engine", look for the message containing "Input = {" and then copy the whole JSON IRE input payload from the message (beginning from {"items" to the end of the message}).
- Step #5: Within the above logs with source as "identification_engine", again look for the message containing "Output = {" and then copy the whole JSON IRE output payload from the message (beginning from {"items" to the end of the message}).
- Step #6: For further IRE debugging you can run the whole JSON IRE input payload (captured in Step #4) in the "identification Simulation" OR use How to run the CI identification on demand using the payload and see in the output payload what IRE errors occur while inserting/updating the CI OR you can directly look at whole JSON IRE output payload (captured in Step #5) and directly see what IRE errors occur while inserting/updating the CI.
- Step #7: Revert the property to avoid any issues with extensive logging when left on.
Release
All
Resolution
Additional Information:
If IRE debug logs aren't registering in the [syslog] table after configuring "glide.cmdb.logger.source.identification_engine" sys_property as mentioned in Step #1 above, check if sys_property "glide.cmdb.logger.use_syslog.identification_engine" is defined and configured correctly.
Property "glide.cmdb.logger.use_syslog.identification_engine" is used to enable logging to [syslog]. It already has default internal values and is typically not present OOB. If configured in the instance, it should be of Type=string and Value=* as both properties are evaluated during the logging process.
