Settings of the XML Parser V4

First, you have to switch to V4 in (3). Checkbox (1) has to be set since V4 always works without namespaces.

(1) As already mentioned, this checkbox is mandatory for V4.

(2) Specifies the tag name (element) below which you want to parse. An entry must be made here, even if the entire XML structure is to be parsed. If you want to parse a partial document, it must also conform to the XML convention (well-formed). Note: Can also be an XPath 1.0 expression, e.g. /inventory/books[@title="xxxx"]. Note: See also section Effect of an Entry in Field 'XML tag for record'.

(3) Version 4 of the XML parser.

(4) We do not want to create a new record per item. Instead, we want 2 item elements in each record, see (5). That is why we use the new root element articles. See section Generating Chunks below.

(5) The number of item elements per record, i.e per articles element, see(4). See section Generating Chunks below.

(6) We have two attributes date and ref in root element invoice. We need these in the mapping, so we activate this checkbox and all available attributes are copied into articles.

(7) The specified elements, including their child elements, are copied into each articles element. All XPath 1.0 expressions are allowed. See section Copy Attributes and Elements Redundantly into Each Record below.

(8) If the XML file is smaller than 2 GB, deactivate this checkbox. More details in section Large XML.

Example XML

We will use the following XML file.

If repeated subelements (here item) are to lead to multiple records, you should not specify the real root element (invoice) of the XML document in (2) (see section Effect of an Entry in Field 'XML tag for record'). Previous parsers (prior to V4) lost all attributes of the root element and any parent or sibling elements that were not within the element item. With the XML parser V4, data from these 'blind' areas of the XML document can be copied into each record, as described in section Copy Attributes and Elements Redundantly into Each Record below.

Generating Chunks

If the structure of the input data would lead to a large number of small records, for example, because it contains several million item elements, the performance would suffer. In this case, it would make sense to combine several item elements in one record. However, there would be no natural structure in the input data to support that. However, you can force the parser to create a virtual element (4) (here articles). This 'chunk' element then appears as a root element that contains several item elements.

The generation of chunks with (4) and (5) is optional. If (4) remains empty, a record is generated per (2) (in the example per item). In that case, the root node of the source structure should correspond to the item element.

If a virtual chunk element is used in (4), an additional root node corresponding to the chunk element (here articles) must be used in the source structure. This node receives a match code as in (4) to parse the virtual chunk element.

Copy Attributes and Elements Redundantly into Each Record

Suppose that we use element item as the XML tag for record for our source file above. The attributes of the element invoice and all data in element header will then be outside the parsed area. As of version V4, the attributes of the real root element can be transferred to every record generated, see checkbox (6). Similarly, in (7), you can enter those elements that are actually outside item but that you want to include in each record. The required adjustment of the profile source structure currently needs to be done manually.

Internal XML Based on the Prior Settings

Internally, based on our prior settings, the input XML looks like this.

Record 1

Record 2

And here the fitting source or destination structure. Setter identifiers can be defined as usual, but they are already created when the source structure is created automatically. The destination structure was created with a 1:1 mapping.

Further Performance Improvement

See section Optional XPath Filter.