Notable Changes to Adobe Experience Manager as a Cloud Service

AEM as a Cloud service - Whats different

There are notable differences between AEM Sites on premise or in Adobe Managed Service as compared to AEM Cloud Service.

1. /apps and /libs are immutable at runtime
• No changes in /libs are allowed at all.
• Overlays for areas in /libs that can be overlaid are still permitted within /apps.
• Static Template design information that is stored in /apps can’t be edited by way of the UI.
• MSM Blueprint and custom MSM roll-out configurations must be installed from Git by way of the CI/CD pipeline.
• I18n translation changes must come from Git by way of the CI/CD pipeline.
2. OSGi bundles and configurations must be treated as code
• New or updated OSGi bundles must be introduced through Git by way of the CI/CD pipeline.
• Changes to OSGi configurations can only come from Git by way of the CI/CD pipeline.
3. Changes to the publish repository are not allowed
   Aside from changes under the /home folder on the publish tier, direct changes to the publish repository are not allowed on AEM Cloud Service. In prior versions of on-premise AEM or AEM on AMS, code changes could be made directly to the publish repository. Some limitations can be mitigated in the following ways:
• For content and content-based configuration: make your changes on the Author instance and publish them.
• For code and configuration: make your changes in the GIT repository and run the CI/CD pipeline to roll them out.
4. Custom run modes are not allowed
   AEM as a Cloud Service does not allow using run modes to install content for specific environments or services. If a development environment must be seeded with data or HTML that is not in the staging or production environments, Package Manager can be used.
   The supported run mode configurations are:
• config (The default, applies to all AEM services)
• config.author (Applies to all AEM Author service)
• config.author.dev (Applies to AEM Dev Author service)
• config.author.rde (Applies to AEM RDE Author service)
• config.author.stage (Applies to AEM Staging Author service)
• config.author.prod (Applies to AEM Production Author service)
• config.publish (Applies to AEM Publish service)
• config.publish.dev (Applies to AEM Dev Publish service)
• config.publish.rde (Applies to AEM RDE Publish service)
• config.publish.stage (Applies to AEM Staging Publish service)
• config.publish.prod (Applies to AEM Production Publish service)
• config.dev (Applies to AEM Dev services)
• config.rde (Applies to RDE services)
• config.stage (Applies to AEM Staging services)
• config.prod (Applies to AEM Production services)
5. Removal of Replication Agents and related changes
   In AEM Cloud Service, content is published using Sling Content Distribution. The replication agents used in previous versions of AEM are no longer used or provided, which might impact the following areas of existing AEM Projects:
   
• Custom workflows that push content to replication agents of preview servers for example.
• Customization to replication agents to transform content.
• Using Reverse Replication to bring content from Publish back to Author.
  In addition, the pause and disable buttons are removed from the replication agent administration console.
6. Removal of Classic UI
7. Publish-Side Delivery
   HTTP acceleration including CDN and traffic management for Author and Publish services are provided by default in AEM Cloud Service.
   For projects transitioning from AMS or an on-premises installation, Adobe strongly recommends using the built-in CDN, because features within AEM Cloud Service are optimized for the CDN provided.
8. Asset Handling and Delivery
   Asset upload, processing, and download are optimized in Experience Manager Assets as a Cloud Service. AEM Assets is now more efficient, enables more scaling, and lets you upload and download at a faster rate. Also, it impacts the existing custom code and some operations. For a list of changes and for parity with Experience Manager 6.5 features, see the changes to Assets.

 

Miscellaneous AEM concepts

What is the difference between jcr:primaryType and jcr:mixinTypes?

A Node can have only one jcr:primaryType but it can have several jcr:mixinTypes, so it is correct to see the mixins as "traits" or additional aspects of a node.

Both properties jcr:primaryType and jcr:mixinTypes are defined in the super node nt:base then inherited by all other nodes.

The jcr:primaryType property specifies the base type of a node and will be assigned at node's creation time and you can think of it as the BASE class of an object in OO world.

1. mix:versionable:
   Usage: Enables versioning capabilities for nodes, allowing multiple versions of a node to be stored in the repository.
   This mixin adds properties and methods related to versioning, such as jcr:isCheckedOut and jcr:predecessors.
2. mix:lockable:
   Usage: Allows nodes to be locked, preventing other users from modifying them.
   This mixin adds properties and methods related to locking, such as jcr:lockOwner and jcr:lockIsDeep.
3. mix:referenceable:
   Usage: Assigns a stable identifier (UUID) to nodes, which can be used to reference them reliably across the repository.
   This mixin adds the jcr:uuid property to nodes.
4. mix:created:
   Usage: Adds properties to track the creation time and user of a node.
   This mixin typically includes properties like jcr:createdBy and jcr:created.
5. mix:lastModified:
   Usage: Adds properties to track the last modification time and user of a node.
   This mixin typically includes properties like jcr:lastModifiedBy and jcr:lastModified.
6. mix:etag:
   Usage: Adds an entity tag (ETag) to nodes, which can be used for cache validation and concurrency control.
   This mixin typically includes properties like mix:etag.
7. mix:language:
   Usage: Indicates that a node represents content in a specific language.
   This mixin typically includes properties like jcr:language.
8. mix:versionHistory:
   Usage: Represents the version history of a versionable node.
   This mixin typically includes properties like jcr:versionHistory and jcr:baseVersion.
9. mix:shareable:
   Usage: Allows nodes to be shared across multiple locations in the repository, enabling the creation of content references.
   This mixin ensures that modifications made to a shared node are reflected across all its references.
10. mix:lockable:
    Usage: Adds locking functionality to nodes, enabling users to lock nodes to prevent concurrent modifications.

What is JCR, JSR, Jackrabbit, Oak and CRX?

JCR : Java Content Repository, a type of repository that provides an interface for Java applications to interact with content repositories. JCR is a specification for a Java platform application programming interface (API) to access content repositories in a uniform manner.

• JCR is a Java technology specification (JSR-283) that defines an API for accessing and manipulating structured content.
• It provides a standard way to interact with content repositories, enabling applications to store, query, and retrieve content in a platform-independent manner.
• JCR implementations typically use hierarchical data structures, similar to file systems, for organizing content.

JSR : Java Specification Request, a formal document that describe proposed technologies and specifications for adding to the Java platform. JCR is based on the principles mentioned in JSR.

• JSR is the process by which specifications for new features or enhancements to Java technologies are developed.
• A JSR is a formal document that outlines the proposed changes and requirements for the technology.
• JCR, as mentioned above, is one example of a JSR.

JCR 283 is the standard that specifies a vendor-independent and implementation-independent way to access content bi-directionally on a granular level within a content repository.

Jackrabbit : Apache Jackrabbit is an example of JCR, an open-source implementation of the JCR standard. It's a software program that provides a content repository according to the JCR specifications. So, it acts like a library that developers can use to store and manage content in their Java applications using the JCR standard.

• Jackrabbit is an open-source implementation of the JCR specification.
• It is developed as part of the Apache Software Foundation's Jakarta project.
• Jackrabbit provides a robust and scalable content repository for Java applications, supporting features such as versioning, transactions, and access control.

CRX : Content Repository Xtreme (CRX), which is Adobe's implementation of the JSR-283. CRX provides additional features such as development tools, clustering capabilities, and has its own storage mechanism. 

• CRX is Adobe's proprietary implementation of the JCR specification.
• It is built on top of Apache Jackrabbit and provides additional features and capabilities tailored for Adobe Experience Manager (AEM) deployments.
• CRX includes features such as replication, clustering, and integration with other Adobe marketing technologies.
• While CRX is specific to Adobe's ecosystem, it is based on the JCR standard and shares many concepts and APIs with other JCR implementations.

Oak : Apache Jackrabbit Oak is a newer and more modern implementation of the JCR standard. It's considered a rewrite of Jackrabbit, with a focus on scalability and performance. It builds upon Jackrabbit but offers a more efficient architecture for handling large volumes of content.

• Oak is a modern, scalable, and performant implementation of the JCR specification.
• It is designed to be the next-generation content repository for Apache Jackrabbit, replacing the older MicroKernel-based architecture with a new, more efficient implementation.
• Oak is optimized for cloud-native environments and supports various deployment scenarios, including traditional data centers, cloud hosting, and hybrid setups.

How are Oak and CRX related in AEM's context?

Oak serves as the underlying content repository technology for AEM, while CRX is Adobe's customized implementation of JCR, built on top of Oak to provide additional features and optimizations specific to AEM's requirements. Together, they form the foundation of the content repository in Adobe Experience Manager.

• Oak forms the foundational layer upon which CRX is built.
• CRX utilizes the capabilities provided by Oak for storing and managing content within AEM.
• While Oak handles the core repository functionalities, CRX adds higher-level features and services that are specific to AEM's use cases.
• Essentially, CRX extends and customizes the capabilities of Oak to provide a comprehensive content repository solution tailored for Adobe Experience Manager.

Java APIs in AEM

Java™ API Best Practices

Adobe Experience Manager (AEM) is built on a rich open-source software stack that exposes many Java™ APIs for use during development. This article explores the major APIs and when and why they should be used.

AEM is built on four primary Java™ API sets.

• Adobe Experience Manager (AEM)

  • Product abstractions such as pages, assets, workflows, etc.

• Apache Sling Web Framework

  • REST and resource-based abstractions such as resources, value maps, and HTTP requests.

• JCR (Apache Jackrabbit Oak)

  • Data and content abstractions such as node, properties, and sessions.

• OSGi (Apache Felix)

• OSGi application container abstractions such as services and (OSGi) components.

The general rule is to prefer the APIs/abstractions the following order:

1. AEM
2. Sling
3. JCR
4. OSGi

AEM APIs

AEM APIs provide abstractions and functionality specific to productized use cases.

For example, AEM’s PageManager and Page APIs provide abstractions for cq:Page nodes in AEM that represent web pages.

While these nodes are available via Sling APIs as Resources, and JCR APIs as Nodes, AEM’s APIs provide abstractions for common use cases. Using the AEM APIs ensures consistent behavior between AEM the product, and customizations and extensions to AEM.

1. com.adobe.cq - supports product use cases
2. com.adobe.granite - cross-product platform use-cases, such as workflow or tasks (which are used across products: AEM Assets, Sites, and so on)
3. com.day.cq - contains “original” APIs. These APIs address core abstractions and functionalities that existed before and/or around Adobe’s acquisition of Day CQ.

Query APIs

AEM supports multiple query languages. The three main languages are 

JCR-SQL2, 

XPath, and 

AEM Query Builder.

Sling APIs

Apache Sling is the RESTful web framework that underpins AEM. Sling provides HTTP request routing, models JCR nodes as resources, provides security context, and much more.

• Accessing JCR nodes as Sling Resources and accessing their data via ValueMaps.

• Providing security context via the ResourceResolver.

• Creating and removing resources via ResourceResolver’s create/move/copy/delete methods.

• Updating properties via the ModifiableValueMap.

• Building request processing building blocks

• Servlets
• Servlet Filters

• Asynchronous work processing building blocks

  • Event and Job Handlers
  • Scheduler
  • Sling Models

• Service users

JCR APIs

The JCR (Java™ Content Repository) 2.0 APIs is part of a specification for JCR implementations (in the case of AEM, Apache Jackrabbit Oak). All JCR implementation must conform to and implement these APIs, and thus, is the lowest level API for interacting with AEM’s content.

Always prefer the JCR APIs over the Apache Jackrabbit Oak APIs. The JCR APIs are for interacting with a JCR repository, whereas the Oak APIs are for implementing a JCR repository.

Sling Dynamic Include in AEM

Sling Dynamic Include

 

Sling Dynamic Include is a feature provided by the Apache Sling framework, which is the underlying web framework of AEM. SDI allows for dynamic inclusion of content from external resources or other AEM pages within AEM pages at runtime.

Here's a brief explanation of Sling Dynamic Include and a comparison with other similar technologies:

Sling Dynamic Include (SDI):

·         Sling Dynamic Include allows you to include content fragments dynamically within AEM pages.

·         It enables the inclusion of content from different sources such as external URLs, other AEM pages, or even specific components.

·         SDI is often used for including dynamic content like advertisements, promotional banners, or content from external systems.

Server-Side Includes (SSI):

·         Server-Side Includes (SSI) are directives that are placed in HTML pages to instruct the server to include external files or execute scripts before serving the page to the client.

·         SSI is typically processed by the web server (e.g., Apache HTTP Server) before the page is sent to the client's browser.

·         While SSI and SDI serve similar purposes of including dynamic content, SDI is specific to AEM and integrates within its framework, whereas SSI is more commonly used in general web server configurations.

Server-Side Rendering (SSR):

·         Server-Side Rendering (SSR) involves generating the HTML for a web page on the server and sending the fully rendered page to the client's browser.

·         SSR is commonly used in traditional web applications to improve initial page load performance and SEO.

·         Unlike SSR, SDI doesn't render the entire page on the server side but allows for the inclusion of specific content dynamically.

 

Configuring SDI on AEM

1.       Download the Sling Dynamic Include bundle, search for “Dynamic Include” and download the Bundle.

2.       Install the bundle in the Apache Felix bundles console of AEM Publish instance.

3.       Configure Sling Dynamic Include via the OSGi Configuration Factory at http://<host>:<port>/system/console/configMgr/org.apache.sling.dynamicinclude.Configuration

4.       Once this configuration is enabled, you can load the page where the component is configured and if you inspect the source code, you can see the component div like this –

 In the above screenshot, the code part i.e. <!–#include virtual='</path/to/resource/component.nocache.html’ –> is the part where the actual code will be replaced once the dispatcher is enabled with Sling dynamic include settings.

 

Configuring SDI on Dispatcher

the minimal configuration necessary to use Sling Dynamic Include on Dispatcher are as follows,

1.       Enable mod_include in httpd.conf

LoadModule include_module libexec/apache2/mod_include.so

2.       Update the vhost file to respect include directives.

<VirtualHost *:80>

...

   <Directory /Library/WebServer/docroot/publish>

      ...

      # Add Includes to enable SSI Includes used by Sling Dynamic Include

      Options FollowSymLinks Includes

 

      # Required to have dispatcher-handler process includes

      ModMimeUsePathInfo On

 

      # Set includes to process .html files

      AddOutputFilter INCLUDES .html

      ...

   </Directory>

...

</VirtualHost>

3.       Update the dispatcher.any configuration file to support (1) nocache selectors and (2) enable TTL support.

/rules {

  ...

  /0009 {

    /glob "*.nocache.html*"

    /type "deny"

  }

}

 

/cache {

    ...

    /enableTTL "1"

}

 

 

Benefits of Sling Dynamic Include

·         Allows to serve highly dynamic content at the same time, allows to cache a fragment of the page using the “.html” extension

·         It can make your pages more modular and easier to maintain.

·         It can be used to include dynamic content that is generated by a script.

Limitations of Sling Dynamic Include

·         It can be complex to configure.

·         It can only be used with Sling-based applications.

·         It can introduce security vulnerabilities if not used properly.

 

Conclusion : Sling Dynamic Include is a powerful feature that can be used to improve the performance and maintainability of your Adobe Experience Manager pages.

Dispatcher : Rewrite Rules

 Rewrite Rules in Dispatcher

Rewrite Rules on Apache webserver using the module mod_rewrite.

- an Apache module for manipulating(rewriting) URLs.

- meaning, taking the requested URL from visitor and responding them with a different URL.

  e.g. visitor hits www.example.com/page.html, the mod_rewrite internally converts it to www.example.com/another_page.html and returns the HTML content back. However, in this process, the prowser URL stays the same as the visitor hit.

- Rewriting and redirecting are 2 different things. Above example was of rewriting.

What can mod_rewrite do?

- lets us create rules to handle the URL manipulation and make cosmetic changes on Apache server/Dispatcher.

e.g. insert values or rearrange strings or remove characters etc.

- let us check server variables e.g. user agent.

- beautify the ugly URLs

e.g. www.ex.com/hello/world to www.ex.com?x=hello&y=world

- stop other site to make use of the resources from our site. respond them with forbidden.

- redirecting to the canonical URLs

e.g. ex.com/hello/world to www.ex.com/hello/world

- avoiding the 404 errors on the page hits from visitor, in cases where we dont wish to change the URL of revamped site but return 200OK to visitor.

How to use the mod_rewrite on Apache server?

- enable the rewrite module in httpd.conf file using/adding below code

LoadModule rewrite_module modules/mod_rewrite.so

- add the below directive to httpd.conf file

<IfModule mod_rewrite.c>

 <VirtualHost *:80>

  ServerName localhost

  ServerAlias 127.0.0.1

  

  LimitRequestFieldSize 32768

  

  AllowEncodedSlashes NoDecode

  RewriteEngine On

  RewriteCond %{REQUEST_URI} !^/apps

  RewriteCond %{REQUEST_URI} !^/bin

  RewriteCond %{REQUEST_URI} !^/content

  RewriteCond %{REQUEST_URI} !^/etc

  RewriteCond %{REQUEST_URI} !^/home

  RewriteCond %{REQUEST_URI} !^/libs

  RewriteCond %{REQUEST_URI} !^/saml_login

  RewriteCond %{REQUEST_URI} !^/system

  RewriteCond %{REQUEST_URI} !^/tmp

  RewriteCond %{REQUEST_URI} !^/var

  RewriteCond %{REQUEST_URI} (.html|.jpe?g|.png|.svg|.gif|.GIF)$

 </VirtualHost>

</IfModule>

How Rewrite rules works?

- on enabling the mod_rewrite module, we can make use of the RewriteRule directive to create a rewrite rule.

The general syntax of the directive is :

RewriteRule Pattern Substitution [optional flags]

Pattern : a regular expression if match with the incoming URL, respective rule is processed.

Substitution : this is the new processed URL to use instead of the incoming matcher one.

[Optional Flags] : one or more flags to alter the behaviour of the rule.

Practical Uses of Rewrite Rules

mod_rewrite is a powerful Apache module that provides a way to rewrite URLs on-the-fly. Here are some practical and real-world examples of how mod_rewrite can be used:

Redirecting URLs: Redirect users from an old URL structure to a new one.

RewriteEngine On

RewriteRule ^old-page\.html$ /new-page.html [R=301,L]

Removing File Extensions: Serve URLs without the .html or .php extension.

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_FILENAME}\.html -f

RewriteRule ^(.*)$ $1.html [L]

Force HTTPS: Redirect all HTTP traffic to HTTPS.

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

User-Friendly URLs: Convert dynamic URLs to more readable and SEO-friendly URLs.

RewriteEngine On

RewriteRule ^products/([a-zA-Z0-9_-]+)$ product.php?name=$1

URL Parameters: Modify or reorder URL parameters.

RewriteEngine On

RewriteCond %{QUERY_STRING} ^id=([0-9]+)$

RewriteRule ^product\.php$ /product/%1? [R=301,L]

Blocking Access: Deny access to specific files or directories.

RewriteEngine On

RewriteRule ^private-directory/.*$ - [F]

Custom Error Pages: Redirect users to a custom error page for 404 errors.

ErrorDocument 404 /404.html

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)$ /404.html [L]

Mobile Redirection: Redirect mobile users to a mobile-friendly version of the site.

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} "android|blackberry|ipad|iphone|ipod|iemobile|opera mobile|palmos|webos|googlebot-mobile" [NC]

RewriteRule ^(.*)$ https://m.example.com/$1 [L,R=302]

ACS common and Core Components Build and Deployment along with the code.

 Integrate the WCM core components with AEM codebase

Core Components Integration

1. update all/pom.xml

a. Add below dependencies

<dependency>

    <groupId>com.adobe.cq</groupId>

    <artifactId>core.wcm.components.content</artifactId>

    <type>zip</type>

</dependency>

<dependency>

    <groupId>com.adobe.cq</groupId>

    <artifactId>core.wcm.components.config</artifactId>

    <type>zip</type>

</dependency>

<dependency>

    <groupId>com.adobe.cq</groupId>

    <artifactId>core.wcm.components.all</artifactId>

    <type>zip</type>

</dependency>

b. Add subpackage as a sibling XML element to embeddeds

<subPackages>

    <subPackage>

        <groupId>com.adobe.cq</groupId>

        <artifactId>core.wcm.components.all</artifactId>

        <filter>true</filter>

    </subPackage>

</subPackages>

c. Add Embedds

<embedded>

    <groupId>com.adobe.cq</groupId>

    <artifactId>core.wcm.components.all</artifactId>

    <type>zip</type>

    <target>/apps/mysite-vendor-packages/application/install</target>

</embedded>

2. Update ui.apps/pom.xml

a. Add below dependency under dependencies section.

<dependency>

    <groupId>com.adobe.cq</groupId>

    <artifactId>core.wcm.components.all</artifactId>

    <type>zip</type>

</dependency>

b. Add below dependency under plugins section

<dependency>

    <groupId>com.adobe.cq</groupId>

    <artifactId>core.wcm.components.all</artifactId>

</dependency>

3. Parent pom.xml

a. Add below dependency under dependencyManagement/dependencies section.

<dependency>

  <groupId>com.adobe.cq</groupId>

  <artifactId>core.wcm.components.all</artifactId>

  <type>zip</type>

  <version>${core.wcm.components.version}</version>

  <scope>provided</scope>

</dependency>

b. Finally, mention the required version of the ACS commons under properties section

<core.wcm.components.version>2.17.12<core.wcm.components.version>

ACS Commons Integration

1. Update all/pom.xml

a. Add the embeddeds

<embedded>

    <groupId>com.adobe.acs</groupId>

    <artifactId>acs-aem-commons-all</artifactId>

    <type>zip</type>

    <target>/apps/my-app-vendor-packages/container/install</target>

    <filter>true</filter>

    <isAllVersionsFilter>true</isAllVersionsFilter>

</embedded>

b. Add dependency

<dependency>

    <groupId>com.adobe.acs</groupId>

    <artifactId>acs-aem-commons-all</artifactId>

    <version>6.5.0</version>

    <type>zip</type>

</dependency>

2. Update the core/pom.xml

a. Add into dependencies

<dependency>

    <groupId>com.adobe.acs</groupId>

    <artifactId>acs-aem-commons-bundle</artifactId>

    <version>6.5.0</version>

    <scope>provided</scope>

</dependency>