Top 5 new features in Bloomreach v14.3.1

This blog post looks at some of the new features in Bloomreach Experience Manager(brXM) version 14.3.1, from a developer’s perspective. Even though it’s a minor version, it seems to have a bunch of very useful new features. Each feature will be explained accordingly.

Experience Pages

Experience Pages are self-contained pages combining content and page layout, which adds the option of a page-driven approach to Bloomreach Experience Manager.
Previously we’ve known Bloomreach CMS as a content-driven CMS which kept the page configuration and the content separated in different locations in the repository and follow separate workflows. Now with the introduction to Experience Pages, it’s now also possible to store both the page configuration (partially only the layout) and the content in the same place. This results in them being able to flow through the publication workflow as a single unit.

In the code definition below you can see that most of the information stored of the experience page is stored underneath the content root node. These definitions would normally be located underneath the hst:configuration node. If we go through the definitions, there’s a hst:xpage node present on line 22 which references the experience page layout it uses. This page layout was made previously underneath the hst:configuration node as one of the steps to be able to use experience pages. Next it also shows the contents of the page. In this case, it consists of a content- and banner component.

/content/documents/myproject/landing-pages/my-landing-page/my-landing-page:
  jcr:primaryType: myproject:contentdocument
  jcr:mixinTypes: ['hst:xpagemixin', 'mix:referenceable']
  jcr:uuid: 2cbe767d-64ff-4038-8787-d75171bc191c
  hippo:availability: [live]
  hippo:related___pathreference: []
  hippostd:retainable: false
  hippostd:state: published
  hippostdpubwf:createdBy: admin
  hippostdpubwf:creationDate: 2020-09-25T12:07:55.043+02:00
  hippostdpubwf:lastModificationDate: 2020-09-25T12:16:30.960+02:00
  hippostdpubwf:lastModifiedBy: admin
  hippostdpubwf:publicationDate: 2020-09-25T12:16:38.347+02:00
  hippotranslation:id: f5665154-8246-4412-926c-2ce88250f940
  hippotranslation:locale: en
  myproject:introduction: My Landing Page Intro
  myproject:publicationdate: 0001-01-01T12:00:00Z
  myproject:title: My Landing Page
  /myproject:content:
    jcr:primaryType: hippostd:html
    hippostd:content: <p>My Landing Page Content</p>
  /hst:xpage:
    jcr:primaryType: hst:xpage
    jcr:uuid: 849ec8db-2976-45c5-bfd8-020234679bca
    hst:pageref: landing-page
    /426f817d-200c-4298-8500-57fd704c37fa:
      jcr:primaryType: hst:containercomponent
      jcr:uuid: a46f2c4a-4ab8-4582-931f-4483249a481e
      hippo:identifier: 6d92607f-3746-4c4d-a6af-eeda0e448098
      hst:lastmodified: 2020-09-25T10:16:30.959Z
      /banner:
        jcr:primaryType: hst:containeritemcomponent
        jcr:uuid: 4d80071b-8716-41bf-b764-864ebf0d533c
        hst:componentdefinition: hst:components/essentials-catalog/banner
        hst:parameternames: [document, org.hippoecm.hst.core.component.template]
        hst:parametervalues: [banners/banner2, 'webfile:/freemarker/hstdefault/essentials-banner.ftl']
      /content:
        jcr:primaryType: hst:containeritemcomponent
        jcr:uuid: 2b5112e1-1d5f-459d-a4f9-e16b37a30995
        hst:componentclassname: org.onehippo.cms7.essentials.components.EssentialsContentComponent
        hst:label: Content
        hst:template: contentpage-main

What we normally would do in the brXM, such as copying or deleting a page, can now be done through the page documents instead. Since the page document and the page are now one entity, it’s not possible to separate the two. If a CMS user wants to delete the page document and link the page to another document that is not possible. Deleting the page document automatically results in the deletion of the page as well.

In previous versions it wasn’t possible to publish separate pages within a channel. The most that could be done is publish all your own changes. Now it’s possible to publish at least your own experience page separately, as the page configuration is now part of the content itself, leaving other CMS users to continue their work without the fear of having their changes published. On top of that, one can also choose to schedule the publication of an experience page which could come in handy when releasing a new part of your website.

xpage in brxm

In the above image, the landing page and several of its capabilities are shown. When clicking on the add button in the right upper corner the CMS user can add an experience page by filling in the form visible to the right of the page. After filling in and submitting the form, the page document will be created and added to the experience page folder within the CMS.

Finally, we also have access to version history of the pages now. When an experience page is selected and the CMS user clicks on the page button in the left upper corner, one can see the versions button. After creating a page and publishing it, it’s automatically added to the version stack and CMS users have access to the previous versions of a page. These versions can be restored and looked into. Besides on publication, a page can also be added to the version stack by clicking the designated button to do so.

Dynamic Components

Headless implementations and decoupled front-end approaches have become more popular over the years. In order not to stay behind Bloomreach has released a few key features to accommodate these changes under which the Page Model API. This API exposes information about the different components and their parameters present on a page in JSON format. Even with the page model API, developers were still left with the task of creating new components within the Java code to accommodate their customers’ needs. As a solution to this, bloomreach has introduced Dynamic Components. Previously a combination of Java and YAML definitions as needed to create new components in headless implementations or decoupled front-end approaches. With this new feature this is no longer necessary for most component use cases. Now new components can be created in a running brXM instance instead of having to redeploy the CMS every time a change is made. There are three types of dynamic components: Base Dynamic Component, Dynamic Query Component, and Dynamic Menu Component. Each of these components will be described briefly below.

Base Dynamic Components

With the Base Dynamic Component most use cases can be solved. As soon as the component is added to the component catalogue, to a page and the fields have been filled in, all its info is visible within the page model API. The key difference between the regular components and the dynamic components is the fact that no Java code is necessary to make use of the dynamic components. Everything that needed to be added in the ParametersInfo interface can now be done with a few parameters within the YAML definition of the component catalogue. In case the component needs to be used for another document, the CMS user can edit the field accordingly within the brXM. This type of Dynamic component will probably be used the most.

Dynamic Query Component

For the base dynamic component only the information of the selected documents will be added to the page model API. This is suitable for pages where only the selected data needs to be added to the page model API. But what if you need several documents to be added to the page model API like for a blog list. The base dynamic component isn’t ideal for this use case unless you’d like to add a lot of fields there. For this use case BR has the second type of dynamic component which extends the base dynamic component: The Dynamic Query Component. As the name suggests, this component queries over the content within the CMS based on the provided JCR node name(s). The CMS user fills in these names of the needed documents and if found, they will be added to the page model API. A fast way to provide all the needed documents without using any Java code.

Dynamic Menu Component

Finally, the Dynamic Menu Component. This component is strictly used to render the site menus available on your site. As soon as the component is added to the page, the CMS user can select the needed site menu in the dropdown made available for this component. This dropdown is an out-of-the-box feature configured to use the menu-list-provider. This provider is implemented by the org.hippoecm.hst.platform.provider.MenuListProvider class, which populates the dropdown with the available HstSiteMenus from the preview channel. To summarize the only thing the CMS user needs to do to get this component to work, is place it on a page and select the needed site menu.

API Output example

Below is the output of the Dynamic Menu Component in the page model API. It starts with an unique ID followed by meta data. This metadata consists of the parameter names and the value selected in the brXM. Next are the name, label, type etc. properties. Within the models parameter, there’s a $ref parameter which refers to the (in this case) selected site menu. This site menu can also be found within the page model API by searching for the reference key provided by the $ref parameter.

"uf738fab95aa54b8a9aa566c5c90c0851": {
      "id": "r5_r1_r1_r2",
      "links": {
        "self": {
          "href": "http://localhost:8080/site/resourceapi?_hn:type=component-rendering&_hn:ref=r5_r1_r1_r2",
          "type": "external"
        }
      },
      "meta": {
        "paramsInfo": {
          "menu": "main"
        },
        "params": {

        }
      },
      "name": "MenuDynamicComponent",
      "label": "Menu Dynamic Component",
      "type": "container-item",
      "ctype": "MenuDynamicComponent",
      "componentClass": "org.hippoecm.hst.component.support.bean.dynamic.MenuDynamicComponent",
      "models": {
        "menu": {
          "$ref": "/page/u0c85defd64ce4bcf909a527abf5a8a55"
        }
      }
    }

YAML definitions

Below is the YAML definition used to get the above described dynamic components to work. We have the BaseDynamicComponent, DocumentQueryDynamicComponent and the MenuDynamicComponent. All three components have next to the jcr:primaryType property three required properties namely:

hst:componentclassname - This property should specify one of the available dynamic component base classes.
hst:ctype - This property is used as a code-level unique identifier for use by the frontend application to select an appropriate frontend component implementation.
hst:label - This property provides the label string that is used in the component listing UI in the Experience Manager to display the component for use in a page template.

For the BaseDynamicComponent we added the property called document in which we describe the document we need for this component. In the below case all the document types can be selected, and no restriction has been set.

For the DocumentQueryDynamicComponent the properties documentTypes and pageSize were added. Within the documentTypes property, a query value is filled in. If no value is set within the brXM, the default query will be documents with the type myproject:basedocument. The pageSize parameter specifies how many results should be shown per page.

And lastly the MenuDynamicComponent which only has the jcr:primaryType property and the three required properties. As explained before the CMS user can select the needed site menu in the brXM.

/hst:catalog:
  jcr:primaryType: hst:catalog
  /example-catalog-package:
  jcr:primaryType: hst:containeritempackage
  /BaseDynamicComponent:
    jcr:primaryType: hst:componentdefinition
    hst:componentclassname: org.hippoecm.hst.component.support.bean.dynamic.BaseHstDynamicComponent
    hst:ctype: BaseDynamicComponent
    hst:label: Base Dynamic Component
    /document:
      jcr:primaryType: hst:dynamicparameter
      hst:valuetype: text
      /hst:fieldconfig:
        jcr:primaryType: hst:jcrpath
        hst:pickerconfiguration: cms-pickers/documents-only
        hst:relative: true
  /DocumentQueryDynamicComponent:
    jcr:primaryType: hst:componentdefinition
    hst:componentclassname: org.hippoecm.hst.component.support.bean.dynamic.DocumentQueryDynamicComponent
    hst:ctype: DocumentQueryDynamicComponent
    hst:label: Document Query Dynamic Component
    /documentTypes:
      jcr:primaryType: hst:dynamicparameter
      hst:valuetype: text
      hst:defaultvalue: myproject:basedocument
    /pageSize:
      jcr:primaryType: hst:dynamicparameter
      hst:valuetype: integer
      hst:defaultvalue: 20
  /MenuDynamicComponent:
    jcr:primaryType: hst:componentdefinition
    hst:componentclassname: org.hippoecm.hst.component.support.bean.dynamic.MenuDynamicComponent
    hst:ctype: MenuDynamicComponent
    hst:label: Menu Dynamic Component

Page Model API v1.0

As briefly mentioned before, the Page Model API displays information about different components and their parameters present on a page in JSON format. This new version guarantees easier integration and debugging by providing an easier to read JSON output, dedicated entities for menus and image sets and full support for Experience Pages and Dynamic Components.

Content Search - Feed Exporter Module

Content Search is a major feature that brings together the AI capabilities of Bloomreach Search with the content creation capabilities of Bloomreach Content. On top of that it improves the personal search experience by utilizing the Bloomreach Relevance Module. Previously if a long-time customer decided to use the Content Search solution, the developers would have the worry of keeping their content synchronized with the search engine. With the Feed Exporter Module, this is no longer a worry since it takes care of this.

brX GraphQL Service

GraphQL is an open-source data query and manipulation language for APIs. The new brX GraphQL Service brings together the APIs from Bloomreach Search and Merchandising and featured commerce platforms into one single GraphQL schema ready to be used by headless front ends.

Tech Blog