I’ve been spending way too much time building BizTalk maps recently, but, I did uncover
some interesting behavior of the Scripting functoid that I thought was worth
My opinion is that using “Inline C#” (or VB.NET or JScript) in the Scripting functoid
should only be for very simple operations, not page-long functions. In my case, I
was receiving a datetime value in “dd/MM/yyyy” format, and needed to convert it to
the XSD datetime format of “yyyy-MM-dd”. There were a few dates I needed to do this
for, so I used the Scripting functoid and wrote a simple function like this:
System.DateTime dt = System.DateTime.ParseExact(param1, “dd/MM/yyyy”, new System.Globalization.DateTimeFormatInfo());
So I simply cut and pasted the same “function” into multiple Scripting functoids.
In essence, the map looked like this:
I wasn’t completely sure what would happen when the XSLT was generated for the map.
Would it allow multiple functions with the same signature? Would I have to create
functions called “DateConvert1″, “DateConvert2″, etc? When I did this as a test using
a trial map and function, even though I had two functoids storing a function called
“DoSomethingCool”, the output XSLT looked like this:
Interesting. So, the XSLT generation engine noticed two methods with the same function
name and only put one of them into the map’s XSLT. Lots of questions then.
So what happened if I changed the implementation of one of those “DoSomethingCool”
methods? That is, same signature, but different behavior inside the method itself. Answer: same
result. It looked at the first implementation and generated code for only that one.
What if I changed the parameter name on the second Scripting functoid? Answer: same
result. Still only one function written out.
What if I changed the return type to “boolean” on the second functoid? Answer: same
Finally, what if I changed the parameter type from “string” to “boolean”? Answer: same
Let’s look at more complete picture of the generated XSLT, containing not just the
generated code, but the function call as well.
Notice that the return type appears irrelevant as it’s simply being printed out in
the XML node. Parameter name of “DoSomethingCool” doesn’t matter when the function
is called. The input parameter is always converted to “string”, so input type doesn’t
So, just be aware of these sort of side-effects of reusing the same inline code function
within a map. I like that I can reuse a simple function over and over, but it’s good
to know how the code generation actually works. Odds are you’d use an external component
for some of these situations, but what’s the fun in that?