Commerce 9 Environments - do we need one of Auth, Ops, Minions and Shops per Environment

Question

I do not think this is required, but I am not certain. After installing Commerce 9 with the Habitat and Adventure Works catalogs, it creates four rest environments: Auth, Ops, Minions and Shops. Each environment only differs by the wwwroot\config.json field Environment. Respectively for me they are: HabitatAuthoring, HabitatMinions, AdventureWorksOpsApi, HabitatShops.

The OpsApi did not seem to be working. I do not find an environment in SQL in the CommerceEntities table for an AdventureWorksOpsApi or HabitatOpsApi. I changed the Ops environment to use the HabitatMinions environment and it seems to be working.

Everything seems to be working, so I do not think this is required; but it almost seems to me that there should be four sites per environment. Should every environment have its own set of Auth, Ops, Minions and Shops supporting sites?

And should there be OpsApi environments in the CommerceEntities table?

Update to add to the above. It appears the install of the demo commerce environments uses the AdventureWorksOpsApi for the Ops host configuration even though it does not create a matching environment. The Ops host will not working until you either create one or your change the configuration to one of the others. I chose to change to one of the HabitatAuthoring for now.

From the posts below, I now have a better understand of the role of each host and the purpose the environment in the configuration.

Answer 1

first of all maybe read this blog article of me

• https://hachweb.wordpress.com/2018/08/06/sitecore-xc-9-0-2-commerce-environments-behind-the-scenes/

There I described exactly that topic in detail. Maybe it already answers your question.

For short summary:

The local installation is a XP0 installation. That means everything runs on one single machine (CM / CD and respectively also the XC instances).

As I have pointed out in the article in such an environment only the Authoring and Minions "instances" are actively used by the installed sitecore instance. the rest is only for demonstration purpose.

In a production environment, where you have separated CM and CD instances you will also have separated XC instances. So e.g. near the CM instances you will have a XC instances with authoring role (environment). Near the CD instance you will have a XC instances with only shops role (environment). Apart of that you will have somewhere on also on the same machine than the other instaces some XC instance with minions role (environment).

In the end to answer your question:

Should every environment have its own set of Auth, Ops, Minions and Shops supporting sites?

-> This is not mandatory. It depends on your built up environment. In a standard production environment you will have these environments, like mentioned above and in the article But e.g. on a XP0 instance you will actively only find authoring role, which is used by Sitecore and for background tasks the minions role.

Best regards

Answer 2

Each role has a specific purpose and each role is required.

Authoring Role: This instance servers traffic from the commerce business tools. Since the traffic comes from the admin, the traffic is low.

Shops Role: This instance of the commerce engine serves traffic from all of your storefronts. You would scale this role based on how much traffic your front end sites get. The best way to look at it is in comparison to your xp installs.

Minions Role: This instance runs independently of the XP and supports asynchronous processing. This is a crucial instance to process orders, cleanup, process other lists. Move order statuses. If you process a large amount of orders, you might want to scale this instance to process them faster.

DevOps Role: This instance is internal and for devops purposes. Usually you give access to this role to admins etc to bootstrap, initialize and other environment functions.

According to the documentation all are required and all have a purpose. I know the only thing diff in all these instances is a piece of text in the json but if you look at it the other way, same code with a small config tweak is able to perform a different job.