Hide parameters from Mobile Form URL

In ES4, Mobile Form had a limitation that it could only hide the template references from the form URL exposed to the user. In ES4 SP1, one can overcome it using the new ways of passing parameters to Mobile Form render service.

Based on your preference and requirement, you can choose to specify the render parameters like template reference, data reference, submit url etc either as node properties or as setAttribute API of server request object. In this post, I will go through both the options in detail and discuss pros and cons. Ideally, in production system, one should use any of these two methods of passing parameters over the request parameter method wherein all parameters are visible to the user accessing the url. Besides hiding the parameters, these two methods also make maintenance easy. For example, let’s say you want to change the data reference, then you wont need to update the URL everywhere because it is anyway not part of the URL.

Let’s say, you already have a servlet or JSP running on the same server and you want to forward the user request to the Mobile Form profile renderer using servlet forwarding. In this case, you can expose the URL of your servlet or jsp as Form URL. That user facing JSP may, in turn, set the template and data references in the request object before forwarding, using setAttribute API of servlet. Now this approach would mean you create one user facing JSP/servlet for each form or pass some parameter based on which it can select a form. The jsp would like the following:

//similarly for other parameters and then get the request dispatcher of the profile URL and forward it.
RequestDispatcher rd = request.getRequestDispatcher("/content/xfaforms/profiles/default.html");
rd.forward(request, response);

If you create the user facing URLs in sling subsystem then it better to go for the other approach. Because, you have to create a content node anyway, to create a new REST URL. But if you are creating node, then you can specify the parameters as node properties as mention in post. In the following screenshot, you would notice, how I have specified Mobile Form render parameters as node properties of “leave” node created under /content section. Also, I specified resourceSuperType for this node to default profile renderer of Mobile Form.



As is evident from the above, you need to create one node for each combination of render api parameter.

It is good practice to do mix and match of both approaches. It is good to specify the static or less dynamic properties like template reference as node properties and pass other dynamic or frequently changing parameters like data reference as setAttribute method.


Smart submission – part II : LiveCycle Process

In my last post on Mobile Form data submission, I discussed how to submit data directly to a LiveCycle process. In ES4 LiveCycle Mobile Form, one needed to deploy the custom package shared in this blog. In ES4 SP1, submission to any LC process is even more easier to do. Now you don’t need custom package any more.

You can download the FormSubmission LiveCycle process and import it following the instructions. You can create your own process as well. The important part is to get the REST url of the process. The rest url of the process turns out to be http://localhost:8080/rest/services/<ApplicationName>/<ProcessName>:1.0 as shown in the screenshot of workbench.



If you hit the REST url in the browser, it will ask for credentials of a user that can run this service or process. You can also disable the authentication required for running this process, for details look for adobe help.

http://localhost:8080/lc/content/xfaforms/profiles/default.html with the following parameters:

  • contentRoot=repository:///Applications/FormSubmission/1.0
  • template=SimpleForm.xdp
  • submitUrl=http://localhost:8080/rest/services/FormSubmission/archiveForm:1.0

The difference between ES4 and ES4 SP1 is, you dont need to preprocess the submission payload of Mobile Form before routing it to a LiveCycle process. You can also implement a custom submission proxy as mentioned in service proxy post. This will not only  do away the need for exposing LiveCycle server from internet but also give you a hook to pass any authentication information to LiveCycle process.