The optimal solution for an end user would be a totally dynamic category structure that has no links to rigid and fixed structures at all. This will however create a mess when it comes to search engines with continuously changing category structures where the content is always changing. Not good for SEO.

In a traditional e-commerce site, there is often only possible to navigate to a structure in one way or maybe two different ways. I mentioned about this problem in my previous posts about the non flexible e-commerce stores.

Categories and attributes

In my case, when using STORM as the source of my product information, I have categories created with a focus on how to structure products in categories where the categories also are used to control which attributes that are valid under each category.

In this implementation, we have chosen to create a shallow category tree compared to what we used to have before in the previous solution. This structure will be available on the web site as a basic navigation structure where it is possible to navigate to each of those nodes.

Site navigation structure

The navigation structure in Sitecore is much deeper than the structure in STORM in order to assist the user in finding the correct product in category navigation. Each of the categories in Sitecore are then connected to a search criteria to find out which of the products to show in each category. The connection is made by the following search parameters:

• One or several categories in the master structure
• Filter on manufacturer
• Filter on attributes
• Filter on stock status

This makes it easy to drill down into the category structure without maintaining the details of each level by managing which products that belongs to each node.

In the screen shot above, you can see that we have connected the category source to a part in the commerce connect data model for classifications. We selected to set the name of each node with the entire hierarchical structure in order to know which leaf that has been selected. In our case, we have the leaf node of E14 in more than 8 places and we prefer to know which E14 we are dealing with.

Using STORM data within Commerce Connect data model

The other benefit of connecting Sitecore Commerce connect classifications with STORM categories is that we manage which attributes that are available on the classification level. This means that we can make an intelligent selection of which attributes that are really possible to drill down into in the end user interface in the e-commerce site. In STORM, we also select which of the attributes that will be possible to drill down on a category so that the user interface is kept nice and tidy for the end user.

When it comes to the actual content of the categories when it comes to populating them, we are using the STORM API to make real time requests to get a sorted list of which products to display on each category level based on the configured source categories and search parameters. The products are then fetched by using standard Sitecore item retrieval which makes us benefit from all cache functions in Sitecore.

Examples of such a query:

• Category: Master Catalog / Lighting / LED / E14
• Attribute: Bulb Shape = Classic P
• Attribute: Dimmable = False

Then Storm will return a list of SKUs matching the query. In Sitecore Commerce Connect, the products all have an external product ID.

This external ID can be calculated to find out the Sitecore ID of that item. There is an IdGenerator class that is accessible through the ProductRepository provided as part of Commerce Connect to really quickly retrieve items based on primary keys for display in the category tree. The request to STORM is of course also managed in a cache to not run a request over the network for each category browsing request.

What about SEO?

From a SEO perspective, we will make sure to have each product existing in one of the master categories that are quite full of data as the master source of that product. Bread crumbs will always point to this category if a product is referred to from a random URL or found in a result of a search engine. This category is then tagged with previous and next SEO style tagging of the links to show browse several pages of the category that at this point is really large. The focus on the smaller categories will be the category text section and prioritized images for each category.

The main navigation will not contain links to every category on the site. It will be limited to the top levels only to make sure that the search engine will have relevant child links when drilled down on each category structure. You will only see one or two levels down in the tree for each level that you drill down.

Each product will have a unique URL that is not connected to a category, so when ever there is a link to a product from a category, the link till go to the product URL and have no relation at all to the category.  This eliminates the need for dealing with canonical tags for each product and risk having a product appearing with details on several pages.

We have to be a bit careful about which information about a product that we share on the categories compared to on the product pages, which is also why we will save the important copy text to only be available on the product pages.

The data model in Sitecore Commerce Connect is based on  artifacts and product information. All data is stored within Sitecore as Sitecore Items, which means that the solution will use the same components as the rest of Sitecore for providing the standard features for search, scalability, API and the possibility to extend the model by use of inheritance. To populate this tree, there is a solution in Commerce Connect that will provide pre defined pipelines in which to run processors to deal with the different types of information required to keep the data up to date.

The tree consists of the data that are used to populate the product information and the product information itself. The folders under Product repository that are yellow are what are called “Artifacts” and are owned by the underlying backend systems but synchronized into Sitecore. The products are stored in item buckets and can be searched just as any item.

Product Synchronization

To be able to benefit from all the features in Sitecore, the product data is synchronized into the data model. This is done by using the concept of pipelines, where there are a couple of steps.

Each step consists of a pipeline itself, but this gives an overview of how the product synchronization works.

Synchronize artifacts

The artifacts are the fundamentals in the logical data model. This includes the different manufacturers/brands, divisions, classifications, attributes, product types. They are by default fetched from the external systems before products are synchronized to ensure that all data to refer to from the products are already present.

In the screen shot above, we can see the parametrics in STORM that are going to be exposed as attributes in Sitecore.  In STORM, the product attributes are named parametrics. Those attributes can be either plain input fields or selections from lists for single or multiple values.

When synchronized into Sitecore it is imported as specification lookups. This is then used to integrate with the product data model in Commerce Connect. A specification value can be either a plain input value or connected to a lookup list of fixed values to provide filtering in the frontend.

Get products list to synchronize

This part of this pipeline is used to decide which products to synchronize. We have connected this list to the ESB and a list of updated products that need to be populated in the frontend system. This is a list of external Ids of products that are to be synchronized. The really neat part here is that if data is fetched from several different system, this list can be concatinated as a total list of all products that need to be synchronized from several source systems such as a PIM system and an ERP system.

It is also possible to set a list of products to delete later on in the pipeline.

This list does not have to be a list of all available products, just the list of the products that need to be synchronized. In our solution, the e-commerce backend system will provide us with a list of the product ids that need to be refreshed in the frontend.

Evaluate which products to synchronize

This stage is to eliminate possible data that is not going to be read from the source system and stored back into the target system. This stage may contain calculations such as if the modification date is changed or based on a checksum. If a product is not to be synchronized, it is removed from the list created by the previous step.

Synchronize product

For each product identified in the steps below for being synchronized, this step is used to read the actual product from the source system. This pipeline is invoked once per product from the list that comes out of the steps before.

Several systems may be the source for the same product such as in the case where the ERP holds part of the information and the PIM systems provides additional information and assets.

This pipeline will also update the indexes with product information.

Delete products

The last step is to use the list provided by the previous processors in the pipeline for product synchronization to delete old products that are no longer to be available. This is normally only used for products that has not yet reach the status of sellable since it is not recommended from a SEO perspective to remove old products from the store. It is often better to preserve the SEO value and instead provide a replacement either by automation or by showing that on the product.

Flexibility in the pipelines

As all parts of Sitecore, the provided pipelines are just an example of how things are done. It is a good thing to try to stick to the intended way and just add and replace parts of the processors in the pipelines in order to keep the solution as standardized and upgradable as possible. We will look into the details in the different parts in the upcoming posts.