No Scripting Map Operation/Functoid?

Question

In the world of BizTalk mapping, the mapper looked very good on the surface until you came across scenarios where you had to use the Scripting Functoid and its various modes or give up and go with Custom XLST. Recognising the limitations of the mapper tool is a key part of being an effective and productive BizTalk developer.

I see that the new mapper tool attempts to solve most of the problems that caused the use of the two techniques above and am impressed by the attempt at real world scenarios in the Transform Samples project. I am concerned, however, that there doesn't appear to be an equivalent to the Scripting Functoid.

The Scripting Functoid is very useful for the edge cases that often creep into maps where more complex logic has to be put into, say, an external assembly method. The new Expression Map Operators "could" be strung together to create the more complex logic but, from my experience of working with many C# developers moving to the mapper, the use of multiple logical functoids causes a lot of confusion, reduces maintainability and testabilty.

Is there a plan to some form of extensibility like the Scripting Functoid?

Answer 1

Hi Rob,          

Thanks for your feedback!

Currently we are thinking about exposing an extensibility functionality to solve some of the more complex scenarios which were being addressed in biztalk through scripting functoid. 

It would be great if you can share some of the use cases where you would like to apply the scripting functoid. Also since biztalk had multiple ways of scripting ( c#, inline xslt, xslt call template, calling external assembly), it would be great to know if there are any specific scenarios which for example can only be solved through xslt call template but cannot/are hard to be solved using lets say c#scipts).

Thanks,

---

Harsh

Answer 2

Hi Harsh,

External assemblies are generally used to encapsulate some specific logic for creating single values for an output element or attribute. The logic can be more convoluted that you may first imagine.  As an example, here's the header from a real method in a map helper method that would be pretty difficult to implement using the logical expressions.

        /// <summary>
        /// Takes all address elements, creates a sorted list, and returns one element
        /// </summary>
        /// <param name="houseName">Address housename</param>
        /// <param name="houseNumber">Address house number</param>
        /// <param name="flatNumber">Address flat number</param>
        /// <param name="road">Address road</param>
        /// <param name="addrline1"></param>
        /// <param name="addrline2"></param>
        /// <param name="town">Address town</param>
        /// <param name="county">Address county</param>
        /// <param name="element">The index of the element to return</param>
        /// <returns>Returns a string containing the address element requested</returns>
        public static string GetAddressElement(string houseName, string houseNumber, string flatNumber,
                                               string road, string addrline1, string addrline2, string town,
                                               string county, int element)

Obviously a method like this needs to be tested thoroughly and it's much easier to test outside a map via normal unit testing. It's also much easier to visualise and maintain outside the map. I have many more examples of code like this in external assemblies.

As for inline C#, This is generally not a great idea because the C# script can't easily be tested. I'd only use it if you have to maintain some variable state during the execution of a map - external assemblies don't allow you to store variables that only live for the duration of the map unless it's all within a method.

Inlne XSLT and Call Template is generally used for creating output structures and getting over mismatched source and target structures. For example, a source document that contains a nested hierarchy is hard to map to a flat name/value structure (possibly nested within an hierarchy) without using the Scripting XSLT functionality.

It looks like you may be addressing some of the need for Inlne XSLT and Call Template  with your new Loop and List operations. But, I wouldn't be too sure that all developers like coding with graphical tools when dealing with more complex problems - it can damage productivity when trying to code and maintain the map. I've seen many people attempt to string functoids together for problems that would only be a few lines of XSLT code.

The key for me is always productivity. The big selling point of the BizTalk mapper was its apparent simplicity but, like all mapping tools, it has limits that need to be understood quickly by developers so that they make the right choices and hit the deadlines.

Hope that helps?

Thanks

Rob

P.S. The other thing that the new mapper could benefit from is using XPath 2.0 (or greater) rather than XPath1.0.  XPath 2.0 is much better with useful functions like distinct-values which really improve productivity.

Answer 3

Thanks for the feedback Rob,

           Not sure if the message was clear, hence restating : Yes we are planning to provide a Scripting Functoid.

Thanks,

---

Harsh