CoreMedia Digital Experience Platform 8 Developer Manual, Version 7.5.45-10
6.3. Website Management | 6.3.8. CMS Catalog

Requirements

Some companies do not run an online store. They do not need a fully featured shopping system. Nonetheless, they want to promote some products on their corporate site.

Solution

CoreMedia Digital Experience Platform 8 provides the CMS Catalog, an implementation of the e-Commerce API (known from the WebSphere Commerce Integration), which is backed only by the CMS and does not need a third-party commerce system. It allows to maintain a smaller number of products and categories for presentation on the website. It does not support shopping features like availability or payment. The CMS Catalog is based on Blueprint features. It is already integrated in the Corporate extension, so you can use it out of the box.

Content Types

In the CMS Catalog products and categories are modeled as content. There are two new content types, CMProduct and CMCategory, which extend the well known Blueprint document types CMTeasable and CMChannel, respectively. So you can seamlessly integrate categories into your navigation hierarchy and place products on your pages, just like any other content. In order to activate the new content types you have to add a Maven runtime dependency on the catalog-doctypes module to your Content Server components.

Content Beans

The modules catalog-contentbeans-api and catalog-contentbeans-lib provide content beans for CMProduct and CMCategory. The content beans integrate into the class hierarchy according to their content types, that is they extend CMTeasable and CMChannel, respectively. The content beans do not implement the e-Commerce API interfaces Product and Category, though. Instead, they provide delegates via getProduct and getCategory methods. While this may look inconvenient at first glance, it has some advantages concerning flexibility:

Configuration

First, you need three settings in the root channel to activate a CMS Catalog for your site. Blueprint Base provides a commerce connection named cms1 which is backed by the content repository. You can activate this connection by the livecontext.connectionId setting. Moreover, your catalog needs a name, which is specified by the livecontext.store.name setting. Finally, your catalog needs a root category, which is specified by the livecontext.rootCategory setting.

Figure 6.16. CMS Catalog Settings

Although the catalog indicator is a CMCategory document, it does not represent a category but serves only as a technical container for the actual top categories (see e-Commerce API, CatalogService#findTopCategories). The concept resembles the site indicator, which is the point of entry to the navigation without being part of it.

In a multi-site project sites may have different commerce connections. In order to make Commerce#getCurrentConnection work correctly regarding to the site a particular request refers to, you need to declare a Maven runtime dependency on the bpbase-ec-cms-component module and import some magic into the CAE Spring configuration:

<import resource="classpath:/com/coremedia/blueprint/ecommerce/cae/ec-cae-lib.xml"/>

While the product → category relation is modeled explicitely with the contexts link list, the reverse relation uses the search engine. Therefore, you need to extend the contentfeeder component with some Spring configuration from the bpbase-ec-cms-contentfeeder-lib module:

<import resource="classpath:/framework/spring/bpbase-ec-cms-contentfeeder.xml"/>

Templating

You can use both, Product or CMProduct templates. You can also use a mixture of both for different views or fallback to CMTeasable templates for views that do not involve CMProduct specific features.

Using Product templates you can easily switch to a third-party e-Commerce system later, since the interface remains the same. Otherwise you are more flexible with CMProduct templates: