Posts tagged "orchestrations"

Creating images from PDFs that are proportionally the same size in LiveCycle ES2 and ES3

Problem:

What if images produced from PDFs within the timeline of LiveCycle need to all be the same size? PDFs that are the same size, dimension-wise, can turn out as images of different sizes after processing with the toImage activity. For example, two PDFs could be 8.5 x 11 inches in size. But one would convert to an image that is 1700 x 2200 pixels in size and the other would convert to an image that is 2550 x 3300 pixels in size.

Resolution:

Use the same DPI argument for each of the PDFs. The resulting images will not be an exact match with one another, however. In my test a variation of ten pixels or so could be seen as the result of differences in the areas of the PDF page that are converted to image. But PDFs that are the same dimensions before conversions result in images that are the same pixel height and width (or very close to it).

See Also:

The documentation for the toImage operation of the Convert PDF service

Appending values to collections within Process Management orchestrations

Within the Process Management module for ADEP Document Services or LiveCycle, values returned from services, if not explicitly XML or primitives, are Java-based. These values, like XML in orchestrations, can be created, modified and deleted using the Set Value service or by using BeanScript within the Execute Script service.

Manipulating Java objects within BeanScript is very similar to how it works in Java. However, setting Java objects in the Set Value service can be very different. It uses XPath as its language. Values for XML behave as described within the W3C XPath specification. In addition, associating schema with XML supports functionality to add values to XML that fit a very specific object model. Though XPath is meant for querying XML, it has been purposed for setting and editing the Java elements within orchestrations as well.

There are many differences in the way Java objects are treated within the Set Value service’s XPath than XML or primitives behave. One difference is in the way items are added to collections within Java objects.

First, to create a collection, a variable must be set to be a new, empty, collection:

/process_data/myList = empty-list()

To append an item to an already existing collection, set the collection to be equal that value you wish to append:

/process_data/myList = empty-list()
/process_data/myList = "a" // collection is now ["a"]
/process_data/myList = "b" // collection is now ["a","b"]
/process_data/myList = "c" // collection is now ["a","b","c"]

To reset the value of the list, do not set it to a different collection. This only appends the collection to the existing list:

/process_data/myList = empty-list()
/process_data/myList = "a" // myList is ["a"]
/process_data/list2 = empty-list()
/process_data/list2 = "b" // list2 is ["b"]
/process_data/myList = /process_data/list2 // myList is ["a",["b"]]

To replace the value of a varible with a new list, first set the list to null:

/process_data/myList = empty-list()
/process_data/myList = "a" // myList is ["a"]
/process_data/list2 = empty-list()
/process_data/list2 = "b" // list2 is ["b"]
/process_data/myList = null
/process_data/myList = /process_data/list2 // myList is ["b"]

One big implication of this is, whenever a collection variable is set to the result of a service, if that variable is not empty the result is appended to the collection. This is sometimes desired, but can cause problems if not expected.

How to iterate through an XML collection within LiveCycle/Document Services Process Management

The Set Value activity within Process Management orchestrations uses xPath for  building expressions. And xPath has some quirks features that can frustrate developers who are not used to it.

One thing that can be confusing is how to iterate through XML collections. The problem is caused by the fact that xPath interprets all variables as strings unless they are coerce to some other type. And this coercion can happen automatically in some circumstances.

In this case, the variable @i is treated as a number because it is being added to another number:

/process_data/@i = /process_data/@i + 1
// this performs addition and increments @i by 1

 

But when used as an xPath reference variables are treated as strings:

/process_data/@i = 1
/process_data/myXML/topElement/childElement[/process_data/@i]
// this will return the first item
/process_data/@i = 20
/process_data/myXML/topElement/childElement[/process_data/@i]
// this returns the first item, too!

 

When used a reference, always coerce variables to be a Number:

/process_data/@i = 20
/process_data/myXML/topElement/childElement[Number(/process_data/@i)]
// this returns the 20th item