Copying XDP-files and the Impact on Performance

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=”” 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

File1.xdp :
<xdp:xdp xmlns:xdp=”” timeStamp=”2011-05-05T16:00:10Z” uuid=”324b5d64-7aff-4beb-88a5-3ded2dde1819″>

File2.xdp :
<xdp:xdp xmlns: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.

1. SaveAs
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 you will find a brief explanation on how to use this tool.

About Feike Visser

Feike is an Adobe Marketing Cloud architect, working for Adobe Consulting in EMEA.
This entry was posted in ADEP. Bookmark the permalink.

2 Responses to Copying XDP-files and the Impact on Performance

  1. Thanks for the information and the tool.

    This information does beg the question of why the filename is not part of the caching algorithm. Making copies of XDPs is a fairly common practice. The only reason I can think of for *not* including the filename to uniquely identify an XDP is linked XDPs, but in 20-odd years of forms development, I have never seen that.

    Can you explain why filename is not also used? Page 17 of the kb article you cite indicates that it is (see 4.2 Dynamically generated templates). If filenames are used, then this problem becomes moot doesn’t it?


  2. Feike Visser says:

    hi rob,

    Thank you for the comment.
    You are right that filename+path is used is most cases to determine the cache key.
    But in cases where you pass in the document as a value the uuid/timestamp is used.
    I noted this now also in the blogpost to make it more clear.