Mobile Form Service Proxy

In the pre-release forum of ES4 and other customer forums of Mobile Form, one of the most sought after feature was to run all the Mobile Form workflows without directly exposing the LiveCycle server to the user accessing the forms in the browser. In ES4, the LC admin is required to open submission service “/lc/content/xfaforms/submission/default” to the whole internet as the Mobile Form needs to talk to it. The service url was embedded in the runtime model of the form. One way was to do URL mapping in webserver and proxy it but the restriction was one cannot change the URL path as it was in the runtime model.

There was another issue with the submission was, it was a two step submission that is you need two trips to server at the minimum to submit form data. This is again unnecessary load on server handling the submission. The data was being send as request parameter in the POST request on contrary to the pdf where data is sent in the body payload. This means for any workflow involving both pdf and mobile form, one has to field two different ways of processing the submission payload.

In ES4 SP1, Mobile exposed a configuration wherein you can register a proxy to submission service by specify its url through request parameter submitServiceProxy. Mobile Form talks to this service over ajax so you need to make sure your submission service proxy is hosted at the same server which is delivering the form.

We can broadly categorize two different types of deployment topology as shown in the following two diagrams. Topology (1) is where LC Server/Mobile Form POSTs data to the server and another Topology (2) where data is POST’d by the proxy server on behalf of Mobile Form.

Topology 1
Topo1
Topology 2
Topo2

Mobile Form rendered in the browser needs to contact LC Server for running server side scripts, web services and submission. The XFA runtime of the form in the browser talks to LC Server using AJAX calls on “/lc/bin/xfaforms/submitaction” end point with various parameters. But as I mentioned earlier one can configure the REST service endpoint using submitServiceProxy. The XFA runtime calls LC Server in the following conditions:

Executing Server Side Scripts (scripts in the form that are marked runAt=server) and webservices.

Here is the detail of the parameters:

Parameters Description
activity events e.g. click, exit or change to execute.
contextSom SOM expression of the object where events to be executed.
template template reference that was passed while rendering the form.
contentRoot template root directory that was passed while rendering the form.
data data bytes that was passed while rendering the form.
formDom form dom in JSON format.
packet This is specified as “form”.
debugDir The debug directory passed while rendering the form.

On submission of data by clicking submit button

And here is the detail:

Parameters Description
template template reference that was passed while rendering the form.
contentRoot template root directory that was passed while rendering the form.
data data bytes that was passed while rendering the form.
formDom form dom in JSON format.
packet This is specified as “data”.
debugDir The debug directory passed while rendering the form.
submitUrl The submit url where data xml is to be posted.

The submit service proxy should act as just pass through if submitUrl is not present in the request parameter that is if it is request type 1. That means whatever is posted to the proxy it should send that to “/lc/bin/xfaforms/submitaction” end point and send the response to he XFA runtime. If submitUrl parameter is specified, the service proxy has one of the two options based on the deployment topology. If data is posted by the LC server as shown in topology (1) then the proxy can act as pass through even in this case whereas if data is posted by the proxy as shown in topology (2) then the proxy server can pass all the parameters except submitUrl to “/lc/bin/xfaforms/submitaction” end point and get data xml bytes in response stream. Then the proxy service can post the data xml bytes to the submitUrl where it is to be processed.

The other proxy is for getting the XFA runtime client logs. This is useful if one wants to debug the forms’ client side runtime. For details refer to (reference to logger page). By using the same argument as of submission service, we need a proxy for logging service also. This should act just as a pass through to “/bin/xfaforms/logger.

You can take a look at Mobile Form Submission Proxy sample on how to create one.

4 Responses to Mobile Form Service Proxy

  1. Pingback: Smart submission – part II : LiveCycle Process

  2. Hi Raghavendra,

    I have a quick question about the data parameter. Here in your blog you always say “data xml bytes” which seems to imply that the xml can be in any valid encoding, however in the ES4 documentation it says This parameter specifies the UTF-8 encoded data bytes that are merged with the template.. This seems to indicate that the xml data must be encoded as UTF-8.

    Would you mind confirming whether the XML in the data needs to be in UTF-8 or not? I hope it does not, as we often have clients who create XML in ISO8859-1 instead.

  3. Raghavendra Pandey says:

    You can still use dataRef parameter to pass the file reference of data xml file in such case. As this way you can pass data in any encoding.

Leave a Reply

Your email address will not be published. Required fields are marked *


− 1 = eight

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>