AEM Asset Distribution Options Compared: Brand Portal, Content Hub & Ass...

AEM as a Cloud Service: How to Make Your Legacy Assets Overlay Work in the New Assets View UI

 

The new Assets View UI in AEM as a Cloud Service introduces a modern experience: but it also breaks many legacy overlays created for the classic Assets interface. This article explains why your existing asset overlay no longer works, what changed under the hood, and the exact steps needed to migrate or rebuild your customization for the new UI. Whether you're using overlays for metadata forms, custom buttons, Rendition workflows, or UI tweaks, this guide helps you identify the root cause and apply the right fix so your AEM asset customizations continue to function seamlessly in the updated interface.

 

Our experience home looks as below, 

 

The URL for assets home is: https://experience.adobe.com/?repoId=author-pXXXX-eXXXX.adobeaemcloud.com#/@client/assets/browse

 The new UI will take you to below experience.

 Traditional Assets Navigation

The traditional method of using repository-level overlays under /apps to customize the Assets console does not work for the new Assets view UI in AEM as a Cloud Service because the new UI is built on a modern micro-frontend architecture. 

To fix this, you must rebuild your customizations using the AEM Assets View UI Extensibility framework, which leverages Adobe App Builder and microservices to integrate custom components. 

Steps to Rework Your Customization

1. Understand the New Architecture: The "Assets view" is a separate, search-first application that uses a micro-frontend architecture. Customizations are no longer simple JCR node overlays but rather independent UI extensions that integrate via defined extension points.
2. Enable Assets Ultimate (Prerequisite): The UI extensibility feature is part of the Assets Ultimate offering. Ensure your Cloud Manager program has Assets Ultimate enabled. You may need to create an Adobe Customer Support case to get access.
3. Set Up Your Development Environment:

1. Install the Adobe I/O command-line tool (AIO CLI) locally.

2. Ensure you have a good understanding of JavaScript, Node.js, and React technologies, as these are used for building the extensions.

3. Set up your local environment for UI extension development as described in the official Adobe Experience League documentation.

4. Develop the UI Extension:

1. Use the AIO CLI to generate the basic structure for your extension.

2. Identify the appropriate extension point (e.g., aem/assets/details/1 for custom side panels on the asset details page, or points for Quick Actions and the Actions Bar) that corresponds to your original overlay's functionality.

3. Develop your custom UI components using the React Spectrum library.

5. Test Locally: The framework allows you to test your extensions locally, connecting them to the production AEM Assets View for testing before full deployment.
6. Deploy: Deploy your extension using Cloud Manager pipelines. The extensions are hosted outside of AEM as a Cloud Service, which helps streamline maintenance and reduce the total cost of ownership. 

By following the official Enable UI extensibility in AEM Assets View guide, you can successfully migrate your customizations to the new UI architecture

Second Option: Replace overlays with a Sling Servlet + Upload Restriction Validator

You must enforce restrictions at server-side, because UI overlays are not guaranteed to run in CS.

Steps

1. Create a Servlet Filter or Sling Upload Servlet Extension that intercepts uploads under /content/dam.
2. Apply your logic:
• MIME type restrictions
• Folder-level restrictions
• File size limits
3. If invalid, return an HTTP error (e.g., 403 or 409) with a meaningful message.
4. AEM UI will automatically surface the error during upload.

Brand Portal vs Asset Share Commons vs AEM Content Hub — Complete Comparison Guide

Adobe Experience Manager offers multiple ways to share, distribute, and reuse content and digital assets. The three common solutions are Brand Portal, Asset Share Commons, and AEM Content Hub. While they may look similar, they are designed for completely different use cases. This article offers a clear comparison across features, capabilities, and ideal usage scenarios.

---

1. What is AEM Brand Portal?

AEM Brand Portal is an Adobe-managed, cloud-hosted platform for distributing approved digital assets to external partners such as agencies, resellers, retailers, and franchise teams. It provides secure access without exposing your main AEM author instance to external users.

Key Features

• Secure external access via Adobe IMS
• Publish-approved assets only
• Download presets and controlled renditions
• Asset expiry and governance
• Analytics and usage visibility
• No hosting/maintenance required

Best For

Organizations that need a governed, branded portal for distributing images, product assets, and marketing materials to external stakeholders.

---

2. What is Asset Share Commons?

Asset Share Commons (ASC) is an open-source asset browser UI built on top of AEM. It is fully customizable and is usually used to provide asset access to internal employees or specific partner groups.

Key Features

• Open-source and fully configurable
• Faceted search and custom components
• Browser and download portal for AEM assets
• Integrated with AEM permissions and workflows
• Runs on customer-managed AEM infrastructure

Best For

Organizations that want complete control over UI/UX and custom functionality without using an Adobe SaaS solution.

Limitations

• Requires AEM development effort
• No Adobe-managed hosting
• Not ideal for large-scale external distribution

---

3. What is AEM Content Hub?

AEM Content Hub is a cloud-native, centrally governed content discovery and reuse layer available only in AEM as a Cloud Service. It allows authors across multiple sites or business units to search, discover, and reuse approved content instantly.

Key Features

• Unified search across AEM instances
• Reuse of components, fragments, and assets
• AI-powered tagging and smart content discovery
• Ideal for multi-site, multi-brand organizations
• No hosting or maintenance required (SaaS)

Best For

Enterprises using AEM Cloud to maintain consistent brand/content quality across teams and regions.

Limitations

• Available only in AEM Cloud Service
• Less customizable compared to ASC

---

Comparison Table

Feature	Brand Portal	Asset Share Commons	Content Hub
Type	SaaS asset distribution portal	Customizable open-source AEM UI	Cloud-native content discovery layer
Primary Users	External partners	Internal teams / controlled groups	Authors across brands/regions
Customization	Low	Very high	Low–medium
Setup Effort	Very low (Adobe-managed)	Medium–high (development needed)	None (cloud-native)
Hosting	Adobe hosted	Customer AEM hosted	Adobe cloud
Best Use Case	External asset distribution	Custom internal/external UI	Content reuse across multiple AEM instances

---

Which Should You Choose?

Choose Brand Portal if you need:

• A secure distribution portal for external agencies/partners
• No maintenance or infrastructure burden
• Strong access governance

Choose Asset Share Commons if you need:

• Complete UI customization
• Integration with custom workflows
• A self-hosted, developer-friendly solution

Choose Content Hub if you need:

• Unified content reuse across regions/teams
• A cloud-native ecosystem
• Modern governance and AI-driven search

---

Conclusion

Brand Portal, Asset Share Commons, and Content Hub are purpose-built solutions that address different content distribution challenges. Brand Portal excels at external asset sharing, Asset Share Commons shines with its customization flexibility, and Content Hub leads in enterprise content reuse across distributed teams.

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.