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.
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