Apama 10.5.3 | Connecting Apama Applications to External Components | Standard IAF Plug-ins | Codec IAF Plug-ins | The XML codec IAF plug-in | Specifying XML codec properties | Performance properties
 
Performance properties
skipNullFields — A boolean that indicates whether you want the XML codec to omit nodes with null values from downstream, flattened, normalized events. Specify true to omit nodes with null values. The default is false.
The skipNullFields property applies to the name/value pairs for XML elements themselves. These have no associated data, so generating normalized event fields for them is not necessary unless they are required for ID rules. The skipNullFields property does not apply to a node whose value is an empty string.
Setting skipNullFields to true has no effect on the ordering suffixes that the codec adds to nodes. For example, consider an XML element that is deep within an XML hierarchy such as the following:
<root>
   <a>
      <b>
         <c>
            I want this string
         </c>
      </b>
   </a>
</root>
In the downstream direction, the XML codec creates a normalized event that contains a dictionary of name/value pairs that includes an entry for each element. If you specify sibling suffixes and Test as the XML field name, the dictionary contains the following:
{  "Test.root/":null ,
   "Test.root/a#1/":null ,
   "Test.root/a#1/b#1/":null ,
   "Test.root/a#1/b#1/c#1/":null ,
   "Test.root/a#1/b#1/c#1/text()#1:"I want this string"  }
Unless you require one of the null value fields for an ID rule, you do not need the null value fields. If you set skipNullFields to true, the XML codec drops the null value fields from the normalized event. In this example, the result is a dictionary with one entry:
{ "Test.root/a#1/b#1/c#1/text()#1:"I want this string" }
As you can see, this is much more lightweight. Turning this feature on can sometimes improve throughput by up to 1.5 times.
parseNode — Specify this property one or more times to identify only those nodes that you want parsed, flattened, and added to the normalized event.
By default, the XML codec parses, flattens, and adds all nodes to the normalized event. If you specify one or more parseNode property entries, the XML codec processes only the node or nodes specified by a parseNode property.
The value of a parseNode property can be any node path. The codec ignores order suffixes (#n or [n]) if you specify them in node paths. In other words, the codec parses all elements of the type specified in the parseNode property.
For example, suppose the value of the XML field property is Test and you have the following XML:
<root>
   <a>ignore me</a>
   <b>look at me</b>
   <c>look at me</c>
   <b>look at me again</b>
<root>
You can specify the following parseNode properties:
<property name="parseNode" value="Test.root/b/text()" />
<property name="parseNode" value="Test.root/c[99999999999]/text()" />
The XML codec produces the following dictionary entries:
"Test.root/b#1/text()#1" = "look at me"
"Test.root/c#2/text()#1" = "look at me"
"Test.root/b#3/text()#1" = "look at me again"
As you can see, the XML codec ignores the [99999999999] suffix.
Typically, you would specify the following parseNode properties:
*For each mapping rule, specify a parseNode property whose value is the transport field for that rule.
*For each ID rule in the adapter configuration file, specify a parseNode property whose value is the field name.
It is not necessary to specify parseNode properties for nodes identified by sequenceField or separator:elementName properties.
Setting the parseNode property prevents some nodes from being parsed. Consequently, the order of subsequent nodes might change, and therefore they would have different node order suffixes. For this reason, you probably want to set the logFlattenedXML property to true to see in what order suffixes are being generated before you add parseNode properties. Then add the parseNode properties and update the node paths used in mapping and ID rules as needed.
Specifying parseNode properties instead of parsing the entire document can result in very substantial throughput improvements. This is especially true for documents in which only a small proportion of the XML is actually going to be mapped.