4 tips for successful replication in LS Central and Business Central

During LS Central implementations, replication setup is often underestimated, and it’s sometimes not thoroughly tested before or during User Acceptance Testing (UAT), which is crucial for a smooth go-live. Since replication is generally reliable, businesses may overlook its importance or assume the demo jobs and subjobs are perfectly configured.

However, these demo jobs are just a starting point and should be adjusted to fit specific needs. Thorough testing helps avoid issues and ensures a successful LS Central deployment on Microsoft Dynamics 365 Business Central.

Here are four essential tips to help you improve the replication process for LS Central implementations.

1. Have full understanding of the business architecture

Before configuring any distribution location, scheduler subjob, job, or other replication-related features, it is essential to understand your requirements, restrictions, deployment architecture, limitations, security and network policies.

For instance, a full Software as a Service (SaaS) architecture may not need replication. However, if data must be transferred to other companies, web replication becomes necessary. In hybrid setups—where the head office is deployed via SaaS or on-premises and the POS terminals function as standalone units—careful consideration of the replication method is critical. This will depend on the network topology, security protocols, and policies.

Below are examples of some existing/recommended architecture options:

Full SaaS architecture

Hybrid architecture

When planning the architecture, ensure that network and security policies enable seamless communication between the computers and servers involved in your deployment. Consider the need to secure connections with certificates and verify which ports will be used for communication.

What are some common replication mistakes businesses make during LS Central implementations?

• Assuming all computers will be in the same domain without the partner and customer verifying this together.
• Believing that the business will have static IP addresses at all locations.
• Presuming there is a VPN for communication between servers and computers at store locations. Assuming TCP/IP communications are universally allowed within the network.

2. Consider the most effective replication method

Before you begin the replication process, it is very important to understand that you can only replicate data between the head office in SaaS and a standalone POS using web services.

If you’re unsure which replication process works best for your business, here are some available methods you can set up in LS Central:

Standard Replication

This is the most common and easiest method to move data across databases.  Standard replication refers to the process of moving data from a source database to one or multiple destination databases using the data director to export the data out of the source DB, compress it into a package that then is sent through the network to the destination(s) and then is uncompressed and applied by the local data director(s) instance(s).

Note that Data Director replication using web services is a must when replicating data from a SaaS database, since there is no way to install Data Director service in the SaaS environment.

Offline replication

Offline replication is used to send jobs to a destination host with a dynamic address or a store that is not always online. The destination host sends a pull request to retrieve waiting jobs.

Web Replication

Web replication is a method to replicate data between databases or companies without the Data Director. Replicating data with the web replication method is an internal Business Central process.

The web replication process can be divided into four steps:

• The functionality that receives and validates the requests from a scheduled job.
• Create a data packet from the request to be distributed.
• Create a distribution request for each distribution location involved.
• Replicate the data to each destination location.

What are common mistakes to avoid when considering the right replication method?

Understanding the differences between these replication methods is critical. For example, confusing web replication with Data Director replication using web services can lead to significant issues. Some common mistakes include:

• Setting up standard replication to pull or push data from a head office database running in SaaS.
• Deploying standard replication where POS computers are not in the same domain or without a VPN that allows communication between them.
• Deploying standard replication for terminals with internet connectivity issues.
• Attempting to replicate data between HCCS and POS terminals using Data Director with web services.

3. Avoid configuring all jobs at the same time

A common issue during LS Central implementations is setting all jobs to run with normal replication, which can cause large data transfers, wasting bandwidth and processing time. Running these jobs too often can also lead to system delays and database locking.

Normal replication with counters or replication by actions is recommended. For tables not generating actions, you can add them to the preaction creation table to track changes, so you optimize the process by replicating the changes instead of the entire table.

Normal replication should mainly be used for initial data sync or specific tables that require manual management. Avoid setting up unnecessary jobs, like replicating tables not needed at POS terminals and always test replication jobs to ensure essential tables for store and POS operations are included.

For replication jobs using actions, only move action records when needed. If further replication isn't required, turning off this option reduces package sizes and improves speed

4. Clean up unnecessary data

Assuming demo database jobs are fully tested and applicable to any project can lead to issues. These jobs are starting points for customization based on specific customer needs.

In addition to demo jobs and subjobs, keep in mind that logs generated by the replication process will also consume space in your database. It's important to configure jobs to regularly clean up unnecessary data, such as preaction records older than a specified number of days, scheduler job logs, and other outdated entries.

Achieving a successful LS Central implementation

By considering the points listed above, you can ensure successful replication for your LS Central implementations, avoiding issues like processing time delays or data integrity concerns. Proper planning and testing will significantly enhance the reliability and efficiency of the solution, as well.

We also recommend following the recommendations listed on our previous blog: Best practices to follow when defining name conventions in LS Central for more insight into the implementation process.

Want to know more about how to make the most of your LS Central implementation? Contact a local partner or get in touch with our experts. We’re here to help you make the process easier!