Dispatcher cache invalidation for shared content in AEM as a Cloud Service
When you update shared content used by cached pages, publishing the shared item alone doesn’t guarantee that every consuming page or CDN response is fresh. Adobe documents explicit Dispatcher invalidation through Sling Content Distribution (SCD) from Author; the Adobe-managed CDN follows response cache headers and TTL separately. To fix this, identify the affected page paths, choose an invalidation or TTL strategy for your implementation, and test Dispatcher and CDN behavior separately.
Description description
Environment
Adobe Experience Manager as a Cloud Service Publish with Dispatcher and the Adobe-managed CDN.
Issue/Symptoms
- After publishing an Experience Fragment, Content Fragment, or DAM Asset, a page that uses the shared content displays older output.
- You need to determine whether the page, the shared resource, or the CDN response remains cached.
- No product error is reported. The question concerns cache-invalidation behavior and cache freshness.
Cause
AEM as a Cloud Service provides out-of-the-box reverse-reference cache invalidation only for Experience Fragments. For Content Fragments and DAM Assets, custom configuration is needed to ensure referencing pages are invalidated when shared content is updated.
Resolution resolution
Follow the steps below to resolve the issue:
-
Review the out-of-the-box cache invalidation behavior:
- When you publish an Experience Fragment, AEM as a Cloud Service automatically resolves all pages that reference the fragment and issues a resource-only flush for each consuming page’s
.htmlpath. No custom configuration is required. - When you publish a Content Fragment, only the Content Fragment path is invalidated. Pages that reference the Content Fragment are not flushed by default.
- When you publish a DAM asset, only the asset and its renditions are invalidated. Pages that reference the asset are not flushed by default.
- When you publish a page, only the page path is flushed. Referenced Experience Fragments, Content Fragments, and DAM assets are not flushed by default.
- When
/statfileslevel "2"is configured, invalidating a path under a directory does not flush the entire subtree. Only the specific path and its immediate parent statfile are affected.
- When you publish an Experience Fragment, AEM as a Cloud Service automatically resolves all pages that reference the fragment and issues a resource-only flush for each consuming page’s
-
To invalidate referencing pages when Content Fragments or DAM assets are published, use one of the following supported approaches:
- Implement a custom SCD INVALIDATE handler that resolves referencing pages when a Content Fragment or asset is published and issues targeted invalidations.
- Use ACS AEM Commons Dispatcher Flush Rules to create regex-based mappings between published content and referencing pages.
- Deliver shared content as independently cacheable fragments, such as by using Sling Dynamic Include.
- As an interim solution, configure a bounded TTL (time-to-live) for pages that consume Content Fragments or assets by using
cdn.yamlor Dispatcher response headers.
-
After implementing the selected approach, publish a shared content item and verify that all referencing pages reflect the updated content.