LiveCycle 8.2.x Form Guides is now LiveCycle 2.5 Guides


LiveCycle Form Guides has been updated to LiveCycle Guides, the blog for it can be found at:

LC Guides are authored in LiveCycle WorkBench and can be built leveraging a XFA based XDP /PDF or an Adobe Data Model.

LiveCycle 8.2.x Form Guides are automatically migrated to the new Guide format when openned in Guide Designer in WorkBench.

Here is a link that I hope is helpful:


Offline Form Guides via PDF

This post describes how to take any deployed Form Guide and embed it in a PDF so that the Form Guide may be emailed or used offline. The resultant PDF looks and behaves just like any other XFA based PDF as far as LiveCycle processing or Reader/Acrobat is concerned. The Form Guide’s data is stored in the standard XFA Datasets part of the PDF.

Adobe Reader/Acrobat 9.0 is the minimal client requirement.

Here is a sample Form Guide delivered as a PDF.

The basic component is a generic base bootstrap PDF into which a Form Guide SWF is added as an Attachment. The bootstrap PDF has some XFA script and an embedded SWF Loader app that invokes the script to find and load the Form SWF. The submission process uses Readers Email option to submit back to the Server process. The target email account is defined in the XFA Script along with the format of the submission which can be the whole PDF or just the xml data.

The PDF will need to be Reader Enabled to allow Reader users to Save the PDF to their disk.

It is also possible to include a optional “document view” XFA based PDF, but requires a minimum of Reader/Acrobat 9.2. The data entered into the Form Guide can automatically update the PDF document (it is expected be a non-interactive document, as data only flows in one direction)

Attached are a White Paper describing the full process flow of generating a PDF of this flavor, sample Guides in PDFs, the basic source Bootstrap PDF and the source for the embeded SWF Loader. The Bootstrap PDF can be loaded into LiveCycle Designer in order to see/modify the XFA script. There are a few options that can be activated/deactivate by modifying a list of supported features defined at the top of the script object.

This technique can also be used to attach a Flex App instead of a Form Guide, as long as the App implements the following functions at the Application root:

function getData():String – returns XML as a string
function setData(xmlData:String):void
function validate():Boolean

The supplied BootStrap SWF Loader can be easily extended to handle many different unique requirements. Those features can include displaying buttons that allow the user to click and Print/Save/Email/ the document without actually seeing the document view or importdata/exportdata or process more than one SWF APP attachment. Note that the PDF will need to be Certified to allow the Print option to work.
Let me know if more information is desired on how to do this.

More Samples:

FormGuide with Document View PDF attached as well
Another FormGuide with Document View PDF attached as well

Source Files:


The cookbook process for creating a generic PDF for delivery of RIAs is Patent Pending.

Other solutions to leverage PDF as an RIA container can be found at:

Patch to Guide Builder SDK for FlexBuilder Usage

Form Guide components need to be built using the same SDK as the core Form Guide Libraries. Flex Builder has updated its’ SDK but since the Guide Buider and the LC Server where shipped using a 3.0.1 version of the sdk, the default in Flex builder no longer works.

Guide Builder’s version of the Flex SDK is missing a file that Flex Builder needs in order for it to recognize the sdk version. Without the identifier file Flex Buidler assumes it is a 2.x sdk and does not load it correctly.

Click, download and save this flex-sdk-description.xml file into the Guide Builder flex-sdk directory.

The Default install location is:
C:\Program Files\Adobe\LiveCycle Designer ES\8.2\plugins\GuideBuilder\flexsdk

After applying the simple patch, in Flex Builder on your Project Properties, select “Flex Library Compiler”, (configure sdks if needed), and select “use a specific SDK”. Point to the Guide Builder 3.0.1 version of the SDK.

Form Guide in an AIR app with a PDF

Here is a sample that is to be taken “as is”, as just a basic sample of how to make an AIR app that has a Form Guide in it that can share data with a PDF that is also in the AIR app. It was created by one of my collegues just to see if it could be done. It is not an officially support solution at this time, but numerous people are starting to build apps of this type. Please keep that in mind. You can retieve your Guide SWFs to use from the temporary Preview directory.
This is a Flex Builder 3.0.1 project zipped up.

Download file

NOTE: TOO MEET the USER LICENCE AGREEMENT for Guide Builder, you must use LiveCycle Forms Service to generate the Guide SWF. The use of the Designer Preview is for Development purposes only.

To get just the SWF returned (instead of the html with callbacks) from the normal LC FormGuide request add/set “cb=1″ to the request.

The GAClientRuntime.swc and XFAModel.swc Library files can be found in LC Designer’s install directory under plugins/GuideBuilder, the project will need to point there on your system.

Patch for Guide Builder Preview

This post is about an issue I uncovered while assisting a client with creating a Form Guide.

Under some circumstances the “history.js” script that ships with Guide Builder, as part of the Guide Preview processing, can adversely affect the Guide and PDF communication messaging as well as have a possible performance impact while previewing. Attached is an updated file for the Guide Builder that will allow preview to work correctly and more effieciently. Basically, I have just disabled the history processing which was of no value in Preview anyway.

Included in this post is a replacement version of the “history.js” file. It should be copied into the installed Guide Builder program directory’s “bin” subdirectory.

Steps to apply the patch:

1. Make sure there are no instances of Guide Builder running.

2. Download ‘history.js’ file, then Copy “history.js” into the “bin” subdirectory of Guide Builder.

For WorkBench installations:
C:\Program Files\Adobe\LiveCycle ES\Workbench ES\Designer ES\8.2\plugins\GuideBuilder\bin

For Designer standalone installations:
C:\Program Files\Adobe\LiveCycle Designer ES\8.2\plugins\GuideBuilder\bin

3. Open Guide Builder and do Previews.

Please let me know if this post was of value to you.

Model Viewer Layout

One of the Form Guide developers produced a ‘Model Viewer layout’ which is used for debug purposes. It allows you to see the XML data of the moment, and even to change that raw XML and immediately reload it so you can test out various scenarios. It also shows you the XML data as a DOM and it also shows you the full Form Object model.

It’s easy to use, just drop it into the project for your custom SWC so as to make it available to Guide Builder. Then add a panel and assign it this Model Viewer layout. Navigate to that panel whenever you want to see the current state of things.

Disclaimer: This layout is provided "as is" and not as a supported part of the product.

Download ModelViewer.mxml

Including Info from any HTTP Header

Sometimes customers wish to transfer information from the context of the client session into the Form Guide. In particular, if the Guide is hosted inside LiveCycle Workspace ES, selected information that is in the HTPP Headers is desired to be made available to the Guide. This can be done.

Workspace ES provides all, yes all, not just a subset, of the HTTP headers to both the render service and the submit service. They are available to those services for any use that they see fit. Unfortunately there is an unexposed link in LiveCycle ES that makes this harder to accomplish. FYI: that link is properly exposed in LiveCycle ES Update 1. Nevertheless the feat can still be accomplished in LiveCycle ES.

Let’s say that you have an HTTP Header of special interest called ‘yourChoice’. We’ll go through the steps needed to have your render service ‘see’ that header.


First, in the render service, create a new process variable. I’ve called it ‘allHttpHeaders’. Mark it as type ‘map’, and mark it as an ‘input’ variable.


Save your updated render service. In your main process, open up the User Service step that references that render service. Examine the process’ Variable list. Naturally it will have a variable that is the ‘Document Form’ that is to be rendered. If you double click on that you will see something like the following:


Now click on Advanced Settings … in order to see:


Because ‘allHttpHeaders’ was defined as an ‘Input’ variable it shows up in these options — begging you to map something to it.


ASIDE: BTW, since I’ve shown the above screen, notice the ability to put the User’s Common Name into a process variable that you have defined as an Input variable in your render service. I happened to name that process variable, a simple string, as ‘UserName’. Above you can see that there is a built-in source for that information under the ‘task’ group of items. This is a great way to get the actual Workspace ES user’s name into your form. This is often an issue since one can’t know which user will process the form until he/she actually chooses to do so (e.g. has taken the task from a group/shared queue). Using the above, your form can show exactly which user is processing the form.


Ok, back to extracting info from any HTTP Header. Your source for a map of all the HTTP Headers comes from the Custom Configuration area of data items. So change the default ‘xpath’ entry in the dropdown to Custom Configuration. If you click the "…" button on the right hand side you will see: <unfortunately>


Alas, there is no entry in there (in LiveCycle ES) that is what you want. ‘environmentBuffer’ gives you some of the HTTP Headers but not all of them. In LiveCycle ES Update 1 there is another entry in the dropdown named ‘httpHeaders’. That would be the one you want. In LiveCycle ES you are still able to simply key that in. You would end up with:


Great! Now your process is providing your render service with all of the HTPP Headers. Save your process, and re-open the render service. Ok, I could’ve done this all at once but I wanted to walk through the steps.

What I want to show now is how you extract information from the ‘allHttpHeaders’ map. You could stuff such data into the data file and have it rendered. You might use it in some other way in some other custom step of the render service. For now, I’ll just show extracting information out of the map and placing it in a simple string variable — which you can later use for any purpose you like. First we need that string variable as a place to store the HTTP header of choice. Let’s create a string variable with the name ‘myHeaderOfInterest’.


Not a lot to that. Note that it is a string, and it is neither ‘Input’ or ‘Output’. We don’t want it showing up anywhere begging to be mapped. It is simply an internal process variable for use inside this render service.

Now for the extraction. As usual we will use the standard SetValue operation to access the data elements in question. Drag on a SetValue operation; under the Properties tab add (+) a new assignment. The left hand side — the target location for the value assignment — is easy. Just use the [...] mapping button and double click on ‘myHeaderOfInterest’. The right hand side — the expression value to be set — is a bit more interesting. To start, use the [...] mapping button and double click on the ‘allHttpHeaders’ entry.


After the double click you will have only the /process_data/allHttpHeaders part. You have to key in the [@id='yourChoice'] part yourself. There is no way, at render service design time, that LiveCycle can know what ids will be in the map at runtime and hence you have to specify that on your own. Of course, ‘yourChoice’ is a pretty unlikely name of an HTTP Header of interest but I’m sure you can supply, well, your choice

You will end up with a SetValue assignment as follows. Your chosen HTTP Header is in a string that you can work with as desired.


   Add the HTTP Header context to your oyster.


Video: Customizing form guides

You can customize form guides using the Guide Builder plug-in of the LiveCycle Designer ES software. With that you can select various built-in panel layouts and navigation styles. You can also choose from in-the-box form guide layouts as well as doing the usual styling, all without the need of programming.

This tutorial covers the creation of custom form guide libraries. It is about having your way with a form guide, making it ‘your own’, via Flex Builder. It is for programmers who want to create alternate guide layouts, alternate panel layouts, and alternate components to display data, alternate navigation mechanisms, and to inject custom business logic.

Topics Under Consideration

I am considering the following blog topics. Perhaps you could comment back on your priorities.

1. “playlist .. slots” — what do you mean by playlist; what do you mean by slots?
2. The absolute wonders of the HTML hosting template
3. What makes Form Bridge tick?
4. A Cheat Sheet on getting at data in a customized layout
5. Wrappers, Panels, and Layouts — what am I looking at?
6. Your write-in


The Four Pillars of Guides

Technologically speaking, Guides have four major pillars of functionality:

1. Object “playlists” being flowed into reusable panel layout “slots”
2. Data Model-based, with binding to the external data file, and with model intelligence in an MVC architecture
3. Built-in navigation techniques to choose from
4. Form Bridge (communicating between a PDF and a SWF)

A subset, or specific instance, of 2) is the ability to extract the logic from an XFA-based form template and use it in ActionScript.

A subset of 3) would be the Question and Answer navigation control.

A subset of 4) would be simply having PDF displayed with the SWF, regardless of whether communication was necessary. The PDF might be a static, for-print, document.

Of course Guides, while giving one a quick Data Capture App from an XFA Form source, out-of-the-box, can also be customized into as rich an app as desired. Once you get the hang of it, there really is very little impedance to creating the App of your choice from a Guide-based beginning.

What is interesting to Development is whether the pillars described above should be available as independent entities in an SDK fashion, as opposed to being incorporated in a Guide app. The answer to that is obvious since it simply says to provide “more”. But the real question is that if those pillars were provided in independent, SDK-like, fashion, would you imagine your using them more than using Guide-Apps-as-consolidated-entities?