Background: Redirect Map Manager vs. Redirect Manager in AEMaaCS

Previously, ACS Commons Redirect Map Manager was unsupported on AEMaaCS, limiting options for handling redirects. As a workaround, customers needed to use ACS Commons Redirect Manager, which came with several challenges:

• Reliance on Dispatcher Rules: Redirect Manager required that all redirect requests pass through the Dispatcher’s rules to reach the AEM publishers, where Redirect Manager rules could then be executed. This dependency on Dispatcher configurations often led to complications. Only requests meeting specific Dispatcher criteria reached the publisher, and requests blocked by earlier Dispatcher rules (e.g., rules for file types or specific paths) would bypass the publisher entirely, causing some redirects to fail.
• Potential for Conflicting Rules: Dispatcher has its own rewrite rules, which can sometimes interfere with redirects set in Redirect Manager. If a Dispatcher rewrite rule processes a request before it reaches Redirect Manager, it can override the redirect, leading to unexpected behaviors or even redirect loops. This makes troubleshooting and coordinating rules more challenging.
• Increased Maintenance and Complexity: Coordinating Dispatcher rules with Redirect Manager required ongoing adjustments to ensure consistency across both levels. This setup added maintenance overhead, as new rules or configurations in the Dispatcher required verification to avoid interfering with existing redirects.

With AEM version 18311 and the support for ACS Commons Redirect Map Manager, these limitations are greatly reduced. Redirect Map Manager now allows redirect processing to be handled entirely at the edge by the Dispatcher, minimizing reliance on AEM publishers and aligning with Adobe’s best practices for cloud environments.

Key Benefits of the New Setup

1. Offloading Redirects to the Dispatcher

With ACS Commons Redirect Map Manager, redirect processing is managed at the Dispatcher level, reducing the need for requests to be handled by publishers. This shift improves performance and scalability:

• Previous Configuration with Redirect Manager: The first request for a redirect had to be processed by the AEM publisher, placing load on the AEM instance until CDN caching took effect. For high-traffic sites, this dependency on the publisher created potential performance bottlenecks.
• New Configuration with Redirect Map Manager: Redirects are processed directly by the Dispatcher, with CDN caching supporting subsequent requests. This reduces publisher load and improves response times, allowing for smoother handling of large-scale redirects.

2. Simplified Management with Fewer Conflicts

Redirect Map Manager reduces the likelihood of conflicts with Apache’s Dispatcher rewrite rules:

• Better Coordination with Dispatcher Rules: With redirect processing fully managed at the Dispatcher, Redirect Map Manager rules are less likely to conflict with existing rewrite rules, eliminating the need to pass through complex Dispatcher configurations to reach the publisher.
• Reduced Complexity: Redirect Map Manager’s edge-based handling simplifies redirect rule management, enabling more consistent behavior and reducing the need for Dispatcher-publisher coordination.

3. Greater Flexibility for Business Users

This update provides a more accessible and flexible redirection setup for business users who need to control redirects but may lack access to development pipelines:

• User-Friendly Management Interface: ACS Commons Redirect Map Manager offers an intuitive interface within AEM for managing redirects. Business users can easily create, edit, and organize large numbers of redirects without requiring deployments or extensive pipeline configurations.
• Scalability for Large-Scale Operations: Redirect Map Manager supports thousands of redirects directly within AEM, making it ideal for business-driven redirect management at scale.

How to Configure Pipeline-Free URL Redirects with Redirect Map Manager

Setting up pipeline-free redirects with the ACS Commons Redirect Map Manager in AEMaaCS is straightforward:

1. Define Redirect Maps: In the managed-rewrite-maps.yaml file, specify paths to redirect files stored in the publish repository.
2. Manage Redirects in Redirect Map Manager: Use the Redirect Map Manager’s user interface to set up and organize redirect mappings. The tool’s UI allows direct integration with Dispatcher for a streamlined process.
3. Configure Apache RewriteMap:
   • Set up the RewriteMap directive in Apache to ensure optimal redirect caching and performance at the Dispatcher level. Here’s a sample configuration:

   1 2 3

   RewriteMap map.foo dbm=sdbm:/tmp/rewrites/my.map RewriteCond ${map.foo:$1} !"" RewriteRule ^(.*)$ ${map.foo:$1|/} [L,R=301]

For a deeper dive into this feature, visit Adobe’s full article: Pipeline-Free URL Redirects.

Visit the official ACS Commons Redirect Map Manager Page.

Conclusion

The introduction of ACS Commons Redirect Map Manager support in AEMaaCS marks a significant improvement in URL redirection management. By handling redirects at the Dispatcher, this feature enhances performance, reduces complexity, and minimizes publisher load, all while aligning with Adobe’s best practices for AEM Cloud environments.

With these changes, managing large-scale redirects in AEMaaCS becomes more efficient, flexible, and scalable, making it easier for teams to maintain high performance and consistency across their AEM implementations.

The post Pipeline-Free URL Redirects & ACS Commons Redirect Map Manager Now Supported on AEMaaCS appeared first on Sourced Code.

1. Rolling Deployment Process in AEMaaCS

During a production deployment, AEMaaCS follows a rolling deployment strategy to minimize downtime and ensure continuous availability. Here’s how it works:

1. Deploy AEM Packages to Author:
   • The deployment begins by pushing the updated AEM packages to the author instance. This ensures that the author environment is updated first, preparing it for any content authoring that might be needed post-deployment.
2. Detach Dispatcher1 from the Load Balancer:
   • The first Dispatcher (dispatcher1) is temporarily removed from the load balancer. This prevents it from serving any requests during the deployment, ensuring that users do not access potentially outdated or unstable content.
3. Deploy AEM Packages to Publish1 and Dispatcher1:
   • With dispatcher1 detached, the deployment of AEM packages to the first publish instance (publish1) and the corresponding Dispatcher package to dispatcher1 occurs simultaneously.
   • After the deployment, the Dispatcher cache is flushed. This step is critical as it clears the old cache, ensuring that the updated content is served once the Dispatcher is brought back online.
4. Reattach Dispatcher1 to the Load Balancer:
   • Once the deployment to publish1 and the cache flush on dispatcher1 are complete, dispatcher1 is added back to the load balancer. It can now serve requests with the updated content and configurations.
5. Repeat for Dispatcher2:
   • The process is repeated for the second Dispatcher (dispatcher2). Dispatcher2 is detached from the load balancer, the deployment is made to publish2 and dispatcher2, the cache is flushed, and then dispatcher2 is reattached to the load balancer.
6. Continue for All Instances:
   • This rolling deployment process continues until all publish and Dispatcher instances in the topology have been updated. By updating one Dispatcher at a time, AEMaaCS ensures that there is always at least one Dispatcher available to serve requests, thus maintaining high availability throughout the deployment.

2. Why Is This Process Important?

Flushing the Dispatcher cache after code deployment is essential for ensuring that users receive the latest content and that no outdated files are served. The rolling deployment strategy employed by AEMaaCS automates this process, making it seamless and reducing the risk of downtime or content inconsistencies.

3. Additional Considerations

While AEMaaCS automates much of the deployment and cache flushing process, it’s important to ensure that your Dispatcher configurations are optimized for this process. Properly configured .stat files and cache invalidation rules help to ensure that the cache is only flushed when necessary, preserving performance while ensuring content freshness.

For more detailed information on the rolling deployment process and how AEMaaCS handles cache invalidation, refer to the official Adobe Experience Manager documentation .

This step-by-step approach ensures a smooth transition during code deployments, keeping your AEM environment optimized and responsive.

The post How to Clear & Flush AEMaaCS Cache After Code Deployment appeared first on Sourced Code.

Ensuring that users receive the latest updates—such as new client libraries (CSS and JS)—requires a carefully managed caching strategy. This article explores how cache invalidation is handled upon releasing new code, particularly clientlibs, and uses the Adobe WKND project as an example to explain the process.

1. Introduction

In this article, we will step through how typically an AEMaaCS website serves newly released client-libraries JS and CSS to users, and we will take a look at the Adobe WKND project as an example.

2. Automatic Cache Invalidation: How It Works

Upon releasing new client libraries, AEMaaCS uses versioned clientlibs. This involves adding a unique hash (previous understanding of the hash generated is pretty much converting the entire minified CSS and JS into MD5 Hash – ACS Commons Approach) to the filenames of clientlibs, served on newly fresh requested HTML pages from the AEM publishers, which forces the CDN and browser caches to recognize and fetch the new files. This automatic mechanism helps ensure that users are served the updated versions.

And please keep in mind, it’s the fresh uncached version of the AEM .html pages who actually serves the path of the versioned clientlibs files. Lets understand .html are cached invalidated from the dispatcher and CDN cache.

Examples of hashed client libs:
/etc.clientlibs/settings/wcm/designs/gandalf/clientlibs/css/all.en-us.min.LIHASHed376af2042959edf283b2591e37eff9.css

3. Example Configuration: Adobe WKND Project

In this article, we will purely inspect the Adobe WKND project which is production live code examples of recommended rules for cache invalidating .html files. The following configuration from the WKND project shows how HTML pages are handled in terms of caching:

4. Breakdown of the Configuration

1. LocationMatch, Targeting HTML Pages:

– The configuration applies to all HTML pages under the /content/ path.

2. Cache-Control Settings:

• max-age=300: HTML pages are cached for 5 minutes. During this time, the CDN serves the cached content without checking with the origin server.
• stale-while-revalidate=3600: After 5 minutes, if a request is made, the CDN serves the stale content and fetches a new version from the server in the background. This background fetch happens within 1 hour, ensuring minimal disruption.

3. Surrogate-Control for CDN:

• stale-while-revalidate=43200: The CDN can continue serving stale content while fetching fresh content for up to 12 hours.
• stale-if-error=43200: In the event of errors fetching the new content, the CDN serves stale content for up to 12 hours.

4. Age Header:

– Header set Age 0: This resets the age of the content to zero, indicating that it is freshly cached.

5. Key Mechanisms and Timings

Initial Cache Period (max-age=300):

– For the first 300 seconds (5 minutes) after the content is cached, the CDN serves the cached version without rechecking with the origin server.

Stale-While-Revalidate (stale-while-revalidate=3600):

– After 5 minutes, the max-age period expires, if a user requests the content, the CDN serves the stale (cached) content immediately and fetches a new version from the origin server in the background. This mechanism ensures that users receive immediate responses, even if the content is slightly outdated, while the cache is refreshed in the background. And again, it’s the fresh uncached version of the AEM .html pages who actually serves the path of the versioned clientlibs files, which is why invalidation on the HTML file is important here.

After Stale-While-Revalidate:

– If a new version has not been successfully fetched within the stale-while-revalidate window (up to 1 hour), and another request is made, the CDN serves the most recently cached version while attempting to fetch the new version again.

6. Conclusion

The correct dispatcher configurations ensures that new client libraries and other updates are served efficiently. The HTML pages need to reference the new clientlibs versioned paths to reflect the latest updates. Since the WKND configuration sets HTML page caching to a maximum of 5 minutes with additional revalidation periods, the new HTML pages and associated clientlibs may not appear immediately; after 5 minutes, if a user requests the content, the CDN serves the stale (cached) content immediately and fetches a new version from the origin server in the background. This mechanism ensures that users receive immediate responses, even if the content is slightly outdated, while the cache is refreshed in the background, the stale-while-revalidate directive helps ensure users see updated content with minimal disruption. This setup minimizes the impact of cache misses and ensures that updated content is available without noticeable delay to the user. This well-balanced approach allows for efficient content delivery while maintaining a seamless user experience.

The post Serving New Client Library CSS and JS After Release on AEM as a Cloud Service (AEMaaCS) appeared first on Sourced Code.

This topic will cover some of the questions that have been asked:

• What are the most efficient ways to cache AEM Experience Fragments in AEM?
• What are different ways to cache AEM Experience Fragments in AEM?
• What are the caching strategies for AEM Experience Fragments in AEM?

1. Server-Side Rendering, utilising the out of the box (OOTB) AEM experience fragment component

Utilizing the OOTB experience fragment component, the experience fragment will be rendered and cached a part of the HTML page.

Pros:

• Easy to include experience fragments to editable templates and pages.

Cons:

• Publishing changes for experience fragments will not automatically flush all the pages that are referencing the experience fragment.
• For large sites, flushing all pages with the experience fragment reference may cause performance issues in the live production sites.

My Solution to the Cons:

• Schedule a re-activation time for the experience fragment. The time set should be of when the site has the lowest traffic would be the best option.
• Create a custom replication agent to invokes all the flush agent(s) that are registered within the publish instance. Flush all the pages that reference the experience fragment; adding a minor throttling mechanism if required. The mechanism should re-fetch all pages after the flush.

2. Javascript Request and HTML Rendering

Creating a custom experience fragment component that uses javascript to request for the experience fragment HTML path. On success, inject and render the experience fragment’s HTML’s structure to the page.

Pros:

• All pages referencing to the updated experience fragment will not need to be flushed.
• All pages referencing to the updated experience fragments will surface new content on the page immediately.
• Flushing all pages with the updated experience fragment is not required.

Cons:

• Components defined in the experience fragment that are relying on the site’s javascript will not be working as expected.

My Solution to the Cons:

• Only allow experience fragments that do not rely on javascript to be allowed in the custom javascript experience fragment component; define the parsys that only allows specific components which do not depend on javascript like slideshows.

3. Sling Dynamic Include (SDI) Component Rendering

Sling Dynamic Include replaces specific and defined components with different types of include tags (apache include tags) and therefore allows to put dynamic content into a page cached by the dispatcher.

Configure Sling Dynamic Include on both AEM Publish and Apache Web Servers. The SDI AEM install exposes an OSGI configuration that allows you to target specific components that will be converted to SDI include tags in the publish mode. When a page is being requested from the Apache Web Server, the resolved page with the SDI include tag will request the JCR path from the targeted components (experience fragment), and will cache the HTML in the webserver. The page with SDI include tags will include the experience fragment HTML (cached) to the final rendered page. In summary, the render of the final page will include the experience fragment as one HTML file.

Pros:

• All pages referencing to the updated experience fragment will not need to be flushed.
• All pages referencing to the updated experience fragments will surface new content on the page immediately.
• Flushing all pages with the updated experience fragment is not required.

Cons:

• If an author unpublishes an experience fragment unexpectedly, the apache web server will display an error directly onto the page.

My Solution to the Cons:

• To restrict all users from unpublishing experience fragments.
• To create a custom approval workflow invoked in the “author” instance, where all pages referencing to the targeted unpublished experience fragment should have the experience fragment removed, and re-published; upon approval.

The post Caching Experience Fragment Techniques in AEM Sites 6.5 appeared first on Sourced Code.