How to Apply DataWeave to the Real-world: Looping (Part 3)

October 31 2017


So far in this 3-part series, we have looked at variables (Part 1) and functions (Part 2) in order to leverage them to our advantage. In this third and final part of the real-world DataWeave series, we will look at another common problem area, that of performing nested loops in data structures.

This case seems to come up regularly when dealing with HR systems that return a list of employees. Each employee item in the list has some attributes and often has a list of job records attached to the employee if they have held multiple positions at the organization.

Typically I see HR systems returning data in an XML format, but anytime we deal with data transformation in DataWeave we want to make sure we are thinking in terms of the object structure and not to concern ourselves with the format specifics.

Now, when we take a list of items as a part of a payload input we can use the syntax:

In these instances, the “$” is a pointer to the current item in our list and we can reference any fields attached to it. When we start working with nested lists, things get complicated if we just rely on this label to access values

A more human-friendly way is to label the inputs as follows:

Our current item in the list is identified by the label “input”, this will make things much easier when we start working with nested lists.

Now onto our scenario, on this occasion we are going to be receiving an XML input with some nested lists that we will want to loop through and use our nicely labeled pointers to the items in the list as we transform them. Our input looks like:

Our first task is to work on the list of “employee” items, we can use the “map”operator as in our earlier example and we will label our pointer so we know how to use it deeper in the transform. I have labeled the item pointer “e” and the list index as “empindex”:

Another way to think of this is that we are doing the equivalent of “for each employee in employees”.

Next, we will want to access each job object, this time our DataWeave goes inside the initial map operator:

By using “e.*job” as our starting point for our map in this DataWeave, we are doing the equivalent of “for each job in employee” and, of course, we are labeling our item pointer as “j” and our list index “jobindex”.

At this point, I recommend mapping a singular field value and using the DataWeave preview to ensure we have the basic construct correct. In this example, I recommend using the job title as an output field as it is unique––so we can easily see if we have the correct output structure. Our DataWeave script should look like below, note that we are referencing the job title using “j.title” as we had called our item pointer “j”:

In our data sample, we had three job records for this employee––we should see those same three in the preview, as follows:

Once we have confirmed we have the correct structure, we can continue mapping the rest of the fields. As we labeled our list item pointers uniquely we can easily reference data fields from anywhere in the input payload using the right pointer. In my output I needed to output a mix of values from the job and employee into a list of job records:

In the interest of being tidy with my output JSON, I also used the “when” clause to prevent my output from containing a null “end_date” value for the latest job that the employee currently holds. Once complete this DataWeave now outputs the structure I was after:

In summary, in order to avoid getting caught up in the pointer confusion you have to label the pointers to list items as part of your map definition when using DataWeave. This technique can be applied to any number of nested lists and will make life much simpler when trying to output fields from different inner and outer loop(s).