Guidelines for working with catalogs

This document provides some important guidelines for working with catalog structures in EPiServer Commerce.

Catalog design

There is no right way to design a catalog. Organizations in the same business may create very different catalogs depending on what they are trying to accomplish and the choices they make. However, there are some central things to consider when designing catalogs, and the EPiServer Commerce Catalog subsystem, architecture, and APIs provide great flexibility for designing and implementing catalogs.

Define a complete set of requirements

As with all systems, it is extremely important to define your complete set of requirements for what you are trying to accomplish with your catalog. Listed below are some important questions to consider when creating the catalog structure.

• How will the catalog be managed, will it be updated directly and/or by some external data source?
• What are the marketing, promotions, and merchandizing requirements the catalog must support?
• Make sure that the catalog structure makes sense to your business team.
• Keep the fields and data structures of your catalog as simple as possible.
• Although EPiServer Commerce can store abstract data types such as images and files directly in the catalog, consider offloading these to the media management system.
• Use solid naming conventions when defining your meta classes and meta fields.

Plan to support integration requirements

Nearly all e-commerce applications, both for B2C and B2B, require integration across a variety of systems, and the needs for these must be understood and planned. Not all e-commerce implementations will require integration, but in the rapidly changing world of e-commerce data is increasingly being shared, not only with internally managed systems, but a variety of external providers. Listed below are some examples of typical system integrations.

• Marketing automation and e-mail marketing
• Retail merchandising
• Enterprise Resource Planning (ERP)
• Product Information Management (PIM)
• Digital Access Management (DAM)

What data will you need?

Think carefully about the data you need. Migrating your product catalog to a new system may give you support for e-commerce and reporting features that you currently do not have. These features normally require data that is needed, but non-existent in your current system. Plan the data you need to support your site, reporting, marketing, and merchandizing and to ensure all of your requirements are met.

Understanding catalog components

Meta classes and meta fields

Use solid naming conventions and standards when creating fields and classes. While complex data types (images, files) are supported by the Meta Data system, their use can have a negative impact on performance. To avoid this, make use of the EPiServer asset/media system and/or image file servers. Use meta classes to model different types of commerce content.

The following example shows a meta class named Fashion_Product_Class to model all fashion products in a sample fashion catalog. The designer of this catalog has chosen to create a different meta class to model all fashion variants(variations)/SKUs called Fashion_Item_Class. The main difference in the two classes is the additional meta fields on the item class to support size and color of the particular variant.

To improve performance, catalog entry meta data is serialized and stored in a field for each catalog entry. This allows all meta data information to be fetched from a single field and de-serialized, which reduces the number of database calls and greatly increases performance compared to non-serialized data fields.

The SerializedData field should be updated after updating any catalog data through 3rd party sources. The SerializedData field is part of the CatalogEntryDTO (data transfer object), and will be cached based on catalog cache settings. Storing images and files in meta fields will increase the size of the serialized data, and increase catalog cache size.

Catalog entry DTOs and caching

Catalog entry DTOs are used to transfer data between your application and the database. Catalog entry DTOs are cached based on your ecf.catalog.config settings. Example:

<?xml version="1.0"?>
<Catalog autoConfigure="true">
  <Connection connectionStringName="EcfSqlConnection" />
  <Cache enabled="true" collectionTimeout="0:1:0" entryTimeout="0:1:0" nodeTimeout="0:1:0" schemaTimeout="0:2:0" />

During development it can be beneficial to disable caching. When deploying your e-commerce site, make sure catalog caching is enabled, and use cache timeouts appropriate for your requirements and environment.

CatalogEntry DTOs are cached based on the response group(s) used to retrieve them.

Types of CatalogEntry response groups:

• Request
• CatalogEntryInfo
• CatalogEntryFull
• Associations
• Children
• Assets
• Nodes
• Variations
• Inventory
• RecursiveAssociations

Catalog entry objects vs. catalog entry DTOs

Entry objects are used to further abstract catalog entry DTOs. Example:

namespace Mediachase.Commerce.Catalog.Objects
{
/// <summary>
/// The Entry parameter serves as a container element that is a child of the Entries element, and
/// represents the Catalog Entry element, which can be Product, Variation, Bundle or any other type of product.
/// </summary>
[Serializable]
public class Entry
   {
}

Entry objects are not cached, but the underlying DTOs they are constructed from are cached.

Catalog categories

Catalog categories provide structure to your catalog content. While search is a vital part of any e-commerce site, many customers still want to browse a site much like they would a typical offline store or print catalog. Display templates can use catalog categories to provide this experience in addition to search based results.

Extracting data from a catalog for use in other systems

You can export the catalog as an XML file, and then write an XSLT template to transform the XML file into a printable version or format for other purposes. Refer to MSDN for more information on XSLT and its usage.