AEM as Cloud Service Dispatcher, CDN & Caching
This article gives you insight about how dispatcher is maintained & configured, how content delivery network (CDN) is setup & finally how caching mechanism works.
In AEM as Cloud Service, A separate module is used for dispatcher configurations which will be part of maven project itself unlike in On-Premises where they were maintained separately.
Dispatcher Tools are part of AEM as a Cloud Service SDK which can be downloaded from adobe “Software Distribution” portal. They provide
· A vanilla structure (basic skeleton) containing the configuration files to include in a maven project for Dispatcher.
· Tooling to validate dispatcher configurations for AEM as Cloud Service supported directives (A list of Whitelisted Directives in Cloud Service).
· A Docker Image that brings up the Dispatcher locally.
Validation & Debugging
There are two ways of debugging dispatcher configurations.
· Types of Debugging Modes
1. Flexible Mode
a. It is recommended mode, as there is no limitation on the file structure under rewrite folder (In Legacy Mode, A single rewrite.rule file was required) & number of rules can be added.
b. This mode can be activated by creating a folder & file under /src directory of dispatcher module.
2. Legacy Mode
a. Legacy Mode was initially introduced when Cloud Service released and has a defined structure with limitations as mentioned above.
· Supported Apache Modules
The table in this article shows list of supported apache modules in AEM as CS.
The basic structure of dispatcher module consists of two main directories.
1. conf.d – This directory contains all the files related to Apache Configurations.
2. conf.dispatcher.d – This directory contains all the dispatcher related files.
The basic structure would look like as below.
To perform local validation of dispatcher configurations “Dispatcher Validator Tool” & “Docker Setup” is required. It has three phases & all the three below phases can be executed at once using the command: validate.sh dispatcher/src
1. It runs the validator. If the configuration isn’t valid, it fails. It can be run separately using below command
$bin\validator full -relaxed dispatcher/src
2. It executes the below command to test if syntax is correct by starting Docker in an Image so that apache httpd can start. If successful, the configurations are ready for deployment. It can be run separately using below command.
bin/docker_run.sh src/dispatcher host.internal.docker:4503 8080
3. Checks the subset of the dispatcher config files, which are intended to be immutable. It can be run separately using below command.
Content Delivery Network (CDN)
AEM as Cloud Service comes with built-in CDN called Fastly which is always included & it can’t be removed. Its advantages are listed as below.
· Reduce latency for cached content delivery
· Fully Manage & configured for optimal performance of AEM applications.
AEM Managed CDN
Managing SSL Certificates
· Customers can install SSL certificates via Cloud Manager UI.
· Cloud Manager does not provide SSL Certificates or private keys. These needs to be obtained from third party certificates.
· AEM as Cloud Service only supports https sites.
· AEM as Cloud Service only accepts OV (Organization Validation) or EV (Extended Validation) certificates. It does not accept DV (Domain Validation) certificates. Also, any certificate must be a X.509 TLS certificate from a trusted certification authority (CA) with a matching 2048-bit RSA private key.
· AEM as Cloud Service will accept wildcard SSL certificates for a domain.
· Cloud Manger will allow a maximum of 20 SSL certificates that can be associated with one or more environments across program.
IP Allowed Lists
· AEM as Cloud Service is opened to the internet & security is handled through user authentication & authorization.
· IP Allow Listing is a feature in Cloud Manager UI used for limiting & controlling access only to trusted users.
Custom Domain Names
· Cloud Manager UI allows to add a custom domain to identify site with a unique name in a self-service manner.
· AEM as Cloud Service is provisioned by default ending in *.adobeaemcloud.com.
Customer Managed CDN
· If customer prefers to use their own CDN, that is possible as they need to point their CDN to AEM Managed CDN.
· Customer need to manage all the activities related to CDN as adobe will only provide support when required.
· Go through Configuration Instruction for pointing Customer CDN to AEM CDN.
Files & Documents
By default, cached by the browser for five minutes, based on cache-control layer emitted by the apache layer. The CDN also respects this value. This behavior can be disabled by setting “Define DISABLE_DEFAULT_CACHING”.
Client-Side Libraries (CSS & JS)
By default, AEM’s Client-Side Library Framework, JS & CSS are generated in such a way that browser can cache it indefinitely. In other words, Client Library Versioning is strictly enabled by default which generates a long-term hash key as a selector to the client library.
<link rel="stylesheet" href="/etc.clientlibs/<project>/clientlibs/clientlib-base.lc-7c8c5d228445ff48ab49a8e3c865c562-lc.css" type="text/css">
To enable in local,
1. Navigate to the OSGi Configuration manager <host>/system/console/configMgr
2. Find the OSGi Config for Adobe Granite HTML Library Manager:
o Check the checkbox to enable Strict Versioning
o In the field labeled Long term client-side cache key, enter the value of /.*;hash
3. Save the changes.
By default, Images are not cached & can be set for caching by following the apache mod_headers directives.
Dispatcher Cache Invalidation
Default Cache Invalidation
· Invalidating cache is not necessary & can be relied on dispatcher refreshing its content when content is being republished & the CDN respecting cache expiration headers.
· Activation/Deactivation of pages will clear the content from the dispatcher cache. When publish instance receives a new version of a page or asset from an author, it uses flush agents to invalidate appropriate path of its dispatcher using timestamp stat file.
Explicit Cache Invalidation
· Prior to AEM as Cloud Service, invoking replication agents are used to directly call the invalidate.cache API to explicitly flush the cache. This approach will no longer be supported.
· Instead, the replication flush agents should be used by using Replication API. Refer the documentation Explicit Cache Invalidation for more information.
Content Delivery Network