Example: Repeating elements in messages

A common use of repeating elements would be to populate tags with lists of data or generate repeating XML elements. The following example illustrates how to do both.

The test that is used to write tag lists and generate repeating XML elements is shown.

The test is opened for editing

Now, each component of the test is described to help illustrate the actions that take place in each one.

Test data set

An Excel test data set is created by using the spreadsheet data that are shown earlier. The data preview is shown.

The data set in Preview mode
Note: The tags that you use in the test must be present in the Tag Data Store. They can be entered manually. In this example, however, the column names are copied from the data set and pasted into the Tag Data Store.

Lookup test data action

The Lookup Test Data action scans the selected test data set and looks up values that match an id of 2.

The Config page of the Lookup Test Data window

In the example, the two rows of data that have an id of 2 are returned.

The Store page of the Lookup Test Data window

The action is configured to store all matching rows, which means it writes tag lists instead of single values. Additionally, all of the columns from the test data set are mapped to tags of the same name.

The Lookup Value field can contain simple numeric comparators. Consider the following example:
 <5 yes <10 no <15 maybe <20 no 200 ask again * yes

On the Store page, change the Output format option to Store one matching row only. Comparisons are evaluated from left to right and stop as soon as a match is found. The following table shows example results.

Table 1. Results of numeric comparisons in the Lookup Value field
Input Result Comments
7 no The number 7 is not less than five, but is less than 10.
50 yes The number 50 does not match any of the specified values, and so passes through to the * (representing any value).
200 ask again The number 200 is an exact match. Note that this is not written with an operator, such as "=200".
A yes Numeric comparison fails, so the test falls back to string matching, and A matches *.


The Publish action contains an XML message to which the schema is applied. The transport that is used for publishing is not important for the example. Each available field in the message is quick tagged. This means, the contents of the field are set to a tag that matches the name of the element. The fields within the data set that contain repeating elements are marked as such.

Additionally, the contents of the entire message are stored in a tag named %%text%%. This tag is created on the root of the XML message, the text (String) element.

Log actions

The two log actions are used to show (in the console) these things:
  • What is being mapped into the specified tags
  • The XML that is being generated from the lookup


When the test is executed, this is what happens:
  • The fields in the data set in the rows that match an "id" of 2 are mapped to the specified tags.
  • The XML of the full message (based on the matching rows) is mapped to the %%text%% tag.

The output of the first log, containing the tag lists, is shown.

As you can see, all of the tags were written as lists, and Order ID and Person contained null values in the second row of data.

The dynamic XML, generated in the message according to the matching rows in the data set, is shown.

<order orderid="002">
  <address addresstype="billing">

Note the 2 "item" elements, created from the 2 rows of data that match an "id" of 2 from the Lookup Test Data action.