SyteLine Multi-Site Replication Checklist

0%

0 of 25 items complete

7 critical items still open - these are the highest-risk gaps.

Download checklist:

Configuration

Sites and entities exist on the Sites and Sites/Entities forms, with linked server names, database names and intranets correctCRITICALA replication rule is enabled for each source and target site pair on Replication Rules, with the right categoriesCRITICALTriggers regenerated on Replication Management after every rule or category change, separately at each siteCRITICALLinked servers exist for transactional rules; trigger regeneration stops with an error until they doIntranets form: the To Site's intranet has a URL defined when it differs from the From Site's intranet

Data checks

New records created at a source site appear in the corresponding _all tables at the target siteSpot check shared master data (items, customers, vendors) across sites for missing or stale rowsCRITICALFind Replication Setup Issue form run for any object that is not replicating, then List Issues reviewed

Services

Replication options set on the Replication tab of Service Configuration Manager and saved to the service configuration fileCRITICALReplication related services running on the utility serverService Configuration Manager run and saved before the Replication Tool is used, so the tool reads current settingsLogMonitor checked for ReplQListener errors while reproducing a replicated change

Queues

Replication Document Outbox and Inbox backlog counted and compared with yesterdayCRITICALReplication Errors form reviewed for inbound records that were retrieved but failed at the targetFailed records corrected and resubmitted from Replication Errors (successful updates are removed from ShadowValuesErrors)Replication Tool used to view, correct and resubmit failed inbound or outbound request documentsLinked site status checked in the Replication Tool

After upgrades or restores

Triggers regenerated at every site after an upgrade, update or database restoreCRITICALLinked servers and remote site settings revalidated after a server rename or restoreOne test transaction per replication category made and followed to each target siteReplication Errors and outbox cleared of backlog created during the outage

Monitoring

Daily backlog count recorded per siteAlert threshold set for backlog and error countsNamed owner for replication health and a deputyRunbook links to this checklist and the Infor replication troubleshooting topics for your release

Critical items cover the failures that let sites drift apart without anyone noticing: missing rules, triggers not regenerated after changes or restores, and backlogs that nobody counts. Run the whole list after every upgrade and the Queues and Monitoring groups daily.

Get a replication health review

Send us your site list, rules and current backlog counts and we will point out risks for your SyteLine release.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use it

Export the checklist to Excel and keep one copy per site. Daily, tick Queues and Monitoring and record the backlog count. After any rule change, upgrade, update or restore, run every group. When a user reports data missing at another site, start with Find Replication Setup Issue for that object and target site, then the Replication Errors form, then the Replication Tool. Do not add steps that are not in your release documentation; replication setup is sensitive to unsupported changes.

Where this lives in SyteLine

Site relationships are defined on Sites and Sites/Entities, replication rules and categories on Replication Rules, and triggers are regenerated from Replication Management. Replication options are set on the Replication tab of Service Configuration Manager. Inbound records that failed at the target are listed on the Replication Errors form, where they can be fixed and resubmitted. The Replication Tool on the utility server views, corrects and resubmits request documents and shows linked site status.

Replication Rules: source and target pairs, categories
Replication Management: Regenerate Replication Triggers
Replication Errors: failed inbound records
Find Replication Setup Issue: why an object does not replicate

Version differences and gotchas

Regenerating triggers drops and recreates trigger code, must be run at each site, and should be done with other users out of the database. Restores and upgrades can leave triggers or linked server definitions out of step with the rules. Transactional rules need linked servers before triggers can be regenerated. Intranet URLs matter when sites sit on different intranets. Form labels can differ slightly between SyteLine 9 and CSI 10, so match them to your release help.

How to check the result in the system

Create or change a test record in one category at a source site, then confirm it at each target site, including the _all table that carries cross-site rows. Watch LogMonitor for ReplQListener messages while you do it. Check Replication Errors stays empty and the outbox backlog returns to its normal level.

Frequently Asked Questions

What kind of system is SyteLine?

SyteLine, also sold as CloudSuite Industrial (CSI), is Infor's ERP for discrete and mixed-mode manufacturers, built on the Mongoose framework and SQL Server. On-prem installations support multiple sites in one or several databases, with replication rules that share master data and transactions between sites.

How does SyteLine CSI 10 replicate data between sites?

Replication rules on the Replication Rules form define which categories of data flow from a source site to a target site. Database triggers, generated from Replication Management, capture changes, and replication services deliver them. Failures surface on the Replication Errors form and in the Replication Tool, and ReplQListener messages appear in LogMonitor.

When do I need to regenerate replication triggers?

After every change to replication rules or categories, and after upgrades, updates or restores that may have replaced trigger code. Regeneration drops and recreates the triggers, so run it at each site with other users logged out. For transactional rules, linked servers must exist first or the process stops with an error.

How do I fix a record that failed to replicate?

Open the Replication Errors form at the target site, read the error for the failed inbound record, correct the cause and resubmit; successful updates are removed from the error list. For request documents, use the Replication Tool on the utility server to view, correct and resubmit, and check linked site status.

If controllers and planners need answers across all your SyteLine sites in plain English, we can set up a private AI layer on your own servers that reads every site.

Talk to an Expert Explore More Free Tools

Related Tools

Infor SyteLine

More Infor SyteLine tools

See all

SyteLine Multi-Site Replication Health Checklist