AEM Forms Architecture and Installation/Configuration
Core architecture
AEM Forms on JEE (the legacy Java EE stack) and AEM Forms on OSGi (the modern AEM-based stack) are different products with different deployment shapes. On OSGi, Forms capabilities ship as bundles on top of AEM Author/Publish, with Document Services (Output, Assembler, PDF Generator) running as OSGi services that may call native binaries. Understand the split between the Author instance (form authoring, FDM editing, Correspondence Management) and the Publish instance (rendering submitted/adaptive forms, serving Document Services to end users).
Installation and configuration concepts
Know the package/bundle layering: the Forms add-on package installs on top of a matching AEM service pack, and version mismatch is the classic installation failure. Configuration lives in OSGi Configurations (PID-based) and in cloud-style config nodes; Document Services need explicit configuration of fonts, watched folders, and native converter/reader paths. PDF Generator requires native libraries (converter, PDFMaker, Tesseract for OCR) whose presence and permissions are checked at startup.
Traps
- Confusing JEE and OSGi deployment models, or assuming a JEE-only feature exists on OSGi.
- Assuming Forms works on Publish without the add-on package; publish must be configured too.
- Forgetting that Document Services on Publish require separate configuration from Author.
- Treating service pack ordering as irrelevant.
Rule of thumb
Match versions first, then configure per instance type: Author for authoring artifacts, Publish for runtime Document Services. If a Document Service fails only on Publish, suspect missing native binaries or fonts, not code.