Synchronizing two or many DirectSmile Integration Servers

Running a DirectSmile Integration Server on a server machine is a quite easy thing. Ok, there is some configuration needed in the first place, but if it’s up and running it does what it’s meant to.

But having a DSMI installed on a single web server has it’s disadvantages. As there are:

  • What if you plan to update your server? What do you present your customers while your server is maintained?
  • A single server is limited in bandwidth and load.
  • You might want to split online previewing and print production.

That’s where the DirectSmile Synchronization service comes into play.

Synchronization scenarios
The Synchronization Service is a windows service that is installed on the master DSMI or on one of it’s clients. It can mirror the file system and all DSMI databases. The service keeps track of all changes made to the master DSMI and synchronizes those changes to the client DSMIs. Changes made to the DSMI could be adding a new account, Documents and Sets or Crossmedia templates. An item deleted from the master is deleted on the clients and so forth.


Because the synchronization is just in time, the system becomes easy to scale. You could set a load balancer in front of it. Here’s an example of a typical load balanced scenario.


How to configure DirectSmile Synchronisation Service
The DirectSmile Synchronisation Service comes with a simple and straight forward xml configuration file, that looks like this.


Generally spoken, the xml consists of three parts. Let us go through the structure in detail:

Synchronization element. Container element for synchronization providers. You can define an email server and credentials if you want to receive emails on errors. You can also define a list of extensions of files that should be skipped while synchronization. Further, you can tell the synchronization service to create a log file. You can define the interval in which the synchronization process should be called by the service. And finally you can set the database synchronization to preflight. In that case you will get a report of how many changes to the client database would be applied, but the database itself would be untouched.

FileSynchronizer element. A FileSynchronizer element consists of two paths, the server and the client replica path. You can add as many FileSynchronizer elements as you like. The service keeps track of changes to all paths defined in the FileSynchronizer elements.

DataSynchronizer element. In DataSynchronizer element you define the instance and database names of the server (remoteserver) and client (localserver) database server. Each DataSynchronizer needs a list of tables that need to synchronized. The tables relevant for synchronization in DSMI are preconfigured already.

Synchronizing file system, especially in our case with loads of files, can be performance relevant. Based on my experience in the past, I recommend to reserve an extra CPU core just for the Synchronization service.

Have in mind that the WriteToLog option is very, very verbose. Usually you won’t need to activate logging. The service is writing to the windows eventlog anyway if updates were made. Error messages are written to the eventlog too and sent out by email if you like.