Archive for September, 2013

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:


request.setAttribute("template","test5.xdp");
request.setAttribute("contentRoot","c:/bugs/layout");
//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.

node-prop

 

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.

process1

 

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.

Mobile Form smart submission

The workflows around Mobile Form generally involve rendering a form in the browser and then capture data and submit it back to the server. You cannot render the form if you are not connected to the server. In general, data capture step doesn’t need any connectivity from server except in case of running any script on server side or executing a web service. But connectivity is very critical in case of form submission. If you are not connected to the server and you submit the form, you would get just 404 error page and  you data would be lost.

Generally, the solution is to check connectivity before one submits the form. Mobile Form with ES4 Sp1, brings out this check out of the box. It will  first issue a HEAD request to LiveCycle Server to check if it is still accessible. If this check fails, it will show the following dialog. Once it gets assurance then Mobile Form submits the data to the server.

network_error