Run Modes in AEM is a concept in AEM using which a developer can configure a purpose-specific AEM instance. AEM instance always serves a purpose be it
· AUTHOR which allows content authors to configure the content in AEM. (It provides editable environment)
· PUBLISH which displays the content configured and published by authors.
· DEV Environment which provides AEM developers an environment for development, usually various security settings are disabled, Loggers are excessively used, usernames and passwords are hardcoded and many more…
· QA Environment which provides Quality Analysts an environment for testing the developed application, usually security settings are at LOW levels, Loggers are densely used, Usernames and passwords are configurable and many more…
· UAT Environment which provides Clients an environment for User acceptance testing. Usually, security setting is at a MEDIUM level, loggers are gently used, Usernames and password are configurable and many more…
· PROD Environment which provides End Users actual web environment to access the application. Always security setting is at Stringent level, loggers are rarely used, Usernames and password are configurable and many more…
Since your custom applications are developed in a phased manner, the developer usually push the developed code in upper environments for Quality Analysis and User Acceptance Testing. So with new code pushes there may [not always] be the need to changes the configuration of the respective environments. Every environment will need a different configuration as explained above.
Disadvantages of using Felix Console for configurations in AEM
ConfigMgr in AEM provides us a console (also known as “Felix Console”) to change the configurations. ConfigMgr has its own advantages such as real-time changes in configurations and Ease of understanding. But some risks are also involved in changing configurations using Felix console.
· There can be a change in many configurations, which is a must in all instances in that environment. Changing the configurations manually can be error-prone.
· The developer usually doesn’t get access to upper environments like UAT and PROD.
· The client-side needs a person with an understanding of the AEM to change configurations manually.
· PROD may get down due to a slight mismatch in configurations, which will cost them a huge loss of revenue.
In such situations “RUN MODES” comes in handy.
Disadvantages of using Felix Console for configurations in AEM
ConfigMgr in AEM provides us a console (also known as “Felix Console”) to change the configurations. ConfigMgr has its own advantages such as real-time changes in configurations and Ease of understanding. But some risks are also involved in changing configurations using Felix console.
· There can be a change in many configurations, which is a must in all instances in that environment. Changing the configurations manually can be error-prone.
· The developer usually doesn’t get access to upper environments like UAT and PROD.
· The client-side needs a person with an understanding of the AEM to change configurations manually.
· PROD may get down due to a slight mismatch in configurations, which will cost them a huge loss of revenue.
In such situations “RUN MODES” comes in handy.
Advantages of Run Modes
· Runmodes allows configuring Environment specific parameters.
· Runmodes are easy to maintain.
· Reusable
· Developer can package all runmodes in one package and deploy it in all environments. Depending on the runmode/runmodes used in that environment, parameters will automatically be applied.
· As runmodes can be packaged and deployed separately than code package, the developer does not need to redeploy the code package when there is a change in configurations.
· Anyone (Without any particular knowledge of AEM) can handle, deploy, redeploy, uninstall the Runmode package. AEM Runmodes are broadly categorized into two types:
1. Installation Runmodes
2. Custom Runmodes
Installation Runmodes
· Runmodes allows configuring Environment specific parameters.
· Runmodes are easy to maintain.
· Reusable
· Developer can package all runmodes in one package and deploy it in all environments. Depending on the runmode/runmodes used in that environment, parameters will automatically be applied.
· As runmodes can be packaged and deployed separately than code package, the developer does not need to redeploy the code package when there is a change in configurations.
· Anyone (Without any particular knowledge of AEM) can handle, deploy, redeploy, uninstall the Runmode package. AEM Runmodes are broadly categorized into two types:
1. Installation Runmodes
2. Custom Runmodes
Installation Runmodes
Installation Runmodes are out of the box (OOTB) runmodes provided by AEM. Installation runmodes are also called fixed runmodes because they are used at the time of installation (Hence the name installation runmodes) and once used, they are fixed for the lifetime of that instance (Hence the name fixed).
AEM provides 4 installation runmodes.
1. author This runmode is used to set up an authoring environment.
2. publish This runmode is used to set up publishing environment.
3. samplecontent This run,=mode is used when the developer needs sample content
4. nosamplecontent This run mode is used when the developer do not need sample content, Production [PROD] Environment is usually a no sample content environment.
[Author, publish] and [samplecontent, nosamplecontent] are mutually exclusive environments.
Meaning,
· An instance cannot be started in publish and author runmode at a time.
· An instance cannot be started in samplecontent and nosamplecontent runmode at a time.
· You cannot combine author with both samplecontent and nosamplecontent at a time.
· You cannot combine publish with both samplecontent and nosamplecontent at a time.
· You cannot combine samplecontent with both authors and publish them at a time.
· You cannot combine nosamplecontent with both authors and publish them at a time.
Installation runmodes are lifetime runmodes. One instance is started in the installation runmode, it cannot be restarted in other installation runmode.
1. author This runmode is used to set up an authoring environment.
2. publish This runmode is used to set up publishing environment.
3. samplecontent This run,=mode is used when the developer needs sample content
4. nosamplecontent This run mode is used when the developer do not need sample content, Production [PROD] Environment is usually a no sample content environment.
[Author, publish] and [samplecontent, nosamplecontent] are mutually exclusive environments.
Meaning,
· An instance cannot be started in publish and author runmode at a time.
· An instance cannot be started in samplecontent and nosamplecontent runmode at a time.
· You cannot combine author with both samplecontent and nosamplecontent at a time.
· You cannot combine publish with both samplecontent and nosamplecontent at a time.
· You cannot combine samplecontent with both authors and publish them at a time.
· You cannot combine nosamplecontent with both authors and publish them at a time.
Installation runmodes are lifetime runmodes. One instance is started in the installation runmode, it cannot be restarted in other installation runmode.
Custom Runmodes
Custom runmodes are developer-defined runmodes. There are many occasions where developers define custom runmodes. Below is an example of this.
Suppose, you are pushing code from DEV to QA to UAT, the security settings for dev environment can be at low levels as we don’t usually handle actual database in DEV environment, but in environments like UAT where client tests the code with the actual database, the security settings need to be at stringent levels.
Custom runmodes are developer-defined runmodes. There are many occasions where developers define custom runmodes. Below is an example of this.
Suppose, you are pushing code from DEV to QA to UAT, the security settings for dev environment can be at low levels as we don’t usually handle actual database in DEV environment, but in environments like UAT where client tests the code with the actual database, the security settings need to be at stringent levels.
Here, the developer has to define custom runmodes to change the configuration parameters according to Environment. Custom runmodes names are defined by the developer. It can be anything. Dev, qa, uat, test…etc are generally used names.
A collection of values for configuration properties, used for a particular run mode, can be saved in the repository.
A collection of values for configuration properties, used for a particular run mode, can be saved in the repository.
The run mode is indicated by a suffix on the folder name. This allows you to store all configurations in one repository. For example:
· Config Applicable for all run modes
· config.author Used for author run mode
· config.publish Used for publish run mode
· config.author.dev Used for author and dev runmode
· config.publish.dev Used for publish and dev runmode
· config.author.prod Used for author and prod runmode
· config.publish.prod Used for publish and prod runmode
How to create run modes?
The run modes are very easy to create, below are some steps to create run modes.
Consider that you are configuring a PROD instance. On production instance [PROD], we must enable the minification of the CSS and js files using the YUI compressor to reduce the load time. Even GZIP compression of js and CSS files is a must on PROD.
Let us see how it can be achieved using Run Modes. Below are steps are given,
1. In CRXDE, go to you Project /apps/<your project>
2. Create a folder with any name, I am using “Config”
3. Under “Config”, create a node having the name “config.author.prod” and of type “sling:folder”
4. Under config.author.prod create a node of type sling:OsgiConfig and having a name same as PID [Persistent ID] of the intended configuration Felix Console.
· As we are enabling minification and GZIP compression, we must target Adobe Granite HTML Library Manager, navigate to Felix Console, search for Adobe granite HTML Library Manager
· Config Applicable for all run modes
· config.author Used for author run mode
· config.publish Used for publish run mode
· config.author.dev Used for author and dev runmode
· config.publish.dev Used for publish and dev runmode
· config.author.prod Used for author and prod runmode
· config.publish.prod Used for publish and prod runmode
How to create run modes?
The run modes are very easy to create, below are some steps to create run modes.
Consider that you are configuring a PROD instance. On production instance [PROD], we must enable the minification of the CSS and js files using the YUI compressor to reduce the load time. Even GZIP compression of js and CSS files is a must on PROD.
Let us see how it can be achieved using Run Modes. Below are steps are given,
1. In CRXDE, go to you Project /apps/<your project>
2. Create a folder with any name, I am using “Config”
3. Under “Config”, create a node having the name “config.author.prod” and of type “sling:folder”
4. Under config.author.prod create a node of type sling:OsgiConfig and having a name same as PID [Persistent ID] of the intended configuration Felix Console.
· As we are enabling minification and GZIP compression, we must target Adobe Granite HTML Library Manager, navigate to Felix Console, search for Adobe granite HTML Library Manager
Picking property names
Picking PID of the configuration
· Now add a property htmllibmanager.minify to the node and set value to true.
· Follow the same process for htmllibmanager.gzip property.
· Now add a property htmllibmanager.minify to the node and set value to true.
· Follow the same process for htmllibmanager.gzip property.
Adding Nodes in CRX and adding properties to the nodes
5. Restart AEM instance using Command prompt “java -XX:MaxPermSize=256m -Xmx1024M -jar AEM-author-4502.jar -Dsling.run.modes=author,prod”
6. Go to Felix console configuration, open Adobe Granite HTML Library Manager and confirm the changes.
5. Restart AEM instance using Command prompt “java -XX:MaxPermSize=256m -Xmx1024M -jar AEM-author-4502.jar -Dsling.run.modes=author,prod”
6. Go to Felix console configuration, open Adobe Granite HTML Library Manager and confirm the changes.
Confirming the changes in properties in a configuration.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.