Behavior of BizTalk Map’s Scripting Functoid

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 sharing.

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());
return dt.ToString(“yyyy-MM-dd”);

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 result.
  • Finally, what if I changed the parameter type from “string” to “boolean”? Answer: same result.

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 matter either.

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?

Technorati Tags:

Author: Richard Seroter

Richard Seroter is Director of Outbound Product Management at Google Cloud, with a master’s degree in Engineering from the University of Colorado. He’s also an instructor at Pluralsight, the lead InfoQ.com editor for cloud computing, a frequent public speaker, the author of multiple books on software design and development, and a former 12-time Microsoft MVP for cloud. As Director of Outbound Product Management at Google Cloud, Richard leads a team focused on products and customer success for app modernization (e.g. Anthos). Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.