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