Biztalk scripting functoid failure

0
votes

In a BizTalk mapping, I use a scripting functoid from an external assembly. The assembly reference is added. When the mapping is used, however, it causes the following error:

'ScriptNS0:DoSomething()' has failed.

Now, this could mean any number of things that's wrong about this scripting functoid. However, even when a try-catch block is placed around the entirety of the C# code and the catch throws a custom exception, a proper new deploy yields the very same error and not the newly added custom one.

This would suggest that the mapping has been started and that something causes an error as soon as it hits the scripting functoid, but without actually performing even the slightest action within the function. When looking at the XSLT of the map, it seemed perfectly fine. The reference to the external assembly has been checked over and over again (and references of this external assembly as well). Everything looks fine and very much like many other mappings I've seen, yet still the outcome is the error above.

I realise this is a rather vague question, but does anyone have a clue what's going on here?

1
biztalkbiztalk-2010
Have you checked if the external assembly add to the GAC? - Zee
Does the map work when testing in visual studio? Is the map being used on a port or in an orchestration? - Dan Field
It is in the GAC and the error occurs both when the mapping is used on a port and when it's used in an orchestration. Not sure about being tested in VS. When the code from the external assembly reference is started from a console application on the same system, no error occurs. - HSN

1 Answers

1
votes

You'll have to test this out in Visual Studio. A few things to keep in mind:

  1. It's very possible that your actual data is causing an exception (it's an edge or corner case that you're not testing for in your console application).
  2. Throwing exceptions in external assemblies doesn't always translate well in an XSLT map, particularly when you do it on a Port. IIRC it's handled slightly more gracefully in an orchestration.
  3. If you can't reproduce this in Visual Studio testing or a unit test, you should be able to attach the Visual Studio debugger to the appropriate BtsNtSvc.exe or BtsNtSvc64.exe (or w3wp.exe if it's running in IIS/isolated host). Set a breakpoint on the entrance to your custom function, step through, see what's going on. If you're only able to reproduce it in a non-dev environment, see if you can set up remote debugging - but you may be better off enhancing the logging on the functoid in that case and redeploying if possible.

In general, I always try to do the following in custom functoid scripts:

  • Avoid throwing exceptions - use methods like TryParse rather than Parse, and on failure to parse return an error string or an empty string or the original string (depending on requirements/tolerance of destination system) rather than throwing an exception. If you do throw an exception, it's unlikely to be handled gracefully and unlikely that the exception type or text will make it back to a user/administrator.
  • Do error logging in these scenarios instead - generally using the Windows Event Log (System.Diagnostics.EventLog.WriteEntry). Make sure to use a properly registered event source, ideally one that matches your application name and is registered by your installation process, but at least one that exists on the computer to avoid throwing another nonsensical exception! This will allow developers/admins faster insight into what's going on next time.