Bloomreach Experience Manager V14.3
Bloomreach Experience Manager Developer Edition V14.3
Highlights for V14.3
We are pleased to announce a new version of Bloomreach Experience Manager (brXM). This minor release introduces new functionality and a number of useful improvements to the product. In this document we will give a brief overview of the highlights in this release. You can also find these release notes at: https://documentation.bloomreach.com/about/release-notes/release-notes-overview.html
Please note that as a result of our security release policy the public availability of the community source code and artifacts for all active releases will follow in about six weeks. Customers however, have immediate access to these new releases at the release date.
Everything mentioned in this document is an integral part of Bloomreach Experience Manager (brXM) and the developer edition, unless mentioned otherwise. If a feature only applies to brXM and not to the developer edition, this is explicitly mentioned. Features that are mentioned as part of brXM also apply to brX.
Key New Features
Advanced Page Management with Experience Pages
Since the introduction of the Experience Manager (formerly known as the Channel Manager) in brXM, users have had the ability to create and manage landing pages, using drag-and-drop components. We’ve continued to invest in the preview and editing capabilities and moved more content editing capabilities into the Channel Manager, but the core functionality of working with pages has remained the same. Until now: with brXM v14.3, we’re significantly expanding the capabilities that users have for working with pages. Highlights for this feature include:
- Page workflow - Team members can work on their own pages simultaneously, publish a single page without publishing the entire channel and make requests for publication or taking a page offline. This also includes scheduled (de)publication to allow users to prepare pages in advance and have them go live when needed.
- Page versioning - Each individual page will have its own version history, and older versions can be viewed and restored in the Channel Manager. A new version of a page is created automatically upon (de)publication, content change and version restore, and additional versions can also be created manually.
- Embedded & referenced content - Since Experience Pages are based on documents, they offer the ability to embed content within the page. The benefit of this embedded content is that it’s also versioned with the page and can be viewed or restored in combination with layout changes. Embedded content can also be used for page-specific metadata or settings. On top of this, components on Experience Pages can reference content in other documents (this is already how components work today). This referenced content has its own lifecycle, and is not versioned together with the page. Referencing content is particularly useful for content snippets that need to be used on multiple pages, but managed in one place.
- Notification banner in Experience manager - When viewing an Experience Page in the Experience Manager, a notification banner is shown to indicate page publication status and other relevant information about the page. Since most of this information is only relevant in the context of an Experience Page, we will not show the notification bar in non-Experience Pages.
- Experience Pages are added to and searchable in the sitemap panel in the Experience Manager application.
- Since the available actions for an Experience Page differ from a regular page, the Page menu options are different when viewing an Experience Page.
This feature represents a major step forward in giving marketers and content editors the tools to work in a flexible way with pages, making it simpler to create landing pages for campaigns ahead of time and providing more opportunities for collaboration and review. We expect to build upon this first release with further page management related improvements in the coming versions. As always, we welcome customer feedback and will incorporate this into our development plans.
Click here for more details.
Example of an Experience Page, showing the version history and notification bar
In Bloomreach Experience Manager (and Bloomreach Experience), users can manage page layout using building blocks called components. These represent a part of the page that is implemented generically and can be re-used across the website. Examples include a Banner, a Carousel, various collections, a Product grid, etc. A typical customer project will include a number of components, some of which are supplied by Bloomreach and others that have been custom built by customers or partners. All these components are available in the Channel Manager Component Catalog, where users can select what to put on the page.
Example of the component catalog (left)
In previous versions, building new components involved writing Java code and doing (local) redeploys to check and test changes. It required a significant amount of familiarity with the HST delivery tier, and would often lead to code duplication and boilerplate being copied between projects. With brXM v14.3, this is no longer needed for the majority of component use cases. With the introduction of Dynamic Components, developers can create components on the fly and from configuration, in a running brXM instance. We provide a number of out-of-the-box base components that can be fitted with custom component parameters to meet a wide set of common requirements.
This feature fits in with our ongoing efforts to make our platform more flexible with less code. This is especially useful for headless implementations and decoupled front-ends using our Page Model API, as the need for redeploys of the CMS is reduced. For backwards compatibility and more complex component use cases, the previous methods for creating components are still fully supported and can be used side by side with Dynamic Components.
Click here for more details.
Page Model API v1.0
- We’ve flattened the JSON output, which makes it easier to understand and debug issues in your front-end application.
- There is no more need for certain work-arounds, such as those related to making sure links don’t contain a content path and are fully qualified.
- The menu is now a separate entity within the PMA response, making it easier to identify.
- Image sets are also a separate entity, and in the SDK we’ve added better support for working with them such as handling link generation for thumbnails.
- It’s easier to add custom contributions to the page model.
- We’ve also added the primary document as a separate entity at root level, which is particularly useful for experience pages.
- It’s no longer necessary to configure the base URL of the CMS, and as a result there is only one required parameter for the SPA SDK.
Click here for more details.
Content Search - Feed Exporter Module
As part of the launch of the new Bloomreach Content Search product, we’re releasing a Feed Exporter Module with brXM v14.3. This module takes care of exporting all documents in the repository for indexing in our centralized search index. It makes onboarding onto the Content Search solution much easier as existing brXM and brX customers do not have to have to worry about keeping their content in sync with the search engine.
Please note that Bloomreach Content Search requires a separate license. The existing brXM-internal query and search functionality (the Delivery Tier Fluent Search API) is still available and supported.
In this initial release, the exporter module only supports limited use cases. If you would like more information about this solution, please contact your account manager.
For end users
- Save as Draft - When creating a new document, a draft version can now be saved in the content perspective. By removing the need to fill in required fields before creating a document version, this enables users to continue work sessions without losing work progress, as well as improving collaboration on documents before publishing. Please note that for customers that have implemented custom SCXML changes, this feature will not be available unless they merge their SCXML definitions with the updates in this release.
- Custom screen types - We’ve added support for adding custom screen types to the Channel Manager, enabling preview functionality on screens other than the standard options (desktop, tablet and mobile). Additionally, it’s now possible to configure a default device for a channel which will be used when the channel preview is first opened.
- Shared & non-shared containers - As part of the Experience Pages feature, we’ve implemented a clearer separation between containers that are part of a page and containers that are shared with other pages (i.e. inherited from the channel configuration). The most noticeable change in user experience is that before being able to add or remove components in shared containers, users must explicitly enable this by pressing the “Edit shared containers” button. This change was implemented for old-style (non-experience) pages as well.
- Open UI field extensions are now able to read other fields in documents in which they are embedded. This is useful for extensions that need to alter their appearance or behavior based on one or more specific document field values.
- Allow custom subpaths in CMS context - With brXM v14.0 we’ve introduced an updated UI which features a separate Navigation Application (NavApp) that handles the internal navigation within brXM and brX. One side effect of this change was that custom resources could no longer be served from the CMS artifact, because their subpaths were blocked, since these were not on the list of allowed paths. With brXM v14.3, developers can now add a allowedPaths filter parameter to their web.xml or web-fragment.xml.
- We’ve added dynamic content bean generation support for the Related Documents, Taxonomy and Tagging plugins.
- Support for Elasticsearch 7 has been added (required for running the Relevance module with Trends & Experiments enabled).
Wicket version in brXM v12
The brXM user interface is partly built on the Apache Wicket framework. In brXM v12 we are using Wicket version 6.x, which uses jQuery version 2.x as a dependency. This jQuery version has a number of known, medium severity security vulnerabilities (see ). We will however not upgrade to a newer version of Wicket/jQuery for brXM v12, because this will not be backwards compatible and v12 will reach end of life when we release brXM v15.
V14.3 is a minor release so it is backwards compatible with the previous minor release. Also, updating to this version from the previous minor version should be of little effort. Please see the upgrade and update documentation  for details.
With this release, we’re adding support for Elasticsearch 7 (required for running the Relevance module with Trends & Experiments enabled).
The full system requirements can be found in the online system requirements . This page also includes a detailed table of maintained third party compatibility.
End-of-life, support and maintained code
As the terms ‘end-of-life’, ‘supported’, ‘maintained’ are used in various ways in our industry, we clarify the nomenclature we use for this below.
Supported product version
When a product is supported, this means that the customer will receive help from the helpdesk when issues arise as described in the service level agreement (SLA) that the customer has with Bloomreach. There are several service levels available.
Please note that if a bug is acknowledged in a supported, but not-maintained version, and a fix is needed, this fix will only be applied in the maintained product versions. This means the customer will need to move to a maintained version to receive the fix.
Maintained product version
When a product is maintained, the product code is updated and security- and bug fixes are made to the code. For maintained products, the system requirements for third party libraries and components is kept updated as well. Please note that we do not provide support for system requirement providers (e.g. databases, java, etc…), but we only support the usage for mentioned certified system requirement providers.
If a product is non-maintained, this means that the code is not maintained anymore and therefore might contain bugs and/or security vulnerabilities due to newly discovered issues in our code, or the libraries used.
End-of-life product version
Products that are not maintained and not supported are end-of-life. These might be available from our archives but could be removed without notice.
What does this mean for the current release?
Please note that this release does not change any maintenance or support mode.
In the table below you can find the support status of your product and when support will end; this is dependent on the version currently being used and license level. Please note that versions that are not listed are not active and not supported, and therefore end-of-life.
Several security fixes have been implemented in brXM v14.3. Per our release policy, these will be disclosed to customers first, and shared publicly approximately six weeks later.
This version of brXM is available as of September 16th, 2020 onwards. Please note that due to our release policy the release of the open source CMS / developer release will follow in approximately six weeks after this date.