LiveCycle Enterprise Suite 2 (ES2) is Adobe’s enterprise offering for generating, capturing, and exchanging business information using integrated RIAs, secure documents and automated processes. LiveCycle ES2 helps businesses and governments more effectively deliver engaging applications across devices and channels to customers, citizens, and partners inside and outside the organization. New features of LiveCycle ES2 include personalized rich Internet application (RIA) workspaces, mobile and desktop access to business critical applications, a more collaborative and productive development environment, and a new deployment option in the cloud – allowing workers, developers and decision makers to bring value to their organizations faster than ever before.

If you want to know more, here is the full LiveCycle Enterprise Suite 2 Press FAQ sheet: LC ES2 Press FAQ External Final


In the theme of rapid application development. I am going to put LiveCycle Enterprise Suite 2 (ES2) up against the ‘Slap Chop’, with a series of blog posts over the next month (check out the category ‘ES2 Highlights’). I think you will see that we are far superior. Here is the competition:

New branding

Hey there LiveCycle developers,

You might have noticed that I recently re-branded my blog. Adobe recently launched the Adobe LiveCycle Cookbook on the Adobe Devloper Connection portal — So I have re-branded my blog so that is does not conflict.

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.


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


Here is a recipe for pre-populating a form for display in Workspace and routing it to another user. The first user initiates the form in Workspace, the form is pre-filled with their name and the time, the completed form is then routed to another user for approval. Note: In this example we will just route it back to the initiator for simplicity.  To change this modify the assign task in the main process.

The trick here is massaging the data in the forms render service so it is displayed for the  initiator task. To accomplish this I use a temp XFA variable in my render service.  Since my form template has an embedded schema I can easily XPath into the form variable to set/get data.

LiveCycle Version: 8.2.1

Completed example LCA: prepopandroute


  • A customized render service
  • An XDP template that has an associated schema embedded within it (if you need a schema you can generate one here)
  • An Assign User activity
  • A User Look Up activity
  • A sprinkling of SetValue
  • 2 Routes
  • 1 Decision point

Recipe: Please see the completed example above

Initiating the task


Second user gets a To Do item with completed form and can approve or deny


The custom Render Service:


Main Process:




At the bottom right of most activities, you will see a lightning bolt icon, simply make a new route off of the icon and choose the target exception you would like to handle. If the operation fails the exception route will be followed.

As an example we will catch an error that may occur during the application of Reader Extensions Usage Rights. This same technique can be used for all LiveCycle activities that have the potential to raise errors.

Here is a completed example with LCA: catchexception

Cooking instructions for creating a fault route:

  1. Identify the activity in your process that you would like to provide a fault route for
  2. Click on the lightning bolt icon at the bottom right of the target activity, then drag to create the fault route.
  3. When prompted select the exception that you will like to handle


If you write DDX this is a must have utility/sample. It is shipped with LC ES 8.2.1 but not deployed by default.

Cooking Instructions:

  1. Locate the adobe-assembler-ivs.ear
    [LC install dir]\LiveCycle8.2\deploy\adobe-assembler-ivs.ear
  2. Copy this into:
    [LC install dir]\LiveCycle8.2\jboss\server\all\deploy\.
  3. No need to bounce the server, just go to:
    http://%5Byour server]:8080/Assembler

Your DDX goes into the left pane (or) you can start with a sample that can be accessed from the menu. The inputs are specified on the right, and the key name is the folder name. The key will map to one or more files that are dragged onto the folder.