Sitecore Commerce is built against Microsoft. NetCore and its service-oriented architecture allow you the flexibility to host services across several roles, each serves different aspect of the overall Commerce platform.
The service roles allow flexible service hosting, with each role having different deployment configurations and management policies. Let’s look at different roles Sitecore Commerce offers and how you can use roles effect to provide scalable solution and infrastructure for your clients.
Before we begin – let me call out, roles provide the logical separation of the code and most of the times same code is deployed on all the roles but the behaviour of each of the role can be independently controlled using policies. More about that later.
When you install Sitecore Commerce following 4 roles are created in IIS, let have a look at each one of them
This role is not accessible to the outside world and is only available to the DevOps team or the people with privilege access. This role is used for housekeeping activities like environment bootstrap, environment management, manual cache management, managing OOTB minions (search, orders, etc) and policies etc.
You can look at all the operations provided by Sitecore in the postman scripts comes with the installation package. If you are a developer, you can use this role to look at currently running pipelines to find where a new plugin you are creating needs to be injected.
- Never expose this role publicly including the functionality to bootstrap or policy management. Host this role on the separate server.
- Use this role to get the currently running pipelines to determine where to inject your custom code.
- Manage one or more environments
- Manage policies and policy sets
- Manage global artifacts
Extensively used role of the platform which handles traffic from storefronts (CD).
As I mentioned earlier – the behaviour of the roles can be managed by the policies, one example of this is the caching policy. Since this role serves the front-end websites, it is heavily cached.
While designing your physical infrastructure, you can benefit from having multiple instances of this role to cater to your traffic.
- Serves the front-end websites
- Heavily cached.
- Make use of vertical and horizontal scaling to cater to changes in website traffic.
- Shopping cart services
- Order Services etc.
In simple terms, this role is used to provide all the functionalities offered by business tools.
Merchandisers use this to manage products, commerce marketers use to manage promotions, and CSR uses it to manage customers and orders.
Due to the real-time nature of this role consider having no or little caching on this role.
This one is my favourite – works behind the scenes without bothering anyone 😊. This role is an asynchronous task runner to run schedule jobs like processing orders, perform clean-ups, index management etc.
Consider extending this role to provide similar services. An example of this is – If you have an order which has customisation entity associated with it. You can extend pending order minion to add a new bock to read this entity and send these orders to customisation services. Similarly, you can use minion roles to provide subscription management services.
- Runs asynchronously, independently, behind the scene
- Used for repetitive tasks
- Like Order Processing
- Post order management
- External integrations
- Subscription management
- Clean-up, indexing etc.
That is it. I hope this post gave you a high-level overview of different Commerce roles. If you have any questions you can reach out to me at email@example.com