AEM Assets Developer Professional cheat sheet
AEM Assets Developer Professional · Keep the key ideas within reach.
AEM Assets Fundamentals and Architecture
Assets are stored as nodes of type dam:Asset in the JCR; each asset node has a dam:AssetContent child holding renditions, metadata, and related subassets.
The binary is stored in the data store (FileDataStore or S3/Azure blob), not in the segment/repository store; the JCR keeps only a reference via the dam:AssetContent/renditions/original node.
Default asset workflow is the DAM Update Asset workflow model; it runs metadata extraction, thumbnail generation, and optional processing steps on ingestion.
dam:Asset is a subtype of nt:hierarchyNode (via mixin); folder nodes are sling:Folder or sling:OrderedFolder of type dam:Folder.
The AEM Assets HTTP API (Assets REST API) exposes assets under /api/assets/{path}.json; it supports CRUD on assets and folders plus metadata and renditions.
Dynamic Media (Scene7) is a separate cloud service; without it, delivery uses the AEM/Dynamic Media Foundation or dispatcher-cached renditions.
OOTB asset processing uses the DAM Update Asset workflow; processing profiles (Processing Profile) apply to folders and run on upload to trigger custom workflows or metadata profiles.
Connected Assets lets a Sites instance reference assets from a remote Assets instance via the Connected Assets configuration and a shared asset lookup API.
Asset Ingestion, Processing, and Metadata
Ingestion paths: browser upload, desktop app (AEM Desktop), bulk import via /content/dam, and the Assets HTTP API or Sling POST; each triggers the DAM Update Asset workflow unless disabled.
Metadata schemas are defined under /conf/global/settings/dam/adminui-extension/metadataprofile or OOTB /libs/dam/... ; the Metadata Schema editor defines namespaces, fields, and cardinality.
XMP extraction writes to dc:, photoshop:, tiff:, exif: namespaces; the XMP writeback workflow (DAM XMP Writeback) pushes JCR metadata back into the binary.
Processing profiles (conf/global/settings/dam/processing) map MIME types to workflow models and can be assigned per folder to override the default DAM Update Asset behavior.
Smart Tags use the Adobe Sensei/AI service via a cloud configuration; the Smart Tag workflow (e.g., smarttag) must be enabled and the cloud config linked to the folder.
Metadata Profiles apply default/derived metadata to assets in a folder at ingestion; they merge with XMP and can mark fields as read-only or required.
The DAM Update Asset workflow's default steps include: metadata extraction (DamMetadataExtraction), thumbnail creation, and web-enabled rendition generation (cq5dam.web.*).
Custom metadata namespaces must be registered via the Namespace registry (Tools > General > Namespaces) before use in schema fields; otherwise properties fail validation.
Asset Organization, Search, and Collections
Search in AEM Assets uses the QueryBuilder API; the /bin/querybuilder.json endpoint translates predicates (path, type, property, fulltext) into JCR-SQL2 or XPath queries.
The OmniSearch full-text index is driven by Oak Lucene; assets are indexed on properties like jcr:content/metadata/dc:title and dam:AssetContent.
Collections are of two types: static collections (explicit asset membership) and smart collections (saved search query evaluated at view time).
Smart collection membership is defined by a saved search (query string + search type) stored on the collection node; it updates as assets match the query.
Tags use the cq:Tag namespace under /content/cq:tags; assets reference tags via cq:tags (multi-valued String) and tag-based search uses the tagid predicate.
Saved searches can be persisted and surfaced in the Assets UI; the query is stored and re-executed, not cached.
Folders support ordered folders (sling:OrderedFolder) for manual ordering; the Assets UI honors ordering via sling:OrderedFolder child ordering.
The Assets search rail facets (file type, size, orientation, etc.) map to QueryBuilder predicates applied on top of the base search query.
Asset Delivery, Integrations, and Customization
Renditions are served via /content/dam/.../_jcr_content/renditions/{name} or the Assets HTTP API rendition endpoint; the original is served from the data store.
The Image Serving/rendition servlet and Dynamic Media Foundation generate on-the-fly renditions; the dispatcher caches static renditions by default.
The Assets HTTP API supports POST/PUT/DELETE on /api/assets/{path} for asset and folder operations, and returns JSON with metadata and rendition links.
AEM as a Cloud Service uses the Assets HTTP API and the Asset Compute Service for custom renditions; Asset Compute workers are Node.js apps deployed to Adobe I/O Runtime.
Asset Compute Service is the extension point for custom renditions/metadata workers on AEMaaCS; legacy AEM 6.5 uses custom workflow process steps instead.
The Connected Assets integration lets a Sites instance fetch assets from a remote Assets author via a configured lookup URL and shared user credentials.
Custom asset metadata/rendition logic can be implemented as a workflow process step (Java) or as a Sling event handler on the dam:AssetCreated/dam:AssetModified events.
The Assets HTTP API and the Assets REST API are distinct: the former is the JSON CRUD API, the latter is the query builder-based search API at /api/assets/.../search.
AEM Assets Fundamentals and Architecture
Assets are stored as nodes of type dam:Asset in the JCR; each asset node has a dam:AssetContent child holding renditions, metadata, and related subassets.
The binary is stored in the data store (FileDataStore or S3/Azure blob), not in the segment/repository store; the JCR keeps only a reference via the dam:AssetContent/renditions/original node.
Default asset workflow is the DAM Update Asset workflow model; it runs metadata extraction, thumbnail generation, and optional processing steps on ingestion.
dam:Asset is a subtype of nt:hierarchyNode (via mixin); folder nodes are sling:Folder or sling:OrderedFolder of type dam:Folder.
The AEM Assets HTTP API (Assets REST API) exposes assets under /api/assets/{path}.json; it supports CRUD on assets and folders plus metadata and renditions.
Dynamic Media (Scene7) is a separate cloud service; without it, delivery uses the AEM/Dynamic Media Foundation or dispatcher-cached renditions.
OOTB asset processing uses the DAM Update Asset workflow; processing profiles (Processing Profile) apply to folders and run on upload to trigger custom workflows or metadata profiles.
Connected Assets lets a Sites instance reference assets from a remote Assets instance via the Connected Assets configuration and a shared asset lookup API.
Asset Ingestion, Processing, and Metadata
Ingestion paths: browser upload, desktop app (AEM Desktop), bulk import via /content/dam, and the Assets HTTP API or Sling POST; each triggers the DAM Update Asset workflow unless disabled.
Metadata schemas are defined under /conf/global/settings/dam/adminui-extension/metadataprofile or OOTB /libs/dam/... ; the Metadata Schema editor defines namespaces, fields, and cardinality.
XMP extraction writes to dc:, photoshop:, tiff:, exif: namespaces; the XMP writeback workflow (DAM XMP Writeback) pushes JCR metadata back into the binary.
Processing profiles (conf/global/settings/dam/processing) map MIME types to workflow models and can be assigned per folder to override the default DAM Update Asset behavior.
Smart Tags use the Adobe Sensei/AI service via a cloud configuration; the Smart Tag workflow (e.g., smarttag) must be enabled and the cloud config linked to the folder.
Metadata Profiles apply default/derived metadata to assets in a folder at ingestion; they merge with XMP and can mark fields as read-only or required.
The DAM Update Asset workflow's default steps include: metadata extraction (DamMetadataExtraction), thumbnail creation, and web-enabled rendition generation (cq5dam.web.*).
Custom metadata namespaces must be registered via the Namespace registry (Tools > General > Namespaces) before use in schema fields; otherwise properties fail validation.
Asset Organization, Search, and Collections
Search in AEM Assets uses the QueryBuilder API; the /bin/querybuilder.json endpoint translates predicates (path, type, property, fulltext) into JCR-SQL2 or XPath queries.
The OmniSearch full-text index is driven by Oak Lucene; assets are indexed on properties like jcr:content/metadata/dc:title and dam:AssetContent.
Collections are of two types: static collections (explicit asset membership) and smart collections (saved search query evaluated at view time).
Smart collection membership is defined by a saved search (query string + search type) stored on the collection node; it updates as assets match the query.
Tags use the cq:Tag namespace under /content/cq:tags; assets reference tags via cq:tags (multi-valued String) and tag-based search uses the tagid predicate.
Saved searches can be persisted and surfaced in the Assets UI; the query is stored and re-executed, not cached.
Folders support ordered folders (sling:OrderedFolder) for manual ordering; the Assets UI honors ordering via sling:OrderedFolder child ordering.
The Assets search rail facets (file type, size, orientation, etc.) map to QueryBuilder predicates applied on top of the base search query.
Asset Delivery, Integrations, and Customization
Renditions are served via /content/dam/.../_jcr_content/renditions/{name} or the Assets HTTP API rendition endpoint; the original is served from the data store.
The Image Serving/rendition servlet and Dynamic Media Foundation generate on-the-fly renditions; the dispatcher caches static renditions by default.
The Assets HTTP API supports POST/PUT/DELETE on /api/assets/{path} for asset and folder operations, and returns JSON with metadata and rendition links.
AEM as a Cloud Service uses the Assets HTTP API and the Asset Compute Service for custom renditions; Asset Compute workers are Node.js apps deployed to Adobe I/O Runtime.
Asset Compute Service is the extension point for custom renditions/metadata workers on AEMaaCS; legacy AEM 6.5 uses custom workflow process steps instead.
The Connected Assets integration lets a Sites instance fetch assets from a remote Assets author via a configured lookup URL and shared user credentials.
Custom asset metadata/rendition logic can be implemented as a workflow process step (Java) or as a Sling event handler on the dam:AssetCreated/dam:AssetModified events.
The Assets HTTP API and the Assets REST API are distinct: the former is the JSON CRUD API, the latter is the query builder-based search API at /api/assets/.../search.