Hi, I am having issues with the sync between Appian data types and corresponding Java plugin objects.
In Appian, I have two CDTs called ‘AttachmentList’ and ‘AttachmentDescriptor’. They were generated from ‘AttachmentList.xsd’ and ‘AttachmentDescriptor.xsd’, respectively.
As seen in the screenshots above, ‘AttachmentList’ contains one field called ‘Attachments’, where ‘Attachments’ is an array of ‘AttachmentDescriptor’ data types. These two CDTs share the same namespace.
I have a custom Java plugin node that takes an AttachmentList data type as input. In the process model that uses this Java plugin node, I set up AttachmentList as shown below.
Here is the code in the Java plugin source file for setting up AttachmentList as input:
@Input(required = Required.OPTIONAL) @Type(name = "AttachmentList", namespace = "urn:placeholder") @Name("attachmentList") public void setAttachmentList(AttachmentList attachmentList) { this.attachmentList = attachmentList; }
The issue is that attachmentList.getAttachments() (from AttachmentList.java) is returning an empty ArrayList<AttachmentDescriptor> object because the protected List<AttachmentDescriptor> attachments variable is null. The call to getAttachments() should be returning the list of 2 AttachmentDescriptor objects that I had set up as input in the process model.
AttachmentDescriptor.xsd:
AttachmentList.xsd:
AttachmentDescriptor.java:
AttachmentList.java:
Discussion posts and replies are publicly visible
The Java list field must match the CDT/XSD element name exactly.Make AttachmentList.java use @XmlElement(name="Attachments") on protected List<AttachmentDescriptor> attachments;.Ensure AttachmentList.xsd has <xsd:element name="Attachments" maxOccurs="unbounded" type="tns:AttachmentDescriptor"/>.Regenerate CDTs, redeploy the plug‑in, and rebind the process model input so getAttachments() returns the items.Let me know if this works for you..
Thanks for your response, but I believe the Java list field already matches the CDT/XSD element name exactly.
From the screenshots I included:
-AttachentList.java already uses @XmlElement(name = "Attachments") on protected List<AttachmentDescriptor> attachments;.
-AttachmentList.xsd already has <xsd:element maxOccurs="unbounded" minOccurs="0" name="Attachments" type="tns:AttachmentDescriptor">.
I had also tried making AttachmentList.java use propOrder = { "Attachments" }, in case propOrder was case sensitive but that did not work either. Do you have other ideas?
Confirm the process model input is type AttachmentList, not Any Type.
Ensure the top-level complexType AttachmentList directly contains the Attachments element (no extra wrapper element level), and that the Java field is @XmlElement(name="Attachments") List<AttachmentDescriptor> attachments.
Then delete and recreate both CDTs from the XSDs and redeploy a freshly built JAR to eliminate any cached definitions.
As shown in the screenshots, process model input is type AttachmentList. Top-level complex type AttachmentList directly contains the Attachments element with no extra wrapper element level. The Java field is @XmlElement(name=Attachments") List<AttachmentDescriptor> attachments.
I also had already tried deleting and recreating both CDTs from the XSDs and redeploying a freshly built JAR to eliminate any cached definitions.
When I tried printing the attachmentList object in the Java code, it returned "placeholder.AttachmentList@3ce56992" and attachmentList.attachments was null. Is that to be expected? Wondering if it could be due to a mismatch in TypedValue between Appian and Java.