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 XLST, 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 “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”, allows us to test an incomplete map without being shown errors due to lack of mandatory data, many of them associated with areas still to map, 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 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 facilitate 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 on 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 post.

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:
BizTalk Server: Basics principles of Maps
GitHub