Architecture overview

Current version: 9.1

Sitecore consists of three major products:

  • Sitecore Experience Manager (XM)

  • Sitecore Experience Platform (XP)

  • Sitecore Experience Commerce (XC)

Each of the Sitecore components contains a number of logical entities that together with a number of cloud services form the entire functionality of the Sitecore platform.

Important

The roles depicted here are logical and do not represent physical or virtual servers, database servers, or search engines. Some logical roles can be combined into single physical entities within a topology.

Sitecore Experience Manager

XM refers to the web content management (WCM) core of the Sitecore Experience Platform. XM encompasses the features involved in the creation, management, personalization, and publishing of content. (The features available depend on which type of XM installation you have.) XM consists of the subset of the logical roles:

XM - arch overview - 9.1+

See also:

Sitecore Experience Platform

XP combines XM with the marketing and customer intelligence features offered by xConnect and xDB. xConnect and xDB introduce a number of additional server roles and storage mechanisms.

  • xConnect is the name given to the set of services that sit in between xDB and any trusted client, device, or interface that wants to collect and search experience data over HTTPS.

  • xDB is the name given to the collection of services and storage roles that store and process experience data. Clients that are external to xDB - such as a Content Management server - must use xConnect to read and write xDB data.

The following diagram lists the logical roles that are added by XP:

XP - arch overview - 9.1+

XP roles extend the content management, personalization, and delivery features of the XM with features that enable cross channel experiences, customer and business insights, collect actionable customer information and provide context when shaping the experience for customers.

The following diagram lists every logical role included in XP:

XM+XP - arch overview - 9.1+

See also:

Sitecore Experience Commerce

Sitecore Experience Commerce (XC) is a fully integrated, feature rich commerce solution. Deployed on top of Sitecore Experience Platform, Sitecore XC combines content management, personalization, marketing, customer intelligence and data with advanced commerce functionality in a single, powerful enterprise-level solution.

The following diagram shows the roles that Sitecore Experience Commerce includes:

See also:

Single and multitenancy

Sitecore XC supports both single and multitenancy out of the box.

With a single tenancy setup, you have a single website – or storefront – served by the Content Delivery role.

In the following diagram, the storefront makes calls to the Commerce Engine, accessing the entities and business logic configured for it.

With a multitenancy setup, a Content Delivery role can house multiple storefront sites and the Commerce Engine can host multiple entity and business logic configurations.

In other words, you can have a single instance of a Content Delivery role and Commerce engine role, hosting numerous storefront sites, each with completely tailored functionality.

Policies, environments and storage roles

There are two storage roles – or databases – in XC:

  • The Global database – stores all the global configuration data (policies and environments) that govern how the engine roles function.

  • The Shared Environments database – the main data store for a commerce deployment. It stores all of the commerce data used on site, including catalog data, customer records, pricing information, and any promotions you have configured, along with the generic entities and lists that power the functionality created in the various installed plugins.

A policy is a group of settings that define and affect the functionality of the individual features or plugins in the commerce engine.

Policies are named, versionable, variable datasets that help make the engine flexible and configurable. They are stored in the policy store in the Global database and are heavily cached.

An environment in XC is a collection of policies that affect how a call to the engine is handled. In other words, when a storefront calls the commerce engine for any functionality, it identifies the appropriate environment, which in turn affects the functionality provided by the engine.

Environments provide you with the ability to have separate functionality hosted in a single service instance.

This means that you can have the same call to the engine function very differently, depending on which environment variable is passed in. For example, if you request product details using a publicly facing Shops Environment, it would probably read from a cache to improve performance, whereas using a management facing Authoring environment would most likely pull data directly from the database.

Typically, you change policies and environments as part of a deployment using a process called bootstrapping.

Bootstrapping

Bootstrapping is the process of loading a set of changed configurations into the commerce system, changing the data models or functionality.

You create and manage environments and policies in configuration files – specifically JSON files – as part of the development or DevOps process.

To reconfigure and bootstrap XC, a developer or system administrator first stops all the engine roles that depend on the new configuration, then deploys the changed JSON configuration files to the DevOps role and subsequently uses a REST API tool, such as Postman, and triggers the Bootstrap REST call on the DevOps role. You can also execute the bootstrapping as part of a continuous deployment through a PowerShell script or similar.

The JSON configuration is read from the files on disk and the environment and policy data is stored in the Global database. If the bootstrapping is successful, the system runs with the new configuration and a message is returned to the developer or system administrator. When the engine roles are started again, they read the new configuration from the Global database.

You can also use the DevOps role to trigger other maintenance and deployment tasks, such as a rebuild of indexes in the system. Just as with the bootstrapping command, this can happen through a manual REST call or through a script. Reindexing loads data from the Shared Environments database and repopulates the appropriate index.

Do you have some feedback for us?

If you have suggestions for improving this article,