Adaptive Image Rendering for AEM components

In the realm of Adobe Experience Manager (AEM) development, optimizing images within AEM components is crucial. One highly effective method for achieving this optimization is by using adaptive rendering.

What are Adaptive Images ?

Adaptive images are a web development technique that ensures images on a website are delivered in the most suitable size and format for each user’s device and screen resolution. This optimization enhances website performance and user experience by reducing unnecessary data transfer and ensuring images look sharp and load quickly on all devices.

Example:

Let’s analyze the example, with a primary emphasis on the srcset attribute for the current blog:

1. <div data-cmp-is="image" ...>: This is the HTML element that is generated by Image component . It has various attributes and data that provide information about the image.
2. data-cmp-widths="100,200,300,400,500,600,700,800,900,1000,1100,1200,1600": These are different widths at which the image is available. These widths are used to serve the most appropriate image size to the user’s device based on its screen width.
3. data-cmp-src="/content/wknd/language-masters/en/test/_jcr_content/root/container/feature.coreimg.60{.width}.jpeg/1695628972928/mountain-range.jpeg": This attribute defines the source URL of the image. Notice the {.width} placeholder, which will be dynamically replaced with the appropriate width value based on the user’s device.
4. data-cmp-filereference="/content/dam/core-components-examples/library/sample-assets/mountain-range.jpg": This is a reference to the actual image file stored on the server.
5. srcset="...": This attribute specifies a list of image sources with different widths and their corresponding URLs. Browsers use this information to select the best image size to download based on the user’s screen size and resolution.
6. loading="lazy": This attribute indicates that the image should be loaded lazily, meaning it will only be loaded when it’s about to come into the user’s viewport, improving page load performance.

How Browsers Choose Images with srcset Based on Device Characteristics:

1. Device Pixel Ratio (DPR): The browser first checks the device’s pixel ratio or DPI (Dots Per Inch), which measures how many physical pixels are used to represent each CSS pixel. Common values are 1x (low-density screens) and 2x (high-density screens, like Retina displays). DPR influences the effective resolution of the device.
2. Viewport Size: The browser knows the dimensions of the user’s viewport, which is the visible area of the webpage within the browser window. Both the viewport width and height are considered.
3. Image Size Descriptors: Each source in the srcset list is associated with a width descriptor (e.g., 100w, 200w) representing the image’s width in CSS pixels. These descriptors help the browser determine the size of each image source.
4. Network Conditions: Browsers may also consider the user’s network conditions, such as available bandwidth, to optimize image loading. Smaller images may be prioritized for faster loading on slower connections.
5. Calculation of Effective Pixel Size: The browser calculates a “density-corrected effective pixel size” for each image source in the srcset. This calculation involves multiplying the image’s declared width descriptor by the device’s pixel ratio (DPR).
6. Selecting the Most Appropriate Image: The browser compares the calculated effective pixel sizes to the viewport size. It chooses the image source that best matches the viewport width or height, ensuring that the image is appropriately sized for the user’s screen.
7. Loading Only One Image: Typically, the browser loads only one image from the srcset list. It selects the image source that is the closest match to the viewport dimensions. This approach optimizes performance and reduces unnecessary data transfer.

Example:

Suppose the browser detects a device with a DPR of 2x and a viewport width of 400 CSS pixels. In this case, the browser selects the image-200w.jpg source (200w) because it is the closest match to the viewport width of 400 pixels. Only the image-200w.jpg will be loaded, not all three images.

By dynamically selecting the most appropriate image source from the srcset, browsers optimize page performance and ensure that images look sharp on high-resolution screens while minimizing unnecessary data transfer on lower-resolution devices.

Implementing adaptive images for Components

In Adobe Experience Manager (AEM), both ResourceWrapper and data-sly-resource are used for including or rendering content from other resources within your AEM components. However, they serve slightly different purposes and are used in different contexts:

ResourceWrapper:

• Purpose: ResourceWrapper is a Java class used on the server-side to manipulate and control the rendering of resources within your AEM components.
• Usage:
  • You use ResourceWrapper when you want to programmatically control how a resource or component is rendered.
  • This appraoch is also used by WCM Core components like Teaser.
• Benefit: Utilized as an abstract class, ResourceWrapper provides advantages in terms of reusability, consistency, and streamlined development. In the context of components responsible for displaying images, developers can extend this abstract class and configure a property on the custom component. This approach expedites the development process, guarantees uniformity, simplifies customization, and, in the end, elevates efficiency and ease of maintenance.

data-sly-resource:

• Purpose: data-sly-resource is a client-side attribute used in HTL (HTML Template Language) to include and render other resources or components within your HTL templates.
• Usage:
  • You use data-sly-resource when you want to include and render other AEM components or resources within your HTL templates.
• Example:

     <sly data-sly-resource="${resource.path @ resourceType='wknd/components/image'}"></sly>

Our focus will be on harnessing the power of the ResourceWrapper class from the Apache Sling API as a crucial tool for this purpose.

Understanding ResourceWrapper

The ResourceWrapper acts as a protective layer for any Resource, automatically forwarding all method calls to the enclosed resource by default.

To put it simply, in order to render an adaptive image in our custom component:

1. We need to integrate a fileUpload field.
2. Wrap this component’s resource using ResourceWrapper. The resource type associated with the image component will be added to the Wrapper.
3. As a result, this newly enveloped resource can be effortlessly presented through the Image component.

It’s a straightforward process!

Now lets get into the details.

Step 1: Create an Image Resource Wrapper

The first step is to create an Image Resource Wrapper. This wrapper will be responsible for encapsulating the Image Resource and appending the Image ResourceType to the corresponding value map. This wrapped instance can then be used by Sightly to render the resource using the ResourceType. Please keep in mind that the URLs generated by Sightly depend on the policy of the Image component used.

Link to complete class: ImageResourceWrapper

Step 2: Create an Abstract Class for Reusability

Link to Complete class: AbstractImageDelegatingModel

Step 3: Create a Model for Sightly Rendering

Link to Complete class: FeatureImpl

Link to Complete interface: Feature

Step 4: Sightly Code for Rendering

These steps provide a structured approach to implement adaptive images for custom components using the WCM Core Image component in Adobe Experience Manager. Customize the Model and Sightly code as needed to suit your specific project requirements and image rendering policies.

Step 5: Configure Image Resource Type

In this step, you will configure the Image Resource Type to be used in the component’s dialog. This involves setting the imageDelegate property to a specific value, such as techrevel/components/image, within the component’s configuration. This definition is crucial as it specifies which Image Resource Type will be utilized for rendering.

Link to the component in ui.apps: Feature

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
    jcr:primaryType="cq:Component"
    jcr:title="Feature"
    componentGroup="Techrevel AEM Site - Content"
    sling:resourceSuperType="core/wcm/components/image/v3/image"
    imageDelegate="techrevel/components/image"/>

Step 6: Add Image Upload Field to the Component’s Dialog

Link to the complete code of component’s dialog

Step 7: Verify Component Availability

Ensure component is available for use in your templates, allowing them to be added to pages. Additionally, it’s crucial to verify that you have appropriately configured the policy of the Image component. The policy of the Image component plays a pivotal role in generating the adaptive image’s URL, ensuring it aligns with your project’s requirements for image optimization and delivery.

At this point, with the knowledge and steps outlined in this guide, you should be fully equipped to configure images within your custom component.

When you inspect the URL of the image, it should now appear in a format optimized for adaptive rendering, ensuring that it seamlessly adapts to various device contexts and screen sizes.

This level of image optimization not only enhances performance but also significantly contributes to an improved user experience.

AEM Tips & Tricks

Hello Everyone

Excited & thrilled to embark on this journey of learning and growth with all of you.
Following this week's theme for Tuesday Tech Bytes.

---

 

AdaptTo(): The Not-So-Smooth Path to Sling Model Instantiation

 

In AEM development, the `adaptTo()` method is a widely used and reliable method, but it is not always the best fit for every job.

 

It's commonly used for translating objects and instantiating Sling Models, but there's a twist. As it turns out, relying solely on `adaptTo()` can lead to some not-so-ideal situations.

 

Let's say, you're tasked with translating a Resource into a Node, and you reach for the familiar `adaptTo(Node.class)` call.

Simple, right? Well, not always.

 

The trouble begins when you find yourself in one of these tricky scenarios:

• The implementation doesn't support the target type.
• An adapter factory handling the conversion isn't active, possibly due to missing service references.
• Internal conditions within AEM fail.
• Required services are simply unavailable.

 

In these situations, instead of throwing exceptions, `adaptTo()` remains silent and returns `null`.

You might think, "No big deal, I'll just add some null checks and handle it gracefully."

But here's the catch: The absence of exceptions means that we often miss out on essential logs and traces that could help us diagnose why a Sling Model is failing.

 

But wait, there's a better way – one that doesn't require you to add multiple null checks everywhere.

That is SLING's ModelFactory.

 

Since Sling Models 1.2.0, there's been a game-changing alternative for instantiating models.

The OSGi service ModelFactory provides a method that throws exceptions when things go awry.

This is a departure from the Javadoc contract of `adaptTo()`, but it's a change for the better.

With ModelFactory, you can wave goodbye to those null checks and gain clear insights into why your model instantiation failed.

 

Here's how it works:

 

 

try { MyModel model = modelFactory.createModel(object, MyModel.class); } catch (Exception e) { // Display an error message explaining why the model couldn't be instantiated. // The exception contains valuable information. // MissingElementsException - When no injector could provide required values with the given types // InvalidAdaptableException - If the given class can't be instantiated from the adaptable (a different adaptable than expected) // ModelClassException - If model instantiation failed due to missing annotations, reflection issues, lack of a valid constructor, unregistered model as an adapter factory, or issues with post-construct methods // PostConstructException - In case the post-construct method itself throws an exception // ValidationException - If validation couldn't be performed for some reason (e.g., no validation information available) // InvalidModelException - If the model type couldn't be validated through model validation }

 

But that's not all.

ModelFactory offers additional methods for checking whether a class is indeed a model (bearing the model annotation) and whether a class can be adapted from a given adaptable (check out `canCreateFromAdaptable`, `isModelClass`, `isModelAvailableForResource`, and more).

 

In a nutshell, while `adaptTo()` is still handy for object translations, when it comes to SLING Model instantiation, ModelFactory is the savvy choice.

 

Want to dive deeper?

Check out the official documentation for ModelFactory.

---

Reduce Code duplication, and complexity, and create Atomic structure by creating an interface for similar SLING models

 

Let's look at these 2 SLING Models:

 

@Model(adaptables = Resource.class) public class FootballArticleModel { @Inject private String title; @Inject private Date publicationDate; // Getter methods for title and publicationDate }

 

@Model(adaptables = Resource.class) public class BasketballArticleModel { @Inject private String title; @Inject private Date publicationDate; // Getter methods for title and publicationDate }

 

In this approach, you have separate Sling Models for Football and Basketball Articles, which can lead to code duplication and complexity if these articles share common properties.

 

// Common Sports Article Interface public interface SportsArticle { String getTitle(); Date getPublicationDate(); } // Sling Model for Football Article @Model(adaptables = Resource.class) public class FootballArticleModel implements SportsArticle { @Inject private String title; @Inject private Date publicationDate; // Implementing methods from the SportsArticle interface public String getTitle() { return title; } public Date getPublicationDate() { return publicationDate; } }

 

You can make a similar Model for Basketball Articles.

• If you need to update the common properties' behavior (e.g., `getTitle`) for all sports articles, you can do so in one place (the interface) instead of modifying multiple Sling Models.

 

• When working with instances of these models in your AEM components, you can adapt them to the `SportsArticle` interface, simplifying your code and promoting consistency across various sports article types.

 

• This approach promotes code reusability, maintainability, and flexibility in your AEM project, making it easier to handle different types of sports-related content with shared properties.

 

This is just a simple and small example, but implementing this for a complex structure can help you achieve atomic design in even SLING Models.

---

Why use Resource Type Mapping in SLING Servlets?

 

Instead of specifying exact paths for servlet mappings, map servlets to resource types, making them more flexible and reusable. But why?

 

1. Enhanced Access Control: Servlets bound to specific paths often lack the flexibility to be effectively access-controlled using the default JCR repository Access Control Lists (ACLs). On the other hand, resource-type-bound servlets can be seamlessly integrated into your access control strategy, providing a more secure environment.
   
   
2. Suffix Handling: Path-bound servlets are, by design, limited to a single path. In contrast, resource type-based mappings open the door to handling various resource suffixes elegantly. This versatility allows you to serve diverse content and functionalities without the need for multiple servlet registrations.
   
   
3. Avoid Unexpected Consequences: When a path-bound servlet becomes inactive (e.g., due to a missing or non-started bundle), it can lead to unintended consequences, like POST requests creating nodes at unexpected paths. This can introduce unexpected complexities and issues in your application. Resource type mappings provide better control and predictability.
   
   
4. Developer-Friendly Transparency: For developers working with the repository, path-bound servlet mappings may not be readily apparent. In contrast, resource type mappings provide a more transparent and intuitive way of understanding how servlets are associated with specific resources. This transparency simplifies development and troubleshooting.

 

---

Implement asynchronous processing for non-blocking tasks to free up server resources and improve responsiveness.

 

The concept is simple enough to understand. So let's look at how to implement it.

We will create a simple trigger and consumer component.

 

 

Job Trigger Component [ MyEventTrigger ]

@8220494(args) public class MyEventTrigger { @Reference private JobManager jobManager; public void triggerAsyncEvent() { // Create a job description for your asynchronous task String jobTopic = "my/async/job/topic"; // Add the job to the queue for asynchronous processing jobManager.addJob(jobTopic, <property_map>); // you can create a property map and pass it to the job. } }

MyEventTrigger triggers an asynchronous event by adding a job with the topic "my/async/job/topic" to the job queue using the jobManager.addJob method.

 

 

Creating a Job Consumer Component [ MyJobConsumer ]

 

@8220494( service = JobConsumer.class, property = { JobConsumer.PROPERTY_TOPICS + "=my/async/job/topic" } ) public class MyJobConsumer implements JobConsumer { private final Logger logger = LoggerFactory.getLogger(getClass()); @Override public JobResult process(Job job) { // Job is passed as an argument, and you can use the property_map in this function. try { logger.info("Processing asynchronous job..."); // Your business logic for processing the job goes here return JobConsumer.JobResult.OK; } catch (Exception e) { logger.error("Error processing the job: " + e.getMessage(), e); return JobConsumer.JobResult.FAILED; } } }

 

MyJobConsumer listens for jobs with the specified topic "my/async/job/topic" and processes them asynchronously.

 

Your specific business logic should be implemented in the process method.

---

Use Sling request filters to perform pre-processing or post-processing tasks without modifying servlet code.

 

Let's say, you want to add a custom suffix to the URLs of specific pages for tracking purposes, but you don't want to modify the servlet code for each page.

 

Instead, you want to handle this at the request level.

 

import org.apache.sling.api.SlingHttpServletRequest; import org.apache.sling.api.SlingHttpServletResponse; import org.apache.sling.api.servlets.SlingSafeMethodsServlet; import org.apache.sling.engine.servlets.SlingRequestFilter; import org.osgi.service.component.annotations.Component; import javax.servlet.FilterChain; import javax.servlet.ServletException; import java.io.IOException; @Component( service = SlingRequestFilter.class, property = { "sling.filter.scope=request", "sling.filter.pattern=/content/mywebsite/en.*" // Define the URL pattern for your pages } ) public class CustomSuffixRequestFilter implements SlingRequestFilter { @Override public void doFilter(SlingHttpServletRequest request, SlingHttpServletResponse response, FilterChain chain) throws IOException, ServletException { // Get the original request URL String originalURL = request.getRequestURI(); // Add a custom suffix to the URL String modifiedURL = originalURL + ".customsuffix"; // Create a new request with the modified URL SlingHttpServletRequest modifiedRequest = new ModifiedRequest(request, modifiedURL); // Continue the request chain with the modified request chain.doFilter(modifiedRequest, response); } @Override public void init(javax.servlet.FilterConfig filterConfig) throws ServletException { // Initialization code if needed } @Override public void destroy() { // Cleanup code if needed } }

 

This is just a small example, but you can achieve many things with this:

• Authentication of requests
• As well as authentication of all the servlet requests coming into a server
• Checking resource type, path, and request coming on from a particular page, etc.

It can act as an extra layer of security or an additional layer of functionality before a request reaches a servlet.

---

Use Custom SLING Injectors for Injecting essential information to your SLING model not present in the component properties

 

Imagine you need a way to effortlessly inject custom request headers into your AEM components.

These headers might carry essential information or flags that your components rely on, but manually parsing them every time is not very efficient.

 

Here we can use custom SLING injectors

 

1. Create Custom Annotation

@1787617({ElementType.FIELD}) @Retention(RetentionPolicy.RUNTIME) // Declareation for custom injector. @InjectAnnotation // Identifier in the Injector class itself @Source("custom-header") public @interface InheritedValueMapValue { String property() default ""; InjectionStrategy injectionStrategy() default InjectionStrategy.DEFAULT; }

 

2. Create a Custom Injector for Request Headers:

 

// Implement a custom injector for request headers by implementing the `org.apache.sling.models.spi.Injector` interface. @Component(property=Constants.SERVICE_RANKING+":Integer="+Integer.MAX_VALUE, service={Injector.class, StaticInjectAnnotationProcessorFactory.class, AcceptsNullName.class}) public class CustomHeaderInjector implements implements Injector, StaticInjectAnnotationProcessorFactory { @Override public String getName() { return "custom-header"; // identifier used again } @Override public Object getValue(Object adaptable, String fieldName, Type type, AnnotatedElement element, DisposalCallbackRegistry callbackRegistry) { if (adaptable instanceof SlingHttpServletRequest) { SlingHttpServletRequest request = (SlingHttpServletRequest) adaptable; String customHeaderValue = request.getHeader("X-Custom-Header"); if (customHeaderValue != null) { return customHeaderValue; } } return null; } }

 

2. Inject the Custom Header into Your Model:

In your SLING model, use the custom @586265 annotation to seamlessly inject the custom header value into your component.

 

@Model(adaptables = SlingHttpServletRequest.class) public class CustomHeaderComponent { @Inject private String customHeaderValue; // This will be automatically populated by the custom injector // Your component logic here, using customHeaderValue }

 

 

3. Use the Injected Custom Header Value:

 

Now, you can tap into the customHeaderValue within your SLING model, accessing the custom request header without the hassle of manual parsing.

 

 

public class CustomHeaderComponent { @Inject private String customHeaderValue; public String getCustomHeaderValue() { return customHeaderValue; } // Other methods to work with the custom header value }

 

In this scenario, we've conjured up a custom injector, CustomHeaderInjector, to inject custom request headers into your AEM components.

 

This kind of custom injection is most commonly used in injecting Cookies and Headers into a component/s, to achieve different functionalities based on it.

 

Official Documentation:

https://sling.apache.org/documentation/bundles/models.html#custom-annotations

You can also refer to this GitHub for sample code:

https://github.com/apache/sling-org-apache-sling-models-impl/tree/master/src/main/java/org/apache/sling/models/impl/injectors

 

 

---

There are many things to learn and explore in AEM, and many tips and tricks as well apart from this, these are the tips that I have not seen implemented as much, and are helpful but lesser known IMO.

 

So, I hope you've gathered some valuable insights to enhance your knowledge of AEM.

I will be writing another part of this which focuses more on the testing and authoring tricks, along with 1(or 2) development tips as well in the next week.

 

Thanks!

Anmol Bhardwaj

 

 

AEM Tips & Tricks

• Discover Errors with Ease, Navigate Nodes in a Click

• Effortless Error Detection: You can find out errors in your SLING models without leaving the page in the error section of developer mode, it shows the entire stack trace.
   
• Point-and-Click Node Navigation: You can easily navigate to your component node or even it's scripts in CRX through the hyperlink present in developer mode.
   
   

  

• Policies Applied to Component: With a click of a button, you can check what policies are added to the particular component.
• Component Details: You can even check out your component details with hyperlink present in developer mode. It gives a very clear and detailed information about your component. ( including policies, live usage & documentation)
   
  Author Perspective:
   
• Live Usage / Component Report : You can also get all the instances and references where the component you selected is being used. This is really helpful for both developers, BA & authors.
   
• Component Documenation & Authoring Guide: The documentation tab in the component details tab will point to the component documentation, which can be customised to add authoring guide to the component , which can help the authors in authoring the component better.

So, let's unlock the power of shortcuts by pressing '?' in the Sites console.

Location: Any edit window mode

 

Shortcut	Description
Ctrl-Shift-m	Toggle between Preview and the selected mode

 

Implement custom health checks as OSGi services to monitor specific aspects of your AEM application's health and performance.

 

You might have noticed that there are health checks present in AEM's Sites  OOTB, but did you know that they can be imported and implemented in your custom code?

Also, you can add a new tile to that health check console through code.

 

Note: The console is available at

• Sites > Tools > Operations > Health Reports through Navigation
• http://localhost:4502/libs/granite/operations/content/healthreports/healthreportlist.html through direct link

 

This can be done through Apache Felix Health API

 

Let's understand this by the following requirement:

 

You want to create a custom health check to monitor the health of AEM's indexing service, specifically checking if the AEM indexing queue is not overloaded.

 

Step 1: Add the following dependency to your maven project :

Add the following new dependencies:

<dependency> <groupId>org.apache.felix</groupId> <artifactId>org.apache.felix.healthcheck.api</artifactId> <version>2.0.4</version> <scope>provided</scope> </dependency> <dependency> <groupId>org.apache.felix</groupId> <artifactId>org.apache.felix.healthcheck.annotation</artifactId> <version>2.0.0</version> <scope>provided</scope> </dependency>

 

 

/* * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information * regarding copyright ownership. The SF licenses this file * to you under the Apache License, Version 2.0 (the * "License"); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, * software distributed under the License is distributed on an * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY * KIND, either express or implied. See the License for the * specific language governing permissions and limitations under the License. */ package org.apache.felix.hc.generalchecks; import static org.apache.felix.hc.api.FormattingResultLog.bytesHumanReadable; import java.io.File; import java.util.Arrays; import org.apache.felix.hc.annotation.HealthCheckService; import org.apache.felix.hc.api.FormattingResultLog; import org.apache.felix.hc.api.HealthCheck; import org.apache.felix.hc.api.Result; import org.apache.felix.hc.api.ResultLog; import org.osgi.service.component.annotations.Activate; import org.osgi.service.component.annotations.Component; import org.osgi.service.component.annotations.ConfigurationPolicy; import org.osgi.service.metatype.annotations.AttributeDefinition; import org.osgi.service.metatype.annotations.Designate; import org.osgi.service.metatype.annotations.ObjectClassDefinition; import org.slf4j.Logger; import org.slf4j.LoggerFactory; @HealthCheckService(name = DiskSpaceCheck.HC_NAME) @Component(configurationPolicy = ConfigurationPolicy.REQUIRE, immediate = true) @Designate(ocd = DiskSpaceCheck.Config.class, factory = true) public class DiskSpaceCheck implements HealthCheck { private static final Logger LOG = LoggerFactory.getLogger(DiskSpaceCheck.class); public static final String HC_NAME = "Disk Space"; public static final String HC_LABEL = "Health Check: " + HC_NAME; @ObjectClassDefinition(name = HC_LABEL, description = "Checks the configured path(s) against the given thresholds") public Config { @AttributeDefinition(name = "Name", description = "Name of this health check") String hc_name() default HC_NAME; @AttributeDefinition(name = "Tags", description = "List of tags for this health check, used to select subsets of health checks for execution e.g. by a composite health check.") String[] hc_tags() default {}; @AttributeDefinition(name = "Disk used threshold for WARN", description = "in percent, if disk usage is over this limit the result is WARN") long diskUsedThresholdWarn() default 90; @AttributeDefinition(name = "Disk used threshold for CRITICAL", description = "in percent, if disk usage is over this limit the result is CRITICAL") long diskUsedThresholdCritical() default 97; @AttributeDefinition(name = "Paths to check for disk usage", description = "Paths that is checked for free space according the configured thresholds") String[] diskPaths() default { "." }; @AttributeDefinition String webconsole_configurationFactory_nameHint() default "{hc.name}: {diskPaths} used>{diskUsedThresholdWarn}% -> WARN used>{diskUsedThresholdCritical}% -> CRITICAL"; } private long diskUsedThresholdWarn; private long diskUsedThresholdCritical; private String[] diskPaths; @Activate protected void activate(final Config config) { diskUsedThresholdWarn = config.diskUsedThresholdWarn(); diskUsedThresholdCritical = config.diskUsedThresholdCritical(); diskPaths = config.diskPaths(); LOG.debug("Activated disk usage HC for path(s) {} diskUsedThresholdWarn={}% diskUsedThresholdCritical={}%", Arrays.asList(diskPaths), diskUsedThresholdWarn, diskUsedThresholdCritical); } @Override public Result execute() { FormattingResultLog log = new FormattingResultLog(); for (String diskPath : diskPaths) { File diskPathFile = new File(diskPath); if (!diskPathFile.exists()) { log.warn("Directory '{}' does not exist", diskPathFile); continue; } else if (!diskPathFile.isDirectory()) { log.warn("Directory '{}' is not a directory", diskPathFile); continue; } double total = diskPathFile.getTotalSpace(); double free = diskPathFile.getUsableSpace(); double usedPercentage = (total - free) / total * 100d; String totalStr = bytesHumanReadable(total); String freeStr = bytesHumanReadable(free); String msg = String.format("Disk Usage %s: %.1f%% of %s used / %s free", diskPathFile.getAbsolutePath(), usedPercentage, totalStr, freeStr); Result.Status status = usedPercentage > this.diskUsedThresholdCritical ? Result.Status.CRITICAL : usedPercentage > this.diskUsedThresholdWarn ? Result.Status.WARN : Result.Status.OK; log.add(new ResultLog.Entry(status, msg)); } return new Result(log); } }

If you notice this code, it is for the OOTB Health CHeck for Disk Space Usage, you will see that most of the properties required for this are actually added through OSGi Configs.

 

You can create any kind of Health Check, as we are creating this in Java, and you can basically add custom libraries as well and use them in combination with each other. You can make it more flexible by letting the users add stuff through OSGi Configs. You can even use context aware configuration, basically, the posibilities are endless.

 

 

Sample health checks using Apache Felix Health API:

 

https://github.com/apache/felix-dev/blob/master/healthcheck/README.md#executing-health-checks

 

Thanks!

Anmol Bhardwaj

 

Basic Guidelines: Content Fragment Models and GraphQL Queries for AEM Headless Implementation

Unlocking the potential of headless content delivery in Adobe Experience Manager (AEM) is a journey that begins with a solid foundation in Content Fragment Models (CFM) and GraphQL queries. In this blog, we’ll embark on this journey and explore the best practices and guidelines for designing CFMs and crafting GraphQL queries that empower your AEM headless implementation.

Guildelines for Content Fragment Models.

• Use Organism, Molecule, and Atom (OMA) model for structuring Content Fragment Models. It provides a systematic way to organize and model content for greater flexibility and reusability.
  • Organism: Organisms represent high-level content entities or content types. Each Organism corresponds to a specific type of content in your system, such as articles, products, or landing pages. Organisms have their own Content Fragment Models, defining the structure and properties of that content type. Example:
    • Organism: “Article”
    • Content Fragment Model: “Article Content Fragment Model”
  • Molecule: Molecules are reusable content components that make up Organisms. They represent smaller, self-contained pieces of content that are combined to create Organisms. Molecules have their own Content Fragment Models to define their structure. Example:
    • Molecule: “Author Block” (includes author name, bio, and profile picture)
    • Content Fragment Model: “Author Block Content Fragment Model”
  • Atom: Atoms are the smallest content elements or data types. They represent individual pieces of content that are used within Molecules and Organisms. Example:
    • Atom: “Text” (represents a single text field) in CFM
• Relationships: Identify relationships between CFMs that reflect the relationships between different types of content on your pages. Also, GraphQL’s strength lies in its ability to navigate relationships efficiently. Ensure that your CFMs and GraphQL schema capture these relationships accurately. Use GraphQL’s nested queries to request related data when needed. For example, an “Author” CFM might have a relationship with an “Article” CFM to indicate authorship.
• Page Components Correspondence: Identify the components or sections within your web pages. Each of these components should have a corresponding CFM. For example, if your pages consist of article content, author details, and related articles, create CFMs for “Article”, “Author” and “Related Articles” to match these page components.
• Hierarchy and Nesting: Consider the hierarchy of content within pages. Some pages may have nested content structures, such as sections within articles or tabs within product descriptions. Create CFMs that allow for nesting of content fragments, ensuring you can represent these hierarchies accurately.
• Manage the number of content fragment models effectively: When numerous content fragments share the same model, GraphQL list queries can become resource-intensive. This is because all fragments linked to a shared model are loaded into memory, consuming time and memory resources. Filtering can only be applied after loading the complete result set into memory, which may lead to performance issues, even with small result sets. The key is to control the number of content fragment models to minimize resource consumption and enhance query performance.
• Multifield in Content Fragment Models: Adobe’s out-of-the-box (OOTB) offerings include multifields for fundamental data types such as text, content reference, and fragment reference. However, in cases where more intricate composite multifields are required, each set should be established as an individual content fragment. Subsequently, these content fragments can be associated with a parent fragment. GraphQL queries can then retrieve data from these nested content fragments. For an example, refer to link
• Content hierarchy for GraphQL optimization: Establishing a path-based configuration for content fragments is essential to enhance the performance of GraphQL queries. This approach enables queries to efficiently navigate through folder and content fragment hierarchies, thereby retrieving information from smaller data sets.
• Dedicated tenant/config folders: In the scenario of large organizations encompassing multiple business units, each with its unique content fragment models, it’s advisable to strategize the creation of content fragment models within dedicated /conf folders. These /conf folders can subsequently be customized for specific /content/dam folders. The “Allowed Content Fragment Models” property can be leveraged to restrict the usage of specific types of CFMs within a folder.
• Field Naming: Opt for transparent and uniform field names across both CFMs and GraphQL types. Select names that provide a clear indication of the field’s function, simplifying comprehension for both developers and content authors when navigating the content structure.
• Comments: Incorporate detailed descriptions for every field found in CFMs and GraphQL types. These comments should offer valuable context and elucidate the purpose of each field, aiding developers and content authors in comprehending how each property is intended to be utilized and its significance in the overall structure.
• Documentation: Ensure the presence of thorough documentation for both CFMs and GraphQL schemas. This documentation should encompass the field’s purpose, the expected values it should contain, and instructions on its utilization. Additionally, provide clear guidelines regarding the appropriate circumstances and methods for using specific fields to maintain uniformity. Any data relationships or dependencies between fields should also be documented to offer guidance to developers and content authors.
• Contemplate the option of integrating CFMs into your codebase, limiting editing access to specific administrators if necessary. This precautionary measure helps mitigate the risk of unintended modifications by unauthorized users, safeguarding your content structure from inadvertent alterations.
• In the context of AEM Sites, it is advisable to prioritize the utilization of QueryBuilder and the Content Fragment API for rendering results. This approach enables your Sling models to effectively process and transform the raw content for the user interface.
• Consider employing Experience Fragments for content that marketers frequently edit, as they provide the convenience of a WYSIWYG (What You See Is What You Get) editor.

Guildelines for graphQL queries

Sharing the general guidelines around creating graphQL queries. For syntax based suggestions, please refer to the links in References section.

• Query Complexity: Consider the complexity of GraphQL queries that content authors and developers will need to create. Ensure that the schema allows for efficient querying of content while avoiding overly complex queries that could impact performance.
• Pagination Implement offset/cursor-based pagination mechanisms within your GraphQL schema. This ensures that queries return manageable amounts of data. It’s advisable to opt for cursor-based pagination when dealing with extensive datasets for pagination, as it prevents premature processing.
  • Consider Updating your Content Fragments for optimized GraphQL Filtering

// Offset based pagination
query {
   articleList(offset: 5, limit: 5) {
    items {
      authorFragment {
        lastName
        firstName
      }
    }
  }
}

//cursor-based pagination
query {
    adventurePaginated(first: 5, after: "ODg1MmMyMmEtZTAzMy00MTNjLThiMzMtZGQyMzY5ZTNjN2M1") {
        edges {
          cursor
          node {
            title
          }
        }
        pageInfo {
          endCursor
          hasNextPage
        }
    }
}

• Security and Access Control: Implement security measures to control who can access which content from GraphQL queries. Ensure that sensitive data is protected and that only authorized users can execute certain queries or mutations. 
• Query only the data you need, where you need it: In GraphQL, clients can specify exactly which fields of a particular type they want to retrieve, eliminating over-fetching and under-fetching of data. This approach optimizes performance, reduces server load, enhances security, and ensures efficient data retrieval, making GraphQL a powerful choice for modern application development.
• Consider utilizing persisted queries as they offer optimization for network communication and query execution. Rather than transmitting the entire query text in every request, you can send a unique persisted-label that corresponds to a pre-stored query on the server. This approach takes advantage of server-side caching, allowing you to make GET requests using the persisted-label of the query, which enhances performance and reduces data transfer.
• Sort on top level fields: Sorting can be optimized when it involves top-level fields exclusively. When sorting criteria include fields located within nested fragments, it necessitates loading all fragments associated with the top-level model into memory, which negatively impacts performance. It’s important to note that even sorting on top-level fields may have a minor impact on performance. To optimize GraphQL queries, use the AND operator to combine filter expressions on top-level and nested fragment fields.
• Hybrid filtering: Explore the option of implementing hybrid filtering in GraphQL, which combines JCR filtering with AEM filtering. Hybrid filtering initially applies a JCR filter as a query constraint before the result set is loaded into memory for AEM filtering. This approach helps minimize the size of the result set loaded into memory, as the JCR filter efficiently eliminates unnecessary results beforehand. JCR filter has few limitations, where it does not work today, like case-insensitivity, null-check, contains not etc
• Use dynamic filters: Dynamic filters in GraphQL offer flexibility and performance benefits compared to variables. They allow you to construct and apply filters dynamically during runtime, tailoring queries to specific conditions without the need to define multiple query variations with variables. More details in video (time 6:29)

//Query with Variables
query getArticleBySlug($slug: String!) {
  articleList(
    filter: {slug: {_expressions: [{value: $slug}]}}
   ) {
    items {
      _path
      title
      slug
    }
  }
}

//Query-Variables
{"slug": "alaskan-adventures"}

//Query with Dynamic Filter
query getArticleBySlug($filter: 
  ArticleModelFilter!){  
    articleList(filter: $filter) {
    items {
      _path
      title
      slug
    }
  }
}

//Query-variables
{
  "filter": {
    "slug": {
      "_expressions": [{"value": "alaskan-adventures"}]
    }
  }
}

• Avoid filtering on multiline textfields
• Avoid filtering on virtual fields
• Content hierarchy for GraphQL optimization: Implement a filter on the _path field of the top-level fragment to achieve this optimization.
• Enable GraphQL pre-caching and configure dispatcher/ CDN cache for persisted queries
• If Dynamic Media is enabled, employ web-optimized image delivery.

AEM Performance Optimization: Best Practices for Speed and Scalability

• Some facts:
  • 15-20ns (admin user)
  • 30-40ns (checks ACL etc, nested setup )
  • 1 ms
• Creating 1 JCRNodeResource :
• Accessing JCRResource takes a similar amount of time.
• Creating ResourceResolver

Building Robust AEM Integrations

In the current digital environment, the integration of third-party applications with Adobe Experience Manager (AEM) is pivotal for building resilient digital experiences. This blog serves as a guide, highlighting crucial elements to bear in mind when undertaking AEM integrations It is accompanied by practical examples from real-world AEM implementations, offering valuable insights. Without further ado, let’s dive in:

Generic API Framework for integrations

When it comes to integrating AEM with various APIs, having a structured approach can significantly enhance efficiency, consistency, and reliability. One powerful strategy for achieving these goals is to create a generic API framework. This framework serves as the backbone of your AEM integrations, offering a host of benefits, including reusability, consistency, streamlined maintenance, and scalability.

Why Create a Generic API Framework for AEM Integrations?

• Reusability: A core advantage of a generic API framework is its reusability. Rather than starting from scratch with each new integration, you can leverage the framework as a proven template. This approach saves development time and effort, promoting efficiency.
• Consistency: A standardized framework ensures that all your AEM integrations adhere to the same conventions and best practices. This consistency simplifies development, troubleshooting, and maintenance, making your AEM applications more robust and easier to manage.
• Maintenance and Updates: With a generic API framework in place, updates and improvements can be applied to the framework itself. This benefits all integrated services simultaneously, reducing the need to address issues individually across multiple integrations. This leads to more efficient maintenance and enhanced performance.
• Scalability: As your AEM application expands and demands more integrations, the generic framework can easily accommodate new services and endpoints. You won’t need to start from scratch or adapt to different integration methodologies each time you add a new component. The framework can seamlessly scale to meet your growing integration needs.

Key Components of an integration Framework:

1. Best Practices:

The framework should encompass industry best practices, ensuring that integrations are built to a high standard from the start. These best practices might include data validation, error handling, and performance optimization techniques.

2. Retry Mechanisms:

Introduce a mechanism for retries within the framework. It’s not uncommon for API calls to experience temporary failures due to network disruptions or service unavailability. The incorporation of automatic retry mechanisms can significantly bolster the reliability of your integrations. This can be accomplished by leveraging tools such as Sling Jobs.

For instance, consider an AEM project that integrates with a payment gateway. To address temporary network issues during payment transaction processing, you can implement a retry logic. If a payment encounters a failure, the system can automatically attempt the transaction multiple times before notifying the user of an error.

For guidance on implementing Sling Jobs with built-in retry mechanisms, please refer to the resource Enhancing Efficiency and Reliability by Sling jobs

3. Circuit Breaker Pattern:

The Circuit Breaker pattern is a design principle employed for managing network and service failures within distributed systems. In AEM, you can apply the Circuit Breaker pattern to enhance the robustness and stability of your applications when interfacing with external services.

It caters to several specific needs:

• Trigger a circuit interruption if the failure rate exceeds 10% within a minute.
• After the circuit breaks, the system should periodically verify the recovery of the external service API through a background process.
• Ensure that users are shielded from experiencing sluggish response times.
• Provide a user-friendly message in the event of any service disruptions.

Visit Latency and fault tolerance in Adobe AEM using HystriX for details

4. Security Measures:

Incorporate authentication and authorization features into your framework to ensure the security of your data. This may involve integration with identity providers, implementing API keys, setting up OAuth authentication, and utilizing the Cross-Origin Resource Sharing (CORS) mechanism.

For instance, when securing content fetched via GraphQL queries, consider token-based authentication. For further details, please refer to the resource titled  Securing content for GraphQL queries via Closed user groups (CUG)

5. Logging

Ensuring robust logging and effective error-handling mechanisms are fundamental for the purposes of debugging and monitoring. Implementing comprehensive logging is crucial for recording significant events and errors, making troubleshooting and maintenance more streamlined. To achieve this:

1. Comprehensive Monitoring and Logging: Implement thorough monitoring and logging for your integration to detect issues, track performance, and simplify debugging. It is advisable to categorize logging into three logical sets.
   • AEM Logging: This pertains to logging at the AEM application level.
   • Apache HTTPD Web Server/Dispatcher Logging: This encompasses logging related to the web server and Dispatcher on the Publish tier.
   • CDN Logging: This feature, although gradually introduced, handles logging at the CDN level.
2. Selective Logging: Log only essential information in a format that is easy to comprehend. Properly employ log levels to prevent overloading the system with errors and warnings in a production environment. When detailed logs are necessary, ensure the ability to enable lower log levels like ‘debug’ and subsequently disable them.

Utilize AEM’s built-in logging capabilities to log API requests, responses, and errors. Consider incorporating Splunk, a versatile platform for log and data analysis, to centralize log management, enable real-time monitoring, conduct advanced search and analysis, visualize data, and correlate events. Splunk’s scalability, integration capabilities, customization options, and active user community make it an invaluable tool for streamlining log management, gaining insights, and enhancing security, particularly in the context of operations and compliance.

6. Payload Flexibility:

Payload flexibility in the context of building a framework for integrations refers to the framework’s capacity to effectively manage varying types and structures of data payloads. A data payload comprises the factual information or content transmitted between systems, and it may exhibit notable differences in format and arrangement.

These distinctions in structure can be illustrated with two JSON examples sourced from the same data source but intended for different end systems:

Example 1: JSON Payload for System A

Example 2: JSON Payload for System B

Both examples originate from the same data source but require distinct sets of information for different target systems. Payload flexibility allows the framework to adapt seamlessly, enabling efficient integration with various endpoints that necessitate dissimilar data structures.

7. Data Validation and Transformation:

When integrating with a third-party app in Adobe Experience Manager (AEM), it’s crucial to ensure that data validation and transformation are performed correctly. This process helps maintain data integrity and prevents errors when sending or receiving data. Let’s consider an example where we are integrating with an e-commerce platform. We’ll validate and transform product data to ensure it aligns with the expected format and data types of the platform’s API, thus mitigating data-related issues.

• We’ve outlined the importance of data validation and transformation when dealing with a third-party e-commerce platform in AEM.
• The code demonstrates how to parse, validate, and transform the product data from the platform.
• It includes more complex validation, such as checking for required fields
• Additionally, it features data transformation methods like sanitizing product descriptions and selecting the main product image.

8. Client Call Improvements:

In the context of availability and performance concerns, a common challenge lies in the customer code’s interaction with third-party systems via HTTP connectivity. This challenge takes on paramount importance when these interactions are carried out synchronously within an AEM request. The direct consequence of any backend call’s latency is the immediate impact on AEM’s response time, with the potential to lead to service outages (for AEMaaCS) if these blocking outgoing requests consume the entire thread pool dedicated to handling incoming requests.

• Reuse the HttpClient: Create a single HttpClient instance, closing it properly, to prevent connection issues and reduce latency.
• Set Short Timeouts: Implement aggressive connection and read timeouts to optimize performance and prevent Jetty thread pool exhaustion.
• Implement a Degraded Mode: Prepare your AEM application to gracefully handle slow or unresponsive backends, preventing application downtime and ensuring a smooth user experience.

 For details on improving the HTTP Client requests. Refer to: 3 rules how to use an HttpClient in AEM

9. Asynchronous Processing:

In the context of AEM projects, synchronous interactions with third-party services can lead to performance bottlenecks and delays for users. By implementing asynchronous processing, tasks like retrieving product information occur in the background without affecting the AEM server’s responsiveness. Users experience quicker responses while the heavy lifting takes place behind the scenes, ensuring a seamless user experience. Sling Jobs provide a reliable mechanism for executing tasks, even in the face of backend hiccups, preventing service outages. For details on how to implement Sling Jobs, refer to resource Enhancing Efficiency and Reliability by Sling jobs

10. Avoid Long-Running Sessions in AEM Repository

During integrations such as Translation imports, encountering Caused by: javax.jcr.InvalidItemStateException: OakState0001 is a common issue in the AEM repository. This problem arises due to long-running sessions and their interference with concurrent changes happening within the repository (like translation imports). When a session’s save() operation fails, temporary heap memory, where pending changes are stored, remains polluted, leading to subsequent failures. To mitigate this problem, two strategies can be employed:

1. Avoiding long-running sessions by using shorter-lived sessions, which is the preferable and easier approach in most cases. It also eliminates issues related to shared sessions.

2. Adding code to call session.refresh(true) before making changes. This action refreshes the session state to the HEAD state, reducing the likelihood of exceptions. If a RepositoryException occurs, explicitly clean the transient space using session.refresh(false), resulting in the loss of changes but ensuring the success of subsequent session.save() operations. This approach is suitable when creating new sessions is not feasible.”

11. Error Handling and Notifications:

Implement error-handling mechanisms, including sending notifications to relevant stakeholders when critical errors occur. Example: If integration with a payment gateway fails, notify the finance team immediately to address payment processing issues promptly.

12. Plan for Scalability

Scaling your AEM deployment and conducting performance tests are vital steps to ensure your application can handle increased loads and provide a seamless user experience. Here’s a structured plan:

1. Define Expectations:
   • Identify the expected user base growth and usage patterns.
   • Set clear performance objectives, such as response times, throughput, and resource utilization.
   • Determine the scalability needs and expected traffic spikes.
2. Assess Current Architecture:
   • Examine your current AEM architecture, including hardware, software, and configurations. Estimate resource requirements (CPU, memory, storage) based on expected loads and traffic.
   • Identify potential bottlenecks and areas for improvement.
3. Capacity planning: Consider vertical scaling (upgrading hardware) and horizontal scaling (adding more instances) options.
4. Performance Testing:
   • Create test scenarios that simulate real-world user interactions.
   • Use load testing tools to assess how the system performs under different loads.
   • Test for scalability by gradually increasing the number of concurrent users or transactions.
   • Monitor performance metrics (response times, error rates, resource utilization) during tests.
5. Optimization:
   • Fine-tune configurations, caches, and application code.
   • Re-run tests to validate improvements.
6. Monitoring and Alerts:
   • Implement real-time monitoring tools and define key performance indicators (KPIs).
   • Set up alerts for abnormal behavior or performance degradation.

Adobe New Relic One Monitoring Suite:

13: Disaster Recovery:

Develop a disaster recovery plan to ensure high availability and data integrity in case of failures.

14. Testing Strategies:

Testing strategies play a critical role in ensuring the robustness and reliability of your applications. Here’s an explanation of various testing strategies specific to AEM:

1. Integration Tests focus on examining the interactions between your AEM instance and external systems, such as databases, APIs, or third-party services. The goal is to validate that data is flowing correctly between these systems and that responses are handled as expected.
   • Example:You might use integration tests to verify that AEM can successfully connect to an external e-commerce platform, retrieve product information, and display it on your website.
   • Resource: For more information on conducting integration tests in AEM, you can refer to this resource
2. Unit Tests are focused on testing individual components or functions within your AEM integration. These tests verify the correctness of specific code units, ensuring that they behave as intended.
   • Example: You could use unit tests to validate the functionality of custom AEM services or servlets developed for your integration.
3. Performance Testing evaluates the ability of your AEM application to handle various loads and traffic levels. It helps in identifying potential performance bottlenecks, ensuring that the application remains responsive and performs well under expected and unexpected loads.
4. Penetration testing assesses the security of your AEM system by simulating potential attacks from malicious actors. This testing identifies vulnerabilities and weaknesses in the AEM deployment that could be exploited by hackers.

15. Testing and Staging Environments:

Create separate development and staging environments to thoroughly test and validate your integration before deploying it to production. Example: Before integrating AEM with a new e-commerce platform, set up a staging environment to simulate real-world scenarios and uncover any issues or conflicts with your current setup.

16. Versioning and Documentation:

Maintain documentation of the third-party API integration, including version numbers and update procedures, to accommodate changes or updates

AEM as a Cloud Service Migration Journey 

• The Cloud Readiness Analyzer is an essential initial step before migrating to AEMaaCS. It evaluates various aspects of the existing AEM setup to identify potential obstacles and areas requiring modification or refactoring.
• This comprehensive analysis encompasses the codebase, configurations, integrations, and customizations.
• Its primary goal is to pinpoint components that might not be compatible or optimized for the cloud-native architecture.
• Areas requiring refactoring might include restructuring code to align with cloud-native principles, adjusting configurations for optimal performance, ensuring compatibility with AEMaaCS architecture, and reviewing customizations to adhere to best practices for cloud-based deployment models.
• This assessment aims to enhance scalability, security, and performance by addressing potential obstacles before initiating the migration process.

• The Cloud Manager code quality pipeline is a crucial mechanism to assess the existing AEM source code against the modifications and deprecated features in AEMaaCS.
• This pipeline integrates into the development workflow using Adobe's Cloud Manager, analyzing the codebase for compatibility, adherence to coding standards, identification of deprecated functionalities, and detection of potential issues that might impede a successful migration.
• Developers gain insights into areas of the code that require modifications or updates to comply with AEMaaCS standards.
• It enhances code quality, ensures compatibility with the cloud-native environment, and facilitates a smoother transition during the migration process.
• This code quality pipeline provides continuous checks and feedback loops within development environments, empowering teams to address issues early in the development lifecycle.

Anmol Bhardwaj

Tools for Streamlining Development and Maintenance

In the dynamic landscape of AEM, where constant upgrades and migrations are the norm, the need for specialized tools to streamline development and ensure optimal performance is undeniable. AEM experts have crafted a set of powerful tools to address common challenges faced by developers and administrators. These tools not only enhance efficiency but also contribute to the overall robustness and security of AEM instances.

Let's delve into some of these fabulous tools that have been developed by AEM experts:

1. AEM Component and Template Usage Metrics

Amidst upgrades or migrations, accurately assessing the usage of components and templates across web pages proves to be a common challenge. The lack of an efficient process for discerning component and template usage can lead to disorganized project structures, impeding effective maintenance.

Enter the Solution:

Kiran Sg introduces a purpose-built tool designed to identify components and templates actively referenced or utilized on web pages during these transitions. This tool conducts a comprehensive analysis of component usage, aiding in the prioritization of component upgrades. Depending on the usage data, strategic decisions can be made, such as removing unused components, merging component versions, or updating to new versions, streamlining space and reducing maintenance efforts.

2. Dispatcher Optimizer Tool (DOT)

Enhance the cache hit ratio for your public-facing site, minimize the influence of unexpected or malicious requests, and mitigate the impact of activations on cached content. Achieving these objectives is made easier with the Dispatcher Optimizer Tool, abbreviated as DOT.

The DOT is available in two forms:

• A Maven plugin for static configuration analysis during development
• A code quality step in the Adobe Managed Services (AMS) Cloud Manager pipeline

A report from maven plugin would look like this:

For more info, please refer to link

3. Content Sync Tool for incremental sync across AEM Instances

Effortlessly synchronize AEM Author instances, ensuring seamless updates for pages, assets, experience fragments, content fragments, tags, and /conf/* data. Enjoy compatibility with AEM CS, preservation of binary data, version history, and node ordering, all while benefiting from incremental updates based on jcr:lastModified/cq:lastModified. Simplify your content management across instances with ACS AEM Common's Content Sync Tool

4. SecureAEM Tool

Secure AEM is a tool designed to identify prevalent security issues in your AEM instance. It conducts tests on both the author and publish instances, as well as the dispatcher, considering that certain resources should be restricted in the cache configuration. The tool assesses various aspects, including:

- Verification of changes to default passwords

- Evaluation of enabled protocols post-publishing to ensure no unnecessary ones are active

- Confirmation of the administrator console access being disabled

- Restriction of content-grabbing selectors on the dispatcher, among other checks

Each test comes with a description and a 'More Info' link, providing a reference to an external site for additional information about a specific security vulnerability.

Thanks