Run Modes precedence in Cloud AEM

[sean12341]

Hello, 

I am trying to understand the Run Modes precedence in Cloud AEM.

I read the Adobe doc here, which provides a list of run modes like below:

config (The default, applies to all AEM services)
config.author (Applies to all AEM Author service)
config.author.dev (Applies to AEM Dev Author service)
config.author.rde (Applies to AEM RDE Author service)
config.author.stage (Applies to AEM Staging Author service)
config.author.prod (Applies to AEM Production Author service)
config.publish (Applies to AEM Publish service)
config.publish.dev (Applies to AEM Dev Publish service)
config.publish.rde (Applies to AEM RDE Publish service)
config.publish.stage (Applies to AEM Staging Publish service)
config.publish.prod (Applies to AEM Production Publish service)
config.dev (Applies to AEM Dev services)
config.rde (Applies to RDE services)
config.stage (Applies to AEM Staging services)
config.prod (Applies to AEM Production services)

I understand that the more specific ones(eg. "config.author.dev") takes precedence over the lower ones(eg. "config.dev").

But what about between "config.author" and "config.dev", which one has more specificity? As you already know, I can be on the Author mode of a Dev environment, which satisfies both, so which one takes precedence here?

Thank you,

[arunpatidar · Accepted solution]

Hi @sean12341 
If you are targeting configs for :

Author : config.author

Publish : config.publish

Dev(Author): config.author.dev

Dev(Publish): config.publish.dev

Dev(Author & Publish): config.dev

You don't need to create more than one config for same runmode.

Order of Precedence:

• Configuration settings are applied based on an order of precedence. The settings in the /apps directory take precedence over /libs settings.
• Run mode-specific settings take precedence over common settings.
• If there are multiple configurations under the same run mode, the order of the paths in the repository matters.
• Configurations at deeper paths in the repository structure take precedence.

[_CL]

@arunpatidar- I have a system configuration defined for each run mode in cloud - config.author.rde, config.author.dev, config.author.stage and config.author.prod

There are about 25+ set of configurations defined out of which only 5 differ based on runmode.

In this case is it better to put the base configuration of 20 in config.author and only put the delta difference of 5 configurations in each runmode based on environment?

[arunpatidar]

Hi @_CL 
Yes, if the configs are common/same for all the runmodes then you can use config(Author and Publish) or config.author(Author Only) or config.publish(Author Only) folders.

Others can go to dedicated runmode folders or use env variables.

[_CL]

Thanks for the prompt response -

Ideally I am trying to categorize all OSGi configurations under config.author and config.publish then put only exclusive properties for a config on respective rde, dev, stage and prod.

However, my architect mentioned the below which I really didn't understand, any pointers on the below?

Adobe suggests that, based on incoming env_id, we need to create OSGI runmode try like item_{env_id} and output the value for specific env_id.
I would recommend when pass env_id = default, the run mode value will be “item“ versus “item_default” incase there is no env_id passed in.

[arunpatidar]

Hi @_CL 
What I understood from above statement is that you put all the values in the same OSGI

Example /config/com.myapp.service.MyService.cfg.json

item_{env_id} = 'val1' // applicable only for a env

item_dev = 'val2'.  // applicable only for a dev

item_qa = 'val3'

item_stage = 'val4'

item = 'val5' // applicable for all the env

This is not a good solution is compared to other, you could use env directly
item = ${env.VARIABLE_NAME}

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/dep... 

[_CL]

Hey @arunpatidar, thanks for the clarification - But how would this approach work?

I mean how would item_dev = 'val2' map only to dev?

It there any setting for it?

For folders the name have a convention and meaning - but for individual config values will simply adding "_envID" work?

[arunpatidar]

Hi @_CL 
I have no idea why your architect is suggested this approach but it would be more like pattern matching. 

[_CL]

Hey @arunpatidar, 1 reason I can think of that my dev3 and dev4 instances have like 100s of configurations with each configuration containing multiple unique values for each instance. If I convert them all to environment variables then the number would be huge. This can make it difficult to keep track of them considering its outside the scope of version control tracking.

[arunpatidar]

Hi @_CL 
You can create a environment variable which will tell you the environment e.g.

 ${env.RUNMODE}

Please check if this helps : 

https://blog.developer.adobe.com/custom-runmodes-on-aem-as-a-cloud-service-79b757f51a6b 

another thing you can do is copy configurations from dev1 or dev4 to dev during build based on environment , so that configuration are always based on OOTB runmode but in your codebase you can manage custom runmode.

https://medium.com/@arunpatidar26/secrets-manager-aem-configs-1c2a23124f7a 

[vikramca06]

config.author or config.publish - gives you the ability to manage common configurations for all the authors and publishers

similarly, you can use environment specific configs to have common configs for the env like dev, stage and prod.

finally, instance specific configurations can be added to config.author.{env} or config.publish.{env}

its not required to keep the same config in all the combinations of run modes. just place it where needed and reduce the duplication.

Regards,

Vikram.