The Connect product data model

The rationale behind the architecture of the Connect product data model is:

  • To have a product data model that fulfills the identified end-user scenarios.

  • To have a single common product data model regardless of the external commerce system (ECS) used.

  • To have the same model across different solutions making it easier for solution developers.

  • To have components that are easy to build and maintain for UI component developers because the data model remains the same across external commerce systems.

Product data is complex and in Connect there is not a one-to-one mapping between a single product and a single item in Sitecore - in the same way that product data in the ECS is not stored in a single SQL table.

Note

Data for a single product consists of multiple Sitecore items. In order not to confuse matters with CMS items, they are referred to as entities in this document and in Connect.

In Connect, a product data model is designed to:

  • Provide a solid base for typical e-commerce scenarios.

    The main reason for pulling product data into Sitecore is to augment it and present it on different shops and channels, for example, media, web, mobile, print.

    The product data must be normalized to ensure it is valid and provides a sound foundation to build on and to enable scenarios to be fulfilled.

    Data for a product is stored as a composite structure. There is a main content item based on a Product template representing a product with only the shared generic fields such as ID, Name, Description, Type, and so on. Below the product item is a sub-tree structure with specifications, relationships, and resources. In addition, there are several related repositories that a product links to, such as Manufacturer, product type, and so on.

  • Avoid redundant product data

    Having too much redundant data (for example, storing all data for a single product in one Sitecore item) results in the need to manually synchronize and update data in Sitecore and this becomes difficult to maintain.

    Instead separate repositories are used for shared data such as manufacturer information, divisions, and specifications and referred to by way of linking. This is similar to the way normalized product data is stored in separate tables in an SQL databases and references with foreign keys.

  • Minimize product data synchronization

    By avoiding redundant data, the amount of data to synchronize is minimized. Also, not all product data is needed from the ECS. Only product data needed to fulfill the scenarios described in the following sections are synchronized and stored in Sitecore.

  • Avoid typical custom model implementation issues

By dividing product data into a composite product structure and placing data into separate repositories, the most typical implementation problems can be avoided. Problems such as:

  • Flat model

    In a flat model, a single item represents a product. Without composition of multiple items to make up product data, the model will:

    • Be simple, missing out on a lot of the needed information.

    • Have a lot of unused fields or use a large number of templates to cover all the different product types. Both are not best-practice.

    • Have a lot of redundant data for similar products or variants.

    • Force data into custom field types or encode data using custom schemes.

  • Redundant data

    Without separate repositories for storing shared information, redundant information is unavoidable.

  • Too many templates

    Using a separate template for each product type soon becomes unmanageable with a large number of different products.

  • Difficult to extend

    With a single item for a product and without composition of multiple items to make up product data, it becomes difficult to extend with custom data.

  • Content editing of redundant data is time consuming

By leveraging the new features in CMS 7, it is possible to use buckets and features such  as Linq based searches against custom product indexes, returning product objects through the new Hydration model. The Hydration model is similar to NHydrate and Nhibernate. For more information, see the latest version of the Data Definition API Cookbook for Sitecore.

Instead of forcing product data into a single item in an artificial construct, the data is stored in a more natural way with a composite structure that will make it easier for the ECS to be integrated with, customized and extended.