.debug

Let’s face it: the BizTalk Mapper generates grossly inefficient XSLTs.  Fortunately, since BizTalk 2004, we are given the option to write our own XSLT and plug it in the map.

Right now, we are in the process of migrating our BizTalk 2004 stuff to BizTalk 2006 (Beta 2), and one of our orchestrations are throwing up because one of the maps caused the following error:

—

Uncaught exception (see the ‘inner exception’ below) has suspended an instance of service ‘APBizTalkPipelines.SFFToAPPL(ba5ec7de-50d9-fb5b-9ff0-18da3cabd48b)’.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 685765f6-1a95-4c14-8e13-4144b66ec639 Shape name: ConstructAPPL
Message ShapeId: 12200bfa-6d27-4892-84b8-195425863f16
Exception thrown from: segment 2, progress 1
Inner exception: There was no XML start tag open.
Exception type: InvalidOperationException
Source: System.Xml Target
Site: Void InternalWriteEndElement(Boolean)
The following is a stack trace that identifies the location where the exception occured
at System.Xml.XmlTextWriter.InternalWriteEndElement(Boolean longFormat)   
at System.Xml.XmlTextWriter.WriteFullEndElement()   
at System.Xml.XmlWriter.WriteNode(XmlReader reader, Boolean defattr) {…}

 —

Great.  Really informative, isn’t it?  Well, to keep the long story short: something in our external XSLT caused it.  And believe it or not, the error has something to do with the /xsl:output tag.  Yes, if you have this tag somewhere in your XSLT, it will cause the above error. 

Please don’t ask how I figured it out; let’s just say I almost strangled myself to death as I was trying to debug this error.