Back-end Interaction without Reader Extending

[Former Community Member]

Please correct me if I'm wrong: It is my understanding that I can have a form interact with back-end systems (such as fetching data from a database) through a LiveCycle Server, as opposed to having the form interact directly (which would require Reader Extensions).

I'd be grateful for an explanation of the technique. I imagine there are two options here:

a) Setting events to execute javascript server-side, effectively having the server perform a database-lookup (how?) with one of the form's fields as a key. Return the data and populate other fields.

b) Submitting data from the form to the LiveCycle server, have the server enrich the data and return it to the same form (effectively populating additional fields with the new, enriched, data).

Can somebody shed some light? Experiences?

[Former Community Member]

Yes you can do this ....you will need LibveCycle Form Server for this.

a) Works the same as on the client (you woudl need to define an OLEDB connection on the server) but you do not have access to all the events. ONly a subst of the events will be exposed on the server (i.e. a click event is only a client event). Usually this technique is used for initializations not interactive work.

b) LiveCycle 9 supports a REST interface so you can create an orchestration that will recieve the inbound data (Form Server function), use any other LC server to manipulate it, then recombine the template and data together (Form Server again) then return the finished PDF to the browser.

Hope that helps

Paul

[Former Community Member]

Thanks pguerett for an informative answer.

I've understood I can prepopulate forms using LC Forms, but I'm especially interested in the run-time interaction.

Can I use both techniques for run-time interaction? What are the caveats? What events are available in option a) ? (Having thought I read click events would be one of them, but you're stating the opposite.)

Are there any deal-breaking reasons an organization should refrain from building a solution offering run-time interaction using Forms instead of Reader Extensions?

[Former Community Member]

I found the following in the LC Designer ES2 documentation:

Does this mean that I can, for instance, have a user enter an id into a field, and upon exiting the field, invoke a server-side javascript which uses that id to fetch associated data from a database or a webservice, and populate the form using the fetched data run-time?

[Former Community Member]

Yes you can ...but you have to have a program running on the server side to catch this submission and do something with them. Your program would in turn  call the processHTTPRequest method of the Form Server API and that woudl render the template of the server, execute the Java script and return back tehe PDF to your client.

The advantage is that you can get around Reader Extensions but you woudl still need to but Form Server. The disadvantage is that you would need to do a round trip to the server for each one of those calls. This puts additional load on the server.

Paul

[Former Community Member]

I took the liberty of reviving this thread.

I actually got this working by creating a custom Submit PDF process (we're using Workspace), which performs the database lookup and returns it to the client (via the 'calc' route). The call is placed on the exit event of the form to execute server-side, and since the form data is transmitted by default, the event source simply contains "//".

I would like to use the exit-event to start a thermometer, which means that it has to execute on the client. I tried having this client-version of the event trigger another event that is set to execute on the server, but it seems that server-side javascript can only be triggered through direct user interaction. Do you have any tips on how to both start a thermometer on the client and perform the server-side database lookup?

I've fiddled around with this as well, altough couldn't get the process to return the right headers for IE/Adobe plug to retain the PDF document. I've tried setting the mime to application/vnd.adobe.xdp+xml, but the Reader plug complains about not being able to find the ref (source) inside the <pdf> tag. Giving a correct ref doesn't seem trivial, as the source is part of a Workspace process inside an Adobe Reader plug container inside an iframe flash interface. Passing "." (I'm thinking "current document") doesn't work, and deleting the <pdf> tag altogether didn't work either. Seems this is harder than it has to be... Insights?

I'd also like to inquiry about an option c)...

Calling Execute (as in web service) set to runAt="server". It seems I still need to define the data source inside the form. Can I work around this somehow, for instance defining the web service programatically in Javascript? (The reason being that form constructors shouldn't have to set up data sources, and process designers shouldn't have to alter the forms)

Any insights are deeply appreciated...