Friday, March 9, 2018

Sitecore Experience Commerce - Commerce roles and how they tie in with environments

As part of the installation of Sitecore Experience Commerce, 4 commerce websites are added to the IIS manager, each of which performs a unique engine role. Note that in some cases users will scale this down to a single instance locally for development and the full 4 in production. These 4 roles are:
  1. Authoring - handles traffic from the commerce business tools.
  2. Shops - serves traffic from a storefront.
  3. Minions - runs independently and runs your minion(s).
  4. DevOps - internal and will have higher permissions to handle environment bootstrapping etc.
Sitecore Experience Commerce roles
These 4 engine roles actually have the same code deployed - via the Sitecore.Commerce.Engine project which contains references to any plugins you create as well as defined environments. 

Where they differ is in which commerce environment is defined against a given role. To quote the Sitecore documentation:
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.
So what exactly is an environment, again lets take a look at the documentation:
Commerce environments provide the ability to have separately configurable pools of data and service functionality that run together in a single-service instance. Environments can share the same persistent store as other environments or be separated into their own exclusive persistent store.
Basically an environment can be used to group configurations for a given function and can share as much as needed with other related/unrelated environments.

To give a better illustration, lets take a look at what comes out of the box with Experience Commerce and Habitat. Inside the default Sitecore.Commerce.Engine project (comes as part of the SDK and is what is deployed to these roles) is an Environments folder which contains a number of JSON configuration files. The files that are relevant for this discussions are:
  1. PlugIn.Habitat.CommerceAuthoring-1.0.0.json - Name: HabitatAuthoring
  2. PlugIn.Habitat.CommerceMinions-1.0.0.json - Name: HabitatMinions
  3. PlugIn.Habitat.CommerceShops-1.0.0.json  - Name: HabitatShops
Take note of the name of each of these environment (as defined in the JSON itself). Looking into the contents of these files you may notice that shops and authoring are quite similar and the main differences are a couple of extra policies and plugins on the authoring environment. They actually share the same store/context so this makes sense as we don't want customer migration processing to happen on the instance accessed by the storefront. The minions environment definition is quite different and of course has a heap of minions defined. 

Now if we go into each of the commerce role websites (mentioned at the start of this post) they each will contain a config.json file in the wwwroot folder. The EnvironmentName setting in these configuration files is the only difference at deployment time (remember the same project gets deployed to all 4). 
  1. Authoring - HabitatAuthoring
  2. Shops - HabitatShops
  3. Minions - HabitatMinions
  4. DevOps - AdventureWorksOpsApi
As you may have noticed, these 4 roles each refer back to one of the habitat environments defined above. This is how each role knows what it's purpose is and it ties back to the environment. In this out of the box implemtation they all work together: All roles share the same storage in the out-of-box implementation.

Note: the AdventureWorksOpsApi environment does not appear to have been defined or shipped with the version of the SDK that I used. In this case it's fine to also set the role of this to the HabitatAuthoring or to remove this and point to the Authoring role.

There are two final pieces to this puzzle:

How does an environment appear in Experience Commerce Business Toosl?
Inside the Sitecore.Commerce.Engine project is a Global.Json file, this contains a GlobalEnvironment section which is where the values of environments you wish to appear in the business tools will be listed. Generally this would just be the authoring and shops environments (as is out of the box).

How do we define which environment is used inside Sitecore itself?
The full answer is available in my post: Sitecore Experience Commerce - Catalogs in the Sitecore Content Editor. The short answer is that the Sitecore.Commerce.Engine.Connect.config configuration file has a defaultEnvironment setting where we name the environment.

Hopefully this blog post has provided some clarity about what the commerce roles are in Experience Commerce and how they relate back to environments. 

No comments:

Post a Comment