Wednesday, September 29, 2010
Monday, September 20, 2010
Flowing clear error messages from transforms
This one comes up every now and again, and although targeted at a specific group – those who use custom xsl for their transforms – as our very own Oleg Gershikov has a nice approach to it, it is worth repeating here -
You have an orchestration, in which you have a transform shape, and at runtime, the transform fails.
This usually results with a typical BizTalk error message – very detailed, and thus very useful – for those who can read it…
What you want is a clear, business related error message, how do you go about achieving that?
Well – to start with, you add some validation in your xsl script, and provide the relevant message, something along the lines of -
<xsl:message terminate="yes">Here’s some nice error message, hopefully this will mean something to somebody….</xsl:message>
Then, you make sure you have a scope around your transform shape, in which you catch the Microsoft.XLANGs.BaseTypes.TransformationFailureException exception
From that exception, you can extract the message provided by the script using -
if(xslex.InnerException != null)
event.Message = event.Message + "Exception details: " + xslex.InnerException.Message;
event.Message = event.Message + "Exception details: " + xslex.ToString();
and use that to change an error that previously looked something like -
Error encountered while executing the transform SomeTransform. Error:Transformation failed..Microsoft.XLANGs.Core.XTransformationFailureException: Error encountered while executing the transform SomeTransform. Error:Transformation failed.. ---> System.Xml.Xsl.XsltException: Transform terminated: '
Here’s some nice error message, hopefully this will mean something to somebody…. '.
at System.Xml.Xsl.XsltOld.MessageAction.Execute(Processor processor, ActionFrame frame)
at System.Xml.Xsl.XsltOld.ActionFrame.Execute(Processor processor)
at System.Xml.Xsl.XsltOld.Processor.Execute(Stream stream)
at System.Xml.Xsl.XslTransform.Transform(XPathNavigator input, XsltArgumentList args, Stream output, XmlResolver resolver)
at System.Xml.Xsl.XslTransform.Transform(IXPathNavigable input, XsltArgumentList args, Stream output, XmlResolver resolver)
at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, Object outParams, Object inParams)
To something like this -
The process failed. Transformation Exception occurred creating request.Exception details: Transform terminated:
Here’s some nice error message, hopefully this will mean something to somebody….
Tuesday, September 14, 2010
Generics will break intellisense, so have some faith!
Sometime there are some BizTalk quirks that whilst not very harmful, can take along time to figure out, and so can really hurt productivity and get developers (and managers) very frustrated; they often happen when you’re taking a step or two away from the paved path, and do things a little bit more adventurous, but not to say not valid….here’s one -
We have a helper class we use in many orchestrations, call it class B.
It, in turn, inherits from the abstract class A, overriding a couple of functions, and leaving some unchanged, it does not add any new functionality.
When used in an expression shape in an orchestration, intellisense shows the two methods we’ve overridden, but does not show any other methods declared in the base class. This is just intellisense, though, keep typing, make sure you don’t make any mistakes, and the compiler will be happy with the ‘missing’ method.
Further more – make a mistake (wrong parameter, for example) and you’ll get the squiggly line with the correct error message and everything, just don’t expect to see the method and it’s signature in the intellisense drop down…
This took ages to figure out, with the developer first assuming he had done something wrong any tried everything to correct it, including the infamous close-VS-restart-VS, only when all things failed I suggested he simply keep typing and viola! how annoying is that?
Turns out we are to blame – for using Generics.
The base class is declared as
public abstract class A<T>
and the concrete class as -
public class B : A<[some other (enum) type here]>
This works fine with BizTalk 2006 – the member declared in the orchestration does not require any generic type so from a runtime perspective it all runs just fine; from a designer point of view there’s no problem declaring a variable of type B (as no generics are involved in this), but – as was evident – don’t expect to see anything from the base class in intellisense.
Wednesday, September 01, 2010
Value does not fall within the expected range, when starting application
Roni was phased by this one for a while, and I didn’t have a clue either, but starting an application which had worked just fine and to which he simply added another orchestration failed with the error -
Could not enlist orchestration <type details here>.
Could not enlist orchestration <type details here>. Value does not fall within the expected range
Turns out there’s a bug in BizTalk 2006 that prevents orchestrations from enlisting if not all orchestrations in an application are configured to run on the same host.
Very unlikely to be the case, which – I guess – is why we haven’t seen this so far; in fact, even now this is only the case because we don’t really care about the configured host, this value will never be used - When you ‘call’ an orchestration, as opposed to ‘start’-ing an orchestration, the host of the calling orchestration is used, regardless of what’s configured in the admin console.
For that reason Roni had left the default host in place, instead of changing it to the one hosting the other orchestrations in the application, which had surfaced this bug.
In any case – a kb, and a hotfix, does exist, and you can find it here