Commerce Engine roles

Current version: 9.2

In a development environment, there is usually only one instance of the Commerce Engine running. This instance of the Commerce Engine services all traffic, both from the storefront and from the business tools.

In a production environment, traffic is usually split up among multiple installed instances of the Commerce Engine, which are usually physically located close to their traffic sources. These instances are referred to as Commerce Engine roles. This distinction is purely logical; there is no real difference in the deployed bits between different installed roles. These roles are defined by where the traffic originates from.

The following engine roles are considered during solution implementation. You must apply these in any production environment, even though implementation details can vary.

  • Authoring role: The Authoring role is the instance of the Commerce Engine that serves traffic from the Commerce business tools. Since this role serves lighter traffic (i.e., eCommerce solutions have relatively few business users compared to the number of shoppers), scale requirements are normally relatively low.

  • Shops role: The Shops role is the instance of the Commerce Engine that serves traffic from one or more storefronts. This role is intended to scale to support demand, and is usually installed in close proximity to the Sitecore Experience Platform instances that generate the traffic. To scale the solution, the Sitecore XP instances and/or the Commerce Engine instances can be scaled depending on traffic mix and the location of any bottlenecks.

  • Minions role: The Minions role is an instance of the Commerce Engine that runs independently and supports asynchronous processing. This includes any post-order capture processing as well as any cleanup or pruning.

  • DevOps role: The DevOps role is an instance of the Commerce Engine that is internal and only available to DevOps personnel. This role can have an identity with higher privileges allowing DevOps personnel to perform maintenance tasks that are not permitted to other roles (e.g., bootstrapping and environment initialization functions).

Each deployed role can have different policies and behaviors, which can be specified using a specific Commerce Environment for that role. When a call is made to the Commerce Engine, the call’s header specifies an environment. This environment is used by the engine to control policies and behavior for that call. Specifying a particular environment allows explicit independent control (per role) of functions, such as caching, data storage, integration connections, and so on.

Using environment policies, engine roles can either share a common persistent store, or use separate dedicated storage. All roles share the same storage in the out-of-box implementation. This allows artifacts to be visible to each role without a publishing process. For example, this makes orders immediately available to the Authoring role, and makes approved promotions and pricing changes immediately available to the Shops role.

Each role can have independent caching policies. For example, reduced caching can be configured on the Authoring role so that changes are seen right away, and heavier caching can be configured on the Shops role to increase performance.

Do you have some feedback for us?

If you have suggestions for improving this article,