This guide provides a methodical approach to identifying causes for data to be out of sync. It requires a birds-eye understanding of the DataSync architecture to see how data flows out of ServiceNow and into the Perspectium Integration Mesh where the data sits until the Perspectium DataSync Agent is able to consume the messages to perform the insert/update/delete into the target database. Here is a diagram that shows the DataSync workflow:
Listed below are the components where this document details how to troubleshoot each of them:
Before deep diving from Source to Target, it is best to perform the following to identify problematic tables where discrepancies have been identified. Prioritizing the tables then allows us to focus on specific shares and possibly time frame of an issue. If possible, it would also be helpful to find sys_id values that either exist in ServiceNow, but not in the database or found in the database but not in ServiceNow.
Create a spreadsheet that includes the following columns and their values:
Click here to download an example template.
Progress through these upcoming steps as we investigate from source to target to possibly identify the root cause for each discrepancy identified or isolate where the problem may be.
The Perspectium DataSync Application in ServiceNow simply creates PSP Outbound Message (psp_out_message) records and publishes them to the Perspectium Integration Mesh (MBS).
NOTE: If you are using MBS 3.0, you can use the mesh_entry_id field to verify that the outbound message is saved to a file record in the Perspectium Integration Mesh.
The majority of discrepancy issues from a ServiceNow perspective are due to:
|
The Perspectium DataSync Agent typically sits within your firewall or network to ensure control and security of your data. Initial struggles with the installation of the DataSync Agent are often due to communication issues between the Agent and Perspectium Integration Mesh, source ServiceNow instance or database. Once the Agent is able to establish connection with each item, it goes through the following workflow to sync data:
Typically, longest delays occur during an interaction with the database.
|
If you’ve gone through this Troubleshooting Guide and are still unable to figure out what may be causing your data to be out of sync, then please don’t hesitate to:
Include the items below when initially opening a Perspectium Support Case:
|
This is a list of Known Issues or ServiceNow configurations that will prevent Perspectium from capturing an insert/update/delete on your ServiceNow Instance:
Fix is in Fluorine Plus Patch 1.1 and up. NOTE: This is not a complete fix. It is a workaround that skips encrypting the problematic field so our code can proceed to populate the value field of the psp_out_message record. Investigation is ongoing. |
current.setWorkflow(false) Impacts Perspectium Replicate business rules from a dynamic shares. This will prevent any other business rule from running on the current record. current.autoSysFields(false) Impacts Scheduled Sync Ups or Scheduled bulk shares. This will prevent the fields updated and updated by to change when the record itself is updated. In regards to the .setWorkflow(false) behavioral flag, Perspectium’s GOLD Release has the option to create a Flow Designer dynamic share to get around this issue. NOTE: Deletes can only be captured by a business rule. |
Inserts, updates, or deletes may not be captured on PPM Tables such as the following:
Likely due to a ServiceNow setting which prevents any business rules from executing: KB0793430: Why is my Project Task not listed in the Deleted Records? |
The workaround is to configure the Query business rule such that it doesn’t run when executed by the bulk share:
|
Fix is in Fluorine Plus Patch 1.1 and up. |