Building a Rapid Development Environment (RDE) in Adobe Experience Manager (AEM)

In today’s fast-paced digital world, speed and agility are essential. Developers need an environment where they can quickly experiment, test, and deploy without lengthy setup times. This is where a Rapid Development Environment (RDE) in Adobe Experience Manager (AEM) becomes invaluable.

---

What Is an RDE in AEM?

A Rapid Development Environment (RDE) is a cloud-based instance of AEM designed for rapid feature development, testing, and validation. It is a key part of AEM as a Cloud Service (AEMaaCS) and provides a lightweight, developer-friendly setup that closely mirrors your production environment.

Unlike local SDK setups, an RDE can be provisioned instantly in the cloud, allowing developers to push code, content, and configurations in minutes.

---

Key Benefits of Using an RDE

1. Instant Provisioning: RDEs are created within minutes, removing long setup times.
2. Cloud Alignment: They replicate your AEM Cloud Service setup, ensuring consistent behavior between development, staging, and production environments.
3. Team Collaboration: Multiple developers can use the same RDE instance to test shared features.
4. Real Content Testing: RDEs allow you to test features with realistic content and user flows before merging to main branches.
5. Faster Debugging: Logs, Sling consoles, and error reports are available instantly through AEM Cloud Manager, making debugging faster.

---

How an RDE Fits into the AEM Cloud Workflow

Here’s a simplified overview of how RDEs fit into your AEM Cloud Service workflow:

1. Develop locally using the AEM SDK.
2. Push changes to Git on a feature branch.
3. Deploy the code to the RDE using Cloud Manager CLI or APIs.
4. Test and validate features directly in the cloud.
5. Once approved, merge the feature branch into the main branch to trigger a full deployment pipeline.

This process reduces iteration time dramatically, taking development cycles from hours or days to just minutes.

---

Setting Up an RDE

Follow these steps to create and use a Rapid Development Environment in AEM:

1. Access AEM Cloud Manager: Go to your AEM Cloud Manager project.
2. Provision the RDE: Under “Environments,” click Add Environment and select Rapid Development Environment.
3. Install and Configure the AEM Cloud Manager CLI:

npm install -g @adobe/aio-cli
aio plugins:install @adobe/aio-cli-plugin-cloudmanager

4. Deploy Code or Content: Deploy packages using the CLI command below:

aio cloudmanager:rde:deploy <PROGRAM_ID> <ENVIRONMENT_ID> --file <ZIP_FILE>

You can deploy complete code packages, OSGi bundles, or content packages directly to the RDE.

5. Test and Debug: Use the AEM Developer Console and logs to verify deployments, troubleshoot issues, and monitor application behavior.

---

Best Practices for Using RDEs

• Keep your RDE clean: Reset or redeploy regularly to maintain stability.
• Automate deployments: Integrate RDE deployments into your CI/CD pipeline.
• Use separate RDEs for each team: Assign dedicated environments for isolated testing.
• Leverage Cloud Manager APIs: Automate repetitive tasks such as deployments and resets.

---

Real-World Example

Consider a marketing team preparing a new campaign component. A developer builds the component locally and deploys it to the RDE in minutes. Content authors then log in, test the new component with real content, and provide instant feedback. After validation, the developer merges the feature branch, and the change is deployed to staging and production — all in the same day.

This process allows for faster iteration, early feedback, and reduced production risk.

---

Conclusion

The Rapid Development Environment (RDE) in Adobe Experience Manager Cloud Service transforms how teams develop and test digital experiences. By providing instant provisioning, cloud consistency, and seamless collaboration, RDEs empower organizations to innovate faster and more efficiently.

If your team still relies solely on traditional development and staging pipelines, it’s time to adopt RDEs — the next step toward agile, cloud-native AEM development.

---

Log Forwarding in AEM as a Cloud Service – Splunk vs S3

Adobe Experience Manager (AEM) as a Cloud Service allows you to forward system and application logs to external destinations. This feature is called Log Forwarding, and it helps teams monitor, analyze, and store logs outside AEM.

Why Log Forwarding?

Log forwarding lets you centralize logs from AEM environments like dev, stage, and prod into your preferred logging platform. You can use tools like Splunk for live analytics or Amazon S3 for long-term storage and compliance.

1. Forwarding Logs to Splunk

To send AEM logs to Splunk, configure your log-forwarding.yaml file with Splunk details such as the host, port, and access token.

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["stage", "prod"]
data:
  splunk:
    default:
      enabled: true
      host: "collector.xyz.com"
      port: 6580
      token: ${{YOUR_SPLUNK_TOKEN}}
      index: "aemaacs"
    aem:
      advancedNetworking: true

How it works:

• Logs from AEM Author and Publish instances are forwarded to your Splunk collector.
• The token provides authentication to the Splunk endpoint.
• advancedNetworking allows secure data transfer within Adobe’s managed network setup.

When to use: Choose Splunk if you want real-time log monitoring, dashboards, and alerting.

2. Forwarding Logs to Amazon S3

If you need to store logs for auditing or long-term retention, you can forward them to an S3 bucket. Here’s an example configuration:

kind: "LogForwarding"
version: "1"
metadata:
    envTypes: ["dev", "stage", "prod"]
data:
    awsS3:
        default:
            enabled: true
            region: "us-east-1"
            bucket: "YOUR_BIT_BUCKET"
            accessKey: "${{YOUR_AWS_S3_LOG_FORWARD_ACCESS_KEY}}"
            secretAccessKey: "${{YOUR_AWS_S3_LOG_FORWARD_ACCESS_SECRET_KEY}}"
        aem:
            advancedNetworking: true

How it works:

• Logs are written to your specified S3 bucket in the given AWS region.
• Access keys authenticate the upload process securely.
• Useful for cost-effective, long-term log retention and analysis using AWS tools like Athena or CloudWatch.

When to use: Choose S3 if you want to store logs for future analysis or compliance without needing real-time dashboards.

Splunk vs S3 – Quick Comparison

Feature	Splunk	Amazon S3
Use Case	Real-time log analysis and alerting	Long-term storage and auditing
Integration	Requires Splunk collector endpoint	Requires AWS S3 bucket and credentials
Access	Search and dashboard in Splunk UI	Access logs from S3 console or via AWS tools
Best For	Monitoring, operations, DevOps teams	Compliance, audit, and archival needs

Best Practices

• Always store access tokens and keys as environment secrets in Cloud Manager.
• Limit log forwarding only to necessary environments to manage cost and data flow.
• Use advancedNetworking for secure connections when available.
• Test log forwarding in the dev environment before enabling in production.

With AEM’s log forwarding flexibility, you can integrate your cloud logs easily into enterprise monitoring systems or cloud storage platforms depending on your operational needs.

How to Enable or Disable Caching in AEM as a Cloud Service

Adobe Experience Manager (AEM) as a Cloud Service uses caching to speed up content delivery and reduce load on the publish servers. Caching works across multiple layers- the CDN, Dispatcher, and browser - to store and serve content quickly. However, you may need to enable or disable caching depending on your project requirements.

Understanding Caching

Caching stores copies of responses so users can access content faster. When caching is enabled, repeated requests are served directly from the cache instead of the AEM origin. Disabling caching ensures fresh content is always fetched directly from AEM.

How to Enable Caching

To enable caching, you can configure HTTP response headers that tell the CDN and browser how long to keep content in cache. You can apply this through the dispatcher configuration or programmatically in your code.

Dispatcher Configuration Example:

Header unset Cache-Control
Header unset Surrogate-Control
Header unset Expires

Header set Cache-Control "max-age=600, stale-while-revalidate=600, stale-if-error=600"
Header set Surrogate-Control "max-age=600, stale-while-revalidate=600, stale-if-error=600"

In this setup, the content remains fresh for 10 minutes (max-age=600) and continues to serve cached data briefly during revalidation or errors for improved performance.

Programmatic Approach: You can also set the same headers from a Sling Servlet or Filter to apply caching rules to specific responses.

How to Disable Caching

In some cases, such as dynamic, personalized, or secure content, you may not want caching. To disable caching, adjust your response headers to mark the response as private or non-cacheable.

Dispatcher Configuration Example:

Header unset Cache-Control
Header unset Surrogate-Control
Header unset Expires

Header always set Cache-Control "private"
Header always set Surrogate-Control "private"

This configuration ensures that content is not stored in the CDN or shared caches. You can also apply the same logic in a custom servlet or filter by adding the header Cache-Control: private.

When to Enable or Disable Caching

Scenario	Recommended Action
Public or static content (images, HTML pages)	Enable caching with a defined time-to-live (TTL) for better performance.
Personalized or dynamic data	Disable caching or set responses to private to prevent serving outdated or user-specific data.
Development or testing environments	Disable caching to see real-time changes immediately.
Mixed content types	Use selective caching rules in dispatcher or via code to manage caching per path or content type.

Best Practices

• Always set explicit caching headers to avoid default or unintended behavior.
• Test your caching configuration in staging before applying to production.
• Use stale-while-revalidate and stale-if-error for better user experience under load.
• Regularly review which pages should bypass caching (e.g., forms, user dashboards).

By managing caching properly, AEM as a Cloud Service can balance high performance with real-time content accuracy — ensuring users always get the right experience.

Understanding CDN Cache Purge in AEM as a Cloud Service

Adobe Experience Manager (AEM) as a Cloud Service uses a global Content Delivery Network (CDN) to cache content closer to users for faster performance. Sometimes, when you update or delete content, you may need to remove the outdated version from the CDN cache. This process is called purging the cache.

Why Purge the Cache?

Purge requests help ensure users always see the latest version of your content. Without purging, the CDN might continue serving stale or old data from its cache instead of fetching new content from AEM Publish.

Types of Purge

• Single URL Purge: Removes a specific resource from cache.
• Surrogate Key Purge: Purges multiple related resources grouped under the same key.
• Full Purge: Clears all cached resources from the CDN.

Fast vs Soft Purge

Fast (Hard) Purge: Instantly removes cached content from all CDN nodes. Users will immediately fetch fresh content from AEM. This is best for critical updates but may cause a temporary spike in origin load.

Soft Purge: Marks cached content as stale but keeps serving it until new content is fetched from AEM. This approach reduces load on the origin and ensures a smoother user experience.

How to Issue a Purge Request

You can trigger a purge using an HTTP request with the PURGE method. Authentication is done using a purge key defined in your CDN configuration.

curl -X PURGE "https://publish-<your-environment>.adobeaemcloud.com/path/to/resource.html" \
  -H "X-AEM-Purge-Key: <your_purge_key>" \
  -H "X-AEM-Purge: hard"

The above command removes a single cached resource immediately (hard purge).

Surrogate Key Purge Example

If your responses include surrogate keys like:

Surrogate-Key: product-page product-images

You can purge all related resources together:

curl -X PURGE "https://publish-<env>.adobeaemcloud.com" \
  -H "X-AEM-Purge-Key: <your_purge_key>" \
  -H "Surrogate-Key: product-page" \
  -H "X-AEM-Purge: soft"

Important Notes

• Use purge operations carefully, especially full purges, as they can cause a sudden increase in requests to AEM Publish.
• Store purge keys securely and rotate them periodically.
• Test purge behavior in development or stage environments before applying to production.
• Always ensure that updated content is available on AEM Publish before triggering a purge.

Best Practices

• Use surrogate keys to control purging in groups instead of URLs for efficiency.
• Prefer soft purges for non-critical updates to minimize system load.
• Schedule purges during off-peak hours if possible.
• Monitor CDN and origin response times after purging.

By using the CDN purge features wisely, you can maintain high performance while ensuring users always access the latest content.

 

Credential-Based Authentication in AEM as a Cloud Service

Adobe Experience Manager (AEM) as a Cloud Service supports credential-based authentication for CDN integrations. This ensures secure communication between your CDN and Adobe’s managed edge network, as well as controlled access and cache management.

Why Credentials Are Needed

When you use a customer-managed CDN or require restricted access, credentials are used to:

• Authenticate trusted CDNs using edge keys
• Authorize cache purge requests
• Enable basic authentication for restricted areas

Key Configuration Elements

Feature	Description
Edge Key	Authenticates customer-managed CDN traffic to Adobe’s edge network using secrets like ${{CDN_EDGEKEY}}.
Purge Token	Allows authorized cache purge requests with credentials like ${{CDN_PURGEKEY}}.
Basic Auth	Enables username-password access control for preview or restricted areas.

Sample Configuration

kind: "CDN"
version: "1"
metadata:
  envTypes: ["publish"]
data:
  authentication:
    authenticators:
      - name: edge-auth
        type: edge
        edgeKey1: ${{CDN_EDGEKEY_NEW}}
    rules:
      - name: edge-auth-rule
        when:
          reqProperty: tier
          equals: "publish"
        action:
          type: authenticate
          authenticator: edge-auth

Best Practices

• Store credentials as environment secrets, not in plain text.
• Rotate keys safely by using dual key entries (e.g., edgeKey1 and edgeKey2).
• Use basic auth only for light access control, not for full user login systems.
• Ensure CDN requests include headers like X-AEM-Edge-Key and X-Forwarded-Host.

Generate and manage your own purge keys 

AEM as a Cloud Service allows you to generate and manage your own purge keys through the self-service configuration process. These keys authenticate cache purge requests at the CDN layer, ensuring that only authorized users or systems can clear cached content.

How It Works

1. Define secret keys in AEM as cloud : [Secret Type env. variables with complex format]

   For e.g. CDN_PURGEKEY_CURRENT, CDN_PURGEKEY_PREVIOUS

2. In your AEM project, create or update a cdn.yaml file under your /config folder. Define a purge authenticator that references your purge key stored as an environment secret:

kind: "CDN"
version: "1"
metadata:
  envTypes: ["publish"]
data:
  authentication:
    authenticators:
      - name: purge-auth
        type: purge
        purgeKey1: ${{CDN_PURGEKEY_CURRENT}}
        purgeKey2: ${{CDN_PURGEKEY_PREVIOUS}}

3. Deploy the configuration through Cloud Manager.
4. Use the generated key in your purge API calls to invalidate cached content.

Best Practices

• Rotate purge keys periodically for security.
• Keep at least two keys (purgeKey1 and purgeKey2) active during rotation.
• Store all keys as environment secrets in Cloud Manager, never in plain text.

This self-service model provides flexibility and security, allowing organizations to control when and how cache purges occur across environments.

 

Summary

Credential-based authentication secures how your CDN interacts with AEM’s edge delivery system. With proper configuration of edge keys, purge tokens, and basic auth, you can ensure safe, authenticated, and controlled content delivery in AEM as a Cloud Service.

Tags: AEM Cloud, Adobe Experience Manager, CDN Authentication, Edge Key, Purge Token, Basic Auth, AEM Security, Content Delivery

Edge Side Include (ESI) vs Sling Dynamic Include (SDI) in AEM as a Cloud Service

When delivering high-performance websites with Adobe Experience Manager (AEM), caching plays a vital role. However, not all content can be cached the same way — some sections (like user info or personalized banners) need to be rendered dynamically while most of the page remains cached.

To address this, AEM supports two major approaches:

• Edge Side Include (ESI)
• Sling Dynamic Include (SDI)

This article explains how each works, their differences, and when to use them.

---

What is Sling Dynamic Include (SDI)?

Sling Dynamic Include (SDI) is an AEM-specific feature that lets you replace specific parts of a cached page with dynamically rendered fragments. It works within the AEM Dispatcher or Apache Sling layer.

SDI replaces a component’s output with a server-side include (<!--#include-->) so that only those parts are fetched dynamically on every request, while the rest of the page is cached.

Example

<!-- Original AEM component -->
<div data-sly-resource="/content/site/en/userinfo"></div>

<!-- After SDI processing -->
<!--#include virtual="/content/site/en/userinfo.html" -->

In this setup, even when the page is cached at the dispatcher, the user info component is re-fetched dynamically.

Key Use Cases

• Personalized welcome messages
• Shopping cart status or counts
• Dynamic banners or time-sensitive content

Advantages

• Works fully within the AEM–Dispatcher setup
• Easy to configure using OSGi settings
• No dependency on CDN

Limitations

• Runs at the origin (dispatcher), not at the edge
• Can add server-side overhead for multiple dynamic fragments
• Less efficient for globally distributed traffic

---

What is Edge Side Include (ESI)?

Edge Side Include (ESI) is a CDN-level technology that allows partial page assembly at the network edge. It is supported by CDNs such as Fastly, Akamai, and CloudFront.

With ESI, cached pages can contain <esi:include> tags. These fragments are fetched and rendered dynamically at the CDN before sending the response to the user. This reduces load on AEM and speeds up delivery.

Example

<html>
  <body>
    <esi:include src="/fragments/userinfo.html"/>
  </body>
</html>

Key Use Cases

• Global personalization via CDN edge
• Dynamic fragments in high-traffic websites
• Reducing origin load while keeping partial freshness

Advantages

• Personalization at the CDN edge (faster delivery)
• Reduces requests to AEM Publish
• Scales globally for high traffic

Limitations

• Requires CDN that supports ESI (e.g., Fastly, Akamai)
• More complex debugging at edge level
• Limited testing in local environments

---

Comparison: ESI vs SDI

Feature / Aspect	Sling Dynamic Include (SDI)	Edge Side Include (ESI)
Processing Location	AEM Dispatcher / Origin	CDN Edge (Fastly, Akamai)
Purpose	Dynamic inclusion at origin	Fragment assembly at CDN edge
Performance Impact	Moderate, depends on dispatcher load	High performance, offloads AEM
Caching Level	Dispatcher or AEM Cache	CDN-level Cache
Best For	Small-scale personalization	Global personalization & edge caching
Dependencies	AEM + SDI bundle	CDN (Fastly, Akamai)
Setup Complexity	Low	Medium to High
Personalization Depth	User/session-based at origin	Anonymous user personalization at edge
Example Tag	<!--#include virtual="..." -->	<esi:include src="..." />

---

How They Fit in AEM Cloud

In AEM as a Cloud Service, both SDI and ESI are supported. However, Adobe recommends using ESI for cloud deployments because:

• It integrates natively with the Fastly CDN used by AEM Cloud.
• Personalization and fragment assembly happen at the edge, improving time-to-first-byte (TTFB).
• It reduces load on AEM’s origin servers, improving scalability.

Still, SDI remains useful in lower environments, development, or internal networks where a CDN may not be available.

---

Best Practices

• Use ESI for edge personalization and global traffic.
• Use SDI for simple dispatcher-level dynamic includes.
• Avoid nested includes (either ESI or SDI).
• Always check cache headers for fragment freshness.
• Monitor performance using AEM Cloud metrics.

---

Conclusion

Both Edge Side Include (ESI) and Sling Dynamic Include (SDI) allow partial page caching in AEM without sacrificing personalization. The choice depends on scale and infrastructure:

• Use SDI for small-scale or internal personalization.
• Use ESI for large-scale, global personalization and high-performance delivery.

Together, they help AEM developers balance caching efficiency with personalized content delivery.

---

Tags: AEM Cloud, Adobe Experience Manager, Edge Side Include, Sling Dynamic Include, Fastly CDN, AEM Performance, Caching, Personalization

Pipeline-Free URL Redirects in AEM as a Cloud Service

In Adobe Experience Manager (AEM) as a Cloud Service, managing redirects efficiently is essential for maintaining SEO ranking, user experience, and link consistency when pages are moved, renamed, or deleted. The new pipeline-free URL redirects feature allows teams to manage redirects easily without needing a full pipeline deployment.

This feature is especially useful when marketing or content teams handle redirects directly without relying on developer or DevOps pipelines.

---

When to Use Pipeline-Free Redirects

Pipeline-free redirects are ideal in the following scenarios:

• When business or marketing users need to add or modify redirects quickly.
• If your team manages thousands of redirects and doesn’t want to trigger a Cloud Manager pipeline each time.
• When using UI-based tools such as ACS Commons Redirect Manager or Redirect Map Manager.
• When redirect management is part of daily operations rather than code deployments.

---

How It Works

Pipeline-free redirects are stored in a publish repository and mapped dynamically by the AEM Dispatcher configuration. Here’s how it functions step-by-step:

1. Redirect mappings are stored in one or more rewrite map files inside the /content/dam repository.
2. A configuration file, such as managed-rewrite-maps.yaml, defines which rewrite maps to load from the repository.
3. The AEM Dispatcher (Apache) loads and caches these maps for use in URL rewriting.

maps:
  - name: my.map
    path: /content/dam/redirectmaps/mysite-redirectmap.txt

The above YAML tells AEM where to find your redirect map file stored in the DAM.

Apache Rewrite Rule Example

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

When a request matches an entry in the rewrite map, Apache issues a 301 Redirect to the mapped destination.

---

Configuration Options

Adobe provides several useful configuration options to control reload frequency and startup behavior:

• TTL (time-to-live): Defines how often Apache reloads the rewrite map. Default is 300 seconds.
• wait: If set to true, Apache waits until the map is fully loaded before serving requests (avoiding temporary inconsistencies).
• Entry limit: Each redirect map entry supports up to 1024 characters.

Example:

maps:
  - name: my.map
    path: /content/dam/redirectmaps/mysite-redirectmap.txt
    ttl: 600
    wait: true

---

Things to Remember

• Use this method only for redirects, not for complex rewrite logic.
• Ensure redirect maps are updated and published to the correct environments (e.g., stage, production).
• Keep the number of maps manageable — each map file can contain thousands of entries efficiently.
• Monitor redirect performance via logs or Cloud Manager metrics.

---

Summary

The pipeline-free URL redirect feature in AEM Cloud gives organizations flexibility and speed. Redirects can now be managed dynamically from the AEM repository without triggering a deployment pipeline. This empowers content teams to maintain SEO and user navigation effectively while keeping developers focused on core code changes.

---

Tags: AEM Cloud, Adobe Experience Manager, URL Redirects, Pipeline-Free Redirects, AEM Dispatcher, Cloud Manager, ACS Commons