Javadoubts

AEM as a cloud service

As we are aware, Adobe now supports AEM as a Cloud Service, which signifies a cloud-native approach to leveraging AEM applications. This blog will undoubtedly provide us the clear and crisp understanding on AEM as a Cloud Service.

This blog will help all of us understand the following things in detail:

• Changes around code development, deployment, and dispatcher
• High Level advantages
• What got changed or require to update while migrating from AEM On-Prem to AEM as a Cloud Service
• Project code structure/hierarchy
• Step to setup AEM as a Cloud Service and dispatcher in local
• Create AEM as a Cloud Service project using maven archetype
• Deploy code using Adobe Cloud Manager

As part of this tutorial, I aim to debunk several major myths surrounding the changes that come with AEM as a cloud service.

There are three major changes in terms of code development, deployment, and dispatcher for AEM as a Cloud Service:

1. AEM Instance: There is a minor change in selecting the Quickstart Jar file to create a brand new AEM as a Cloud Service environment. Please refer to this link for detailed instructions.
2. Dispatcher: Previously, we used Apache to set up the dispatcher. Now, Adobe provides an SDK to create a dispatcher locally. Moreover, the same AEM as a Cloud Service Dispatcher SDK can be used to validate Dispatcher configurations locally. For more information, follow the link provided.
3. Deployment: Previously, developers used to consume code repositories such as GitHub, GitLab, BitBucket, and others available in the market to maintain code. Earlier code deployment could be done manually even though manual code deployment was never considered a best practice or also with the help of one of the CI/CD pipelines (e.g., Jenkins, Bamboo) available in the market. However, Adobe has now introduced Cloud Manager to maintain and deploy code to AEM environments. This enforces the practice of deploying code exclusively through Cloud Manager CI/CD pipelines only. Cloud Manager also allow us to check code in terms of quality and security.

High-Level Advantages

Below, we outline the major high-level advantages of using AEM as a Cloud Service:

1. CI/CD framework for deploying code, autoscaling, API connectivity, code quality gates, service delivery transparency, built-in Content Delivery Network (CDN), and adherence to network-layer best practices.
2. Mitigation of security risks through automated tests that scan for common vulnerabilities.
3. Utilization of tools that accelerate the migration tasks, such as code refactoring, content transfer, and more.

What got changed or require to update while migrating from AEM On-Prem to AEM as a Cloud Service ???

1. Editing of static template design information stored in /apps can no longer be done via the UI. Instead, it must now come from Git via the CI/CD pipeline.
2. Certain functionalities like MSM Blueprint, custom MSM roll-out configurations, I18n translation, new or updated OSGi bundles, changes to OSGi configurations, folders, templates, workflows, Search index definitions, ACLs and permissions, Service users and user groups must all be managed through Git via the CI/CD pipeline.
3. Direct changes to the publish environment are not permitted. Content must be published from the author environment.
4. Custom runmodes (e.g., author, publish, dev, stage, prod, author.dev, publish.dev, author.stage, publish.stage, author.prod, publish.prod) are not allowed in AEM as a Cloud Service, as these are provided out-of-the-box.
5. Class UI is no longer supported in AEM as a Cloud Service.
6. HTTP acceleration, including Content Delivery Network (CDN) and traffic management for author and publish services, is provided by default in AEM Cloud Service. Adobe strongly recommends leveraging the built-in CDN since AEM Cloud Service features are optimized for it.
7. The Cloud Manager provides access to log files from various nodes in both the author and publish environments. These log files can be accessed either as downloadable files or through APIs.
8. In the on-Prem environment, administrators used to create user accounts for team members, such as developers, QA, and functional roles. However, in AEM as a Cloud Service, access can be granted by providing Adobe IDs to team members, enabling them to access the author environment through the Adobe Admin Console, which facilitates user and group management. The user accounts enable your users to access Adobe products and services, as user-profile information is centralized in the Adobe Identity Management System (IMS) to be shared across all cloud services.
9. Code executed as background tasks must assume that the instance it is running on can be brought down at any time. To minimize potential issues, it is advisable to avoid long-running jobs if possible. Instead, try to utilize Sling Jobs, which provide an “at-least-once” execution guarantee. In case of interruptions, Sling Jobs will be re-executed as soon as possible to ensure successful completion.
10. Request rate limits: When the rate of incoming requests to AEM exceeds healthy levels, AEM responds to new requests with HTTP error code 429. However, before mid-August 2023, AEM used to respond to the same condition with HTTP error code 503.
11. AEM Forms: AEM Forms as a Cloud Service provides a hardened Rule editor. The code editor is not available on Forms as a Cloud Service. Create a custom client library to consume custom JavaScript and provide a category as part of form shown below:

12. Due to the inaccessible nature of immutable content at runtime, certain AEM Sites operations are not available, including:

• i18n dictionary translation
• Developer Mode in AEM Sites Page Editor.

13. Discover the WKND reference site, the latest addition to AEM, designed to exemplify best practices for building websites with AEM. Get started with WKND by following the link and accessing the GIT repository to learn and implement AEM as a Cloud Service best practices.

14. Smart translation is not supported in Experience Manager as a Cloud Service.

15. The rating widget in the metadata schema editor is not supported.

16. Multi tenancy: Managing multiple projects as part of a single repository is a pain and at the same time it require full control over the repo and deployment process. However, it becomes easier to maintain common reusable code/config in one place, preventing the accidental override of other code/config.

17. The Replication Agent has been discontinued

In AEM Cloud Service. Instead, content is now published using Sling Content Distribution. Replication will use pub-sub mechanism to publish content from author to publish.

Reverse replication is not supported as part of cloud service.

This change may have implications for certain aspects of existing AEM projects:

1. Custom workflows that utilized replication agents to push content to preview servers may require adjustments.
2. Any customizations made to replication agents for content transformation may need to be reevaluated.
3. Reverse Replication, which brought content from publish back to author, is no longer available.

Furthermore, please be aware that the replication agent administration console no longer includes the pause and disable buttons.

CSRF Token

CSRF Tokens are require to make a POST, PUT, and Delete requests to AEM for authenticated users. The same CSRF token is not required for GET requests or for anonymous requests.

/**
 * Get CSRF token from AEM.
 * CSRF token expire after a few minutes, so it is best to get the token before each request.
 *
 * @returns {Promise<string>} that resolves to the CSRF token.
 */
async function getCsrfToken() {
    const response = await fetch('/libs/granite/csrf/token.json');
    const json = await response.json();
    return json.token;
}

// Fetch from AEM with CSRF token in a header named 'CSRF-Token'.
await fetch('/path/to/aem/endpoint', {
    method: 'POST',
    headers: {
        'CSRF-Token': await getCsrfToken()
    },
});

For make it work on dispatcher, it will also require to add/update below lines in dispatcher.any configuration file

dispatcher/src/conf.dispatcher.d/filters/filters.any/0120 { /type “allow” /method “GET” /url “/libs/granite/csrf/token.json” }

Project Code Structure/hierarchy

Follow below project structure/hierarchy for mutable and immutable content to place code depending on module.

All content and sub-folders within /apps and /libs are immutable and now set to read-only. Any attempts to modify this content will fail, resulting in an error indicating that the content is read-only and the write operation cannot be completed.

Everything else in the repository, /content, /conf, /var, /etc, /oak:index, /system, /tmp, and so on, are all mutable areas, meaning they can be changed at runtime.

On-premise versions of AEM did not enforce read-only restrictions in /libs, but in AEM Cloud Service, changes in /libs are completely disallowed. However, /libs overlay within /apps is still permitted through the GIT CI/CD pipeline.

Code Packages / OSGI Bundles

Deployable artifacts such as OSGI bundle jar type file directly gets embed in all project

• all content package embeds the following packages, to create a singular deployment artifact
• core OSGi bundle Jar required by the AEM application
• ui.apps deploys code required by the AEM application
• ui.config deploys OSGi configurations required by the AEM application
• ui.content deploys content and configuration required by the AEM application
• vendor-x.all deploys the everything (code and content) required by the vendor X application
• vendor-y.all deploys the everything (code and content) required by the vendor Y application

ui.apps package contains changes made update /apps hierarchy.

ui.core OSGi bundle Jar required by the AEM application

ui.content package contains changes made under below hierarchy:

• /content
• /conf
• /etc

ui.config package contains OSGI configurations and below changes made under below hierarchy:

/apps/practice/osgiconfig

/apps/practice/osgiconfig/config -> Common OSGI configuration to all AEM environments.

/apps/practice/osgiconfig/config.<author|publish>.<dev|stage|prod> -> Environment specific configurations.

Repo Init scripts themselves live in the ui.config project as scripts, they can, and should, be used to define the following mutable structures:

• Baseline content structures
• Service Users
• Users
• Groups
• ACLs

Repo Init scripts which contain the Repo Init scripts are defined in the RepositoryInitializer OSGi factory configuration via the scripts property. Because these scripts defined within OSGi configurations, they can be easily scoped by run mode using the usual ../config.<runmode> folder semantics.

Because scripts are typically multi-line declaration, it is easier to define them in the .config file, than the JSON-based .cfg.json format.

/apps/my-app/config.author/org.apache.sling.jcr.repoinit.RepositoryInitializer-author.config

scripts=["
    create service user my-data-reader-service

    set ACL on /var/my-data
        allow jcr:read for my-data-reader-service
    end
    create path (sling:Folder) /conf/my-app/settings
"]

Step to Setup AEM as a Cloud Service and dispatcher in local

Follow link to create AEM as a Cloud Service project using maven archetype.

Additionally, the AEM as a Cloud Service Dispatcher SDK can be used to validate Dispatcher configurations locally. Follow link for more information.

Code Deployment using Adobe Cloud Manager

Cloud Manager all us to manage all the AEM as a cloud service environments and the same time provide us the capability to deploy code. It is a pre-requisite to have an access of cloud manager to deploy code on the environments.

We can access Cloud Manager using link and credentials as our personal Adobe ID.

Follow below steps once we are good with pre-requisites.

1. access Cloud Manager using link and select below highlighted program.

2. Click on below Access Repo Info button to get Git command line URL to checkout code using username and password.

3. Click on Generate password button for generating password to clone code in local using Git command line URL.

4. Open command line, paste Git command line and click on enter as shown below. It will ask for required user name and password we got as part of step 3.

5. import code in to the intellij and make all required changes. Push code once done with the changes using below sub sequent basic GIT commands:

git add .

git commit -m “provide commit description”

git push

6. Go back to adobe cloud manager and select the same program what we selected in first step.

7. Select below highlighted option in green for Non- Production pipeline to deploy changes on DEV.

Click on the three dots/ellipses and select run option to trigger build on DEV will help us to deploy code.