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.

1. Why Disable Logs During Unit Tests?

Logging during unit tests can add unnecessary overhead, especially in large projects where tests generate extensive logs. While logging is essential in production and development environments for debugging, it offers little value during unit tests where the focus is on verifying the correctness of isolated components. Disabling logs during tests provides several benefits:

• Reduced I/O Overhead: Logging operations require I/O, which can slow down test execution. Disabling logging eliminates this overhead, leading to faster tests.
• Cleaner Test Output: With logs disabled, test outputs are cleaner, making it easier to focus on test results without the distraction of log entries.
• Improved Test Performance: Benchmarks have shown that disabling logs can significantly speed up test execution.

2. Adding slf4j-nop to Your Project

To disable logging, you can add the slf4j-nop dependency to your pom.xml:

For multi-module AEM projects, ensure this dependency is also included in the core/pom.xml file.

https://mvnrepository.com/artifact/org.slf4j/slf4j-nop

3. Benchmarks and Examples

Here’s a comparison of test execution times to illustrate the impact of disabling logs:

• JUnit 5 (with logging):
  • Run from IntelliJ IDEA: 9.276 seconds
  • Run with mvn clean test: 8.696 seconds
• JUnit 5 (with slf4j-nop):
  • Run from IntelliJ IDEA: 2.116 seconds
  • Run with mvn clean test: 1.892 seconds

These results clearly demonstrate that disabling logging can drastically reduce test execution times, allowing for faster feedback during development.

4. Further Optimizing AEM Tests

In addition to disabling logging, further optimization can be achieved by selecting the appropriate AemContext:

• NoResourceResolverTypeAemContext (Fastest): Ideal for tests that don’t require resource resolution.
• ResourceResolverMockAemContext (Default): Best for tests that need a mocked resource resolver.
• JcrMockAemContext: Useful for tests requiring JCR features like indexing.
• JcrOakAemContext (Slowest): Necessary for simulating a full JCR, though it’s the slowest option.

By combining these strategies—disabling unnecessary logging and selecting the appropriate context—you can achieve significantly faster and more efficient unit tests.

Implementing these strategies ensures your unit tests are optimized, allowing you to maintain high development velocity without being slowed down by lengthy test runs.

The post How to Speed Up Unit Tests in JUnit 5 AEM Projects with SLF4J-NOP 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.

In this article, I will show you how to set up environment-specific and secret variables. If you would like to understand when to use environment-specific and secret variables effectively, check out the official AEM Adobe git documentation. At the end of this article, you are equipped to run your AEM local development environment with environment-specific and secret variables!

One last thing, it looks like only AEMaaCS SDK has environment-specific and secret variables feature enabled for OSGI configurations.

Examples of what OSGI configurations would look like with environment and secret variables set in your code base:

Environment-specific variable
high-level use-case: Values that are specific to a particular environment and may vary between different development environments cannot be targeted accurately by run mode, as AEMaaCS only has a single development run mode. For instance:

Secret variable
high-level use-case: Sensitive information, such as confidential data or authentication credentials, should not be stored in Git repositories due to security concerns. For instance:

Example of an OSGI configuration with the combination of the environment-specific and secret variables being used:

So how we can actually set these environments and secret variables into AEM? Well, it’s simple. We will be using a Linux environment to set this up. In the examples below, we will be setting up one environment-specific variable and one secret variable.

• $[env:SERVER_API_URL]
• $[secret:SERVER_API_KEY]

1. set AEM Environment variables on local AEM instance

1. Close down your local AEM environment.
2. open git bash or terminal.
3. cd to the AEM folder, where the executable jar file exists.
4. run export SERVER_API_URL=https://api.sourcedcode.com
5. run echo ${SERVER_API_URL}// you should see the environment variable being set as this call will echo out what the environment variable is for SERVER_API_URL.
6. now restart your local AEM environment.
7. done.

2. set AEM Secret variables on local AEM instance

1. Close down your local AEM environment.
2. open git bash or terminal.
3. cd to the AEM folder, where the executable jar file exists.
4. run vim ./crx-quickstart/conf/quickstart.properties
5. add this to the last line org.apache.felix.configadmin.plugin.interpolation.secretsdir=${sling.home}/secretsdir
6. save in vim.
7. run mkdir ./crx-quickstart/secretsdir
8. run cd ./crx-quickstart/secretsdir
9. run echo “23u1kn1jbkjs789fds8f_ewrqasd” > SERVER_API_KEY
10. repeat the step-9 to add more secret variables into your AEM local environment. run echo “secret_value” > secret_key
11. You may have more than 1 secret variable stored in the secretsdir folder:
12. now restart your local AEM environment.
13. done.

The post Set AEM Local Environment and Secret Variables AEMaaCS appeared first on Sourced Code.

There are several mobile emulators available for AEM, such as the iOS Simulator and Android Emulator. These emulators simulate the functionality and appearance of mobile devices, allowing developers to test their websites or applications as if they were running on an actual device.

In AEM, the “/etc/mobile/groups” is a location where mobile groups are created and managed. Mobile groups are used to segment content for different mobile devices, such as smartphones and tablets. They allow you to configure and tailor your website or application for specific devices, optimizing the user experience for each device type.

Using the /etc/mobile/groups feature, you can create and manage different groups of mobile devices, set up rules for device detection, and define content for each group. This allows you to provide a tailored experience for users based on the device they are using.

When I tried to introduce a new mobile emulator under the path of ui.content/../etc/mobile/groups/sourcedcode, I was getting a big error:

[ERROR] ValidationViolation: “jackrabbit-filter: Filter root’s ancestor ‘/etc/mobile/groups’ is not covered by any of the specified dependencies nor a valid root.”, filePath=META-INF/vault/filter.xml
[INFO] ValidationViolation: “jackrabbit-filter: Found orphaned filter entries: entry with root ‘/etc/mobile/groups/sourcedcode'”

Solution

Under the ui.content/pom.xml it looks like we can add configuration to allow validRoots as a part of the maven build. You can simply add this configuration as a part of the <plugin>, and it should be working as expected.

Keep an eye on the code below, line:16-22.

The post jackrabbit-filter: Filter root’s ancestor ‘/etc/mobile/groups’ appeared first on Sourced Code.

The AEMaaCS local publish environment runs on port 4503, and the security settings are configured by default to align with AEMaaCS setup. If you need to debug the AEMaaCS local publish environment, it’s important to authenticate into the environment, especially for accessing crx/de and system/console.

In this article, we will guide you through the process of authenticating into the AEMaaCS local publish environment.

To access the crx/de and system/console for your AEM publish environment, follow these simple steps:

1. Open your web browser and go to http://localhost:4503/libs/granite/core/content/login.html.
2. Enter the username “admin” and the password “admin”.
3. Once you have successfully logged in, you can navigate to the crx/de and system/console environment.
4. Visit crx/de: http://localhost:4503/crx/de/index.jsp
5. Visit system/console: http://localhost:4503/system/console/bundles

The post How to login to AEMaaCS Local Publish crx/de system/console appeared first on Sourced Code.