AEM Forms Backend Developer Professional cheat sheet

AEM Forms on OSGi (AEM Forms add-on package) runs all Forms services as OSGi bundles on the AEM/JCR stack; the JEE (JBoss/WebLogic) deployment runs Forms services on a separate Java EE application server with its own database.

The Document Services (Output, Assembler, PDF Generator, Forms, Reader Extensions) are exposed as OSGi services on the OSGi deployment and as web services on JEE; client libraries differ accordingly.

PDF Generator requires native binaries (e.g., Acrobat/PDF Generator conversion libraries) installed on the host; it is not supported on all OS/architecture combinations and must run on a dedicated author/processing instance.

Forms add-on must match the AEM service pack/version exactly; mismatched add-on and AEM quickstart versions cause bundle resolution failures at startup.

Forms Workflow on OSGi uses AEM Workflow models with Forms-specific workflow steps; the JEE stack uses its own Process Management/LiveCycle Workbench process definitions.

Correspondence Management and Interactive Communications require the Forms add-on plus the appropriate package (e.g., letters/IC samples); they are not available on plain AEM Sites.

AEM Forms Document Services can be called from AEMaaCS via the Forms Document Services API (HTTP endpoint) rather than local OSGi services, since PDF Generator is not available on Cloud Service.

Sling/Felix console (/system/console/bundles, /system/console/services) is the primary diagnostic for Forms bundle state and Document Service registration.

Adaptive Form data binding uses the element's 'bindRef' property (defaults to the item name) to map form fields to data model nodes; the bindRef is relative to the form's data root.

Data types drive rendering: a bound element with type 'string' renders as text, 'date' as date picker, and enumerations render as drop-downs when bound to a data source with enumerated values.

Fragments (form fragments) are reusable panels stored as assets; changes to a fragment propagate to forms that reference it (reference vs. copy semantics differ).

Rules Editor offers visual rules and code (JavaScript) rules; code rules run in the client and can access the 'this' field object and the guideBridge API.

guideBridge is the client-side JS API to interact with an Adaptive Form: getGuideBridge().getFormData(), .setData(), .validate(), and event subscriptions.

Submit actions include Submit to REST endpoint, Submit to Form Data Model, Email, PDF (via Document Services), and Workflow; the submit action determines the data serialization format (JSON/XML).

Adaptive Form themes control styling via LESS/CSS client libraries; the theme is a separate asset referenced by the form and can be customized per form.

Pre-fill service (Forms prefill) can populate fields at render time via a data provider or a Form Data Model; prefill data is merged into the initial data XML/JSON.

A Form Data Model (FDM) is backed by one or more data sources; each data source is configured via an OSGi Data Source Pool (JDBC) or a REST/SOAP connector, and the FDM references the service.

FDM operations are generated from the data source schema; a form binds to FDM objects/services, and submit to FDM invokes the configured insert/update service.

FDM supports read, write, and get services; the 'get' service supplies prefill, and the 'write'/'insert' service executes on submit.

REST data sources require an OpenAPI/Swagger definition or manual configuration; SOAP requires a WSDL. The connector generates the associated services.

FDM associations (one-to-many, one-to-one) are derived from foreign keys in the data source and are exposed as navigation properties used to bind nested panels.

AEM Forms supports OData, REST, SOAP, and relational (JDBC) data sources; each data source type has its own connector bundle that must be active.

FDM can be used with Adaptive Forms, Interactive Communications, and workflows (via the FDM step); the FDM asset is referenced by path in each consumer.

Data source credentials are stored in the OSGi configuration or a secure vault; use the AEM secure vault (CryptoSupport) to avoid plaintext passwords in configs.

Output service renders XDP templates + XML data into PDF (or other formats); the template must be created in AEM Forms Designer and stored in the repository (or referenced by path).

Assembler service combines, splits, and manipulates PDFs (DDX-driven); DDX is an XML document describing input documents and the desired output operation.

PDF Generator converts Office/PostScript/image files to PDF; it depends on native conversion binaries and is unsupported on AEMaaCS (use the Document Services API instead).

Forms service renders interactive/static forms from XDP; Reader Extensions service applies usage rights (e.g., save, comment) to a PDF for Adobe Reader.

Document Services on OSGi are invoked via the DocumentServiceFactory / OutputService / AssemblerService OSGi service interfaces; on JEE they are invoked via SOAP/REST web service APIs.

Output service supports 'PDF/A' and tagged PDF generation through options; PDF/A compliance requires embedded fonts and no encryption.

Assembler operations include 'Assemble', 'Convert', 'Transform', and 'Extract'; the DDX result element defines the output document name and options.

Document Services calls are asynchronous on the JEE stack (invocation returns a result object with a job ID) and synchronous on the OSGi stack; plan timeouts accordingly.

AEM Workflow models are authored in the Workflow Editor; Forms Workflow steps include 'Assign Task' (Forms Task), 'Submit to FDM', and 'Document Services' steps.

Forms Workflow 'Assign Task' creates a task in the AEM Inbox; the task's form (Adaptive Form or HTML form) is specified by path and the task payload is stored in the workflow metadata.

Workflow process steps can be implemented as OSGi services implementing the WorkflowProcess interface (execute(WorkItem, WorkflowSession, MetaDataMap)).

Workflow data is carried in MetaDataMap; use the 'com.adobe.granite.workflow.args' argument map to pass parameters to workflow steps.

AEM Workflow launcher triggers a workflow on node events (e.g., on asset added); Forms-centric workflows can be launched on form submission.

On the JEE stack, process management uses LiveCycle Workbench processes and the Forms Workflow/Process Management service; these are distinct from AEM workflow models.

Workflow steps can call Document Services (Assembler/Output) to generate PDFs as part of a process; the generated document is stored in the payload and can be attached to the task.

The Workflow console (/libs/cq/workflow/admin) shows instances, tasks, and history; use it to inspect failed steps and payload state.

Correspondence Management composes letters from data dictionary, text/layout fragments, and conditions; the letter is rendered to PDF via the Output/Forms service.

Interactive Communications (IC) extend Correspondence Management for multi-channel (print, web, mobile) output; IC uses document fragments, charts, and a data model for personalization.

Data Dictionary defines the data elements and their types used in letters/IC; it maps to the underlying XML schema for the correspondence.

Text fragments are reusable text blocks with variables; layout fragments define the visual structure and can contain target areas for content.

IC web channel renders as an Adaptive Form; print channel renders as a PDF via the print channel's XDP/layout.

Conditions in letters/IC use the expression editor (JavaScript-like) to show/hide content based on data values.

Correspondence Management assets are managed in the Forms portal/Assets console; publishing requires the correspondence packages to be replicated to publish instances.

IC/letters can be generated on demand via the Correspondence Management API (e.g., createCorrespondence) and then rendered with Document Services.

AEM Forms access control uses AEM ACLs on assets (forms, FDM, letters); users need read on the form and the referenced assets to render it.

Forms Portal supports authentication via AEM authentication handlers; anonymous access is controlled by the portal's draft/submission configuration and ACLs.

Document security (DRM/Reader Extensions) applies usage rights; Reader Extensions rights are stored in the PDF and honored by Adobe Reader.

PDF encryption (password/AES) is applied via the Assembler/Output service options; PDF/A output must be unencrypted.

FDM data source credentials should be stored in the AEM secure vault or OSGi configuration with CryptoSupport-encrypted values, never in plaintext.

Forms workflow tasks are protected by AEM task ACLs; assignees and groups determine who can claim/complete a task.

Cross-origin and CSRF: AEM Forms REST endpoints require the CSRF token (CSRF filter) for state-changing requests; configure the CSRF filter accordingly.

SAML/OAuth authentication can front AEM Forms; the authenticated principal is used for FDM calls and workflow task assignment.

Custom Adaptive Form components are built as client libraries (JavaScript/HTL) plus a component definition; they register with the Adaptive Forms framework via the component's cq:isContainer/field type.

Custom submit actions implement the SubmitAction OSGi interface (com.adobe.aemds.guide.common.SubmitAction) and are registered as an OSGi service with the submit action name.

Custom prefill services implement the PrefillDataProvider interface; register as an OSGi service and reference by name in the form's prefill configuration.

Document Services APIs are available as OSGi services (OutputService, AssemblerService, FormsService, ReaderExtensionsService); obtain via @Reference or ServiceTracker.

The Forms Document Services API (AEMaaCS) is an HTTP endpoint; authenticate with a service credential (JWT/OAuth) and post the request payload.

Custom workflow steps implement WorkflowProcess and are referenced by class name in the workflow model's process step.

Sling Models and HTL can be used to build custom form-related components; use the @Model annotation and adapt from SlingHttpServletRequest/Resource.

OSGi component configuration uses @Designate with an interface; configurations are stored under /apps/system/config or via the web console.

PDF Generator should run on a dedicated instance; conversion is CPU/memory intensive and competes with authoring if co-located.

Tune the Output/Assembler JVM heap and the OSGi thread pools; large PDF assemblies can exhaust heap and cause OutOfMemoryError.

Use the AEM Forms health check endpoints and /system/console/status-* pages to verify Document Service availability after deployment.

Deploy Forms packages via Package Manager or the Forms add-on installer; replicate forms/FDM/letters to publish instances for runtime rendering.

Enable debug logging for com.adobe.fd.* and com.adobe.aemds.guide.* packages to diagnose Document Service and form rendering failures.

Common rendering failures: missing font (PDF/A), missing template path, FDM data source connection failure, and missing ACL on referenced assets.

Assembler/Output jobs on JEE are asynchronous; poll the result or configure timeouts to avoid hung workflow steps.

Dispatcher must allow the Forms Portal and form submission endpoints; verify /content/forms and /bin/forms filters are not blocked.

Monitor Forms workflow instances and purge completed instances to prevent repository bloat; use the workflow purge tool.

FDM data source pools (JDBC) should be sized to the expected concurrency; exhausted pools cause submit/prefill timeouts.

Cache rendered PDFs where appropriate; Output service rendering is deterministic for identical template+data and can be cached by hash.

Staged deployment: install the Forms add-on on author, verify bundles, then replicate packages to publish; do not install the add-on on publish without the matching AEM version.

Use the AEM error.log and Forms-specific logs under crx-quickstart/logs to trace Document Service exceptions.

PDF Generator native library version must match the Forms add-on version; mismatches cause conversion errors.

For AEMaaCS, Document Services calls go to the Forms Document Services API; there is no local PDF Generator, so plan for API latency and retries.

Back up the Forms repository (forms, FDM, letters) before upgrades; FDM data source configs and secure vault keys must be migrated.

Sling Service Health Checks (/system/console/healthcheck) report Forms Document Service status; use for post-deploy validation.

Thread dumps (jstack) reveal blocked Document Service calls; PDF Generator conversions are the usual long-running threads.

Repository size and blob store growth from generated PDFs should be managed with the AEM offloading/GC tools.

Network: Forms Portal and submission endpoints must be reachable through the Dispatcher; check filter rules for /content/forms/af and /bin/forms.

FDM REST connector timeouts are configured in the data source; set connect/read timeouts to avoid hung form renders.

Use the Forms Portal draft/submission storage config to avoid unbounded repository growth from saved drafts.

Log level for com.adobe.fd.output and com.adobe.fd.assembler at DEBUG reveals DDX and template resolution errors.

Version compatibility matrix: Forms add-on, AEM service pack, and PDF Generator native libraries must all match.

Two deployment models: AEM Forms on OSGi (add-on on AEM) and AEM Forms on JEE (separate application server); feature parity differs (e.g., PDF Generator unsupported on AEMaaCS).

AEMaaCS supports Forms via the Forms Document Services API and Adaptive Forms; PDF Generator/Output local rendering is not available on Cloud Service.

The Forms add-on package is installed via Package Manager or the installer; it must match the AEM quickstart version.

On JEE, the Forms database (e.g., JBoss/WebLogic) stores process and document data; on OSGi, the JCR repository stores it.

Document Services on OSGi are OSGi services; on JEE they are web services. Client code differs (OSGi @Reference vs SOAP/REST).

Forms Portal is an AEM site component set; it requires the Forms add-on and is configured via the Forms Portal component and draft/submission services.

Forms Workflow on OSGi uses AEM Workflow; on JEE it uses Process Management (LiveCycle Workbench).

Health checks and bundle state in the Felix console verify a successful install; missing native libs break PDF Generator only.

bindRef maps a field to a data node; empty bindRef means the field is not submitted.

Data type mismatch between the bound node and the field causes submit/prefill errors; keep types aligned (string, number, date, boolean).

Panel binding with a repeating data node renders a repeatable panel; the panel's bindRef points to the array node.

Rules can be visual (no code) or code (JavaScript); code rules run client-side and can call guideBridge.

Submit action 'Submit to Form Data Model' invokes the FDM's configured submit service; the data is serialized per the FDM schema.

Prefill via FDM 'get' service populates fields at render; prefill via data XML merges into initial data.

Fragments are referenced assets; editing a referenced fragment updates all consuming forms.

Theme is a separate asset (LESS/CSS clientlib); the form references it by path.

FDM data sources: JDBC (relational), REST (OpenAPI/Swagger), SOAP (WSDL), OData. Each requires its connector bundle active.

FDM services: get (prefill), insert/update (submit), and read; associations come from foreign keys.

JDBC data source is an OSGi Data Source Pool config (JDBC URL, driver, credentials); the FDM references it.

REST connector generates services from the OpenAPI definition; SOAP from WSDL.

FDM is referenced by path in Adaptive Forms, IC, and workflows.

Store credentials in the secure vault (CryptoSupport) to avoid plaintext.

FDM associations expose navigation properties for binding nested panels.

FDM submit service failures usually trace to data source connection or schema mismatch.

Output renders XDP+XML to PDF; template must be an AEM Forms Designer XDP stored in the repository.

Assembler is DDX-driven: DDX describes inputs and the operation (assemble, convert, transform, extract).

PDF Generator converts Office/PostScript/images to PDF; requires native binaries; unsupported on AEMaaCS.

Forms service renders XDP forms; Reader Extensions applies usage rights honored by Adobe Reader.

OSGi: invoke via OSGi service interfaces; JEE: SOAP/REST web services, asynchronous with job IDs.

PDF/A output requires embedded fonts and no encryption.

Output options control PDF/A, tagged PDF, and font embedding.

Assembler DDX result element names the output document and sets options.

AEM Workflow models are authored in the Workflow Editor; Forms Workflow adds Assign Task, Submit to FDM, and Document Services steps.

Assign Task creates an AEM Inbox task; the task form is referenced by path and payload is in workflow metadata.

Custom steps implement WorkflowProcess (execute(WorkItem, WorkflowSession, MetaDataMap)).

MetaDataMap carries workflow data; arguments pass via the workflow args map.

Launchers trigger workflows on node events; forms workflows can launch on submit.

JEE uses LiveCycle Workbench processes (Process Management), distinct from AEM workflow models.

Workflow steps can call Assembler/Output to generate PDFs attached to tasks.

Workflow console shows instances, tasks, and history for troubleshooting.

Letters compose from data dictionary, text/layout fragments, and conditions; rendered to PDF via Output/Forms.

IC extends letters to multi-channel (print, web, mobile) with document fragments, charts, and a data model.

Data Dictionary defines data elements/types and maps to the XML schema.

Text fragments are reusable blocks with variables; layout fragments define structure and target areas.

IC web channel renders as an Adaptive Form; print channel renders via XDP layout.

Conditions use the expression editor to show/hide content by data value.

Correspondence assets live in Assets/Forms portal; replicate packages to publish.

Generation API (createCorrespondence) plus Document Services renders letters on demand.

AEM ACLs on forms, FDM, and letters govern access; users need read on the form and referenced assets.

Forms Portal authentication uses AEM auth handlers; anonymous access is governed by portal config and ACLs.

Reader Extensions usage rights are embedded in the PDF and honored by Adobe Reader.

PDF encryption (password/AES) via Assembler/Output options; PDF/A must be unencrypted.

Store FDM credentials in the secure vault or CryptoSupport-encrypted OSGi config.

Workflow task ACLs determine who can claim/complete tasks.

State-changing Forms REST calls require the CSRF token (CSRF filter).

SAML/OAuth principals drive FDM calls and task assignment.

Custom Adaptive Form components combine clientlib JS/HTL with a component definition registered with the Adaptive Forms framework.

Custom submit actions implement SubmitAction and register as an OSGi service with a name.

Custom prefill implements PrefillDataProvider and is referenced by name in prefill config.

Document Services OSGi interfaces: OutputService, AssemblerService, FormsService, ReaderExtensionsService; inject via @Reference.

AEMaaCS Document Services API is HTTP; authenticate with service credentials (JWT/OAuth).

Custom workflow steps implement WorkflowProcess and are referenced by class name.

Sling Models + HTL build custom form components (@Model, adapt from request/resource).

OSGi config uses @Designate with an interface; stored under /apps/system/config or web console.

Run PDF Generator on a dedicated instance; conversion is CPU/memory intensive.

Tune Output/Assembler JVM heap and OSGi thread pools; large assemblies can cause OutOfMemoryError.

Health checks and /system/console/status-* verify Document Service availability after deploy.

Deploy Forms packages via Package Manager or installer; replicate forms/FDM/letters to publish.

Enable DEBUG for com.adobe.fd.* and com.adobe.aemds.guide.* to diagnose rendering.

Common failures: missing font (PDF/A), bad template path, FDM connection failure, missing ACL.

JEE Document Service jobs are asynchronous; poll results or set timeouts.

Dispatcher must allow /content/forms and /bin/forms; verify filter rules.

Purge completed workflow instances to prevent repository bloat (workflow purge tool).

Size JDBC data source pools to expected concurrency; exhaustion causes submit/prefill timeouts.

Cache rendered PDFs by template+data hash; Output rendering is deterministic.

Staged deployment: install add-on on author, verify bundles, replicate packages to publish.

Trace Document Service exceptions in error.log and Forms logs under crx-quickstart/logs.

PDF Generator native library version must match the Forms add-on.

AEMaaCS: Document Services calls go to the HTTP API; plan for latency and retries.

Back up forms/FDM/letters and secure vault keys before upgrades.

Sling health checks (/system/console/healthcheck) report Forms Document Service status.

jstack thread dumps reveal blocked Document Service calls (PDF Generator conversions).

Manage repository/blob growth from generated PDFs with offloading/GC tools.

Dispatcher filter rules must permit /content/forms/af and /bin/forms.

FDM REST connector connect/read timeouts are set in the data source config.

Forms Portal draft/submission storage config prevents unbounded draft growth.

DEBUG on com.adobe.fd.output and com.adobe.fd.assembler reveals DDX/template errors.

Compatibility matrix: Forms add-on, AEM service pack, and PDF Generator native libs must match.

AEM Forms on OSGi = add-on on AEM; AEM Forms on JEE = separate app server with its own DB.

AEMaaCS supports Adaptive Forms and the Document Services HTTP API; no local PDF Generator.

Forms add-on version must match the AEM quickstart version.

JEE stores process/document data in the Forms database; OSGi stores it in the JCR.

Document Services are OSGi services on OSGi and web services on JEE.

Forms Portal requires the add-on and draft/submission services.

Forms Workflow on OSGi uses AEM Workflow; JEE uses Process Management.

Felix console bundle state and health checks confirm install success.

bindRef maps field to data node; empty bindRef is not submitted.

Type mismatch between node and field breaks submit/prefill.

Repeating panel binds to an array node.

Rules: visual or JavaScript code; code rules can call guideBridge.

Submit to FDM invokes the configured submit service.

Prefill via FDM get service or data XML merge.

Fragments are referenced assets; edits propagate.

Theme is a separate LESS/CSS clientlib asset.

Data sources: JDBC, REST (OpenAPI), SOAP (WSDL), OData; connector bundle must be active.

Services: get (prefill), insert/update (submit), read.

JDBC pool config holds URL, driver, credentials.

Associations from foreign keys become navigation properties.

FDM referenced by path in forms, IC, workflows.

Use secure vault for credentials.

Schema mismatch is a common submit failure.

FDM works across Adaptive Forms, IC, and workflow steps.

Output: XDP+XML to PDF; template in repository.

Assembler: DDX-driven assemble/convert/transform/extract.

PDF Generator: Office/PS/images to PDF; native libs; not on AEMaaCS.

Forms service renders XDP; Reader Extensions adds usage rights.

OSGi invocation via service interfaces; JEE via SOAP/REST (async).

PDF/A needs embedded fonts and no encryption.

DDX result element names output and options.

Large assemblies can exhaust heap; tune JVM.

Workflow Editor authors models; Forms steps include Assign Task, Submit to FDM, Document Services.

Assign Task creates Inbox tasks; form referenced by path.

Custom steps implement WorkflowProcess.

MetaDataMap carries data; args map passes parameters.

Launchers trigger on node events or form submit.

JEE Process Management differs from AEM Workflow.

Steps can generate PDFs via Assembler/Output.

Workflow console shows instances and failures.

Letters: data dictionary + text/layout fragments + conditions.

IC adds multi-channel (print, web, mobile).

Data Dictionary maps to XML schema.

Text fragments are reusable with variables; layout fragments define structure.

IC web channel = Adaptive Form; print channel = XDP layout.

Conditions show/hide content by data value.

Replicate correspondence packages to publish.

createCorrespondence API + Document Services renders on demand.

ACLs on forms/FDM/letters control access.

Forms Portal auth via AEM handlers; anonymous access via config and ACLs.

Reader Extensions rights embedded in PDF.

PDF encryption via Assembler/Output; PDF/A unencrypted.

Store credentials in secure vault/CryptoSupport.

Task ACLs govern claim/complete.

CSRF token required for state-changing REST calls.

SAML/OAuth principal drives FDM and task assignment.

Custom AF components: clientlib JS/HTL + component definition.

Custom submit action implements SubmitAction, registered as OSGi service.

Custom prefill implements PrefillDataProvider.

Document Services OSGi interfaces injected via @Reference.

AEMaaCS Document Services API is HTTP with service credentials.

Custom workflow step implements WorkflowProcess.

Sling Models + HTL for custom components.

OSGi config via @Designate interface.

PDF Generator on dedicated instance.

Tune heap and thread pools; large assemblies can OOM.

Health checks verify Document Service availability.

Replicate forms/FDM/letters to publish.

DEBUG com.adobe.fd.* and com.adobe.aemds.guide.* for diagnosis.

Common failures: fonts, template path, FDM connection, ACLs.

JEE jobs async; poll or set timeouts.

Dispatcher must allow /content/forms and /bin/forms.

Sling health checks for Document Service status.

jstack thread dumps for blocked conversions.

Manage blob/repo growth with offloading/GC.

Dispatcher filter rules for Forms endpoints.

FDM REST timeouts in data source config.

Draft storage config prevents unbounded growth.

DEBUG logs for DDX/template errors.

Version matrix: add-on, service pack, native libs.