A customer new to LiveCycle recently asked for some technical information regarding the requirements of SmartForms for interfacing to a third party application.
Unfortunately (or perhaps fortunately), there are several ways of interfacing Smart forms to a third party application – the technique you choose depends on a number of factors, including exactly what you’re trying to achieve, and the capabilities of the application.
I’ll try to go through some of them:
1. You can submit the data from a Smart Form directly into your application, via http or https (This is similar to if you submitted an html form to the same application). In order to do this, the application must already define some web-based interfaces using http POST requests. It’s quite straightforward to create a button in a form that invokes an http POST.
2. You can submit the data directly from the form to the application via web services (ie SOAP). Again, in this case, the application must already expose the appropriate web services. Alternately, you could write (using the tool of your choice), a web-service front-end to the application. Calling a web-service from within a form is reasonably straight-forward, since a form can simply import the WSDL (web services definition language). There are some limitations:
- Some types of web services are not supported by Reader
- There are some issues with secure web services, and with authenticating proxies.
- It is quite fiddly to change the destination of the web service. For example, if you have two different web services, one for testing, and the other for production, it generally requires the two versions of the form, each pointing to a different destination.
3. You can submit the data directly from the form to the application via the sending of an email. It’s quite easy to create a button in a form that will send either the form’s data, or the full form, as an attachment. Obviously, again, the application will have to poll a particular mailbox server, and process the data that arrives.
4. You can submit the data from the form using any of the above methods (http/SOAP/email) to an intermediate web application, which you build. The web application can optionally process the data, and then invoke the third-party application. You can build the intermediate application in whatever language/platform you like.
5. You can submit the data from the form using http/SOAP/email to the LiveCycle orchestration engine. You can then use any of the capabilities of the LiveCycle engine to process or manipulate the data, and then submit it to the third-party application. In order to communicate with the third-party application, you can either use one of the “out of the box” capabilities of the orchestration engine (eg database access, messaging, file system, web services, and many more), or you can create a custom component for this purpose.
The final option is by far the most powerful, as well as possibly being the simplest to modify if requirements change. You will need LiveCycle Foundation, however, this is an “almost free” product, that Adobe bundles with just about every LiveCycle product that it sells. LiveCycle Foundation gives you a rich graphical flowchart-like environment for defining exactly what should happen when the data from your form is submitted, and a wide variety of ways of integrating with your third-party application. A full discussion is beyond the scope of this short blog, but it is very powerful and easy. Please see Adobe’s web site for more details.
Avoka provide an add-on component for invoking a LiveCycle process directly as a http or https request from a form. Please see our web site at: http://avoka.dnsalias.com/confluence/display/Public/Avoka+Process+Invoker
Another type of integration with a form is populating the form with data from the application – we’ll get to this another time.