I had a great time at Adobe MAX 2009. I talked to many users of LiveCycle ES and got some great feedback about the documentation. I don’t mean you all love our docs, but I mean you provided some great insights into how we can improve. (But some of you do apparently love our docs!)
Some of the things you asked for:
- More examples
- PDF versions of Help
- More access points to Help via F1
- Make it easier to find information on Adobe.com
These issues are all on our radar.
For one, we are working on mining the Adobe.com LiveCycle ES forums for examples. I also hope for more suggestions from you on our LiveDocs pages.
Also, take a look at the Beta version of the Community Help AIR application. Let us know what you think. This new tool makes all the information that you need available from one location, and includes ‘Livedocs’ commenting and other easy ways to keep in touch with the user community. This is only implemented for a few Adobe products right now. Would you like to see it used for LiveCycle?
If you try to add a list to a list in a process, you’ll get unexpected behavior — because it’s not supported. Nor can you add a list to a map, a map to a list, or (you guessed it) a map to a map. If you try to add a collection to another collection, each item in the first collection is added to the second, not the collection itself.
LiveCycle ES provides a sample application called Output Installation Verification Sample (IVS). The sample is a web application that interacts with the Output ES service to generate PDF or printed output. After you deploy the application, you can browse to the web page it provides and render form designs for testing purposes. So, the Output IVS application enables you to debug the Output ES part of your solution in isolation from the rest of your LiveCycle ES application.
If you are handy with the Java language, you probably already know how to use the Execute Script service to interact with the process data model. The LiveCycle Workbench ES Help describes all the methods that are inherently available to the Execute Script service for getting and setting process variable values. (See patExecContext reference). However, you can also code against any of the Java libraries that are available to the Java virtual machine that runs the LiveCycle ES server.
A common pattern that’s used in process design is establishing ‘constant’ values that you refer to a few times in the process. To establish a constant value, you either:
- Create the variable and configure the default value at design time (i.e. in Workbench ES), or
- Save a value that is either passed into the process or returned by a service operation at run time.
You know those notes that can be added to tasks using Workspace ES? (If you don’t, you can take a look at Working with notes and attachments). The Workbench ES help explains how to retrieve those notes as a document value after the form is submitted, but (believe it or not) the help leaves out a few details about how to reference the information in those notes.
LiveCycle ES Update 1 introduced the ability to use DDX files and the Assembler service to invoke the following LiveCycle ES services:
- Reader Extensions
- Generate PDF
Typically, these services would be invoked using a process (via LiveCycle Workbench ES) or custom client application (via the LiveCycle ES Java API or web services). Consider using the DDX file and Assembler instead to simplify your process diagram. Or maybe you’re a power DDX user but not so good with Java or another programming language needed to create web service clients.
Note: Information about all of the DDX elements that are discussed in this posting can be found in DDX Reference.
Here are a few easy ways to improve performance when using the Output service with forms.
A user contacted me recently with a question about the “Multiple instances synchronization” process modeling example in the Workbench ES Help. I realized that a mistake in the process diagrams had caused the confusion (Sorry Lachlan, and thanks again for pointing it out).
The example shows how to converge a number of process branches or subprocesses that are executing independently. This scenario is useful if you want your main process to execute the same subprocess or branch multiple times, and then continue only after all of the instances of the subprocess are complete.
To converge the instances, each one throws an event that the main process receives. A loop is used to count the number of events that are received. The loop executes until the number of received events equals the number of instances that were executed.
The problem with the diagrams for the Multiple instances synchronization example is that they did not include the loop (my bad). Below are the diagrams with the loop included.
Gateway implementation (click to see larger image)
Events implementation (click to see larger image)
For more modeling examples, such as Multiple independent instances, see Process diagram modeling examples.