Replication Overview
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.
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.
/hippo:configuration/hippo:modules/replication/hippo:moduleconfig/metadata/relevance: 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:
- Enable Your Project For Replication
- Configure Replication
- Using The Replication Control Panel
- How Replication Works
- Extend Replication For Your Plugin
- Deployment
- Filtering Properties
- Best Practices