Replication Overview

This Bloomreach Experience Manager feature requires a standard or premium license. Please contact Bloomreach for more information.
The Replication module is an advanced feature that's only suitable in specific use cases. Please contact Bloomreach Professional Services or your account manager to determine the suitability of the Replication module for your project.
Please note that the Replication and Synchronization add-ons are incompatible with the Relevance Module.

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.
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.

Also currently the following modules/features are not replicated by default.

  • Document types: Document types need to be bootstrapped to have them on both source and target environments.
  • Projects : Even though projects' data itself is not replicated, channel and content changes in a project are replicated once the project is merged into the core. Running a campaign doesn’t result in replication of channel and content changes in the project.
  • Web files: Web files need to be bootstrapped to have them on both source and target environments.
  • Relevance Module settings: (brXM 15.1.0 and later) Relevance Module settings (persona's, characteristics, etc.) below the  /targeting:targeting path can be replicated by adding this node into includedpaths config property and defining relevance scope provider as below.

  jcr:primaryType: hipposys:moduleconfig
  className: com.onehippo.cms7.replication.metadata.RelevanceReplicationScopeProvider

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?