I often get questions about the appropriate use of LiveCycle process variable types. Here is a cheat sheet that attempts to cover the major types.
- Document variable – This is a generic type used for storing and passing around bits. I commonly use it to read in and pass around .pdf, .jpeg, .doc, .xls, .tiff, .txt etc… Note: You can coerce types back and forth between Document and other types using the setValue operation. e.g. if you have xml data stored in a Document variable you can create a variable of type xml and map the data to the new variable using the SetValue operation. This is an important concept since some services expect a Document type.
- boolean, date, data-time, int, long, short, string – Basic primitive types
- xml – Even though you can use the Document type to store and pass around xml data, the xml type has a distinct advantage. You can associate a schema with the xml contents which makes XPath operations seemless. i.e. you can drill down into the structure using setValue operation to set/get data. Note: Some operations expect a Document type that contains XML, so after manipulating the data you can coerce it to a Document type using setValue.
- list – A list has a sub-type attribute, so this can be a list of any of the other supported types
- map – Maps come into play when working with services like Assembler, if a service expects a map you can use this type to build one up.
Form related variables:
- xfaForm variable – The most common use of this type is for rendering .xdp or .pdf to a user in Workspace. You can also use it for rendering Form Guides. This is a special type since it has an associated template and render service. Using the type allows you to pass the template and data around your process and render it on-the-fly to users as needed.
- Document Form variable – This is essentially interchangeable with the xfaForm type with one big difference; With this type you get an additional option in the advanced properties ‘Call the render service only once’. This allows you to pull a template from the repository and render it once, then pass around a persistent pdf copy of the form. Typically the submit type on the form will be PDF instead of XDP when using this type. This allows users to submit and pass around the entire PDF (not just the template and data). The primary use of this type is when working with Digital Signature, Certified Documents, Comments or any data that can’t be captured in a template/data model. When using a basic xfaForm variable the form is re-rendered for every user so maintaining a digital signature would not be possible. If you are interested in Digital Signature workflows please see my post: digital-signature-workflow-with-a-topping-of-reader-extensions
- Form variable – This type is typically used to display items in Workspace that do not require rendering such as a .swf file.
There are numerous other types that can be leveraged within your process. Typically you stumble upon these when examining the input/output of a service. As an example the invokeDDX/Assembler service returns a type of AssemblerResult; This particular complex type contains a varietey of information as well as the result file(s). To get familiar with these types, examine one with the setValue operation and discover the various attributes. Often you can pull out the data you want using the setValue operation. i.e. Location = MyDocVar, Expression = /process_data/assemResults/object/documents[@id=’result.pdf’]