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. In this article, as we explore the BizTalk Mapper Designer, we will explain its main concepts, covering slightly themes such as product architecture, BizTalk Schemas and some of the most widely used standards in the translation of messages.
Maps transform messages from a source schema format to a target schema format. They are created with the BizTalk Mapper, a visual tool used to map between schemas by drawing lines from source to target and by using functoids.
Functoids are BizTalk components that provide encapsulated functionality for doing things like Boolean logic and string manipulation. The screenshot below shows the map Workplace.
XSL Stands for Extensible Style sheet Language, and is a style sheet language for XML documents.
XSLT Stands for XSL Transformations.
The Built-In Functoids as shown above, BizTalk Mapper uses the XSLT as its source languages.
The steps below help to create the custom XSLT and apply to the maps.
Using the Direct XSLT (Custom-XSLT) we have the performance benefits when compared to the direct mapping.
The Custom XSLT is the best option when the mapping logic is very complex (using lot of functoids and scripting functoids) to reach our logic.
In the past couple of months, I learnt when to use the BizTalk Virtual Mapper (Using Functoids...) and when to use the Custom-XSLT mapping.
Although, the post might be a debatable but I consider them to be a good guidelines for my future BizTalk mapping practices.
My choice is using the Custom-XSLT than using the BizTalk Mapper, once you get used to it, I guarantee you will not want to go back to using clunky visual interface ever again, the main reasons are…
If we have a simple map which uses no scripting functoids and some 50-100 connections will be easy to understand.
For the more complex map as the scenario above, custom XSLT will be very good.
The Custom-XSLT is very easy to maintain when designed properly.
The Complexity of the Map that is designed using the Custom-XSLT is really less when compared with the map designed using the BizTalk virtual Mapper.
Just consider the map which is very complex and requires you to have more logical pages to have a clear view. In this case, maintaining the complex BizTalk map would far outweigh the benefits of rapidly creating in the visual interface. In this case the Custom XSLT will be good choice.
My Preference is using the Custom - XSLT which is a good choice if you are most familiar with the XSLT. If you are not familiar with the XSLT, you need to get the good learning XSLT kit to get familiarized, to build the complicated project efficiently...
Read suggested related topics:
Steef-Jan Wiggers edited Revision 20. Comment: Minor edit
Naomi N edited Revision 17. Comment: Minor edit - nice article
Steef-Jan Wiggers edited Revision 14. Comment: Fixed typo, minor edit
Carsten Siemens edited Revision 10. Comment: Fixed typos
Carsten Siemens edited Revision 9. Comment: Fixed typo
Richard Mueller edited Revision 8. Comment: Removed (en-US) from title, added tag
Ed Price - MSFT edited Revision 5. Comment: Font style and size, per guidelines. Great article!
Steef-Jan Wiggers edited Revision 4. Comment: Grammer, errata
Rajasekhar.R edited Original. Comment: Modified the Design
Good article!
i think the article is a little biased.
Are there no scenarios where you think that a BizTalk Virtual Map would be ok?
I would expect the following:
1. For new developers to BizTalk a map is a much easier way to develop mapping rather than learning custom xslt
2. When working with developers from other teams of business users the visual aspect can make it easy to work with them to develop the mappings
3. A biztalk map can be self documenting if well maintained
Probably a few others.
I dont disagree with your points about performance and other things but i think there is a more even balance over when custom xslt is more appropriate.
For most teams I would expect that they would be best off picking one approach over the other as their default and then agree with the rest of the team over exceptions to their default. In most teams I work with I would encourage the use of the normal maps for most cases because in most cases you wouldnt really notice much difference and as a new developer to the team i would expect to see biztalk maps. When we have exceptions to this rule i would encourage your documentation to include the reason why this map is done differently eg: because it performs n% better.
Lower your total cost of ownership by having consistent ways of doing things
My personal preference is to use XSLT, but Michael make a good point. For development shops new to XML transformation, they may prefer to use BizTalk maps for simple transformations since the technology is easier to learn. And simple BizTalk maps are relatively easy to maintain. But when transformations are very large and complex, BizTalk Maps are just too difficult to maintain. The new mapper does provide some good improvements, but overall XSLT is my recommendation for complex maps. Also, performance suffers a great deal with the XSLT generated by the BizTalk mapper. Each development shop should make a decision on if and when to use Maps and XSLT. I've found that a common strategy is to use the BizTalk Mapper for simple maps and XSLT for complex transformations or transformations that are a bottleneck in the process.
Very good article
Reading this article... I am certainly motivated to look at xslt seriously.... valuable information..