Understanding the product repository
If your Commerce Connect solution uses product synchronization, then you use a product repository to store product data locally in Sitecore.
One single repository
It is best practice to manage only a single product repository even if multiple webshops are hosted in the same Sitecore instance. The product repository is designed to handle multiple webshops, and products can either be completely isolated from each other, or some of them can be shared between the different webshops. You can use divisions to tag products, and a product can be tagged with multiple divisions. You can use divisions to indicate, for example, which webshop or webshops a product belongs to.
The default implementation is only designed to handle a single product repository, but it can be customized.
Template design for the item model
The product synchronization service layer also includes an item model representation in Sitecore XP content based on a number of predefined templates. The model consists of:
-
A main bucketed product repository that contains composite tree structures, each representing a product.
-
A number of associated repositories that hold data that is related to products such as manufacturers, classifications, categories, product types, divisions, and resources.
A typical approach to designing product repositories is to put all product data into a single item to represent a product in Sitecore. This single-item approach results in a flat model with the following disadvantages:
-
Redundant data – the same data being duplicated into multiple product items, which share the same information. This is not best practice in an SQL database or in Sitecore. The more duplicated data, the more space it consumes and the harder it becomes to maintain when data is changed.
-
Template overload – can lead to one of these undesirable designs:
-
One template for all products that has to include all the combinations of all fields for all the types of products in the repository. Only a small fraction of the fields is filled out for any given product.
-
One template for each type of product, with dedicated fields for the given product. Even though template inheritance seems like a good idea, it will lead to an overload of templates because of the amount of different product types.
-
In Commerce Connect, the solution is to split up the product data into multiple items, with a single template for the core product data and a fixed small number of additional templates for each additional type of information.
The templates used for the item-based model remain the same, regardless of the types of products.