Web Replication

In this article

Web Replication allows for replicating data without using Data Director. When replication data from/to a SaaS environment, Web Replication is most frequently the recommended way to go.

The different web replication methods available covers all kind of data replication requirements, like moving data between different tenants, environments, companies, either in SaaS or on-premises.

There are three different Web Replication methods:

The steps below outline the general process for setting up web replication. For detailed instructions on each specific replication method, refer to the corresponding links provided above.

Process

Web replication is an internal LS Central process.

The process is divided into two separate steps.

The first is similar to the existing scheduling of jobs (replication jobs), but instead of passing the requests to Data Director, the requests are passed to an internal web replication module.
The second is the web replication module that processes the replication requests. This process handles the data replication in a different way, depending on the Web Replication method assigned to each distribution location.

Note: Each step relies on a different scheduler job to run and for the second step, the Web Replication method is not configured in the Scheduler Job itself but rather at the distribution location level.

This means that depending on the data replication complexity, you might only need to run two different scheduler jobs for this purpose.

Replication jobs

To activate web replication:

In LS Central, click the icon, enter Scheduler Job Card, and select the relevant link.
Open the Object Setup FastTab, and in the Object No. field, enter codeunit 99008923, called LSC Data Distribution WS (this feature shares the same codeunit that is used for Data Directorreplication).
Enable the Use Web Replication field(this is how the scheduler knows if Data Director or Web Replication replication method is going to be used).

With this method the job sends its replication request to the web replication module instead of the Data Director.

All destination locations must have a valid Web Server connection, see the Distribution Location Card, Web Server FastTab:

Web replication module

You find all UI related to the web replication module in the Scheduler Setup page.

Web replication

The web replication module that processes the replication requests is run by a Scheduler job.

To run the web replication, create a Scheduler job and connect it with codeunit 99009521 (the Object Setup FastTab in the Scheduler Job page):

Web replication requests

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 distribution request for each distribution location involved.
Replicate the data to each destination location.

Create Request Queue

When a web replication scheduled job is run, the request is passed to the web replication module that validates that the request can be processed, see web replication limitations above.

To see requests in the queue, go to the Scheduler Setup page, and click the Related action, then select Web Replication - Request Queue.

The outcome is a list of all waiting requests:

(Click image to enlarge)

If the request is in order, a queue entry is created. At the same time, a log file containing the request is written at the same path.

This file is in json format and could have a name like ADMIN_SendJobRequest_D20210115T144450333Z.json. The json file can now be downloaded from the Web Replication Request Queue manually.

Go to Web Replication Request Queue, and select Actions, and then Download Request.

Web replication

Steps 2, 3, and 4 are all run by the web replication Scheduler job in that sequence. Each step could fail individually, but should resume correctly with next retry by the Scheduler.

If everything is in order, the request is moved to the Web Replication Request Log and all extra data is deleted. This way, the log only holds limited information on process requests.
See Scheduler Setup page, click the Related action, then select Web Replication - Request Log.

(Click image to enlarge)

The request is not removed from the queue until it has been fully processed. If some steps of the process fail, additional information becomes available.

If Step 2, Create a data packet, is successful, a flag, Data Packet Created, is set and information regarding the data packet becomes available in the Request Queue list by clicking the Related action and selecting Packet Data.

If Step 3, Create distribution, is successful, the distribution information becomes available in the Request Queue list by clicking the Related action and selecting Distribution Queue.

Step 4 is the stage where the prepared distributions are delivered to their destination. How this is done depends on the Web Replication method in use:

Point-to-Point

This step that has the highest potential of failing because of its dependency on web connections and so on. This step will try to process for each distribution location the oldest request waiting for that location. If a request is successfully delivered, it is then removed from the distribution queue, leaving only those with problems.

Note: If the oldest request is not processed for a given location, no other requests are processed for that location. This can result in a situation where all requests have been processed for all distribution locations except one which has perhaps a list of request waiting.
You can see status for individual locations in the Request Queue list by clicking the Related action and selecting Distribution Queue.

You can cancel a request any time.

Click Actions - Cancel Selected Requests. When this is done, the request is moved to the Request Log and all procession data are removed. The Request Log now indicates that the request was canceled.
When a request is canceled, an additional Distribution Canceled Log is created for the remaining locations still waiting, therefore listing locations that never get this data. This side effect of canceling is only recommended as last resort when this data (request) can never be delivered to the remaining locations.

Note: A request is not closed (that is moved to the Request Log), until it has been delivered to all locations or canceled.

For Step 4 to work, a web service to process the incoming request is needed at each destination location. Here a new type of web requests is used that utilizes OData V4 Inbound Action. The only thing needed is to publish a codeunit 99009520 with the service name WebReplicationODataMgt.

(Click image to enlarge)

Azure Storage

When replication is configured via Azure Storage, step four does not deliver directly to each location. Instead, the Scheduler uploads the distribution packets into the configured Azure Storage container. Each destination retrieves its data independently from there.

This removes the oldest request blocks newer requests limitation, since each location pulls data on its own schedule.

Failures typically relate to Azure connectivity or container access rights.

Requests are closed, once the upload to storage is successful.

Company-to-Company

In Company-to-Company replication, step four delivers the data across companies within the same Business Central environment. Instead of relying on external connections or Azure Storage, the Scheduler transfers the distribution packets internally.

Processing is faster since no external service is required.

Failures are usually related to intercompany setup (such as permissions, company availability).

A request is only closed, once delivery has succeeded for all target companies.

Web replication limitations

From Location Code can only be the current location. The user must define the Use Current Location. This means that the source location and process location must be the same, or in other words, only data push is valid.
This process only supports replication between identical tables, that is from a table to the same table.

Web replication monitor

The Web Replication Monitor is a functionality that you can configure to collect the status of web replication tasks, and, if needed, to send emails.

For more information see Web Replication Monitor