Kentico CMS 6.0 Developer's Guide

Bi-directional staging

Bi-directional staging

Previous topic Next topic Mail us feedback on this topic!  

Bi-directional staging

Previous topic Next topic JavaScript is required for the print function Mail us feedback on this topic!  

Bi-directional content staging, i.e. content staging where servers are not exclusively source or target ones, but can act both ways, is achievable with some extra settings. The advantage of such configuration is that you can make changes not only on the source server, but also on the other server(s), while the changes are transferred to the rest of the servers too.


There are two types of bi-directional content staging, depending on the number of servers between which you want to synchronize:


Simple - used for synchronization between 2 servers only

Advanced - used for synchronization between more than 2 servers


Both configuration procedures are described in the text below, click the respective link to scroll directly to the beginning of the description.


Simple bi-directional staging


If you want to perform content staging bi-directionally between two servers, i.e. you want to transfer changes made on Server 1 to Server 2 and also in the other direction from Server 2 to Server 1, you need to configure both servers as a source and a target server at the same time, as described in the Staging configuration topic.


On top of it, you also need to disable the Log staging changes option in Site Manager -> Settings -> Versioning  & Synchronization -> Staging on both servers.


If this option is enabled, changes made to the system via content staging synchronization (i.e. transferred from Server 1 to Server 2) are logged as new synchronization tasks on the target server (on Server 2). Now if you perform synchronization in the reversed direction, i.e. back from Server 2 to Server 1, these tasks are also performed and logged back on Server 1 as new staging tasks. This goes on and on in a never-ending loop, which results in the tasks remaining and not being deleted on both servers.


In order to prevent this behavior, you need to disable the Log staging changes option on both servers so that the staging changes are not logged as new synchronization tasks.




Advanced bi-directional staging


Bi-directional content staging is also possible on more than two servers. In this case, a list of servers where a staging task has already been processed is transferred with each task. This prevents redundant staging tasks from being logged for servers where the changes have already been performed.


The rule is that there has to be only one path between any two servers in both directions. The following figures show examples of supported server topologies. The rectangles represent particular servers, while the arrows indicate the flow of content staging synchronization tasks.


The first option is to have the servers connected using star topology.


devguide_clip1147     devguide_clip1148  


Another possible topology is the circle topology.




Other topologies are not supported. The following diagram shows an unsupported environment. It doesn’t follow the rule which says that there should be only one path between any two servers. There are two paths from the LIVE server to the TEST server, which breaks the rule.




To enable advanced bi-directional staging, you need to go through the following steps:


1. Enter the following key into the AppSettings section of the web.config file on each server. The key should have a unique value on each server. The value of the key determines the name of the staging server which will be used as target server code name on the rest of the servers.


<add key="CMSStagingServerName" value="server2" />


2. Configure each server as both a target and a source server, as described in the Staging configuration topic. When specifying target servers in CMS Desk -> Tools -> Staging -> Servers, specify all remaining servers in the network. Use the respective values set by the web.config keys in the previous step for each Server code name.




With this configuration, content staging should work between all servers in both directions, whilst no redundant tasks should be generated.