About replication

Transactional replication

This method (also sometimes referred to as "synchronous" or "connected") performs updates on the target site, based on the transaction being performed at the source site. All changes on both the local database and the target database are committed or rolled back together. Transactional replication assumes that the source site and the target site are always connected through SQL Server and have the same database schema (same SyteLine version).

Transactional replication allows immediate updates between databases without the use of queues or XML-formatted content. Only database triggers and direct stored procedure calls are used to replicate the data.

Data errors (for example, requesting an item that does not exist at the specified remote site) are caught immediately, and the system will not allow the user to save the record with the error.

Transactional replication generally should be used between sites on the same intranet. For best performance, both site databases should be on SQL Server machines within the same LAN, or even on the same SQL Server machine.

Non-transactional replication cloud environment

This method (also sometimes referred to as "asynchronous" or "delayed") assumes that the source site and target site may not be connected through SQL Server. Non-transactional replication uses inbound/outbound queues and XML documents to transfer data or to pass application calls (remote procedure calls, or RPCs).

In a Cloud environment, non-transactional replication is used only for transmission of BODs to and from ION.

Non-transactional replication on-premises

This method (also sometimes referred to as "asynchronous" or "delayed") assumes that the source site and target site may not be connected through SQL Server. Non-transactional replication uses inbound/outbound queues and XML documents to transfer data or to pass application calls (remote procedure calls, or RPCs).

If on-premises, the sites must be running SQL-based versions of SyteLine. The sites need not be on the same version of SyteLine; however, if you use different versions, you might need to define XSL transformations so the data arrives at the target site in a usable format for that version. Transformations are required if something significant has changed from one version of the data source to the other, or the target site has more differences than just new nullable columns.

You can also use non-transactional replication to communicate with other applications, if transformations are provided. For more information, see the document Integrating IDOs with External Applications.

Non-transactional replication can occur "immediately" (that is, updates are placed in the replication queue as soon as the Replicator service polling interval has elapsed), or at specified intervals (that is, updates are put in the queue when the time interval specified in the replication rule has elapsed). As soon as it reaches the queue, the data is processed by the replication services.

Data errors in non-transactional replication must be handled by the target site system. The user at the source site may not be aware that a replication-related error occurred.

Non-transactional replication populates the ShadowValues table. This and other replication-related tables grow very quickly and may impact system performance.

General notes about replication

You can use transactional replication between some of your sites and non-transactional replication between others; it depends on how the sites are connected and how quickly you want the data to be available.

When data is updated in the target system via replication, the replication process bypasses business rule validation and triggers, so replication should only be performed between "trusted" sites. Referential integrity and database-level constraints still apply. Note also that trigger validation is not applied to tables in any case.