Relevant Changes in Bloomreach Experience Manager 13

This pages describes the relevant changes between Bloomreach Experience Manager 12 and Bloomreach Experience Manager 13.

Platform

Bloomreach Experience Manager is a DXP, a Digital Experience Platform. In order to improve Bloomreach Experience Manager towards exposing a sensible, well-defined Platform API, a number of significant architectural changes have been made to the core of Bloomreach Experience Manager in version 13.

HST in Platform

Most notably, Bloomreach Experience Manager's delivery tier, HST, has undergone significant changes: we've split it up into a request-serving "core" and a platform part. The platform part lives with the content repository, forming what we now call the Platform. Typically, the Platform is located inside the CMS web application, but it can also exist as a Platform web application if a certain cluster node is set up to only serve the available sites/channels, but not the CMS' authoring environment. Inside the platform, HST's platform part exposes services through the HST API in the web container's shared library to one or more site web applications, which perform the task of delivering content as web pages or in other useful formats.

As a consequence of splitting up HST, a number of features / add-ons have also undergone serious refactoring, including moving parts from the site web application into the Platform, and vice versa. Most notable are the Relevance add-on, which now also exposes a targeting API through the shared library, and the Projects feature. 

When your Bloomreach Experience Manager project is started, the Spring Configuration of the platform part of HST in the Platform web application is loaded first, before the Spring Configuration in the site web application(s) is loaded. The Spring Configuration of HST has been refactored, leading to changes in the amount and types of Spring-instantiated beans your project can use or override. We are now providing an explicitly documented [list of Spring bean IDs], along with their intended exposure, available to your project.

Splitting up HST has resulted in a need to rearrange the dependencies of your Bloomreach Experience Manager project. We have introduced a few new, POM-packaged Maven artifacts, grouping product dependencies into sensible categories, such that, overall, the dependency structure of your project becomes simpler.

The operation of the platform part of HST is controlled through HST configuration separate from the one defined in and used by a site web application. The platform's HST configuration is defined in the repository under the node /hst:platform, while every site web application defines its own HST configuration under its own root path, typically /hst:<contextPath>. As of version 13, each web application must define the root path of its HST configuration in its hst-config.properties file. For every Virtual Host Group defined in your project, you must explicitly define the CMS mount below /hst:platform/hst:hosts, using a nested structure of Virtual Host nodes. Then, decorate the CMS' hst:mount node with the properties hst:ismapped = false and hst:namedpipeline = WebApplicationInvokingPipeline in order to tell HST that this is the mount for serving the CMS.

These separate HST configurations are loaded into and kept in memory by the platform part of HST, which makes them available as separate HST models, one for the platform and one for each site web application. If necessary, your project code can access these models through the HstModelRegistry (look-up by context path) or the new HstModelProvider.

Changed Service Registry

In version 13, the HippoServiceRegistry has been refactored. Separate whiteboard registries are now defined for [Persisted]HippoEventListeners, ChannelEventListeners, HippoWebappContexts and more. Also, service registration tracking functionality has been added, and the new code has been documented extensively (javadoc).

Multiple Site Web Applications

As hinted on above, as of version 13, Bloomreach Experience Manager supports projects with multiple site web applications. The rationale behind supporting splitting your project into multiple sites is that it becomes easier to manage large projects, because the project becomes more modular, and the development of different sites (sets of channels) can more easily be distributed over multiple development teams. Converting the structure of your to-be-upgraded project into the structure needed for supporting multiple site web applications (Multi Site Mode) is not part of the upgrade to version 13. This conversion should be considered an optional follow-up step. The upgrade instructions documented here will result in an upgraded project using Single Site Mode.

Modular development of a site web application, separate from your project's Platform web application, has produced the need to maintain that site web application's HST configuration in the context of that web application. The Platform's Configuration Management mechanism has been adjusted to support loading site-specific HST configuration definitions which are packaged inside the site web application rather than the Platform web application. Likewise, Bloomreach Experience Manager add-ons who specify HST configuration definitions (e.g. catalog components) have been split up such that their HST configuration definitions can now be packaged with the site web application(s) who depend on these definitions, leading to a number of new artifacts. In the scope of the upgrade to version 13, these new artifact dependencies need to be added to your project; they will go into the CMS/platform web application.

Repository Clean-up

We have cleaned up some no-longer-used definitions from the JCR repository. Many of these changes are related to the refactoring of HST, described above. When upgrading your project to version 13, cleaned-up properties and node types will need to be removed from your YAML definitions and JCR repository instances.

3rd Party Library Upgrades

As part of regular house-keeping chores, we have upgraded the usage of a few 3rd party libraries to a new major version. Most notably, we upgraded to using Wicket 7 and Spring 5. If your project code directly interacts with these frameworks, it may need to be changed in order to interact correctly with the new versions of these libraries.