BizTalk maps are graphical representations of XSLT (Extensible Stylesheet Language Transformation) documents that allow us to perform, in a simple and visual manner, transformations between XML messages.
Maps can be used for processing messages received at a receive port, inside orchestrations or for processing messages sent to a send port, as the following figure suggest:
The map editor, BizTalk Mapper Designer, enables us to perform transformations of complex messages in a visual and extremely simple way, expressed in graphics associations of links that define the relationships between the various elements of messages.
Transformations inside maps can be defined as simple relations, such as copying a name or address of a document to another. We can express a direct copy of the data using a link, which is represented in the BizTalk Mapper Designer as a line connecting the elements from source to destination elements:
The mapper grid plays a critical role in the definition of maps, containing the links and functoids that control how data in a source instance message is transformed into an instance message that conforms to the destination schema.
By default, a map file is created with one grid page named “Page 1”. Once you have selected source and destination schemas, you can access the grid page menu by right-clicking the tab at the bottom of the grid page.
When we perform a transformation in the message there are 5 basic functionalities that typically arise:
This is the most basic operation of all, where we intend to move a value from the source to the destination schema, without perform any kind of operation on the values (direct copy or simple drag-and-drop).
Concatenate two or more values from the source to a particular element in the destination schema, is another of the daily operations in mapping, for this we need to:
Often we don't want to simply move values from source to destination schema and sometimes we need to generate data output according with certain conditions. We can make these conditions in many different ways using functoids or through custom scripts, here's an example: test whether the value in the source is a valid string, if so map it to the destination schema, for this we need to:
Custom scripts are commonly used in more complex transformations or to facilitate some mapping conditions. Basically there are two main scenarios where we can or should use this functoid:
In many scenarios we need to add new data to the final message that do not exist in in the source message. It is normal to find situations where, based on existing data in the source message, we will need to consult an external system, e.g. database, in order to acquire more information to complete the required data in the final message. An example, more basic and simple, is to add a stamp date in the final message, describing the date and time it was processed. For this we need to:
If you are dealing with large maps, they can become very complex and therefore very difficult to maintain and read.
You can segment groups of links in to different grid pages. BizTalk allows to create/remove/delete and order grid pages. You can see this like different pages or segments of links of the map. By default, map file is created with one grid page named “Page 1”. This feature has been described earlier.
In previous versions of the product, by default, The XPATH query is presented if a link from the source schema is established to a functoid:
Although it may seem a trivial feature and without significant impact, in my opinion, this is an important supporting map feature in the long term. While the ideas are fresh in our head we know what we are doing, but if it is necessary to intervene after some time and review the mappings, this feature will make our task easier.
At design time we have, included in Visual Studio, 3 features that allow us to test and validate the maps:
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:
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.
This option allows us debugging 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.
All source code used in this article is available on MSDN Code Gallery to download: BizTalk Server – Basics principles of Maps.
Due to the countless number of different existing systems and applications in organizations, it is imperative to use good tools and techniques to produce solutions that work for many years in a controlled and easy way to maintain. At the same time, new processes are added and existing ones will suffer minor improvements, all this without losing track of what is happening in production environment.
Sandro Pereira DevScope | MVP & MCTS BizTalk Server 2010 http://sandroaspbiztalkblog.wordpress.com/ | @sandro_asp
Another important place to find a huge amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki.
Read suggested related topics:
This article is also available in the following languages
Ed Price - MSFT edited Revision 12. Comment: Title casing and tags
Steef-Jan Wiggers edited Revision 20. Comment: Fixed Typo
Steef-Jan Wiggers edited Revision 21. Comment: Minor Edit
Maheshkumar S Tiwari edited Revision 23. Comment: minor edit
Horizon_Net edited Revision 4. Comment: added language tags
Sandro Pereira edited Revision 9. Comment: Fix TOC