Feeds:
Posts
Comments

Posts Tagged ‘XFA’

In LiveCycle ES2 Action Profiles streamline the creation and management of pre-fill and custom render services. If you are familiar with this pain point from a previous release you are going to absolutely love the flexibility and power of Action Profiles in ES2.

Let’s pre-fill a form for display in Workspace in less than five minutes…

LiveCycle Version: 9.0

If you get stuck… here is the collateral and completed LCA (.pdf w/ attachments): ES2_Prepopulate

Ingredients:

  • An XML schema (a sample schema is provided in collateral download if you do not have one).

Brewing Instructions:

  1. Launch Adobe LiveCycle Workbench and create a new application.
  2. Expand the application, right click version 1.0 and select New > Form, this will launch the new Form wizard. When promoted for a data model import your schema (The use of a schema is highly recommended, if you do not have a schema you can use a service such as http://www.hitsw.com/xml_utilites/ to create one based on sample XML).
    datamodel
  3. Adobe LiveCycle Designer will launch — Drag a few items from the Data View onto your form. This will automatically bind your form fields to the schema. Save and close the form. If you don’t see any items in the Data View, right click the Data Connection and specify the correct root node in the schema.
    DataBinding
  4. Launch the new process wizard by right clicking your application and selecting New > Process. Choose the following options in the wizard: When a user submits a task in Workspace… & Use an existing Form (select the form you just created)
  5. In the process double click the start point and click on the Manage Action Profiles button.
    ActionProfile
  6. Create a new Action Profile named Prefill.
  7. Make sure your newly created profile is selected and click the Create a Prepare Data Process button, select defaults and click OK. This is going to automatically stub out a new pre-fill process for you. Close the Manage Action Profile dialog and switch back to your process.
    PrefillConfig
  8. Notice that the new Action Profile you just created is now selected for the Workspace Starpoint. Action profiles are tied to a specific form, you can manage them by right clicking the form in the application view or from the startpoint Presentation and Data settings property editor.
  9. Save your main process and open the pre-fill process that was created for you (If you left the defaults intact it should be named [YourFormName]PrepareData).
    PrepareProcess
  10. Examine the stubbed out process — Notice that you already have an xml variable that is backed by the schema that your form is associated with; This is the advantage of using the wizards.
  11. Drag a SetValue operation onto the canvas from the tool bar.
  12. To configure the SetValue, the location should be the node you want to set in your form’s input data (Since you are using a schema you can simply drill down into it and double click it to build the XPath statement).
    x1
  13. For this example let’s set the field’s value to the task creator’s name. Double click the empty [Expression],  drill down into the Task Context and locate the Common Name, double click it and say OK to complete the SetValue operation. x2
  14. Deploy the application by right clicking version 1.0 in the application tree and selecting Deploy.
  15. Test the application: Right click the main process in your application view (or right click in the canvas) and select the Invoke operation. Choose the option to Open the selected start point in a web browser (another nice ES2 shortcut).
    prefilled

Additional Action Profile Tips:

  • For each step in a workflow you may have a different Action Profile e.g. you may want to perform a pre-fill when a process is initiated, but for the second user you may just want to use the default (no-op) profile so that the form is not modified. Action profiles give your this flexibility.
  • An Action Profile set is associated with a particular form. You can re-use the associated pre-fill and render processes but each form will have its own Action Profile definition/set.

Cheers,
_Seth

Advertisements

Read Full Post »

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.

vars

Primitive 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.

Complex Types:

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’]

Cheers,
_Seth

Read Full Post »

When using the xfaForm or Document Form variable it is extremely easy to set and get data if your form has an associated schema. Here is a basic recipe for setting and getting data from within an XFA based form in a LiveCycle process.

LiveCycle Version: 8.2.1

Here is a completed example with LCA: setget1

Ingredients:

  • One XFA Form
  • One Schema

Cooking Instructions:

  1. Generate an xml file that will represent your form data:
    <?xml version=”1.0″?>
    <customerData>
    <name>Joe Smith</name>
    </customerData>
  2. Generate schema based on the form data. There is a great little web utility that will do this for you here: Generate XML Schema
  3. Build a form based on the schema
    1. Create a new form in LiveCycle Designer
    2. In the Data View panel select New Data Connection
    3. Specify your schema and choose the option to embed
    4. Drag items from the Data View onto your form and save resulting file in the repository
  4. Specify the form you just created as the template for your xfaForm or DocumentForm variable. If you can see the schema when you select Schema Settings you successfully embedded the schema. You can also load an external schema here.
  5. Now you can XPath directly to the form fields using the SetValue activity within your process and set or get data. If you want to pre-populate data before a form is presented you can use this technique within your render service.

get

setget

embed

Note: I strongly recommend using schema. However, if you are not using one, you can still XPath to items within a form using the // syntax e.g.
/process_data/form/object/data/xdp/datasets/data//FirstName

Cheers,

_Seth

Read Full Post »