Wednesday, 08 July 2009

Hi all

Upon reading a forum post today, I stopped to think about the usage of custom XSLT to completely replace the mapper, custom scripting functoids and the built-in functoids.

Some people can’t be bothered using the mapper and go straight to custom xslt whenever a mapping is to be created. Others use the built-in functoids whenever possible. And the rest go for some path in the middle, with functoids and the occasional scripting functoid whenever the built-in functoids either can’t get the job done or seem to be too troublesome to use.

The advantages of custom XSLT

  1. Performance. It seems rather obvious that automatically generated XSLT can’t perform as well as custom XSLT. So if you really need high performance, use your own XSLT.
  2. Maintainability. I will be using this argument against custom XSLT as well :-) but in essence, some people think that having a map with perhaps 200 functoids is too difficult to maintain. Sometimes you need lots of functoids in order to complete some mapping task that can be easily done in XSLT. In that case, the XSLT can be more readable and hence maintainable than using functoids.

The advantages of using the built-in functoids

  1. Overview. Using the functoids can give a developer an overview of what functionality a map provides, whereas custom xslt needs to be gone through and “parsed” by a developer before he can understand what is happening.
  2. Maintainability. (See, there it is again – in the opposite direction). A BizTalk developer knows about maps and functoids. He does snot necessarily know about xslt – and even if he does, he is not guaranteed to very proficient in it. By staying with the functoids you give a BizTalk developer the best possible opportunity to understand a new map he is going to maintain.

The advantages of using functoids and the scripting functoids

  1. Everything is possible :-). Basically you can do what you want. Use built-in functoids as much as you prefer and throw in scripting functoids if you think the solution either can’t be done with the built-in functoids or is too troublesome to do.

My preference

Well, those that read my blog regularly wont be surprised when I say that my preference is to use the built-in functoids whenever possible. I turn to XSLT only when I cannot solve my problem with the built-in functoids. And when I need XSLT, I always use custom scripting functoids to supplement the other functoids, so I let as much of the job as possible be handles by built-in functoids. I never use custom XSLT to replace the map. My main reasons for this are:

  1. Maintainability. I truly believe that it is easier for a new BizTalk developer to troubleshoot and/or change an existing map if only built-in functoids are used.
  2. Overview. If a BizTalk developer opens up a map and sees lots of scripting functoids, he needs to open them all up and examine the code inside it in order to know what the map does. And after looking at 5 different scripting functoids, he needs to go back and look at the first again. Really annoying!

If I am doing a rally complex map where the number of custom scripting functoids is larger than the number of built-in functoids, I might consider using a custom XSLT script… but this haven’t happened yet :-) And also, if i run into really serious performance issues, I will consider it as well, off course.

Just my thoughts.

--
eliasen

Wednesday, 08 July 2009 21:36:39 (Romance Daylight Time, UTC+02:00)  #    Comments [2]  | 

Theme design by Jelle Druyts