Tips For Quick and Effective Sitecore Commerce Development


When we are asked to invent or extend Sitecore Commerce functionality, starting our new Solution/Project can be a bit daunting. There are many Sitecore DLLs to decompile and consult, and many .Net Solution templates to choose from online. This can quickly result in “analysis paralysis”. In such a situation, it's better to start out, simply. As such, there are some approaches I find very helpful when inventing or extending Sitecore Commerce functionality that I’d like to share.


1.    Execution architecture to keep in mind. In general:

  • Controllers call Commanders
  • Commanders call Pipelines
  • Pipelines call Blocks
  • Blocks execute the detailed work germane to their scope

2.    When you need to understand a Sitecore Plugin, decompile the DLL and familiarize yourself with these two classes first:

  • ConfigureSitecore.cs

This class defines the Pipelines provided by the Plugin.

This is Sitecore Commerce’s version of the Sitecore.config <pipelines>…</pipelines> configuration.

  • ConfigureServiceApiBlock.cs

This class leverages the Microsoft.AspNetCore.ODataBuilder.ODataConventionModelBuilder class to define the plugin’s available service endpoints, service parameters, and service return types.

3.    Consult the Node Configuration Log
In each Sitecore Commerce Service directory, there will be a log file: [Service Name]\wwwroot\logs\NodeConfiguration_Deployment[…].log

Within this log file, you’ll find a handy, easy-to-read representation of all pipeline definitions in this Node.

Additionally, when you create a new Pipeline and/or Pipeline Block, this log is a good way to assure yourself that your new Pipeline has been loaded and that your new Pipeline block is loaded in the correct place.

4.    Read the CommerceCommand derived classes:
Most of the CommerceCommand derived classes leverage the Command Pattern.

As such, they will bring you up to speed very quickly on exactly what is necessary to facilitate a particular Sitecore Commerce functionality.


1.    Steal Shamelessly
There is no reason to re-invent the wheel. The Sitecore Commerce code is the standard by which we guide our own development and is, therefore, a great starting point for your own Controller, Command, Commander, Pipeline, or Block.

For example, if you’re extending the Sitecore Commerce Cart functionality:

a.    First, decompile the Sitecore.Commerce.Plugin.Carts.dll file

b.   Use the Research cheat sheet above to quickly familiarize yourself with the functionality of the Plugin

c.    Literally copy the Sitecore source code germane to your feature into your solution

d.   Add your new functionality to the copied Sitecore code in your solution.

2.    Enable .Net Core logging
In the root of each Sitecore Commerce Service is a web.config file. It’s a quite modest file, but the <aspNetCore …/> element provides us with the ability to capture .Net Core output:

a.    stdoutLogEnabled:
Enable, or disable, .Net Core logging for the Sitecore.Commerce.Engine.exe process

b.   stdoutLogFile:
The location to where your stdout log files will be written. Do be mindful of disc space: The Sitecore.Commerce.Engine.exe process can be loquacious. Finally, be sure not to ship your code with stdout logging enabled.

3.    Other helpful aspNetCore attributes in Web.config

a.    arguments:
You may pass .Net Core startup arguments to the Sitecore.Commerce.Engine.exe executable

b.   requestTimeout:
Very helpful when debugging long-running processes or testing request timeouts.

Again, do remember to set these values back to their defaults before you ship your code.

4.    Favor Commanders over Repositories
If we examine the ConfigureSitecore.cs file for any Sitecore Commerce project we’ll see these lines (not necessarily contiguous as shown):

Assembly assembly = Assembly.GetExecutingAssembly();

The Sitecore.Commerce.Core.CommandsServiceCollectionExtensions.RegisterAllCommands() method simply loads all classes that inherit from the Sitecore.Commerce.Core.Commands.CommerceCommand class into the IOC Service collection.

Meaning any custom Commander class you create, which inherits from CommerceCommand, will be available for constructor injection immediately.