Error in in importing Xfa Json caused while creating adaptive form from xdp template

Hi ​@SmrithiGo 

This specific XFAJSONTransformer NPE when hitting guideContainer.xfajson is almost always bad XDP binding or a broken environment.

1.Verify Forms is correctly installed

• Check AEM 6.5 SP and Forms add‑on match (e.g. 6.5.21 + Forms 6.5.21) from Tools > Deployment > Product Info.
• In /system/console/bundles ensure these bundles are Active (not Installed/Resolved):
  • com.adobe.aemds.guide.aemds-guide-core
  • com.adobe.aemds.guide.aemds-guide-core-impl
  • com.adobe.aemds.guide.aemds-guide-addon

2. Prove your XDP is good and the model binding works

• Upload a tiny test XDP (1–2 fields, created in Designer) into DAM: /content/dam/formsanddocuments/test/sample-form.xdp.
• Create a new Adaptive Form (Foundation):
  • Form Model: Form Template
  • Template: sample-form.xdp
• Open it and check the Data Model Objects tab:
  • If the fields appear, the environment is fine; your original XDP or its fragments are the problem.
  • If even this fails with the same error, fix step 1 (versions/add‑on) again until this sample works.

3.Fix the broken form by rebasing on a clean XDP

• Open your failing form's Properties > Form Model:
  • Ensure Select From = Form Template.
  • Point it to a freshly uploaded, validated XDP (open in Designer > run consistency check > save > upload again).
  • Do not fight the existing AF. Instead:
    • Create a brand‑new Adaptive Form using that fixed XDP (Form Model = Form Template).
    • Confirm the Data Model Objects tab now shows fields (no xfajson error).
    • Copy any custom layout/rules from the old form into the new one and delete/retire the broken AF.

In practice, once a sample XDP works and you recreate the Adaptive Form from a clean, validated XDP, this error disappears unless you hit a very rare product bug.

Hi ​@SmrithiGo,
 

Yes, this pattern is known: when an Adaptive Form (foundation components) is created from an XDP and guideContainer.xfajson throws a XFAJSONTransformer NullPointerException, it almost always means the XDP model couldn’t be converted to the internal XFA JSON representation.

The logs you shared:

com.adobe.aemds.guide.xfa.XFAJSONTransformer Error in transforming xfa json:null
java.lang.NullPointerException
...
com.adobe.aemds.guide.service.impl.GuideModelImporterImpl Error in importing Xfa Json
...
Caused by: com.adobe.aemds.guide.service.GuideException: null
...
Caused by: java.lang.NullPointerException: null

This also matches internal cases we’ve seen with multiple forms customers as well and this is because:

• the XDP is corrupt or incomplete from an XFA point of view, or
• the XDP depends on a schema/fragments that are not present/embedded in AEM, or
• the XDP uses constructs not handled by the transformer (bad SOMs, invalid subform structure, etc.).

To narrow it down, could you please run through the following checks:

1. Validate the XDP in Designer

   • Open the XDP in AEM Forms Designer.
   • Run the syntax/validation checks and fix any reported XFA issues.

2. Confirm schema handling (if the form is schema-based)

   • Check whether the XDP is bound to an external XSD.
   • If so, either embed the schema into the XDP or make sure the XSD is also available on AEM in the expected path.

3. Check fragments and references

   • If the XDP uses fragments, ensure all fragment XDPs are uploaded to AEM (via Forms → Forms & Documents) with the same folder structure as the original project.
   • Missing or moved fragments are a common cause for this NPE.

4. Re-upload the XDP using Forms UI

   • Delete the existing XDP asset in AEM.
   • Re-upload it via Forms → Forms & Documents → Create → File Upload (not via CRX/Package Manager), then recreate the Adaptive Form using “Form Template” as the form model.

5. Sanity check with a simple XDP

   • Create a very simple XDP (one text field), upload it, create an AF from it, and see if that renders.
   • If the simple XDP works but your complex one fails, the problem is in the content of the original XDP rather than the environment.

If you can share the following, I can help you pinpoint it more precisely:

• The AEM path of the XDP (e.g. /content/dam/formsanddocuments/.../A123-abc.xdp), and
• Whether it is schema-bound and/or uses fragments.

Based on that, we can decide whether this is something that can be fixed by adjusting the XDP/assets or whether we need to involve product engineering for a transformer edge case.

Thanks

Hi ​@SmrithiGo 

Assuming you are referring to the XDP XFAJSONTransformer NullPointerException from previous discussion..

The Root Cause: Your AEM environment and configurations are completely fine. The error is strictly a payload crash. AEM's internal web parser is choking on a single corrupted element, missing fragment reference, or empty data binding inside that specific XDP.

The Most Efficient Solution:  Force the form to reveal the broken node mechanically:

1. Copy & Split: Take a local copy of the failing XDP and delete exactly half of its contents (subforms or fragments).

2. Upload & Test: Upload this halved XDP to AEM and try to create an Adaptive Form.

3. Evaluate:

   • If the Data Sources load perfectly: The corrupted node was in the half you deleted.

   • If it still throws the NPE: The bad node is in the half you kept.

4. Repeat: Keep taking the broken section and halving it. Within 3 to 4 quick tests (under 10 minutes), you will isolate the exact field, row, or fragment causing AEM to crash.

The Fix: Once you isolate the specific element, you will almost always find one of three things:

• An orphaned fragment: The XDP references a fragment path that doesn't perfectly match the /content/dam/formsanddocuments/... structure in AEM.

• A null binding: A field, table row, or subform lacks a proper internal Name, which crashes the JSON parser.

• Malformed Rich Text: Hidden XML entities caused by copy-pasting text directly from Microsoft Word.

Fix that single isolated element, and your form will instantly work.

Thanks
Partyush Kumar