I85PREP
⌘ K
AEM Forms Backend Developer Professional study materials
AEM Forms Backend Developer Professional study resources

Forms Workflow step cannot resolve FDM service in a custom OSGi bundle

AEM Forms Backend Developer Professional · Put your knowledge to work in context.

All case studies

Forms Workflow step cannot resolve FDM service in a custom OSGi bundle

A developer builds a custom OSGi bundle (com.acme.forms.workflow) deployed to AEM 6.5 Forms. It implements a WorkflowProcess that, at a Forms Workflow step, must call a Form Data Model service to fetch a customer record and write it to workflow metadata. The bundle imports com.adobe.fd.fd.core and com.adobe.granite.workflow.api. At runtime the step throws NoClassDefFoundError: com/adobe/fd/fd/core/FDMService and, after adding the import, ServiceNotFoundException. The FDM is authored on author and published; the workflow runs on publish. The developer's @Reference uses service = FDMService.class with default cardinality. The bundle is Active in the Felix console, but the component is unsatisfied. The FDM's data source points to an internal REST endpoint reachable only from author.

1. Explain why the component is unsatisfied and why the FDM call fails on publish, and give the fix.

Read the worked answer

Two distinct failures:

  1. NoClassDefFoundError / unsatisfied component: the bundle's Import-Package does not include the FDM API package actually exported by the AEM Forms bundle (the package name must match the exporter's export, not a guessed one). With maven-bundle-plugin, use <Import-Package> wildcards and verify with bnd output / Felix "Bundle" view which bundle exports the FDM service package. An unsatisfied @Reference with default mandatory cardinality keeps the component inactive; confirm the service is registered (Felix Services tab) and that the reference package is imported.

  2. ServiceNotFoundException at runtime on publish: even with a correct import, the FDM service may not be active on publish, or the FDM/data source is not deployed there. The data source points to an author-only REST endpoint, so on publish the FDM cannot resolve the data source and the service call fails. Fix: deploy the FDM and a reachable data source to publish (or route through an accessible endpoint), and verify the FDM is published, not just authored.

Also confirm the workflow model and the custom step are deployed to publish, and that the step's process class is in an Active bundle.

2. The developer wants to make the reference optional to 'avoid the error.' Evaluate this and describe a robust design.

Read the worked answer

Making the reference optional (cardinality = OPTIONAL) only hides the failure: the component activates but fdmService is null at call time, producing an NPE or silent no-op in production. It converts a startup error into a runtime data bug - worse for a workflow that writes customer data.

Robust design:

  • Keep the FDM reference mandatory so misconfiguration fails fast at activation.
  • Add a timeout and retry around the FDM call, and handle FDMException explicitly, failing the workflow step with a clear error rather than writing partial metadata.
  • Validate the data source is reachable from the publish tier at deploy time (health check).
  • Use a service user with least privilege for the FDM call and map it via ResourceResolver/ServiceUserMapped.
  • Add logging and metrics for FDM latency/failures.

If the FDM genuinely may be absent in some environments, use a target filter and a guard that fails the step with a diagnostic message, not a silent optional injection.