Custom XSLT, Scripting functoid, or built-in functoids – a question about religion?

by | Jul 8, 2009 | BizTalk Community Blogs via Syndication

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