Monitoring LS Central replication: the daily Data Director check

Monitoring · 11 min read

Replication failures are rarely loud. The price change that never reached Store 2, the transactions that stopped arriving at head office — both surface hours later as a wrong shelf price or a short statement. The fix is not better heroics; it is a short daily check, in a fixed order, while there is still time to act. This is that check. (For how replication and Data Director fit together at all, see how LS Central and Business Central talk to each other — this guide assumes that model and covers the monitoring task only.)

What to check, in order: the daily five-minute routine

Run these steps in order, before stores open or before the first statement is calculated. Each step has a pass condition — if a step fails, stop and work that problem before moving on.

1. Confirm the scheduler actually ran. Replication jobs are run and scheduled from LS Central — most need to run every day or more often. In the Scheduler Job List, confirm the overnight jobs show recent runs. No recent run means there is nothing for Data Director to move, and no Job Monitor investigation will change that.
2. Open the Job Monitor and read the tray state first. Open the Data Director Configuration tool as administrator and use the Job Monitor button on the Debugging tab (the monitor also lives in the Windows tray). The tray icon is the fastest health signal in the product: green means the monitor is connected to the DD Host and no errors have been reported; red means at least one job has an error. Connect with Load Done selected so completed jobs load from DD Router Memory — how far back that reaches is set by the Jobs Memory Timeout value in the Configuration Tool — and keep Live selected so the grid keeps updating as job statuses change.
3. Filter to errors only. Turn on the Error Only toolbar filter. What remains is the day's real work list. Note the first (red) job in each group — per the reading rules below, it is the blocker; the jobs queued behind it are victims, not separate faults.
4. Check the destination spread, not just the source. The upper grid is Source Processing; the lower grid is Destination Processing. A job can be fine at source and failed at one store. Switch to Host View — one line per DD host, showing that host's latest error — to answer "which store?" in one glance.
5. Check the manual backlog. Click the Manual button to see jobs waiting in the Outgoing folder or in Cloud Storage. The Manual button itself turns green when jobs are waiting, which is easy to miss on a busy screen. Waiting manual jobs are data that has not moved at all.
6. Sanity-check one known change. Pick one item or price changed at head office yesterday and confirm it is visible at store level. This catches the failure mode no monitor shows: jobs reporting success while the business data is stale.

What success looks like: scheduler jobs show fresh runs, the tray icon is green, Error Only returns an empty grid, no host line carries a fresh error, the Manual list is empty, and yesterday's known change is visible in the store. That combination — not any single green light — is a healthy morning.

Reading the Job Monitor: colours and statuses as one picture

The Job Monitor documentation defines each signal separately. Read together, they separate three very different problems: a failed job, a blocked queue, and a store that simply has not reported back.

• Red source line — the blocker. A job with an error shows red. Critically, when a job has an error, all later jobs with the same job ID or the same destination host wait, shown as white lines that do not turn red. So one red line plus a tail of waiting white lines is one fault, not many. Fix or clear the red job and the queue behind it can move.
• Yellow-green — on hold. The job or queue is on hold and Data Director will not try to send it until it is released. Holds are deliberate (a store known to be offline) but also automatic: if Max Error Retry is set and a job reaches that count, it is put on hold by itself. A job that "stopped retrying" is often a job on automatic hold.
• Yellow destination — a warning on that destination, short of a hard error. Treat it as tomorrow's red line and note which host it belongs to.
• Sky blue destination — no status came back. No status message was received from that destination, so this monitor cannot say whether the job was processed. The documented next step is to check the Job Monitor on the destination's own Data Director before concluding anything.
• Unknown destination status — often normal. Stores and POSs in a distribution list show Unknown for destinations other than their own, because their Data Director never receives updates about the other locations — only head office or the sending host gets those. Jobs sent via DD2 or Manual transfer also show Unknown, because those paths send no status report back. Unknown is a reporting gap, not an error — except at head office, where a destination that should report back and shows Unknown deserves a second look.

Two working habits make the grid faster to read: use the Filter by Jobid and Filter by Source Host toolbar filters (both are case-sensitive "contains" filters) to isolate one job family or one store, and use Re-Check Status on a selected job to make Data Director refresh its status in the monitor instead of guessing from a stale line. And know the reset trap: the Reset button returns the tray icon to green, but if a job updates and still has an error, the icon goes red again — a green icon after a reset is not a fix.

When store data stops flowing: the triage order

Work this order. Each step rules out a layer, and the order matters because the common causes sit at the top. One point from LS Retail's own troubleshooting applies throughout: a job can be started from LS Central and still fail during its run in Data Director, so "the scheduler ran it" never closes the case — and the first few runs of any newly set up replication job should be watched in the Job Monitor rather than assumed.

1. Did the scheduler job run at all? Scheduler Job List first. If Run Now itself errors that the job has no receiver, the documented fix is on the job: Related → Job → Receiver Groups, and add the All group as a receiver group (creating an all-stores group first if none exists).
2. Is there a red job at the head of the queue? In the Job Monitor, Error Only view. Open the red job's error before touching anything else — jobs behind it are waiting on it. Right-clicking the job also offers View Query/Result Datafile for a job with an error or not yet processed, which shows the actual data file in an XML viewer.
3. Is the queue on hold? Check the Hold Only filter. If the host is offline (a store closed for renovation, a network outage), putting the job on hold is the correct holding action — Data Director stops retrying until release, and it can be set to release off hold automatically after a number of minutes. If the hold is the automatic Max Error Retry hold, the underlying error still has to be fixed before release means anything.
4. Is it one destination or all of them? Host View answers this. One bad destination points at that store's Data Director or connection; all destinations failing together points back at the source, the job definition, or the data itself.
5. Is the data waiting outside the queue? Check the Manual view for jobs sitting in the Outgoing folder or Cloud Storage. If the host is back online, Load TCP reloads manual jobs for online replication and sends them right away; Load OFF returns them to the queue to wait for an offline pull request. Skip the manual reload entirely for destinations set to pull — when an offline host comes back online, its pull loads the jobs automatically.
6. Is an offline store actually the whole story? For offline replication, check the Distribution Location setup: offline destinations carry Data Director Mode OFFLINE, with the Distribution Server Name holding the host path in the form host name, port, and an :OFF ending. To force a check, Pull Now overrides the interval timer and starts the pull monitor, which shows the status of incoming jobs. Remember the reporting shape: an offline host's own monitor shows jobs to head office as Done with the head-office destination status Unknown — the success or failure of those jobs is known at head office's monitor, not the store's.
7. Does the error match a known pattern? Two documented ones are worth checking before deep investigation. A version mismatch between SaaS and on-premises environments can fail replication in Data Director — checking "ignore extra fields" in the DD Configuration tool lets the job run. And the "LSC Preaction table not found" error in jobs such as INS_ACTIONS or INS_NORMAL_COUNT points at a subjob setting: open the Scheduler Subjob List on the scheduler server, filter on the job ID, and check whether the Move Actions flag is enabled on the subjobs. (That specific error is documented for the Analytics replication jobs; the subjob-checking habit generalises, the error text is the guide.) A third documented check for SaaS setups: if a "v1 web request is missing" error appears, open Web Service Setup in LS Central, select web Request 1.0, and confirm the list is populated — GET_TABLE_DATA and GET_TABLE_DATA_BY_PRIMARY_KEY should be among the requests.

Actions that are safe to take — and the escalation line

Safe, reversible, and documented — handle these directly:

• Retry Now on a job whose cause has cleared (store back online, transient failure). It overrides the normal wait until the Error Wait time expires — which is exactly why it should follow a fix, not substitute for one.
• Put a queue on hold for a host known to be offline, and release it when the host returns, so retries stop masking the real error list.
• Re-Check Status and the data-file view, to gather facts.

Escalate instead — with evidence — when: the same job fails again after its documented cause is fixed; the error text matches no documented pattern; or the fix involves changing connection details. Note that commands such as Cancel Job, Put Job on/off Hold, and Change of DB/Host string may demand the Configuration Tool's Lock Code, and a wrong host path or database string can fail or cancel the job — string changes are not a casual experiment. A good escalation note carries: the job ID, the first red job's exact error text, the affected destination hosts from Host View, whether the job is on hold, and what the scheduler side shows. That is the difference between "replication is broken" and a problem someone can pick up cold.

Setting up central history so you are not watching one screen

The live Job Monitor answers "now." For trend questions — is Store 4 failing every Friday? — LS Retail documents a collection route. When Data Director finishes a job, it moves the job header XML file into the Archive folder under the Data Folder path. That archive data can be converted by the Monitor Data Jobs (DDArchiveJob and DDStatusWorkJob) into a central database for reporting, or read by the Web Monitor program. The monitoring tables (prefixed LSC in Central 17.5 and later) include DDMonitorHdr (job ID, status, create time) and DDMonitorLine (source and destination host status, server messages, connection string, last registration time), alongside DDMonitorLocStatus, DDScheduler, and DDSchLog. Setup is in the DD Configuration Tool's Monitor Config tab: activate it and enter the DD Host and the central database connection string, which can be copied from the Distribution Location card in LS Central. Collection is needed wherever source data is pulled from and wherever the scheduler sends jobs, because destination statuses are always reported back to the source host. One housekeeping note from the data-file feature: if Keep Data Files is switched on in Configuration so processed jobs can be inspected, the Keep folder needs periodic cleanup to free up space.

FAQ

The tray icon is green. Is replication healthy? Not by itself. Green means connected with no errors reported. Run the full check: fresh scheduler runs, empty Error Only grid, no manual backlog, and one known change verified at the store.

One red job and twenty white ones — how many problems is that? Usually one. Jobs with the same job ID or destination wait behind the errored job and stay white; only the first job shows red. Work the red job.

A destination shows Unknown. Is it broken? Often not — other stores in a distribution list and DD2 or Manual paths never report status back. Head office, or the destination's own Job Monitor, is where the answer lives.

When should a failed job just be retried? After its cause clears. Retry Now skips the Error Wait; retrying into the same fault only spends the Max Error Retry count and ends in an automatic hold.