Mobile Forms Service Proxy

Mobile Forms Service Proxy is a configuration to register a proxy for the submission service. To configure Service Proxy, specify the URL of submission service through request parameter submitServiceProxy.

Benefits of Service Proxy

The service proxy eliminates following: 
  • Mobile Forms workflow requires opening up of the submission service "/lc/content/xfaforms/submission/default" for the Mobile Forms users. It exposes LiveCycle servers to a wider unintended audience. 
  • The service URL is embedded in the runtime model of the form. It is not possible to change service URL path.
  • The submission is two-step process. To submit the form data, submission requires at least two journeys to server. Thus, increases load on the server.
  • Mobile Forms send data in the POST request instead of PDF request. For workflow involving both PDF and Mobile Forms, two different methods of processing the submissions are required.

Topologies

Mobile Forms can use following topologies to connect to the LiveCycle servers.

  • A topology where LiveCycle Server or Mobile Forms send data via POST to the server.
  • A topology where proxy server sends POST data to the server.
Mobile Forms service proxy topologies
Mobile Forms service proxy topologies

Mobile forms connect to the LiveCycle servers to run server-sided scripts, web-services, and submissions. The XFA runtime of the Mobile Forms uses Ajax calls on "/lc/bin/xfaforms/submitaction" end point with various parameters to connect to the LiveCycle servers. Mobile Forms connect LiveCycle servers to perform following operations:

Execute Server-sided scripts and Web Services

The scripts marked to run on the server are known as server-sided scripts. The following table lists all the parameters used in Server-sided scripts and Web Services.

Parameter

Description

activity

Activity contains the events that trigger the request. Such as click, exit or change

contextSom

contextSom contains SOM expression of the object where events are executed.

Template

Template contains the template used to render the form.

contentRoot

contentRoot contains the template root directory used to render the form.

Data

Data contains bata bytes used to render the form.

formDom

formDom contains DOM of Mobile form in JSON format.

packet

packet is specified as form.

debugDir

debugDir contains the debug directory used to render the form.

Submit data

On clicking the submit button, Mobile Forms send data to the server. The following table lists all the parameters that Mobile Forms send to server.

Parameter

Description

Template

Template used to render the form.

contentRoot

template root directory used to render the form.

Data

bata bytes used to render the form.

formDom

DOM of Mobile form in JSON format.

submiturl

The URL where data XML is posted.

debugDir

The debug directory used to render the form.

Note:

If attachments are enabled (mfAllowAttachments = true) then the multi-part form data containing dataXml and attachments is posted to submiturl. This turned off by default for backward compatibility. By default, to maintain backward compatibility the option is turned off.  

How the submit proxy works?

The submit service proxy acts as a pass through if the submiturl is not present in the request parameter. It acts as a pass-through. It sends the request to the /lc/bin/xfaforms/submitaction end point and sends the response to the XFA runtime.

The submit service proxy selects a topology if the submiturl is present in the request parameter.

  • If LiveCycle servers post the data, proxy service acts as a pass-through. It sends the request to the /lc/bin/xfaforms/submitaction end point and sends the response to the XFA runtime.
  • If proxy posts the data, the proxy service passes all the parameters except submitUrl to the /lc/bin/xfaforms/submitaction end point and receives xml bytes in response stream. Then, the proxy service posts the data xml bytes to the submitUrl for processing.
  • Before sending data (POST request) to a server, Mobile Forms verify connectivity and availability of the server. To verify connectivity and availability, Mobile Forms send an empty head request to the server. If the server is available, Mobile Form sends data (POST request) to the server. If the server is not available, an error message, Could’t connect to the server, is displayed. The advance detection prevents users from the hassle of refilling the form. The proxy servlet handles head request and does not throw exception.

 Adobe

Get help faster and easier

New user?