Overview

The purpose of the Product Content Mangement Module is to allow users to organize and manipulate the structures and heirarchies of every aspect of catalogs of products. From a distance, the product heriarchy is this:

Catalog <- Version <- Category <- Product

That is, a product will belong to a catagory (or many), categories will belong to catalog versions, which will belong to a catalog. Each of these aspects will be explored in the following sections.

Backoffice Product Content Management is a makeover of the old Product Cockpit. it allows for convenient product data management using an intuitive design. Backoffice Product Content Management (aka Backoffice PCM) is built utilizing the Backoffice Framework, which makes it highly configurable.

Products

Catalog <- Version <- Category <- Product

Products are items that will have a corresponding real world SKU (Stock Keeping Unit). That means that products exist in the real world. Product manager users can create products in Backoffice quickly, applying these properties.

• Article number – A unique identifier for the product. (not restricted to numeric values)
• Approval – Sets the approval status of the product. If not approved, it will not appear on site.
• Catalog versions – Applies catalogs to the product, allowing the product to appear where the user would like it to appear as per the catalog properties.
• Identifier – Name of the product displayed. Localization (translation) is supported.
• Description – The text description of the product. Localization is supported.
• Categories – Applies categories to the product, allowing the product to have the appropriate properties as provided by the category. Uncategorized products cannot be found in search but can be accessed via URL.
• Images – The user can upload images directly or use existing images to showcase the product.

EXERCISE: Create a Product

Media

A media item (image, video, etc) in SAP commerce cloud:

• Contains metadata
• Is stored in the database as a reference to a single physical file (such as a jpeg or mpeg.)
• The Physical files can be stored locally or remotely
• Has an identifier
• Is assigned to a catalog version and can be synchronized along with it
• Has a URL that points to the location of the actual file

A media container is a group of media items that are mostly the same. For example, multiple sizes or file types of the same image. For example, a product should inherit a media container. The media container should be assigned several of the same image with different image formats.

• SuperZoom format 1200Wx1200H (Depreciated)
• Zoom format 515Wx515H (Magnified zoom on product page)
• Product format 300Wx300W (standard product image)
• Thumbnail format 96Wx96H (Auxiliary product page images and cart image)
• cartIcon format 65Wx65W (mini-cart image)
• StyleSwatch format 30Wx30H (shows product variants on product page)

SAP Commerce uses the open source ImageMagick to handle image conversion in Backoffice. With it you can access these capabilities in any image properties, or from the media conversion navigation menu:

• Import/Upload one high res image file
• Convert the media file to required predefined formats
  • Manually – triggered by user
  • Automatically via CronJobs
  • In real time when requested by a touchpoint (web, mobile, etc.)

Product variants

Variants are products of identical design and functionality, but with some differences, such as a t-shirt with several color options. Variants commonly use the type system product variance. For example, a shirt product might have several size variants which each inherit from the base product. Each size might then have a color variant which inherits from the size variant. In this example, the customer cannot select a color variant until they have selected a size variant. Customers can only buy an SKU that corresponds to the lowest variant product. In Backoffice, base products will have a single block icon, variant products will have a multi cuboid icon in the status column. This model is best for catalogs where products’ attribute sets rarely change. To create a product variant in Backoffice, follow the instructions here.

Multi-dimensional product variants

As an alternative to the type system for variants, you could employ the multi-dimensional product variant design. Each product will inherit from multiple variant categories. Each variant category will have child variant value categories (color might have blue, green, and red for example). Then, each generic variant product inherits from the product and a variant value category from each value category. Be warned that the more dimensions you have, the more difficult it will be to practically visualize on the front end.

Configurable Products

Configurable products have customer-controlled variables. They will require this additional information from the customer to complete the purchase flow. Configuration categories can be applied as supercategories in the same way as the classification categories. When a configuration category is applied to a product the UI will automatically include configure buttons in many views. In this example, you can see how this works. You can also see that the nearest inherited category property overwrites further away category properties of the same name.
Requires CPQ integration.

Categories

Catalog <- Version <- Category <- Product

Categories are groups within versions that are applied to products (or even other categories) to share attributes and manage navigation. As opposed to strict parent-chlid relationship between categories and products, they share a many to many relationship, meaning that a category can contain multiple categories and belong to multiple categories. To understand the function and potential of a category, you need to understand product data modeling. There are two ways of modeling your product strategy in SAP Commerce: use the type system or the classification functionality. Each of these two ways is a technically different approach with individual advantages and disadvantages. In many cases, a mixture of both typing and classification is a good idea.

Type system

A type is a template for objects. Types define product data that objects may carry and specify relations between objects, and also make product data persistent by categorizing the data and relating it to database fields. Every object stored in Platform is a type instance. The property templates of an object cannot be modified except by developers in the item.xml file. To add properties to an object dynamically, use the classification system.

Classification system

Products use a standard type system inheritance for properties. In this way, all products will share all product properties as well as properties specific to their own product type. But, outside of creating basic shared properties, it is supported practice to add properties to a product using classification. These allow the business user to create and apply supercategories dynamically which will add properties to any product based on the applied classification. Learn more.

When should you implement the classification system?

• When we need to define product attribute only for selected number of products rather than defining for each and every product.
• When we are not sure about the lifetime of the attribute which may become unnecessary after few weeks or months.
• When we need to add product attributes dynamically at run-time.

Versions

Catalog <- Version <- Category <- Product

Categories are contained in catalog versions. A catalog version can represent the collection of products you offer at a certain point in time. To maintain your collection within a basic process, you typically contain two or more catalog versions in an object called a catalog. For example, while you can have one catalog version for editing the content (the Staged version), you can use another catalog version for propagation as a web shop (the Online version).

Only one catalog version within a catalog can be active at a time, which in a web frontend typically provides the propagated online version. Consequently, this concept is applicable only for sequential catalog maintenance processes that propagate only one catalog version. 

Synchronization

Synchronization is the process of copying content from one version to another. Un-synced items will have a clearly visible split red icon which turns green and level when synced.

• Syncronization is unidirectional
• It can be performed manually or through scheduled Chronjobs
• Works at catalog, category, and product level (so long as category exists).
  • Synchronization at category level does not sync products within the category
• Items in the target catalog that match identifiers are overwritten. Those in the target that are not overwritten remain in the version. (Can be modified in configuration)
• Synchronization should be scheduled for low traffic times as it is performance heavy.
• Synchronization jobs can be created and customized
  • Remove missing elements: True/False (If target has products not in source)
  • Create new elements: True/False (If target missing products in source)
  • Many other configurations

Catalogs

 Catalog <- Version <- Category <- Product

A catalog is a list of available catalog-aware items (users, products, orders, etc). Catalogs provide functionality to hold, structure, and manage products and product info.

A catalog contains one or more catalogs versions (subgroups), such as staging and online. Each catalog version has a hierarchy of categories, containing the basic element of a catalog; the product. Products are items that will have a corresponding real world SKU.

Catalogs allow you to set up visibility by defining visibility explicitly or by inheriting visibility from a parent category.

There are two types of Catalogs

Catalog Management

SAP Commerce supports several catalog management structures. Consider these common structures.