My Intro To Sitecore Commerce
I’ve been working with Sitecore for years now, but recently I got the opportunity to work with a Sitecore module I had never been exposed to before — Sitecore Commerce. I’m FAR from being an expert with Commerce yet, but I thought I’d share what I’ve learned so far.
What Is Sitecore Commerce?
As you might have guessed, Commerce is an module that allows you to add eCommerce functionality to a Sitecore application. It takes the form of a .NET core web application that provides various REST API’s to interact with, along with a number of background services (called Minions) that perform tasks on a scheduled basis. The Commerce application itself has no administrator interface, but Sitecore provides an admin application called BizTools to manage data in Commerce.
One Application — Four Roles
While Commerce is one code base, it is deployed as four separate web applications, which take on different roles based on configuration. The four instances of Commerce are:
- Minions — Runs background task pipelines based on various triggers.
- Shops — Provides the API endpoints for the public-facing web site to interact with Commerce.
- Authoring — Provides the API endpoints for the back-end administration to interact with.
- Ops — Manages the configuration and maintenance of the other three instances.
Application Structure
There are two main components to the application, the API endpoints that allow the web site to interact with commerce, and the tasks run by the Minions.
The API exposes various endpoints using the OData protocol that allows for all the interactions between Commerce and the web site.
The Minions define a number of multi-stage pipelines that run independently based on various triggers.
The Database
The Commerce database stores information differently than regular Sitecore items. There are a number of different entity types in Commerce, and each one is stored in its own set of tables.
Entities are stored in a single row, with their content stored in a single fields as a serialized JSON block.
Each entity also has a corresponding “lists” table. These tables allow entities to join lists that can then be queried against.
