ESB Fault Handling Bug: Message Content Type Incorrect

Question

We have an ESB Orchestration service & we are trapping errors and creating a fault message as per the ESB documentation, i.e. XLANG like

Microsoft.Practices.ESB.ExceptionHandling.ExceptionMgmt.AddMessage(FaultMessage, InMessage);

However when you view the message within the ESB Portal the content type of our failed message is always showing as text/plain when in fact it should be text/xml. This prevents resubmission because the ESB Portal fault handler treats text/plain messages as flat file & so we can't resubmit to the WCF receive handler.

I have not been able to find anyway of telling the ESB toolkit the correct content type of the message - how is it determining this? As far as BizTalk is concerned our message is an XML message - if I view the messages in the tracking database I can clearly see our incoming message as text/xml. On the All.Exceptions port I see 2 messages, one being the ESB fault message & the other is our failing message which BizTalk shows as text/xml.

So is this an ESB bug?

The ESB fault handler for messaging only scenarios seems to work fine.

Answer 1

I looked at this a bit more & found that practically all messages are being logged as text/plain. It seems the ESB toolkit is using a function in urlmon.dll called FindMimeFromData which relies at peeking at the data. If the message begins with an XML declaration (<?XML?/>), then this function returns text/xml, otherwise it comes back as text/plain. Unfortunately most XML messages within the BizTalk messasge box have the XML declaration stripped off after going through the XML dissassembler pipeline & later re-insterted using the XMLTransmit pipeline. Because of this, practically all errors logged by the ESB toolkit show the message type incorrectly. BizTalk must use some other method to determine the message type since it shows it as text/xml - it has a ContentType property for each message part which is what the ESB aught to be using.

One way to solve the ESB fault logger problem is to create a custom version of the ESBFaultProcessor pipeline and add an XML Assembler component with AddXmlDeclation = true. This component runs before the ESB pipeline components, so the message will have an <?XML?/> declaration. Then create a "All.XML.Exceptions" port, like All.Exceptions, and then use filters to ensure only XML msgs get to this port & non-XML messages to the All.Exceptions port.

Answer 2

Hi MikeGBUK,
I  have the same issue with esb.portal, which show content type of failed message as text/plain.
Colud you share filter expressions form All.Exceptions and ALL.XML.Exceptions send ports? It will be very helpful for me.

Thanks.

Answer 3

Outlife,

I haven't got around to doing this yet, but you could try filtering on the BTS.MessageType context property - if it exists and NOT = string, then the message is likely to be an XML message. You need the reverse rule for the All.Exceptions port, but there is no !Exists comparator. If you don't have any non-XML messages, then why not just change the pipeline on the All.Exceptions port?

Answer 4

I have fixed this by modifying the SP usp_insert_Message in the EsbExceptionDb, adding these lines:

IF (@ContentType = 'text/plain' AND LEFT(@MessageData,1) = '<')
BEGIN
  SET @ContentType = 'text/xml'
END