How BizTalk Maps Work – Processing model (Part 1)

Posted: April 16, 2012  |  Categories: BizTalk Maps


Maps or transformations are one of the most common components in the integration processes. They act as essential translators in the decoupling between the different systems to connect. This article aims to explain how maps are processed internally by the engine of the product as we explore the map editor BizTalk Server.

This series of posts is based on the series “BizTalk Server – Basics principles of Maps” published earlier where it’s explained in detail the basic functionalities of maps and how they can be implemented. This article intends to be an introductory note for who is taking the first steps in this technology.

As explained in the previous article, when we perform a transformation in the message there are 5 basic functionalities that typically arise:

  • A simple mapping of a given value (direct copy)
  • Concatenation of values
  • Conditional selection
  • Custom scripts
  • Add new values (data)

Based on these functionalities we will explain how the BizTalk Mapper Designer processes and translates these links internally. To better understand its functioning, we perform some changes to the structure of the destination schema: we add an optional element (“CivilStatus”) and intentionally disorganized its structure.

disorganized destination schema

Processing model of BizTalk Maps

Although traditionally the information is extracted from the source as it is being processed, in reality in the models based on XSLT what happens is exactly the opposite: each element in the target (destination schema) causes the search for the corresponding in the source. Here’s a traditional example:

  • The source is traveled (parsed) from beginning to end of file;
  • The information is extracted from the source in the exact order that is found;
  • The mapping rules are constructed as the source is traveled (parsed).

BizTalk also uses this technique in the conversions of Flat Files to XML format (Syntax Transformations, also explained in BizTalk Server – Basics principles of Maps), however, the transformations inside maps use a different approach, as we will see later in this article.

One of the important factors when using integration tools is also having in mind the existing standards format or technologies, and that’s what the creators of the product made. BizTalk works internally, almost exclusively, with XML documents, so it made sense to use a standard format to carry out this type of transformations. For that W3C defined the XSLT (Extensible Stylesheet Language Transformation) as the standard format to represent the transformations between XML documents.

This way all links and functoids that are graphically visible in the Mapper Grid are not more than a graphical representation of an XSLT document that transforms the source document in a particular format specified by the destination schema, i.e., BizTalk maps are graphical representations of XSLT documents that allow us to perform, in a simple and visual manner, transformations between XML messages.

We can say that BizTalk maps always have its focus in the final document, thereby making sense that the mapping rules to be processed in the sequence required to create the final document. When the map is compiled, these rules are translated into XPath queries and XSLT functions in order to transform the required information, i.e., the mapping rules are built from the destination (target) and not by the source as some traditional tools (or traditional models).

BizTalk maps follow the model below:

  • The BizTalk mapping engine traverses the destination schema from beginning to end;
  • The mapping rules are constructed and executed as links are encountered in the destination schema;
  • The information is extracted from the source when a link is encountered in the destination schema.

Note: We can use an XSLT created by an external application and include it on the map inside a Scripting functoid (XSLT custom script) or by importing a XSLT file that carrying out the complete transformation of the map (of course the editor – BizTalk Mapper Designer – does not represent the graphical representations – links and functoid – in this scenario).

Related links

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.

1 thought on “How BizTalk Maps Work – Processing model (Part 1)”

Leave a Reply

Your email address will not be published. Required fields are marked *


Back to Top