Posts tagged XDP
If you are attempting to save an XDP file in LiveCycle Designer ES2, created with an earlier version of Designer (i.e. 7, 7.1 or ES), then it can occur that the Save process never completes, and you must kill the Designer process manually in Task Manager. If you analyse the files on your local disk, you will notice some tmp files with large file sizes.
This issue is related to the Data Binding option Allow binding to data not defined by the default data connection. For some forms that contain data connections, Designer ES2 can get stuck in an endless loop while saving the XDP to an intermediary tmp file. You will see the tmp file will contain a huge number of repeated entries related to the DataDescription similar to the following:
<DATACONNECTION xmlns:dd=”http://ns.adobe.com/data-description/” dd:additions=”$template(DATACONNECTION)”/>
Read the complete post at Adobe LiveCycle Blog.
- Girish Bedekar, LiveCycle Solution Evangelist @ Adobe
A common use case is to let the end user select various fragments to insert in the final PDF. The screen shot below would better explain what I mean by this. AS you can see this screen captures some user information, and allows the user to select fragments that need to be inserted in the final pdf. When the user hits the submit button it will call a LC process which will parse the parameters and build the DDX needed for XDP Stitching. The Process makes use of a custom component called xmlUtilities which allows you to insert elements in an xml document. The input parameters to the process are the name,city,address,state,zip and fragments. The fragments variable will hold a comma separated list of selected fragments.
Read the complete post at Adobe LiveCycle Blog.
If you are developing multiple forms / fragments inside your application whereby some forms look similar, a common way is then to copy some XDP-files at some point to make specific changes to these forms. What most developers don’t realize is that doing a copy on the OS (not doing a Save As in Designer) could have major performance impact while rendering forms.
To better understand why this is, you have to go into the details of the caching mechanism used by forms and output.
If you want to know more on this, please read this document. In most cases the filename and path are used to determine the cache key, when this is not available (e.g. template is passed in by value), the caching is based on the following metadata line inside your XDP :
<xdp:xdp xmlns:xdp=”http://ns.adobe.com/xdp/” timeStamp=”2010-12-01T14:00:26Z” uuid=”324b5d64-7aff-4beb-88a5-3ded2dde1819″>
Based on the combination of “timeStamp” and “uuid” it is determined whether the form is already cached or not. This seems to be very straightforward, you would think. However, where you have copied XDP-files, you have the following situation
<xdp:xdp xmlns:xdp=”http://ns.adobe.com/xdp/” timeStamp=”2011-05-05T16:00:10Z” uuid=”324b5d64-7aff-4beb-88a5-3ded2dde1819″>
<xdp:xdp xmlns:xdp=”http://ns.adobe.com/xdp/” timeStamp=”2011-05-05T15:59:35Z” uuid=”324b5d64-7aff-4beb-88a5-3ded2dde1819″>
When you render File1.xdp and File2.xdp one after the other, Forms and Output assume that the XDP has been changed and therefore the cache need to be rebuilt. Functionally you won’t see a difference, but performance-wise you will see a lot of expensive operations because the cache gets constantly invalidated.
A way to see this is to use JMX whereby you expect invocation-times that are constant, when the cache is invalidated you will see spikes in the timings on these operations.
How to get an unique uuid?
Basically you have two ways to renew your uuid with Forms Designer.
If you use File->Save As, Designer will automatically assign a new uuid to your XDP-file
2. Remove uuid
If you go into the xml source of Designer, remove the uuid attribute and save the XDP file, Designer will assign a new uuid.
Checking on shared uuids
We have created an ANT script that helps you to identify XDP-files that share the same uuid. The tool inspects all XDP-files and compares the uuids used. When it finds XDP-files with the same uuid, an error is printed.
You can see an example of that here :
[echo] Checking UUIDs ...
[java] ERROR: Found duplicate uuid 324b5d64-7aff-4beb-88a5-3ded2dde1819 in
File1.xdp and File2.xdp
In the README.txt inside the uuidchecker.zip you will find a brief explanation on how to use this tool.
Original article at http://blogs.adobe.com/livecycle/2011/05/copying-xdp-files-and-the-impact-on-performance.html.
As many people know, e-Invoicing is gaining a lot of traction these days in order to save money. In general many of the solutions use PDF as the format for the electronic invoice. But there is PDF and PDF. We have created a sample electronic Invoice in PDF format that is more then just a digital invoice, and also focuses on the experience of the recipient in addition to the ability to exchange structured data. Have a look at a video that includes a demo. If you would like to download the sample and play with it yourself, here it is.
Original article at http://www.drflex.eu/2009/05/e-invoicing-with-adobe/?utm_source=rss&utm_medium=rss&utm_campaign=e-invoicing-with-adobe.
How to Invoke LiveCycle Forms from an Existing XDP Form in Acrobat/Reader or Browser Plugin and Get Another Form Rendered Back to the Client0
Lately I have had a request from a customer of mine who wanted to modify existing XDP forms (ie. change a label or a field value) on the fly without going in LiveCycle Designer (ie. the procedure would imply costs for hiring the dev department).
His idea was to have a Form A, in which he would be able to specify the changes he desires to have in the Form B, submit the form A to a LC orchestration which would apply the changes and render the Form B back in Acrobat/Reader or even the browser plugin.
Here I am only covering the call to LC and the rendering back to the client.
Note: I am using LCES 2 SP2 (220.127.116.11) running on Jboss.
So we have Form A that could look like this:
As we can see we have a few fields that would mean something to Form B and as an end user we will open Form A in Acrobat/ Reader or even the browser plugin to enter the value we want to see in Form B.
We need to go in LC Workbench to create an orchestration which will render Form B:
We can find the right URL for the call by selecting the Default startpoint properties:
Since I going to run the test on the same machine where Livecycle is running the URL looks like this:
Note: “test” is the name of my application and “renderForm” is my process (orchestration) and 1.0 is its version.
This is the URL I put in the submit button in Form A (see first screenshot).
In order to make the call successful, we need to create variables to match the fields in Form A: Name, FormContent and MainParagraph.
Of course, in the scenario where you want to modify Form B with Form A fields values, you would need those variables to apply the desired changes.
Note: by matching i meant the variables name and type (most of the time it would be string but you can have list as well).
Here I am only rendering the Form B without any changes so I did not bother adding more activities in my orchestration which would utilise those variables.
Once the orchestration and the forms have been saved and the application deployed on the server, all we need is to open Form A in the client of our choice, here I used Internet Explorer so we can see the URL at the top.
I click on the button “open form via REST” and the login request pops up and i use my LC credentials to access:
Once logged in Form B is appearing in the same window:
Note: When using Reader or Acrobat, it will open a new window for Form B.
No need to Reader Extend Form A to make it work hence it works in Reader standalone and plugin.
Original article at http://blogs.adobe.com/ADEP/2011/08/invoke_forms_from_xdp.html.
I was suppose to post easy techniques on how to pre-populate forms via LiveCycle’s Render service but unfortunately it is taking longer than what I expected. This is the story so far… Please comment if you are aware of this and enlighten me around the changed behavior.
I used the customized render service till LC 8.0.1 SP2 and what we get in dataDoc variable of the Render service is xdp data which had the whole form specific XML structure. But I’m finding that in LiveCycle 8.2 SP2 the dataDoc contains the xdp data but ONLY the Root element of form data is present.
The issue: This results in stalled operations (exception) as the elements that I want to populate does not exist.
The strange thing:
The most strange thing that I have seen is related to where the ‘caller’ orchestration was developed. So if your orchestration which has xfaForm variable was created on LC 8.0.1 then the dataDoc variable will have the xdp data with the whole and empty form data section in it. BUT….. if you touch that variable or re-create that xfaForm variable on LC 8.2 then you’ll start getting the blank form xml section in xdp data (of dataDoc) variable of render service.
Please let me know if anyone has seen this before and knows if this was intentional in LC 8.2 or it is a reported/unreported bug.
stay tuned for the pre-population.. I’ve decided to post a series of two articles to discuss the strategy that I think can work nicely.
Original article at http://blog.pandyaparth.com/2009/06/form-pre-populate-via-render-service-delayed/.