Considerations when building an eform solution using LiveCycle - part 2

Continue'd from last part

5. Volume
What is the anticipated volume of electronic submissions expected? Simultaneous submissions? If large and simultaneous submissions are expected, then you want to leverage a JMS queue to handle the submission part. The downside to this is that results can not be returned to the user synchronously.

The other approach is to leverage clustering of your web / application server. This will result in better performance as well as a more reliable solution. Unfortunately there is a cost associated with clustering (software licenses and hardware).

6. Paper based submissions?
Are there times in which the signed paper forms are required for legality reasons? This is found in particular in heavily regulated industries (financial institutions and government organizations). If you require to keep a copy of the signed paper forms, then at design time, you want to consider leveraging 2D Barcode. The way the 2D Barcode works is that as you enter data using Reader / Acrobat, the data is being encoded into the Barcode. The data by default is encrypted. To decrypt the 2d barcode, you would need 1) reader extensions rights 2) barcode decoder from Adobe 3) Acrobat to print the barcoded forms.

Let me know if you have other questions in the comments area, I will do my best to include them in my post.

David

Considerations when building an electronic form (eForm) solution using LiveCycle - Part1

This article is intended for those who are interested in migrating your existing paper based processes over to an electronic one. I will go through some high level considerations in finding the right solution.

1. PDF or HTML?
Are you interested in implementing a pure PDF solution or one that includes both HTML and PDF? LiveCycle Forms allows multiple output formats (PDF, PDF Form, HTML, DHTML, AHTML, etc) to be generated from a single template (.xdp) created from LiveCycle Designer. The caveat is that the scripting behavior is different between the HTML and PDF, resulting in scripts that has to be coded into the templates. Unless there's a significant requirement to continue to support HTML based forms, I would stick with PDF Forms.

2. When is HTML Form an appropriate output from LiveCycle Forms?
Scenario 1: If the PDF form is very long (5-10 pages), I sometimes use HTML Forms to capture data, in a multiple step wizard. This breaks the long time into a sequence of smaller and more focused forms for the user to fill out.

Scenario 2: Use HTML Forms when screen real-estate becomes a high premium (within a portal, within LiveCycle Form Manager)

3. Requirements to archive the PDF?
Do you have existing requirement to archive the PDF that the user submits? If yes, then the submit type needs to be either XDP or PDF. This is done at the form design stage. Note, to support this capabilities using Adobe Reader, the PDF needs to be reader-extended first. (Product: LiveCycle Reader Extensions)

4. Requirements to use digital signature?
Are you planning to support digital signatures in your PDF Form? If that's the case, you should be aware that an existing PKI infrastructure and/or support for roaming certificates / id needs to be there to associate and identify the signing party. Also, if digital signatures are required, the submission type (of submit buttons on the PDF) has to be an XDP aor a PDF.

to be continued..