Minion
Commerce

Working with Minions – An Introduction

In this article, we are going to look into what Minions are in Sitecore Commerce and how you can utilise Minions to customise your implementation. Hands-on implementation of a minion will follow in the next article.

What are Minions

As the name suggests, Minions are the workers performing background tasks. In short, they are asynchronous task runners to perform repetitive tasks.

Why Minions are used

Minions can perform various tasks related to :

  1. Orders (watching a specific component in an order and process it differently), managing sales activities etc
  2. Indexing Commerce Data
  3. And managing your commerce environment like purging carts

Minions works on a list, they can

  1. Watch the list
  2. Action on an entity in the list
  3. Move items from one list to another

‘PurgeCartsMinion’ is an example of OOB Minion that watches ‘Carts’ List and purges the carts after every 24 hours as per the cart policy “Sitecore.Commerce.Plugin.Carts.PurgeCartsPolicy”. (see – Plugin Specific Policies)

How to Configure a MinionPolicies

Minions are defined in the Minion environment of Sitecore Commerce installation. Assuming that you have already created a minion, you can configure the same in environment-specific policy file Plugin.Minion.PolicySet-1.0.0.json. Here you must specify:

  • How Frequently a Minion should run – WakeupInterval
  • List from which the Minion picks items to process – ListToWatch
  • Fully Qualified Minion Name – Type and concrete implementation
  • Number of items the Minion is going to fetch at once – Items per Batch
  • How long the minion should Sleep before the next execution – SleepBetweenBatches
  • In Commerce 9.2, you can specify the list of entities – In case those entities are processed by other Minions, the current minion will not execute.

Plugin Specific Policies

Minion is a plugin, one can govern the behaviour of a minion via plugin policies defined in PlugIn.<EnvironmentName>.CommerceMinions-1.0.0.json, here you can define the policy for the minion plugin. This is different from the minion policy – former governs the execution parameters of the minion like when it should run, what data it should process etc., while minion specific policies pass the parameters to the minion, on which you can base your code logic. Hence, the behaviour of a minion can be controlled and execution can change without the need for deployment.

Example of a Policy Set
Including Policy set into the configurations

Boss Minion

In Sitecore Commerce, you can create a Boss Minion to act like a ‘Boss’ to its delegates (Children). Boss minion will have the main list (Parent List) to be processed, with every child working on a separate list which will have items from the Parent list.
This allows Boss to split the Parent list processing among multiple child minions, hence improving the performance.

Boss minion and every child minion can be configured using the same policies as specified in the section above.

Example of a Boss Minion

A case for extension

Let’s suppose you are providing customisation services on the products you sell on your website. Whenever a user selects a customisation option on the front end, you will write a plugin to read the customisation component from Order entity.

You can create a custom minion to watch the list and process the incoming Orders to look to the newly added Customisation Component. Once you find it, you can send this order to a third-party customisation service or allocate such order to your customisation department.

Another Minion can be created to watch the return list, once the item is returned from the customisation provider, it can be released to next OOB state so that OOB minions can take over the processing.

We will use the above example to demonstrate this hands-on in the next article in this series

Assure your implementation and book a 30 mins consultation with one of our experts.

.

Did you find this useful? If so, please share with your connections.

Leave a Reply

Your email address will not be published. Required fields are marked *