5.2 Content Fragments, Experience Fragments & Headless Delivery

5.2 Content Fragments, Experience Fragments & Headless Delivery

Exam Focus: Modern AEM enterprise architectures rely on Content Fragments (CF) and Experience Fragments (XF) to power both traditional sites and omnichannel headless applications. The AD0-E128 exam tests the explicit architectural boundaries between CFs and XFs, Content Fragment Model (CFM) data types and relationships under /conf, headless delivery using AEM GraphQL Persisted Queries via HTTP GET (and why GET is required for CDN/Dispatcher caching), page-based Experience Fragment variation structures, exporting XFs to Adobe Target as HTML offers, and embedding fragments into Sites pages via Core Components.

---

Content Fragments vs. Experience Fragments Comparison Matrix

Choosing between a Content Fragment and an Experience Fragment is one of the most fundamental design decisions in AEM. The following comparison matrix contrasts their architectural characteristics:

Practical Decision Heuristic

• Choose a Content Fragment when: You need to model raw structured entities (e.g., Products, Team Members, Financial Rates, News Articles) that must be syndicated headlessly to native mobile apps, smart watches, third-party marketplaces, or single-page applications (React/Next.js/Vue) via GraphQL, without dictating visual presentation.
• Choose an Experience Fragment when: You need to author a reusable, styled visual section composed of multiple components with distinct responsive layouts (e.g., Global Header, Global Footer, Promotional Hero Banners, Legal Disclaimers) that must be maintained centrally and embedded across hundreds of multi-site pages or delivered as HTML offers into Adobe Target.

---

Content Fragment Models (CFMs) & Data Types

For current model-based Content Fragment authoring and GraphQL delivery, define and enable a Content Fragment Model (CFM) before authors create fragments from that model. Legacy fragment forms exist in older AEM versions, so schema binding should not be stated as a universal property of every historical Content Fragment.

Model Configuration Path

Content Fragment Models reside under the tenant configuration tree: /conf/<my-app>/settings/dam/cfm/models/<model-name>

• Persisted as a cq:Template node containing a Granite UI dialog structure (cq:dialog) that outlines the model schema.
• Models must be set to Enabled in the Content Fragment Models console (Tools > Assets > Content Fragment Models) before authors can instantiate them.

Supported Data Types

AEM Content Fragment Models provide a rich palette of field data types:

1. Single-Line Text: Standard string field. Supports validation rules including maximum character length, regex pattern matching, default values, and uniqueness enforcement.
2. Multi-Line Text: Supports plain text, Rich Text (RTE), or Markdown. Authors can define custom variations (e.g., a "mobile-short" variation containing concise copy alongside the "master" long-form text).
3. Number: Supports Integer and Double/Float values, complete with minimum, maximum, and step validations.
4. Boolean: Renders as a toggle switch or checkbox, storing true/false values.
5. Date and Time: Supports Date-only or combined Date and Time inputs with timezone handling.
6. Enumeration (Dropdown / Options): Provides static drop-down selections or radio button groups.
7. Tags: Maps to AEM Tagging taxonomies under /content/cq:tags.
8. Content Reference: Stores JCR path references to DAM assets (images, PDFs, videos) or Sites pages.
9. Fragment Reference: Enables nested data modeling. A Content Fragment can reference one or multiple other Content Fragments, allowing developers to establish 1:1 or 1:N relational hierarchies (e.g., an "Author" Content Fragment nested inside a "Blog Post" Content Fragment).
10. JSON Object: Stores arbitrary structured JSON payloads for complex, non-relational technical data.

---

Headless Delivery via the AEM GraphQL API

AEM includes a high-performance GraphQL engine that automatically compiles Content Fragment Models into strongly-typed GraphQL schemas. The engine exposes query endpoints capable of retrieving nested content structures in a single round-trip network request.

The Critical Architectural Imperative: Persisted Queries via HTTP GET

Understanding the operational difference between dynamic GraphQL queries and Persisted Queries is a frequent, critical test point on the AD0-E128 examination:

Dynamic POST Query:   Client === POST /content/graphql/endpoint ===> AEM Publish (CANNOT BE CACHED AT CDN)
Persisted GET Query: Client === GET /graphql/execute.json/my-app/allArticles ===> CDN / Dispatcher (CACHE HIT!)

• Standard Ad-Hoc POST Queries (/content/graphql/global/endpoint): When a client issues a dynamic GraphQL query using an HTTP POST request with a JSON query payload, the request passes directly through the CDN and AEM Dispatcher, hitting the AEM Publish instance every single time. By HTTP specification and Dispatcher caching architecture, HTTP POST requests cannot be cached. In a production environment with high client traffic, dynamic POST queries will quickly saturate publish CPU threads and exhaust JVM memory, resulting in severe outages.
• Persisted Queries via HTTP GET (/graphql/execute.json/<conf-name>/<query-name>;param1=val1): In modern AEM headless architectures, developers save and compile GraphQL queries server-side as Persisted Queries under /conf/<my-app>/settings/graphql/persistentQueries. Clients invoke these queries using a standard HTTP GET request.

Because persisted queries use GET, responses are cached efficiently by both the AEM Dispatcher and the Cloud Manager CDN edge nodes using HTTP Cache-Control headers (e.g., s-maxage=3600). Subsequent client requests across the globe are fulfilled at the CDN edge in milliseconds without ever touching the AEM Publish tier.

Sample Persisted GraphQL Query Execution

A persisted query named articleList created in /conf/wknd/settings/graphql/persistentQueries/articleList:

query getArticlesByTag($tag: String!) {
  articleList(filter: { tags: { _expressions: [{ value: $tag }] } }) {
    items {
      _path
      title
      publicationDate
      authorFragment {
        fullName
        biography {
          plaintext
        }
        profilePicture {
          ... on ImageRef {
            _path
            _publishUrl
          }
        }
      }
    }
  }
}

Client application invocation via HTTP GET:

GET /graphql/execute.json/wknd/articleList;tag=technology HTTP/1.1
Host: wknd.site
Accept: application/json
Cache-Control: max-age=60

---

Experience Fragments (XF) Architecture & Multi-Channel Variations

While Content Fragments focus strictly on data, Experience Fragments provide reusable presentation layouts composed of fully functional AEM components.

Repository Structure of an Experience Fragment

Experience Fragments reside under /content/experience-fragments/<my-project>/<xf-name>:

+ /content/experience-fragments/my-project/global-header
    - jcr:primaryType = "cq:Page"
    + master
        - jcr:primaryType = "cq:Page"
        - jcr:mixinTypes = ["cq:ReplicationStatus"]
        + jcr:content
            - jcr:primaryType = "cq:PageContent"
            - sling:resourceType = "cq/experience-fragments/components/xfpage"
            - cq:template = "/conf/my-project/settings/wcm/templates/xf-web-variation"
            + root (Layout Container)
                + navigation
                    - sling:resourceType = "my-project/components/navigation"
                + search
                    - sling:resourceType = "my-project/components/search"
    + mobile-header
        - jcr:primaryType = "cq:Page"
        + jcr:content
            - sling:resourceType = "cq/experience-fragments/components/xfpage"
            + root
                + mobile-nav
                    - sling:resourceType = "my-project/components/mobile-nav"

• The fragment root and each variation use the page structure (cq:Page with a jcr:content child). Experience Fragment identity and variation behavior come from properties and resource types on that page content, not from cq:ExperienceFragment primary node types.
• The jcr:content node uses the resource type cq/experience-fragments/components/xfpage.
• The Master variation represents the canonical desktop web experience. Authors can create sibling variations optimized for specific channels (e.g., Facebook, Pinterest, Mobile, or Email).

Exporting Experience Fragments to Adobe Target

A signature capability of Experience Fragments is direct export to Adobe Target as HTML offers:

1. Integration Setup: Administrators configure an Adobe Target Cloud Service configuration in AEM (Tools > Cloud Services > Adobe Target), linking AEM to the target Adobe Experience Cloud organization and IMS credentials.
2. Export Mechanism: When an author opens an Experience Fragment variation in the editor and clicks Export to Adobe Target, AEM renders the complete HTML DOM markup of the components, packages any referenced image assets, and transmits an HTML Offer payload into Adobe Target via Target's REST APIs.
3. Marketing Personalization: Marketers operating inside Adobe Target can select the AEM-authored HTML Offer within their Visual Experience Composer (VEC) for A/B testing, multivariate testing, or automated experience targeting (XT). This bridges brand governance with personalization: developers and authors build brand-compliant UI in AEM, while optimization teams run targeted campaigns in Target.

---

Integrating Fragments into AEM Sites Pages via Core Components

Both Content Fragments and Experience Fragments seamlessly integrate into standard Sites pages using out-of-the-box Core Components:

• Content Fragment Component (core/wcm/components/contentfragment/v1/contentfragment): Allows page authors to select a specific Content Fragment from the Assets browser. Authors can choose which specific elements to display, select a custom text variation, configure paragraph split ranges, or configure the component to emit clean structured JSON via the Sling Model Exporter.
• Content Fragment List Component (core/wcm/components/contentfragmentlist/v1/contentfragmentlist): Dynamically queries and displays a collection of Content Fragments matching a designated Content Fragment Model, filtered by JCR tags or parent repository folder paths.
• Experience Fragment Component (core/wcm/components/experiencefragment/v1/experiencefragment): Embeds an Experience Fragment variation into a page's layout container. The component includes intelligent localization support: if a page resides under /content/wknd/fr/fr/home and references an XF at /content/experience-fragments/wknd/us/en/header/master, the component can automatically resolve and render the matching localized French variation under /content/experience-fragments/wknd/fr/fr/header/master.