Page History
Overview
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.
NOTE: It is recommend you use Table Compare to first check for discrepancies. This guide will then help you troubleshoot further to determine the cause of discrepancies.
Here is a diagram that shows the DataSync workflow:
Listed below are the components where this document details how to troubleshoot each of them:
- ServiceNow (Source)
- Perspectium Integration Mesh
- DataSync Agent
- Database (Target)
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.
Anchor | ||||
---|---|---|---|---|
|
Identify tables where there is discrepancy
Create a spreadsheet that includes the following columns and their values:
- Table Name
- Count in ServiceNow
- Count in Database
- Count difference
- Date/time of when counts were recorded
- Flag indicating if there are more records in Database or ServiceNow
- Examples (if possible): sys_id values with a discrepancy
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.
ServiceNow
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 in a queue in the Perspectium Integration Mesh.
The majority of discrepancy issues from a ServiceNow perspective are due to:
- Dynamic share or bulk share not creating PSP Outbound Message record.
- The PSP Outbound Message is not properly created (e.g. empty value, see Known Issues for more details).
- Dynamic share does not capture final version of source record.
- Perspectium MultiOutput Processing Job(s) inactive or platform blocks from running.
- Perspectium MultiOutput Processing Job(s) unable to communicate with Perspectium Integration Mesh.
UI Steps | ||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
DataSync Agent
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:
- Consume messages from the Target Queue in the Perspectium Integration Mesh
- Decrypts and deserialize message
- If configured, Agent will fetch table schema from ServiceNow and alter tables in the database
- Query the database to determine if it needs to perform an insert or update/delete (for .bulk messages)
- Build the SQL Statement
- Execute SQL Statement
Typically, longest delays occur during an interaction with the database.
UI Steps | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Contact Perspectium Support
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:
- Visit the Perspectium Support Portal to open a Support Case
- Give us a call at (888) 620 - 8880 to open a Support Case
- Reach out to your Perspectium Customer Success Manager
Include the items below when initially opening a Perspectium Support Case:
UI Steps | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Anchorknown_issues known_issues
known_issues | |
known_issues |
Known Issues
This is a list of Known Issues or ServiceNow configurations that will prevent Perspectium from capturing an insert/update/delete on your ServiceNow Instance:
Expand | ||
---|---|---|
| ||
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. |
Expand | ||
---|---|---|
| ||
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. |
Expand | ||
---|---|---|
| ||
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? |
Expand | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
The workaround is to configure the Query business rule such that it doesn’t run when executed by the bulk share:
|
Expand | ||
---|---|---|
| ||
Fix is in Fluorine Plus Patch 1.1 and up. |