Understanding and demystifying the Scope of the Table Looping Functoid

Let’s have a look at some inside information that will appear in my upcoming book about maps. I want to demystify and clarify a few features of the Table Looping Functoid.

Inputs of the Table Looping Functoid

This functoid requires at least 3 inputs and supports up to 100. The official documentation states:

• Parameter 1: A link from a repeating node in the source schema. The number of instances of this structure in a particular input instance message determines how many times the associated table looping grid is processed.
• Parameter 2: A constant input parameter that defines the number of columns in the associated table looping grid.
• Parameters 3 – 100: A link from a node in the source schema or from another functoid, such as a Value Extractor functoid, or a constant input parameter. The relative order of parameters 3-100 is unimportant.

For anyone familiar with functoids, the last parameters (3–100) do not create confusion. These are simply the values we map from the source to the destination. The order is not important because the Table Looping Grid property defines the appearance order.

What the Table Looping Grid does

The Table Looping Grid is basically a configurable table containing an arbitrary number of rows, configurable while editing the table, and a number of columns specified by the second input parameter of the Table Looping functoid.

Each table cell uses a drop-down list. The list contains values from parameters 3 to the last parameter. These parameters include links to the functoid and any constant input values.

If a link input parameter has a Label property, BizTalk displays that label in the drop-down list. Otherwise, BizTalk shows the Link Source value. Labels are usually easier to read. Constant parameters appear as their constant value.

Important notes:

• The number of rows in the Table Looping Grid does not come from any input parameter of the Table Looping Functoid. The number of rows is never dynamic.
• You define the number of rows during development. You do this to apply a specific transformation rule and solve a particular mapping problem.

Why developers misunderstand the functoid

Developers often use this functoid correctly when they work with a repeating record in the source schema. However, problems appear when they try to transform a flat structure into a recursive structure.

At this point, many developers misunderstand the first input parameter. To be honest, the official documentation does not explain it clearly either.

The documentation states that the first input must be a scoping element linked from a repeating group. That is not entirely true.

Clarifying the documentation

Although the Table Looping Functoid states that the first input must be a scoping element linked from a repeating group, that is not really true. In fact, this description is completely false for me!

• A link from a repeating node in the source schema – most commonly used but not entirely true, you can also make use of a constant value, a simple node, or an element.
• The number of instances of this structure in a particular input instance message determines how many times the associated table looping grid is processed. – I understand and, in a way, yes, but sometimes developers understand that this is the number of rows that they have to define in the table Looping Grid, which is not true, or that this input requires a number, and in fact, this is also not true.

So, to be clearer, for me, the best description of this parameter is:

• Parameter 1: the first input parameter defines the action scope of the Table Looping Functoid, and it can be defined by a link from a source tree node, repeating record, simple records, or even elements, or by a constant value. This means:
  • If the scope is defined by a repeating record or repeating element, the Table Looping functoid will be created/execute in each occurrence of the record or element (in each iteration over the node). We can define this as multiple scope action.
  • If the scope is defined by a simple element or record (which occurs only once), the Table Looping will be executed only once. We can define this as a simple scope action.
  • If the scope is defined by a simple constant value, whether an integer, alphanumeric, or string, then the Table Looping will be executed only once. Again, this is a simple scope action.

Both these options are valid! For those looking to move beyond the basics of message transformation, I highly recommend checking out my eBook, BizTalk Mapping Patterns & Best Practices, published in partnership with BizTalk360.

This resource is a deep dive into the real-world challenges of data transformation. It covers:

• Mapping Patterns: From simple field-to-field links to complex structural shifts.
• Performance Optimization: How to build maps that don’t slow down your environment.
• XSLT vs. Functoids: Knowing exactly when to use built-in tools and when to write custom code.

Whether you are maintaining a legacy BizTalk 2010 environment or planning a migration, these patterns are the foundation of clean, maintainable integration.

Download the full eBook here: BizTalk Mapping Patterns & Best Practices

Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.