Replication Overview - Bloomreach Experience - Open Source CMS

This article covers a Hippo CMS version 13. There's an updated version available that covers our most recent release.


Replication Overview

This Bloomreach Experience Manager feature requires a standard or premium license. Please contact Bloomreach for more information.
Currently, the Replication and Synchronization add-ons are incompatible with the Relevance Module. Please contact BloomReach if you wish to use Relevance in combination with Synchronization and/or Replication.

Bloomreach Experience Manager offers a solution for replication between repositories. Replication can for instance be useful when you want to separate your external-facing content service from your intranet-hosted editing environment.

The public website is backed by a read-only repository that lives inside the organisation's DMZ. The CMS is hosted behind a firewall and backed by a repository that is outside the public network.

Replication happens automatically when editors publish changes using the CMS. At that time the replication source repository cluster pushes out the changes to the replication target repository cluster. In the case where the target is down, the source will suspend the replication process for the time being and automatically resume and send the backlog of changes when the target comes up again.

For the source to communicate with the target cluster, the target needs to be fronted by a load-balancer. The source sends its replication packages to the load-balancer which forwards the request to a live repository node.

Not any and all changes to the repository are replicated. Changes to document types and changes to the CMS configuration are not replicated for instance. Although this can easily be customized, preview documents and HST preview configurations are not replicated either.

By default the following repository subtrees are included in replication:

  • /content: all documents, assets, images, and other content stored here as part of plugins. Only live published documents will appear on the target.
  • /hst:platform: HST platform configuration is replicated by default. HST site web app configuration is ready to be replicated. To enable the replication of the site configuration, the root node name of the site configuration should be added into the includedpaths property on the node /hippo:configuration/hippo:modules/replication/hippo:moduleconfig/metadata. Then, the site configuration is replicated with the exception of site preview configuration which is only relevant to the Channel Editor.
  • /targeting: Relevance Module settings (persona's, characteristics, etc.)
In general you do want to configure your site webapps HST configuration(s), for example /hst:myproject, to be replicated. Make sure to add those configs as a subtree to replicate.

If you have your own subsystem built on top of the repository, you can write a plugin for the replication engine to allow your content to be replicated.

Read more about replication on the following pages:

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?