Skip to content

Product

Overview of the main product classes

classDiagram
  direction TB
  class ProductStock {
    InStock
    Reserved
  }
  class Price {
    CurrentPrice
    ListPrice
    ActiveFrom
    ActiveTo
  }
  class ProductVariant {
    ProductVariantId
    Name
    Fields
  }
  class Product {
    Id
    Url
    Images
    Videos
    Files
    Breadcrumbs
    Fields
  }
  class ProductCategory {
    Id
    Name
    Description
    MetaTitle
    MetaDescription
    MetaKeywords
  }
  ProductVariant --> Price
  ProductVariant --> ProductStock
  Product "1" --o "1..n" ProductVariant
  Product ..> Product : Sibling
  Product "0..n" --> "0..n" ProductCategory
  ProductCategory --> ProductCategory : parent

The Product together with the ProductVariant are the main domain classes for products. One Product can have one or many ProductVariant.

Each product can be associated with multiple ProductCategory.

Each ProductVariant has a price and a stock number. This is the SKU.

Each Product can have none or multiple sibling Product.

Product data flow

In general product data flows from ERP system to the backend API like this:

flowchart TB
  ERP[ERP system] -->|Some format to CSV import| PIM[Bizzkit PIM]
  PIM -->|PIM views to ProductSearch| Index[Search Index]
  Index -->|ProductSearch to domain model| API[Website API]

The first two data transfers are usually handled by recurring jobs in the backend. The third is done by request.

There is an enrichment of data going on in each step. The data from ERP is the core product data. Then we enrich it in the PIM with more data including images and texts that make the presentation more suited for web. Next, we enrich it even further with price and stock data in the index. Finally, we map and format the data for the frontend presentation to use in the backend API.

Read more about the Bizzkit PIM integration here.

Read more about the Search implementation here.

Variants and siblings

Think of the Product as what we render a card for in the product list. The ProductVariant is a variant of this particular product. We do not show each of these on the product list.

Think of the sibling Product as the same model of a product, but with a different configuration. The sibling has it's own product detail page and it's own card on the product list.

Example: Clothes

If you are selling shoes, then the shoe model in a specific color is the Product. The ProductVariant is a specfic size of this shoe in this color. Finally, the sibling is the same model of shoe in a different color.

So on the product list you see all the different colors of the shoe, but we don't have a card for each size.

On the product detail page we link to the siblings which in this case would be the other colors of the same model of shoe.

Example: Furniture

If you are selling a chair, then the chair in a specific color would be the Product. The chair only has one ProductVariant.

The other colors of the same model of chair are siblings of the Product.

Example: Letter bricks

If you are selling letter bricks for kids then the brick would be the Product and each letter would be a ProductVariant.

The brick product has no siblings.

Example: Tools

If you are selling a drilling machine, then you only need one Product with one ProductVariant and no siblings.

{{% alert title="Note" color="primary" %}} If you want to have related products displayed on the product detail page, then they are not siblings. These belong in a product attribute instead. {{% /alert %}}

A flexible system

As you can see from the examples the model we have here supports most relevant scenarios:

No siblings Multiple siblings
One variant ✅ ✅
Multiple variants ✅ ✅

It is even possible to mix these within the same solution.

We implemented support for this model all the way from exporting product data from the PIM all the way through the product search index and out to the backend API.

Mapping variants out of the Bizzkit PIM

The Bizzkit PIM features a very flexible product variant hierarchy. We have limited the implementation to only support variant hierarchies of depth 1 to 3 which covers the above mentioned scenarios.

Read more about the Bizzkit PIM integration here.

Mapping variants and siblings into the search index

Bizzkit ProductSearch supports two levels: Product and Sku. We map Product to the former and ProductVariant to the latter.

The siblings of a Product are mapped into the meta data.

Read more about the Search implementation here.

Frontend presentation

In the frontend we present the data from the Product on the product list. If the variants have different prices we display a "from price" on the card. The best stock status from the variants is displayed.

If you click a product on the list you navigate to a product detail page. If there are multiple variants you can select a specific variant here. No variant is selected until you do that and for that reason we still display a "from price" etc.

When you select a specific variant all the data on the page then reflect what is on that variant.

You can not add the product to the basket until you select a variant if there are multiple variants to choose from.

Siblings are by default only displayed on the product detail page. We only show an image and a product name and link to the siblings product detail page.

Attribute system

Bizzkit PIM limitations

The product data is managed by the Bizzkit PIM which features a very flexible attribute system. Mapping these attributes into the product search index and out to the backend API is not easy for all edge cases. For this reason the implmentation you get by default does not support every conceivable attribute configuration you can imagine in the Bizzkit PIM.

What we do support:

  • Up to four fields per attribute.
  • Attributes with multiple values.
  • Fields with a simple primitive type (int, bool, decimal, guid, datetime, string etc).
  • Fields with some referential types: CMS article, DAM file, Brand, Product, Youtube video. The rest are up to the specific solution to implement.
  • Support for ranges from a number to another number.
  • Product heirarchy attributes.

Notable features we currently do not support but might be added in the future:

  • Bundles.
  • Attributes on a global list item.
  • Attributes on a brand.

If you need these you will have to extend the integration.

When we map to the product to the Ecommerce Search model, we try to map everything the frontend needs to display products in the frontend without calling the backend for additional data. For this reason there are a lot of meta data mapped in that is then deserialized in the frontend.

The product attribute data you see on the website is based on the data from Ecommerce Search - not the PIM. This mapping is done directly in the frontend.

In the backend we also map data out to the product domain model. This product data is then used in for instance basket calculations and other places that need information about products.

Product fields

In the previously mentioned administration UI you can configure specific attributes to be the source of specific "product fields". You can think of "product fields" as the data on the product detail page that has a specific placement on the page. Like for instance the product name or the brand or the images. Under Website > Attributes you are completely free to pick the attribute that is the source of for instance the product name. This is not hardcoded - it is configurable!

This system is specifically designed to keep the model flexible and the work to change things minimal. You do not have to change all the layers of the application to handle new attributes or data on the product detail page or product cards. You only have to change the "product field" configuration and the mapping from Fieldsto the API response.

We use the following product fields in Bizzkit Blueprint:

  • Name
  • Description
  • Images
  • YoutubeVideos
  • Files
  • Brand
  • Size
  • RelatedProducts
  • MetaTitle
  • MetaDescription
  • MetaKeywords

Feel free to extend these to meet your specific needs in your solution.

Product specs

In addition to the product fields, you generally display attributes in a table on the product detail page. The so called "specs".

All attribute field values that are configured to be "visible in specifications" are located in the "Specs"-property.

We display these in a table on the product detail page in the frontend.

Pretty URL

Each Product has a unique URL for each Segmentation. We generate these every time you change the product. If the URL changes then we make sure to redirect from the old URL to the new one.

The default URL for a product is based on our own standard for SEO best practices. Assuming your host name is www.foo.com and the product name is "My Fancy Product" the URL will be: www.foo.com/my-fancy-product. That is the host plus a slug based on the product name.

It is very easy to change this to include other product data like for instance the breadcrumbs for the primary product category. All you have to do is change the ProductRouteInput-class in domain to include whatever data you need. You can map anything you want from the Bizzkit PIM's product view to this class.

Product Categories

Product categories in the solution are managed by the Bizzkit PIM. By default we syncronize one product hierarchy based on the config setting productCategoryRootSystemName (default just "ROOT").

You are allowed to have multiple hierachies in the Bizzkit PIM, but we have no support for that scenario out of the box.

Pretty url

Each ProductCategory has a unique URL for each Segmentation. We generate these every time you change the product hierachy node in the PIM. If the URL changes then we make sure to redirect from the old URL to the new one.

The default URL for a product category is based on our own standard for SEO best practices. Assuming your host name is www.foo.com and the product category name is "Vegetables" which is a child of a category called "Food" the URL will be: www.foo.com/food-vegetables. That is the host plus a slug based on the product category breadcrumb.

It is easy to change this URL. Just modify the RebuildCategoryRoutesJob.

Mega menu

The mega menu on the website is build by the ILayoutResolver implementation. The standard implementation builds the mega menu from the product hierarchy levels 1 to 3 under the root node.

Product breadcrumbs

In the Bizzkit PIM you can place a product in any number of product hieraki nodes you want. One of the placements has to be the primary one. We generate a bread crumb for the product based on the primary placement.

Price

Prices are associated with a specific ProductVariant. You can read more about prices here.

Stock

Stock is associated with a specific ProductVariant. You can read more about stock here.

Images, videos and files

We support both normal images and videos in the gallery on the product detail page. In addition we have support for downloadable files. This can for instance be used for downloading product manuals or promotional materials.

To use these features you have to configure the relevant Bizzkit PIM attributes and then configure these to be the source of these product fields.