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,
Solved! Go to Solution.
Views
Replies
Total Likes
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:
/apps
directory take precedence over /libs
settings.
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:
/apps
directory take precedence over /libs
settings.
@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?
Views
Replies
Total Likes
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.
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.
Views
Replies
Total Likes
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}
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?
Views
Replies
Total Likes
Hi @Cross_Leaf
I have no idea why your architect is suggested this approach but it would be more like pattern matching.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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.
Views
Likes
Replies
Views
Likes
Replies