MSMQT, Transactional Queues and Xml Validating Pipelines
I’ve spent a bit of time recently debugging and trying to figure out a number of weird problems that customers have spotted when trying to send messages to BizTalk via MSMQ (MSMQT on the server side), one particularly strange one was where the client (configured to be a Independent client – so has a outgoing queue) was failing to send messages to BTS2004.
From the MSMQ configuration tool you could see it was “connected”, but the “unacknowledged messages” counter was going up. You’d send more messages and they’d just stack up seemingly forever, it later turns out after a period of time they would properly fail and be moved to the dead letter queue.
I’ll cut a long (protracted) story short and get straight to the point, it turned out that the XML Message being sent from the client was failing validation on the BizTalk 2004 MSMQT side, we’d configured the BizTalk Pipeline to a standard XmlReceive pipeline which will ensure the schema and Root Node are valid and registered with BTS04. In this case the XML being sent was the wrong message and was therefore failing this validation.
This pipeline validation causes BizTalk to unacknowledged the message as it’s unable to process it, this is by design with transactional queuing as we were unable to process it, and this causes the client to then attempt the message again. However the other “good” messages were still backed up in the queue – this it turns out is because Transaction MSMQ also guarantees in-order deliver so the client can’t attempt the other pending messages and come back to the problematic one – so it ends up blocking the send queue for a while.
If you had your own custom pipeline that did say fail schema validation (using the XML Validator) and the message didn’t quite conform to the schema you’d get the same result, unfortunately you don’t get any logging or auditing of this occurrence on the BizTalk side (Event Viewer, or Health and Activity Tracking) it’s as if it never happened J- This seems to be down to how closely coupled the MSMQT transport is to the pipeline inside BTS04.
It hasn’t hit the MessageBox hence HAT doesn’t show anything but it’d be nice if MSMQ logged something to the event viewer. I must look to see if there’s a WMI event to hook.
This is an unusual circumstance as your unlikely to get completely malformed messages, but it’s interesting to know what happens if you do!
I’ve been working with a customer that has a requirement to “see” all messages, regardless of them being well formed or otherwise for tracking and auditing purposes. I’ll discuss how we did this on my next blog entry!
