Guidelines for working with catalogs

This topic provides important guidelines for working with catalog structures in Episerver Commerce.

Catalog design

There is no single 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. 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 a complete set of requirements for what you are trying to accomplish with your catalog. Consider the following list of important questions when creating the catalog structure.

• How will the catalog be managed? Will it be updated directly or by an external data source?
• Which marketing, promotion, and merchandizing requirements must the catalog support?
• Does the catalog structure makes sense to your business team?
• Are the catalog's fields and data structures as simple as possible?
• Should you offload abstract data types (such as images and files) to the media management system (even though Episerver Commerce can store them)?
• Are you using solid naming conventions when defining meta-classes and meta-fields?

Plan to support integration requirements

Nearly all e-commerce applications, for B2C and B2B, require integration across a variety of systems, and you should understand and plan the needs for these. Not all e-commerce implementations 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. The following are examples of typical system integrations.

• Marketing automation and email 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 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 metadata system, their use can have a negative impact on performance. To avoid this, use 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 fashion products in a sample fashion catalog. The designer of this catalog creates a different meta-class to model fashion variants(variations)/SKUs called Fashion_Item_Class. The main difference between the two classes is the additional meta-fields on the item class to support the variant's size and color.

To improve performance, catalog entry meta-data is serialized and stored in a field for each catalog entry. This allows metadata 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.

Update the SerializedData field after updating any catalog data through third-party sources. The SerializedData field is part of the CatalogEntryDTO (data transfer object), and is cached based on catalog cache settings. Storing images and files in meta-fields increases the size of the serialized data and catalog cache size.

Catalog entry DTOs and caching

Catalog entry DTOs transfer data between your application and the database. Catalog entry DTOs are cached based on your ecf.catalog.config settings. For 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, enable catalog caching, 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. For 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 to a printable version or format for other purposes. See MSDN for  information about XSLT.