Best Practices for Mapping array to multiple arrays

Conditionally mapping individual record elements from a record in a record list, to individual record elements in records where the records are in serveral different record list.

In my loop for the source record list, I entered the input array and no output array, because I have serveral of them. Then I branch on an element value in the record list and based on its value I am try mapping record elements to my destination elements, which are in recored that are in four different record list.

What is the best approach for specifying the output arrays, being that in you loop, you have entered the input array, but can’t enter the output array?

Hopefully with out having to loop thru the source array more than once or create temporary record and handle the indexing yourself.


I’m assuming that each record from the source list will be mapped to only 1 of the 4 target lists. I also assume that you map out different fields depending on the target list.

Loop over the source list
…Branch on a record var
…value 1: SEQUENCE
…MAP the source record to a target 1 record AT THE FIELD LEVEL, not the record level.
…INVOKE appendToRecordList–target list 1
…DROP target 1 record
…value 2: SEQUENCE
…MAP the source record to a target 2 record
…INVOKE appendToRecordList–target list 2
…DROP target 2 record
…value 3:

This approach will create independent copies of each source record and append them to the appropriate list. No need to worry about indexes. The key step not to forget is the DROP step. Otherwise, you’ll use the same temp record reference over and over, wiping out the previous data and ending up with lists where every entry points to the same record.

The other key item is map at the field level, not the record level. If you map one record to another, even a nested record, you’ll get a reference, not a copy.

One caution: if the lists are large this will be very inefficient as appendToRecordList does an array allocation for EVERY call.


Rob, I was afraid you would say that. I just finished implementing the mapping, as you sugguested and yes it is extremely time consuming. I have fairly complex structures and a lot of record elements that require mapping.

The other issue I noticed, by accident, was if you are looping thru a recordList that is inside another record list and mapping at an element level to a destination record list and need to map a few elements from the source parent recordlist to a record or element not in the destination recordlist, WM was able to handle this, or at least seems to. Just wondering if this approach has any side effects?


loop/parentRecList/childRecList-inarray /DestRecList-outarray
—map /childRecList/element to /DestRecList/element
—map /Parent/element to a different element or record element


Side effects will depend on if you do validation or not.
Record definitions serve two purposes (well maybe more than that but these are two of them): 1) help development so we know what fields to use when mapping; 2) to define a structure to follow when validation is used.

If you don’t use validation, or “Allow unspecified fields” is checked, then you won’t run into any issues when mapping “extra” fields.

In another scenario, given the following structures

Record Price
—record UnitPrice
—recordList PriceBasis

I loop through source record list (in array) destination Record Price | recordList PriceBasis (out array)
branch on source record element @indicator
map element 1,2,3 to destination Record | recordListPriceBasis| element1,2,3 if label is = 001

this works, but in the source I have two index 0 and 1. for the record index 0, the @indicator is = 001 and for the record index 1, the @indicator is = 002. After running the flow steps (above), my destination recordList has two index 0 and 1. Record Index 0 has the mapped element values as expected, but unexpectly, I have record index 1, which is null. I am guessing the loop is creating this second record index and initalizing it to null because there is no map step defined for the branch that matches the value of @indicator in the second source record index.

How can I avoid creating null record indexes in the destination recordlist when the source record index of the source record list has not matching map step?


Two approaches:

  • Map to a new record and use appendToRecordList for the output record list.

  • Continue as is but when using the output record conditionally use the PriceBasis elements only if they are not null.

Option 2 probably isn’t feasible for what you’re doing and not really advisable–lot’s of potential issues (can’t do recordToDocument directly, someone will forget about the null entries later on, etc.)

I believe the array for the output list is allocated up front for the loop, as an optimization, to match the size of the input list. It’s actually rare that in the mappings I’ve done that I get to set the output list in the LOOP step–for exactly this reason.

Hi Reamon,
I know that this was a old thread. but have one question on output arrays in loops. i posted this kind of question in another thread, but didnt get heard any replies yet.
the question i have is… when we use loop step, we have an option of providing the output document list name in output array. which one of the below two is advisable : 1. using append to document list 2. out document list name in outout array.
i read previously in some thread (not able to figure out where) that using document list in output array is not recomended.
please suggest the best way according to our best practices.
Also, please show some light on pros and cons of using document list name in output array of the loop.

Thanks in advance,

In general, use an output array in the loop. The scenario where this cannot be done is if you don’t want an output entry for every input entry (e.g. you want to skip some input records). In that scenario, you can use appendToDocumentList (depending on IS/JVM versions, this can get slow when the number of items is more than a few hundred) or use a Java collection class (you’ll need to write a couple of Java services).