Form Data Model and Data Integration
FDM fundamentals
A Form Data Model is a logical schema over one or more data sources (REST, SOAP, OData, databases via JDBC). You create data sources, add data source services, define entities and their associations, and expose get/create/update/delete and custom service operations. Adaptive Forms, document fragments, and workflows consume the FDM.
Services and operations
Understand read vs write services, service arguments, and how FDM services map to AEM Forms workflows. Know that FDM operations can be invoked from rules, from the submit action, and from workflow steps. Associations let you navigate related entities; they do not automatically fetch data unless a service is invoked.
Traps
- Assuming an association implies automatic data retrieval.
- Forgetting that a data source must be reachable from the instance performing the call (Author vs Publish network paths).
- Confusing FDM entity fields with the underlying REST payload shape; mapping and transformations matter.
- Overlooking authentication configuration on the data source (basic, OAuth, etc.).
Worked example
Given a REST service returning {id, name, orders[]}, model Customer and Order entities, associate them one-to-many, expose a read service for Customer and a write service for Order. Bind the form to Customer, repeat the order panel over orders, and call the write service on submit. If data does not appear, check the service invocation rule and the data source authentication before suspecting the binding.