Monitoring & Troubleshooting the Synchronization



Chapter Topics
Sync Logs
Synchronization Troubleshooting
How to Find the Problem
How to Fix the Problem


Sync Logs
When everything is configured properly, the synchronization process should run smoothly in the background without any need for user intervention. There are a pair ofreports called Sync Logs you can run after every synchronization cycle is scheduled to be completed to check for errors and make sure everything was synched properly. To run these reports, go to Synchronize>Sync Logs:



This will open a reports window you can use to preview and print reports.



The Complete Synchronization Log records, for every step of the synchronization cycle : the date, hour, name of the synchronization file, and whether the action (synchronize, upload, or download) was successful. The Synchronization Error Log merely shows those synchronization process which were not sucessful and writes in the type of error experinced (e.g. could not access the FTP). Use these two reports to monitor ongoing synchronizations.


Synchronization Troubleshooting
Over time, there are a number of minor problems that could disrupt the synchornization process: an employee forgets to leave XpertScheduler open ; there is a power failure at one of the stores; somebody accidentally deletes a task from the scheduler; the FTP Server goes down, and so on. Most of the time the problem is not a recurring problem and the data will be synched the next time around. Because the system works off of DLMs , the system "makes up" for lost synchronizations and you are always up to date with the next synchronizaiton--if everything is configured right.


How to Find the Problem
Usually you will find out there is a problem by running one of the Sync Logs and noticing they report an error. However, on other ocassions you may suspect there is an error if a file you were expecing to see (a new Style in the Styles Catalog, a new batch of Invoices for the previous day, etc.) does not show up at the Main or Remotes.  If this is the case you need to be able to quickly diagnoses where the problem is and fix it. Follow these steps:

1) Make sure there is in fact a problem. For example: perhaps you were expecting more transaction data but there were no further sales done at a store during the period since the last synchronization. Call the store and ask them to find the last Invoice Number in the Documents>Invoices Catalog and compare this serial number with the one found at the Main. You can also compare the audit log for a given item at the Remote and at the Main. Any discrepancy will indicate that there is in fact a problem. However, if these match up, it probably means that the synchronization was sucessful but there was no new data to transmit.

2) Check the FTP connection. Verify that the Remote in question can still access the Internet (do a sample dial-up if you are using a phone dialer). If possible, check to see if the synchronization files for recent dates are on the FTP Server . For example: if you suspect the Main did not receive transaction data from Store #5 from June 7, 2003, then check to see if there is an INVOICE00520030607.xfn or INVOICE00520030607.xtm on the FTP.
If these files are on the FTP Server then you know these files are being created at the Remote and are successfully uploaded. The problem then lies at the Main which cannot download and process. If these files are not on the FTP, then the problem is at the Remote. You should also test to make sure the FTP is configured correctly.

3) Check the Sync Stores Catalog. Verify that the number of entries in the Sync Stores Catalog matches the total number of stores. Make sure there is still an entry in the catalog for the store in question and that the "Inactive" checkbox has not been selected.

4) Check the Scheduler. At both the Main and the Remote in question, check to make sure that all 8 steps of the synchronization cycle are entered into the Scheduler and are entered in the correct sequence .

5) Check the Synchronization Dates. Make sure the document synchronization dates and the catalog synchronization dates match at both the Main and at the Remotes . These should be set to the exact same date for every Catalog and Document type pair.

6) Do a Manual Sync. If you still cannot find the problem, go through all eight steps of the synchronization cycle manually and watch for any error messages.


How to Fix the Problem
Once you've identified the culprit (bad phone line, misconfigured scheduler, offline FTP server, etc.) you still need to reconfigure the synchronization to make sure you get all of the data.

Suppose it is now September 16th, 2002 and the problem ocurred between September 14- 15th and you are not sure you have all of the data from those days. Most likely the date of last synchronization at the Main or Remote is now set to September 16, 2002.

The safest thing to do is to Set the Catalog Synchronization Date back to September 14th at both the Main and Remote, and to Set the Document Synchronization Date back in both places as well. This way the system will backup and "scoop-up" all of the data from those dates and you need not worry about duplication.

In an extreme case, set the dates back even further or you may even have to resort to Initializing Catalogs or Regenerating Documents .


Copyright © 2004 Dinari Systems LLC

* Return to Table of Contents *