Strategies for Designing your SAP Commerce Cloud Content Catalogs
6 min read
The SAP Commerce, Web content management system (WCMS) module solution is designed to manage content in the SAP Commerce Cloud catalog system. The catalog system for the WCMS is using a content catalog which can be configured to set up a specific content production workflow. This document will help to identify the different content catalog designs that are used in projects.
Table of Contents
The WCMS module provides important features for the catalog system like the catalog versions for creating "staged" content before it's published to the online storefront. The catalog versions are also used to grant read and write permissions to business users. The standard SAP Commerce Cloud WCMS supports two models for managing content in a storefront: single content catalog and shared content catalog. This article outlines three different models. For detailed pros and cons of each option, go to "Implementing Internationalization with SAP Commerce Cloud."
Single Content Catalog System
The standard approach to set up the content catalog in the WCMS is to use a single catalog for each storefront. This approach is used in the accelerator storefronts, represented in the schema below.
With this setup, you can't reuse content between different storefronts. You should use this setup if you want to isolate the content of your websites and restrict users from editing the content of specific websites. If you are aiming to reuse content between different storefronts (that is, for a multi-site setup for different countries), this setup is inefficient. Even if you are not sharing any content between storefronts, you will use the exact same storefront implementation (that is, design, templates, headers, footers). This catalog design may not be appropriate since templates can't be shared.
Shared Content Catalog System
The content you reuse should follow this design. In this example, the German and UK sites are sharing an EU content catalog. This design can be configured and is supported out-of-the-box in the WCMS module.
This design is advantageous because it can be managed in a central place and it's available to different storefronts. This is very useful if you manage your content from a central organization. To differentiate content for different storefronts connected to the same content catalog, for example, a page or component that is only visible for DE, you can use the standard WCMS restriction system. The restriction system determines whether or not pages or components are visible to users. Since there is no out-of-the-box restriction for storefronts, it requires some customization, so that content can be restricted to display when it is loaded in a specific storefront.
If your content is managed by different teams or organizations, this design might not work. Different organizations would change and publish the same content in parallel. This can cause serious issues in the workflow. Instead, we recommend that you consider a multi-layered catalog design.
Multi-Layered Shared Content Catalog System
A multi-layered content catalog system lets you reuse content for different storefronts while different organizations work on the content. This scenario is quite common for large organizations who are active online in multiple countries. In that case, you should have at least a global and local layer where the content is created. Your central organization would create and maintain templates, common pages, and content, like the checkout pages or corporate pages. Your local departments would maintain local homepages, landing pages, and campaign content. You can also use a third layer (regional) or even a fourth (channel).
The multi-layered content catalog design is the recommended practice for organizations who want to maintain content within different teams and still share some content.
The child content catalog inherits content from the online version of the parent content catalog. This means if your content managers have made changes to the parent catalogs in the staged catalog, the child content preview will not have these changes visible until they are published. See the following documentation for more details.
For more on how this can be configured in SmartEdit, please watch the following video:
The ability to create content workflows was added in SAP Commerce 1905. With the introduction of workflows, you can now set up complex approval processes to ensure your content is validated by the right people in the right order prior to being published in your online catalog. Two sample workflows are included in the default implementation, page approval workflow and the page translation and approval. These workflows are available in SmartEdit for users executing tasks. However, if you are looking to create new workflow templates or you would like to customize an existing workflow, administrators can do so in the Backoffice. We recommend that you review your requirements and create the necessary workflows to ensure only approved content reaches your online content catalog.
If you are familiar with the existing workflows or the collaboration center in the Backoffice, you can also use the Backoffice to access the same workflow actions available in SmartEdit. This could be used in cases where a content manager and product manager are on the same team.
This article introduced you to the fundamental challenges of content catalog design. Now, you know what
to consider if you want to design your content catalogs according to your context and needs. It also
discussed how you can use workflows to add an additional layer of checks on your site content. For more
information on how these different types of catalogs can be applied, please see Implementing
Internationalization with SAP Commerce Cloud.