19 November 2007
You should be knowledgeable about building processes in LiveCycle Workbench ES and understand how to get forms to render in LiveCycle Workspace ES.
In many cases users want to be able to render a PDF form (with advanced functionalities) inside of Adobe LiveCycle Workspace ES, but they are limited to using Adobe Reader to view the form. Adobe LiveCycle Reader Extensions ES enables form designer to extend the use of Adobe Reader to allow for any advanced functionalities that they put into their forms. In this article I will show you how to extend your forms for use inside of LiveCycle Workspace ES.
When a user-based process is created, the process creator will declare an input variable that is used to hold the inbound transmission when the user clicks Submit. This variable also will contain a pointer to the location of the template file that will be used to show the form to the user as well as a link to a special process (sometimes called an orchestration) that will tell the system how to combine that data and template together to show the form to the user. This special process is called a renderer, because it tells the system how to render the form to the user. Different renderers will be used depending on the type of template (XDP versus PDF), data format to be merged, and type of form being generated (PDFForm, Guide, or HTML). Adobe provides numerous samples and standard renderers for your use. Figure 1 shows an example:
All of the renderers follow the same format. They start with a SetValue service, which will modify parameters that are fed into the render operation. This is followed by the RenderForm operation, which is the actual call to LiveCycle Forms ES (which creates the form). Finally, there is an optional step (if the form is being used with LiveCycle Workspace ES) that will inject the FormBridge code into the form to enable it to communicate with the workspace application.
Now that you understand how to render a form, you can create your own renderer. A number of excellent examples ship with the product that you can use as a base. In this case, I will assume that you are starting with an XDP form template and will use the renderPDFForm service that is in the Samples/Forms category.
The properties should look like Figure 5:
Save your process and activate it. Note that if you do not reference the correct Credential Alias or you try to turn on rights for which you do not have the associated server product (for instance, 2D Barcode), then your process will fail and an error message will be written to the application server log file.
Now that you know how to render your forms, how do you call it in your process? When designing your process, you need to create a variable that will hold the data that is merged with the form. If you are using XDPs from Designer, then you need to define a variable of type
xfaForm variable gets associated with a particular template that is in the repository. This association is held in the definition of the
xfaForm variable's template
URI parameter. You can create the variable by hand and associate the template by browsing to the appropriate template (using the Browse button), or you can simply drag the desired template onto the variables view and it will create the variable and make the association for you (see Figure 6).
If this is the variable that will be used as the first step in your process, it must be set as an input variable. Now that you have defined a variable to hold your data and associated it with a template, you must tell it how to render this form and associate it to a renderer. This is done under the Advanced Settings button.
The ability to customize renderers is not limited to adding LiveCycle Reader Extensions ES. You can modify the renderer to certify forms before delivery to the user. The beginning of the renderer can also be modified to get additional data to merge onto the form (database lookups, web service calls or LDAP queries, to name a few).