All you need to know about Sitecore Experience Commerce 9 - Part 1: Architecture

Last week, I gave a presentation on Sitecore Experience Commerce 9, covering quite a few topics all the way from architecture, extension and plugins,to Commerce APIs. I'll be covering these in a series of blog posts with the same title, with this being the first part on Experience Commerce 9 architecture.

Key Building Blocks

There are three main areas that make up the key building blocks of XC 9:

  1. Commerce Engine
    The Commerce Engine is the core application that provides OOTB ecommerce functionality such as Cart, Order, Pricing, Promotions, Catalogs and Inventory. It is built on .NET Core and provides a framework that allows for a pluggable architecture to customise, add and remove OOTB functionality. This is the area that this series of posts will focus on mostly.

  2. Business Tools
    Business Tools is the backend UI that is used by merchandisers and CSRs to manage catalogs, inventory, promotions, pricing, orders and customers. To ready more about how to extend Business Tools, have a look at my post here.

  3. SXA Storefront
    The SXA Storefront provides a set of pre-built drag and drop components (40+ and increasing) to implement ecommerce functionality on your website. These components are themeable and extensible, similar to standard SXA components.

Solution Components

solution_components

They key Commerce components are highlight in blue above. Core functionality is provided by the Commerce Engine which hosts all the Commerce services such as catalogs, inventory, pricing, promotions, customers, and orders. Commerce Engine Connect is a connector that integrates the Commerce Connect Core layer and Commerce Engine, whereas Commerce Connect core allows integration between the front end website and Commerce functionality. At the very top sits SXA Storefront.

Solution Architecture

solution_architecture

The key Commerce components are highlighted above in blue. The Commerce Services section groups the Commerce Engine instances. In a scaled out architecture such as above, you have seperate instances of the Commerce Engine that are configured for different roles (more on roles in next section). The four main roles are Authoring, Minions, Shops and DevOps. The Business Tools sits in Content Management. Both Content Management and Content Delivery interact with the Commerce Engine, but normally via dedicated instances of the engine as shows. Commerce data is stored in two databases- global and shared, each of which serve different purposes.

Commerce Roles

commerce_roles

Roles are logical entities that can be scaled and configured to create your desired topology.

Commerce has application, storage, and index roles.

  • Application roles can be hosted in IIS or Azure App Service.
  • Storage roles support SQL Server or Azure SQL Database.
  • Indexes can either be on Solr or Azure Search.

Some roles, such as commerce application roles can be combined into a single entity to simplify your architecture.

Application roles:

application_roles

The Commerce Authoring role is the instance of the Commerce Engine that serves traffic for the Business Tools.

The Commerce DevOps role is an instance of the Commerce Engine that is used for DevOps purposes such as bootstrapping etc.

The Commerce Minions role is an instance of the Commerce Engine that runs background async process and scheduled tasks. It runs independently.

The Commerce Shops role is the instance of the Commerce Engine that serves traffic to the customer facing website/storefront.

NOTE: All these roles can be scaled except for Minions.

Storage roles:

storage_roles

The global database stores all the global configuration data (policies and environments) to configure various Commerce Engine roles.

The shared database stores Customer, Order, and Catalog Entities.

Index roles:

index_roles

The indexing roles are responsible for indexing Commerce entities such as catalog data, orders, and customers. These indexes allow merchandisers to search for catalog items, orders, and customers in the Business Tools UI.

Indexing is performed by minions by watching specific Commerce lists in the shared database. Both incremental and full index rebuilds are supported.

Note that these indexs are not used by the customer facing website- they are only used by the backend Business Tools.


Hopefully, this gives you a good high level overview of the architecture in Sitecore Experience Commerce 9. Stay tuned for my upcoming posts in this series where I'll dig deeper into customisation, plugins and the commerce service API.