Sdílet prostřednictvím

MSMQT, Transactional Queues and Xml Validating Pipelines

  • Článek

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!

Comments

  • Anonymous
    April 05, 2004
    This happened to me.
    How do you fix it?
  • Anonymous
    April 06, 2004
    It's not a bug, MSMQ is following the in-order semantics specified by transactional MSMQ.

    Eventually a "bad" messae wil lbe suspended and stuck in the dead letter queue, to work around this you can use a PassThru pipeline as my other blog entry discusses
  • Anonymous
    April 10, 2004
    Can't you subscribe on the dead letter queue?

    Regards,
    Christof

    (please reply to bts2004communityfeedback (at) hotmail (dot) com)
  • Anonymous
    May 04, 2004
    We were trying to achieve this but got stuct at first step only,
    How we can post message to MSMQT from MSMQ Independent Client?
    What Queue name we should provide?
    we are trying Direct=OS:<BTS2004ServerName>Private$QName


    Seems not working.
    Can you please help with this regard.

    Thanks.
    Ashish Udas