This content has been marked as final. Show 12 replies
A document variable (com.adobe.idp.Document) can contain pretty much any type of information. Typically that's the data type LiveCycle uses to store the PDF. It also uses that data type to store XML and other things.
When you define your xfaForm variable, you point to a file in the repository to be the form template. The form template doesn't get added to the xfaForm variable. It's just a pointer to it. The xfaForm variable will just contain the data for the form template with a pointer to the form in the repository.
In your case, you use a PDF in you xfaForm variable. That will still work, but you won't be able to write the PDF to the file system by writing the xfaForm variable since it just contains a pointer to the pdf in the repository.
I'm not sure what your process actually does but if you want to write the PDF to the file system, you'll need to find a way to put that PDF back into a "document" variable before you use the "Write Document" operation.
You can use the Read Resource Content operation from the Repository service to read the PDF from the repository and that will put it in a "document" variable.
If you can explain a bit more what you are trying accomplish (the overall picture), I could be more specific on what you need to do.
I've added a Read Resource Content step but haven't been able to figure out what the Resource Uri should be set to. Conceptually, this must be the pointer you mentioned to the PDF within the repository - but I'm not clear on exactly how this pointer is obtained or referenced... I tried to use an XPath expression that refers to "/process_data/RealEstateForm" but this throws an exception.
Basically all I'm trying to do is create a simple form that a user can enter data in and which can then be saved to disk as well as emailed as an attachment. I'd also like to be able to have the user view previously completed forms and select one to initiate anoterh workflow (I haven't yet started to try to figure out how this would be done - if you have any quick suggestions I'd apprecaite it)...
The uri from the repository is simply the folder structure where the form is located. For example "/MyFolder/MySubFolder/MyPDF.pdf"
Using xPath you just get the value of the variable. If you specify /process_data/RealEstateForm you would get the value of a variable called RealEstateForm.
But ReadRessource takes a URI to the repository (basically a string).
I have another question about your process. How are you planning the user to fill the form? Are you planning to use LiveCycle WorkSpace or a different mechanism? That may impact the way you'll do things.
I had also tried setting the Input Variable to /BDI/Forms/RealEstateForm.pdf (i.e. the same valaue as the "Template URL" for the form). When I do this I end up having the form created on the servers hard drive, but it does not contain the data that I entered...
To answer your question, we currently plan to have the user enter the forms through LiveCycle WorkSpace. It is possible, however, that we may also want to have some users submit PDFs via email which would then trigger the workflow... even in this case, however, we would still want users to be able to browse completed forms and utilize these to initiate other workflows - i.e. this application relates to real estate change management and approvals - so a PDF could be created, approved, and then stored before being retrieved and modified as input to another approval workflow.
It makes sense the form doesn't contain any data because you read it from the repository and at that point the form is blank.
Here's what I think you should do.
Create a variable of type "Document Form". This is a more appropriate data type to hold the pdf. Make sure it's of type IN. Browse to your PDF in the repository to set the URL.
The other thing you need to make sure is that the submit button on your form submits the whole PDF and not just the data. Using LiveCycle Form Designer make sure the "Submit As" is set to PDF and not XDP. There are advantages to send just the data, like route evaluation, size on the network, but then you have to recreate the PDF with the data later on if you want to archive. This may or may not be the best option. It depends of your process and architecture.If you have a lot of conditions based on the form's data, then sending the data might be a better option and just create the PDF at the end.
Now, since the submit button is set to submit the whole PDF, you can extract the pdf from the "Document Form" variable using xPath and put it in a "document" variable for the "Write Document operation". You can use the follow xPath in a SetValue to do it:
/process_data/@myOutDoc = /process_data/myDocForm/object/document
This should contain all your data.
I'll definately want to have access to the form data so that Routes ect can be evaluated using XPath expressions. Can I not have both the PDF and the data accessible in the process without having to somehow generate the PDF... i.e. I noticed that on the Submit button setup you can choose "XML Data Package (XDP)" as the "Submit As" type
and then select the "PDF (Includes Signaturs" check box? will this not result in the form data being available through the xfaForm variable and the PDF being available through a variable of type "Document Form"? When I try this I get an ALC-WKS-007-043 error... If I do have to recreate the PDF, what service do I use to do this?
there are several ways you can get the data. If you submit the PDF, then you can extract the data on the server side, but then you'll need to extract the data after every user step (since it might change). If you send the XDP, the pdf can be stored in one of the XML node but then you need to go and extract it (not user friendly either).
The easier way (that I would recommend) is to use the xfaForm variable with an XDP. Then configure the xfaForm variable to point to the XDP in the repository and configure the render service so it creates a PDF when the form is being rendered in workspace (see the following post for the settings : Jasmin Charbonneau, "Creating your first application" #1, 4 Sep 2007 5:29 am). Then it'll be easy to use the data for your logic since the xfaForm variable will contain the data
At the end you can just use the RendePDFForm operation from the Forms service to create the PDF and save it to the file system.
My suggestion is:
- Go back to using the xfaForm as your primary form type. This will allow you to manipulate the data via xpath, etc.
- Create a document variable (do not specify "in")
- Use the Repository component to read the empty PDF document from the repository into this document variable. (I think you've already gotten this going.)
- Use the Form Data Integration component to inject the data from your xfaForm variable into the PDF.
- Use File Utils to save the PDF to the file system
I haven't explicitly tested this, but the following Xpath expressions should work:
XML Data: deserialize(serialize(/process_data/xfaInputForm/object/data/xdp/datasets/data/*, true))
PS Form data integration may require an XDP envelope - can't remember if it does or doesn't.
If you do require it, you can either add it using SetValue, or use our operation for this. See:
insertXdpEnvelope in http://avoka.dnsalias.com/confluence/display/Public/XML+Utilities+DSC
You can download the component to try it out here:
PS2 I just read Jasmin's response. We're both basically saying the same thing, but he's recommending the use of RenderForm, while I'm suggesting Form Data integration. You can use either, but Form Data integration is a bit simpler.
I had intially attempted to follow Jasmin's instructions, then tried to revert the workflow to use of the xfaForm variable - now, for some reason, the workflow goes to completion the moment the "Complete" button is pressed when first creating the form... I can't find any clear error in the server log - only the following... I've spent hours not looking at this without avail - if you can offer any suggestions as to how to fix things I'd appreaciate it...
2007-11-21 09:28:58,265 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/DocumentManager].[Docum entManagerServlet]] Servlet.service() for servlet DocumentManagerServlet threw exception
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j ava:252)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j ava:202)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.ja va:159)
at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java: 81)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11P rotocol.java:744)
2007-11-21 09:30:23,546 INFO [STDOUT] Nov 21, 2007 9:30:
I was never able to solve the problem above, but created a completely new workflow...
I've now tried both the Render Form and the Form Data Integration object but am unable to get either to work. The basic problem is that I'm unable to understnad what the imput and output parameters really mean and, hence, to set them properly. I think the main problem is that I haven't been able to locate any document that clearly explains what the various variables and data types really are. i.e. my xfaForm variable is, as far as I can gather, a data structure that references XML data associated with the process (defined in the xsd file) as well as a pointer to the repository where the actual "form" (whatever that means) is stored. Is there actually a PDF document stored in the database that some part of the xfaForm variable points to?
- Form to Render - I presume that I would set this to the pointer to the form in the repository, but I'm not clear on how to reference it.
- Form Data - I presume that this would be an xPath pointer to the forms data - would this be "/process_data/BDIForm"?
- Rended Form - I presume that this is my Document Form variable.
I'm sorry if I'm not "getting it", but again, I find the documentation very confusing and the samle applications haven't helped me really understnad what is going on.