Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Run Modes precedence in Cloud AEM

Avatar

Level 3

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,

 

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

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.


Arun Patidar

View solution in original post

10 Replies

Avatar

Correct answer by
Community Advisor

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.


Arun Patidar

Avatar

Level 4

@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?

 

Avatar

Community Advisor

Hi @Cross_Leaf 
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.



Arun Patidar

Avatar

Level 4

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.

Avatar

Community Advisor

Hi @Cross_Leaf 
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... 



Arun Patidar

Avatar

Level 4

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?

Avatar

Community Advisor

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



Arun Patidar

Avatar

Level 4

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.

Avatar

Community Advisor

Hi @Cross_Leaf 
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 



Arun Patidar

Avatar

Level 4

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.