BizTalk Server: Basics principles of Maps – Testing and Validation of maps (at design time) (Part 6)

At design time, we have included in Visual Studio 3 features that allow us to test and validate the maps:

• Test Map: Tests the selected map.
• Validate Map: Validates the map
• Debug Map: If a map is compiled successfully, Debug Map launches the XSLT debugger. It allows you to step through the generated XSLT, just like any other Visual Studio debugger.

These features are available to developers in an easy manner and directly from the development tool, Visual Studio, without the need to build and deploy the maps or even create and configure ports.

Test Map

Testing should be a continuous process as you build your map, not only at the end of development but when necessary or when an important mapping block is complete. For this, we need to:

• Open the Solution Explorer windows
• And execute the test by right-clicking the map name and selecting Test Map option

By default, an instance of the input schema is generated automatically with dummy values, according to their type, and tested in the selected map. In the end, the generated result, or the errors that occurred, are displayed in the output window.

However, all too often, this scenario is not ideal, and what we want is to test an existing document, not a dummy one, with the map. For this, we only need to configure the properties of the map before we execute the test:

• Right-clicking the map name and select Properties option;
• In the Properties window, set the TestMap Input Instance property with the path to the input file.

In this window we can also configure other properties such as: specify the format of the input instance message (TestMap Input) or the format for the output instance message (TestMap Output); specify the location where the Test Map should generate the output message (TestMap Output Instance), but more importantly we can specify whether we want to validate input instance messages against the source schema before you test the map (Validate TestMap Input) or the output instance messages against the destination schema after you test the map (Validate TestMap Output).

This last option, Validate TestMap Output, is extremely important for the partial tests of maps. By setting this property to False, we are able to test an incomplete map without being shown errors due to a lack of mandatory data, many of which are associated with areas still to be mapped; therefore, validating only the work done to date.

Note: This property must be set to True for the final test

Validate Map

This option allows us to validate the structure of the map. This way, we can inspect and analyze the XSLT code generated by the compiler, providing us with more information on how the maps work and also with an option to debug maps.

You can also extract the XSLT generated by the BizTalk Mapper for possible hand-crafting or for use in another project.

To perform this option, we need to:

• Right-click your BizTalk Mapper file in the Solution Explorer, and select the Validate Map option

Verify that there is a message in the Output window indicating that the operation succeeded. Also in the Output window, note the name and path of the output XSLT. This XSL file will be given the same name as the map file, but with an XSL extension. You can press CTRL and click the link to display the XSL file in the BizTalk Editor.

Debug Map

This option allows us to debug a map, thereby facilitating the identification and correction of complex problems of mapping at design time. Debugging a map is very straightforward and can be useful in many situations.

When debugging the map, the Debug Map feature uses the map file properties, such as TestMap Input Instance and TestMap Output Instance. Therefore, before you debug the map, it is recommended that you configure the input and output instance properties in the map file.

To perform this option, we need to:

• In Solution Explorer, right-click the map you want to test, and then click Debug Map. Visual Studio displays the map in XSLT format in its editor.
• Press F10 or F11 to debug the XSL code.
  • When you press F11 on a functoid call, Visual Studio steps into the C# code for the functoid. You can view the values of variables used in the functoid source code in the Locals debugger window.
• Standard debug shortcuts apply, including F9 to toggle a breakpoint and F5 to continue

Yes, I made 34 years today! This is my gift to you guys, and I hope you liked this series of posts.

Related links

• BizTalk Server: Basics principles of Maps – Introduction (Part 1)
• BizTalk Server: Basics principles of Maps – What are maps and where BizTalk can use them? (Part 2)
• BizTalk Server: Basics principles of Maps – Introduction to map editor (Part 3)
• BizTalk Server: Basics principles of Maps – Basic maps functionalities (Document mapping) (Part 4)
• BizTalk Server: Basics principles of Maps – Organizing Maps (Part 5)

Source Code

You can download the source code from:

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.