Why the 100 Parameter Limit in the BizTalk Table Looping Functoid Shouldn’t Matter
If you have ever used the Table Looping functoid in a BizTalk map, then you’re aware of its ability to take multiple inputs (whether they’re links from a source schema or other functoid outputs), and configure them as a table looping grid, so that these values can be used to create multiple nodes in the destination schema. Essentially, this functoid can be used to unpivot repeating or flattened data into multiple nodes.
For example, in the mapping below, I’m taking a flat file that has repeating fields to represent ten Line Items, all on a single record. Using the Table Looping functoid, I can map these repeating fields to create multiple LineItem records in my destination.
However, the limitation to this functoid is that it can only have 100 parameters. And the since first 2 parameters are used to specify the number of rows and columns, that really only leaves 98 parameters that you can specify. In the example above I’m mapping 70 fields (7 fields per set of line item fields) to my table looping functoid, so I’m well within the 100 parameter limit.
But let’s say I need to map another 4 fields for every Line Item. That’s an additional 40 fields I’ll need to link to my table looping functoid, but there’s only room for 28 more parameters (100 – 2 row/column params – 70 field links = 28).
Fortunately, BizTalk doesn’t restrict how many Table Looping functoids you have linked to a destination node. And when you link multiple Table Looping functoids to a node, the mapping makes sure to set fields on the same record (based on the Table Looping row being set), rather than creating a new set of records for each Table Looping functoid.
So as an example, in the mapping below I added another Table Looping functoid to map the 4 additional Line Item fields. Each LineItem record in the destination message will have 7 of its fields set by the first Table Looping functoid, and the other 4 fields set by the second Table Looping functoid. And the resulting message will still just have 10 LineItem records (not 20).
The other nice thing about being able to split up Table Looping/input parameters into separate functoids is that it allows you to place the functoid on separate map pages, which will make the map easier to follow and maintain. In the screen below, I moved the second Table Looping functoid to another mapping page.