You probably already know that Form Guides are an exciting way to render an Adobe dynamic form via a Wizard-style interface. See this link for more details: http://help.adobe.com/en_US/livecycle/es/fggettingstarted.pdf
However, all this document says about how rendering a Form Guide works is:
“The process for rendering form guides is similar to the process used to render forms in PDF or HTML. You must create a new process in Workbench ES that uses the form guide rendering operation renderFormGuide.”
How does rendering a Form Guide really work?
The short answer is that it is similar to rendering a PDF. The longer answer is that there are some subtle differences, and these differences can have an impact on how you architect your solution. In particular, a Form Guide actually consists of three separate parts:
- An html page containing the Form Guide SWF file.
- The SWF file that is the Form Guide itself.
Each of these is loaded in a different interaction between the user’s browser, your custom servlet, a special LiveCycle servlet, and LiveCycle Forms itself.
The easiest way to explain this is via a sequence diagram:
(Click for larger image)
- HTML page
- The user clicks on the link to your Form Guide, sending a http request to your custom servlet.
- The servlet will invoke an orchestration defined in LiveCycle Workbench.
- The orchestration will obtain pre-population data if required (usually from some sort of database, using the logged-in user’s details)
- The orchestration will then invoke the LiveCycle Forms “render” operation, passing through the name of the XDP template, and the pre-population data.
- The object tag will identify a uniquely named SWF file on the LiveCycle server
- The object tag will also include a “Flash Variable” embedded within the page – this Flash variable contains the pre-population data in an encoded form.
- The html page will be returned to the browser.
- Note: You could use Java code to directly invoke the LiveCycle Forms API, rather than using an orchestration.
- Form Guide (SWF file)
- The browser will identify the object tag on the page.
- It will make a request to the LiveCycle server to obtain the object referenced in this page. This request goes directly to the LiveCycle supplied servlet, it does not involve your orchestration or custom code.
- The servlet will look at the unique object id specified, and will use this to locate the correct XDP template to turn into a SWF. (This is the same template that you specified when you called the “render” method.)
- The servlet will convert the XDP into MXML/ActionScript, and invoke the Flex compiler to generate the SWF file.
- It will then save the SWF file into the LiveCycle Forms cache. As long as the underlying XDP file doesn’t changed, (and assuming you don’t manually clear the cache), the servlet will serve up the SWF file from the cache from now on. This is because compiling the SWF file can be quite time-consuming.
- Finally, the SWF will be returned to the browser.
- Final display.
- In a clustered environment, it doesn’t matter whether #2 and #3 go to the same member of the cluster, or a different member of the cluster – what’s returned to the browser is always identical.
- LiveCycle only needs to generate the SWF the first time, because it’s always identical. The pre-population data is embedded in the html file, which is generated each time the client requests a Form Guide, and may be different for each invocation.
- You should manually load the Form Guide the first time you publish the Form Guide into production – otherwise the first user to load it will experience a longer than usual delay.
Things can get a little more complicated in a real production environment.
The second diagram indicates a more real-life environment, where:
- An Apache server has been introduced which front-ends the Application Server. The end-user can only “see” the Apache server, and cannot directly access the custom servlet or the LiveCycle Forms application server. This is generally considered to be a more secure way to architect any public-facing web application.
- A firewall has been introduced between the custom servlet, and the LiveCycle server. Another firewall is usually inserted between the Apache server and the custom servlet, although this is omitted from the diagram.
- A variation on this architecture is that the custom servlet may run on the LiveCycle application server.
- The LiveCycle server may run in either the DMZ or within the corporate zone, depending on it’s accessibility requirements to databases and other corporate resources.
This requires some modifications to the architecture of our application.
- When rendering the form using LiveCycle Forms “render”, you must specify the URL of the Apache server, rather than the URL of the LiveCycle server. This ensures that the client’s browser will interact with the Apache server, rather than attempting to communicate directly with the LiveCycle server.
- You must set up Apache to “pass-through” requests for both the custom servlet and the LiveCycle servlet.
- You must somehow allows requests to the LiveCycle servlet to pass from Apache through to the LiveCycle servlet on the LiveCycle server. There are a number of ways of doing this:
- If the Apache server can “see” the LiveCycle server, you can set up a proxy rule to allow traffic for the servlet to be passed through.
- You may need to write a simple proxy service within your custom servlet. This is basically a servlet with the same name as the LiveCycle servlet, which passes any requests through to the LiveCycle servlet, and forwards any responses back to the browser.
Thanks to Rak Siva of Avoka and Gareth Faulkner of Adobe for assistance with this blog.