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.

To read the complete article, visit this blog post.

Mobile Form goes Right To Left

With ES4 SP1, we added support for Right To Left languages like Hebrew in Mobile Form. Now you can see html for your hebrew forms. Not only that but you can also fill the fields in Hebrew. We also support mix and match of English or any Left to Right script for that matter with Hebrew in form fields. Based on form locale we even show the date and days info in localized form.

Read the complete post here.

Passing parameters to Mobile Form

In LC ES4, we get this feedback from customers that they want to hide the parameters passed to Mobile Form profile to render a form. If you could see the There was only one way to pass parameters that is through request parameters (refer to Mobile Profile page). In ES4 SP1, we introduced couple more ways to pass parameters to Mobile Form.

Read the complete post here .

Create custom Mobile Form profile

Mobile Form renders the form based on profile. If you want to change the look and feel or do other customization, you are required to make modifications in the default profile. In ES4, Mobile Form profile script was one single monolithic jsp file. So if you want to modify the profile script you have to copy the whole script and then make the changes as suggested in ES4 Adobe documentation. This way, you loose the updates provided in the script over different patches.

To know more, read this blog post by Raghavendra Pandey.

Debugging Mobile Form

Logging in Mobile Form or any application for that matter is of utmost importance. It helps our customers in debugging the various issues in forms including performance. Mobile Form is a distributed application. It has a server component that generates data for the XFA runtime. XFA runtime is a javascript implementation of XFA reference that runs inside the browser and interprets the data generated by the Mobile Form server to render an XFA template and data in html5. In distributes scenario, logging helps a lot in keeping tab at what is going on at various sites.

Read the complete post here.

POST data size limit

A generic Mobile Form workflow involves rendering a form, filling up fields and then submit it for further processing. Mobile Form submits data to server on HTTP POST. If the form is very big or it is merged with large size data, sometimes there is chance that the submission payload exceeds the default limit of the server. In this case, you might see HTTP 500 error on form submission. If you inspect the server logs, you will see this exception – “Template is not specified”.

Read the complete post here.

Cache is king

Cache plays a very important role in the performance of Mobile Form or for that matter any component. Mobile Form caches all the intermediate objects required to process (rendition or submission) a form on first request. It doesn’t cache the objects dependent on the data as they are very likely to change.

To know more about Cache in Mobile Forms, read the complete post here.

Rendering a Chart in Mobile Forms

In this article we will use JQPlot charting capabilities to draw a pie chart.To Learn more about JQPlot- click here The charts data will be coming from the table which is designed using the LiveCycle Designer. We will also be exploring the FormBridge API’s to access the Table’s data to feed into the JQPlot chart.

Read the complete post here.

Adobe LiveCycle Blog 2013-06-24 22:11:48

A lot of times you have a need to extract or import the data from Excel file into LiveCycle form in a programmatic manner. To accomplish this I have written a simple component. This component makes use of Apache POI classes to extract data from the Excel file. The sample component is not generic for all Excel files, but it was written for extracting data from a specific Excel file. With little modifications you can get this code to work with any Excel file. The code creates a map of xml documents where each xml document corresponds to a row in the excel document. You can deploy this component using workbench and use it as part of your process.

For the instructions, read this blog post.

The Adobe LiveCycle Portable Protection Library: an SDK to Manage your Rights Management Server

First, a little background information about Adobe LiveCycle

Adobe LiveCycle is an enterprise suite of server based software products that are meant to help structure business processes. One of its key features is the ability to protect a document (of the following types PDF, Microsoft Word, Microsoft Excel, Microsoft PowerPoint, text, and more!) with a policy to restrict access to a subset of users. Adobe LiveCycle offers this ability through one of its components called, Rights Management.

After a certain point large organizations or organizations that have been using Adobe LiveCycle for an extended period of time may accumulate a significant number of policies and documents, these can become tiresome to manage through the web interface for the Rights Management component of LiveCycle. Users of LiveCycle can also fall into performing the same action over and over, such as protecting documents with the same policy again and again. What if there was a programmatic way to apply these policies to new documents? What if there was a programmatic way to use a policy from one document in another? What if there was a programmatic way to manage these?



Read the complete post here.
Go to Top