AEM 6.4 has reached the end of extended support and this documentation is no longer updated. For further details, see our technical support periods. Find the supported versions here.
AEM configurations serve to manage settings in AEM and serve as workspaces.
A configuration can be considered from two different viewpoints.
In summary: from an administrator’s point of view, configurations are how you create workspaces to manage settings in AEM, whereas the developer should understand how AEM uses and manages these configurations within the repository.
Regardless from your perspective, configurations serve two main purposes in AEM:
The AEM administrator as well as authors can consider configurations as workspaces. These workspaces can be used to gather groups of settings together as well as their associated content for organizational purposes by implementing access rights for those features.
Configurations can be created for many different features within AEM.
For example an administrator may create two configurations for Editable Templates.
The admin can then create general page templates using the WKND-General configuration and then templates specific to the magazine under WKND-Magazine.
The admin can then associate the WKND-General with all content of the WKND site. However the WKND-Magazine configuration would be associated only with the magazine site.
By doing this:
Similar setups are possible not only for Editable Templates but also for Cloud Configurations, ContextHub Segments, and Content Fragment Models.
The Configuration Browser allows an administrator to easily create, manage, and configure access rights to configurations in AEM.
It is only possible to create configurations using the Configuration Browser if your user has admin
rights. admin
rights are also required in order to assign access rights to the configuration or otherwise modify a configuration.
It is very simple to create a new configuration in AEM by using the Configuration Browser.
Log into AEM as a Cloud Service and from the main menu select Tools -> General -> Configuration Browser.
Tap or click Create.
Provide a Title and a Name for your configuration.
Check the type of configurations you wish to allow.
Tap or click Create.
Configurations may be nested.
If you think of configurations as workspaces, access rights can be set on those configurations in order to enforce who may and may not access those workspaces.
It is not possible to unselect a feature once the configuration has been created.
As a developer, it is important to know how AEM as a Cloud Service works with configurations and how it processes configuration resolution.
Although the administrator and users may think of configurations as workplaces to manage different settings and content, it is important to understand that configurations and content are stored and managed separately by AEM in the repository.
/content
is home to all content./conf
is home to all configuration.Content references its associated configuration via a cq:conf
property. AEM performs a lookup based on the content and it’s contextual cq:conf
property to find the appropriate configuration.
For this example, let’s assume you have some application code that is interested in DAM settings.
Conf conf = resource.adaptTo(Conf.class);
ValueMap imageServerSettings = conf.getItem("dam/imageserver");
String bgkcolor = imageServerSettings.get("bgkcolor", "FFFFFF");
The starting point of all configuration lookup is a content resource, usually somewhere under /content
. This could be a page, a component inside a page, an asset, or DAM folder. This is the actual content for which we are looking for the right configuration that applies in this context.
Now with the Conf
object in hand, we can retrieve the specific configuration item we are interested in. In this case it is dam/imageserver
, which is a collection of settings related to the imageserver
. The getItem
call returns a ValueMap
. We then read a bgkcolor
string property and provide a default value of “FFFFFF” in case the property (or entire config item) is not present.
Now let’s have a look at the corresponding JCR content:
/content/dam/wknd
+ jcr:content
- cq:conf = "/conf/wknd"
+ image.png [dam:Asset]
/conf/wkns
+ settings
+ dam
+ imageserver [cq:Page]
+ jcr:content
- bgkcolor = "FF0000"
In this example, we assume a WKND specific DAM folder here and a corresponding configuration. Starting at that folder /content/dam/wknd
, we’ll see that there is a string property named cq:conf
that references the configuration that should apply for the subtree. The property will usually be set on the jcr:content
of an asset folder or page. These conf
links are explicit, so it is easy to follow them by just looking at the content in CRXDE.
Jumping inside /conf
, we follow the reference and see there is a /conf/wknd
node. This is a configuration. Please note that its lookup is completely transparent to the application code. The example code never has a dedicated reference to it, it’s hidden behind the Conf
object. Which configuration applies is completely controlled through the JCR content.
We see the configuration contains a fixed-named settings
node that contains the actual items, including the dam/imageserver
we need in our case. Such an item can be thought of as a “settings document” and is usually represented by a cq:Page
including a jcr:content
holding the actual content.
Finally, we see the property bgkcolor
that our sample code needs. The ValueMap
we get back from getItem
is based on the page’s jcr:content
node.
The basic example above showed a single configuration. But there are many cases where you want to have different configurations such as a default global configuration, a different one for each brand and maybe a specific one for your sub projects.
To support this the configuration lookup in AEM has inheritance and fallback mechanism in the following order of preference:
/conf/<siteconfig>/<parentconfig>/<myconfig>
cq:conf
somewhere in /content
/conf/<siteconfig>/<parentconfig>
/conf/<siteconfig>
/conf/global
admin
role/apps
/libs
Configurations in AEM are based on Sling Context-Aware Configurations. The Sling bundles provide a service API that can be used to get context-aware configurations. Context-aware configurations are configurations that are related to a content resource or a resource tree as was described in the previous example.
For further details about Context-Aware Configurations, examples, and how to use them, see the Sling documentation.
For debugging and testing purposes, there is a ConfMgr web console at https://<host>:<port>/system/console/conf
, which can show configurations for a given path/item.
Simply provide:
Click Resolve to see which configurations are resolved and receive sample code which will resolve those configurations.
For debugging and testing purposes, there is a Context-Aware Configuration web console at https://<host>:<port>/system/console/slingcaconfig
, which allows querying context-aware configurations in the repository and viewing their properties.
Simply provide:
Click Resolve to retrieve the associated context paths and properties for the selected configuration.