Rarely does data emitted from one system match the structure and content expected by another system. Hence, some sort of capability is needed to translate data so that it can be digested by a variety of consumers. Extensible Stylesheet Language Transformations (XSLT) is the industry standard for reshaping XML documents, and the BizTalk Mapper is the tool used by BizTalk developers to graphically build XSLTs.

When creating a map, the BizTalk Mapper uses a straightforward design paradigm where the source schema is identified on the left-hand side and the destination schema resides on the right-hand side of the tool:

We are often lucky enough to be able to make direct connections between nodes. For instance, even though the node names are different, it is very easy to drag a link between a source node named FName and a destination node named FirstName. However, you are frequently required to generate new data in a destination schema that requires reformatting or reshaping the source data. This is where the BizTalk Mapper functoids come to the rescue. What in the world is a functoid? Well, it is a small component that executes data manipulation functions and calculations on source nodes in order to meet the needs of the destination schema. There are over 75 out-of-the-box functoids available in the BizTalk Mapper, which span a variety of categories such as string manipulation, mathematical calculations, logical conditions, and cumulative computation. This can be extended with the custom functoids that you can add to your project.

If you don't see exactly what you're looking for, you can use the Scripting functoid that enables you to write your own XSL script or .NET code to be executed within the map.

An example of the concatenate string functoid configuration screen is shown as follows:

It's important to understand that the BizTalk Mapper is for data normalization logic only, not business logic. If you need to make business decisions, a map is not the right place to store that logic. For example, you would not want to embed complex discount generation logic within a BizTalk map. That sort of business logic belongs in a more easily maintained repository than in a map file. As a simple rule, the map should only be responsible for shaping the output message, not for altering the meaning of the data in its fields. Maps are great for transformation instructions, but a lousy place to store mission-critical business algorithms.