While XML data is very versatile and useful in terms of what can consume the data, running an XML report can potentially produce voluminous amounts of data. Consider that the column headers are imbedded in the report for every single line that is represented in the report. In fact the characters that make up the column headers are imbedded twice, since the closing tag for each element in a line contains the column header name as well.
We strongly recommend that, for most detail reports, XML data not be produced, unless the report is being filtered for specific criteria that can limit the amount of data.
The issue of document size is important if the XML document is going to be consumed by an application running on a different platform. This means that the entire document is transmitted across the wire to the receiving platform. There is no data compression in a CA JARS XML document, so remember this when composing a report that is used to write XML data. There is no problem with using an additional product to compress the data before sending it to the consuming application platform, provided there is a matching decompression for the data upon arrival.
Also, we recommend that the consuming application itself be considered when constructing an XML report. The consuming application may have restrictions on any number of items that are part of a CA JARS XML document. For instance, the consuming application may not allow tag names longer than 10 characters. There are any number of tailoring commands to set up column headers, field values, and so on, and these can be used with the XML writer, as the XML writer picks up customer column headers.
| Copyright © 2012 CA. All rights reserved. |
|