- Mark as New
- Follow
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report
"I am guessing it is because the xfaform variable is still bound by the form template that I had configured it for and therefore starts of with that empty form template rather than with the data that was submitted to the email end point"
That's correct. The form referenced in the xfaForm variable is going to be loaded and it will call the render service to render it. Now if you look at the properties of the render service, one of the parameter that is passes is Form Data. You can set that parameter to the variable that contains the data, which would be your input variable.
"How do we get the data from the PDF that was submitted to the email endpoint into the xfaform variable that would get set if we use Workspace?"
You can change the Form Data parameter of the render service, but then all the users step will populate with the same data. If you have multiple users what you can do instead is set the data node of the xfaForm variable using xPath. Something like
/process_data/myXmlData = /process_data/@myinputDoc (You might have to put the document content into xml))
/process_data/myXFAForm/object/data/ = /process_data/myXmlData (Assign that XMl to the data node of the xfaForm variable)
"...and setting the MyFormDocument (xfaform) input variable to the document variable that was set earlier from the email endpoint"
If your process expects an xfaForm variable, you need to provide it a xfaForm variable. You can't just give it a document varibale with data because you'll get the coercion error. That's why I was suggesting to have a setValue before calling the subprocess to set that xfaForm variable properly.
If you're not planning to initiate from WorkSpace, then I would stick with the first technique which is to have only one input variable of type document.
Jasmin