Sdílet prostřednictvím

MSMQT: Debugging and Getting hold of malformed messages

  • Článek

So, I was discussing previously how MSMQT works with relation to BizTalk when malformed messages come in, if you have a XML validating pipeline (to ensure the validity of the XML message) then the message will be rejected and you’ll be none the wiser about what happened.

I was working with a requirement whereby all messages coming into MSMQT had to be “visible” within Health and Activity Tracking (HAT) for debugging, auditing, etc. Yet the messages still had to be validated before hitting the orchestration to avoid bad messages spinning up orchestration that would then choke later on.

I did some digging internally and ended up talking to the MSMQT guys on the product team and they came up with a neat trick, it’s a bit convoluted especially if you new to BTS!

To get the Message into the MessageBox we have to configure the Receive Pipeline on the MSMQT port to be PassThru, this will perform no validation whatsoever and will deliver the message to the MessageBox, which will then allow us to “see” the message regardless of it’s quality. Once the message is in the MessageBox we need to configure something to validate this message and deliver it ultimately to the Orchestration.

We can’t have an Orchestration pick this message straight up because we have to do some XML Validation via a pipeline, to enable this we need to create a new Send port, we need to configure this Send port to subscribe to all messages that come in on the MSMQT receive port, we do this by creating a filter of BTS.ReceivePortNamewith a value of our MSMQT Receive Port Name, and then configure the Send port to send the messages to say a directory using the File Adapter via a PassThru pipeline.

This step creates a subscriber for all messages that come in on our MSMQT port and send them across to directory, so it’s effectively another MessageBox hop.

We then configure a straight forward FILE Receive Port to pickup all messages from the directory specified in the previous step and select a XmlReceive pipeline, then bind your orchestration to this port. If the messages fail validation here then they will be suspended in the usual way by BizTalk, otherwise they’ll be processed by the Orchestration.

So – your not going to want to do this in most scenarios but if you really must track/log all messages then this is the way, it’s also a very neat option to allow you to debug why messages are being rejected by MSMQT due to validation errors in the pipeline!

Phew! Hope that makes sense

Comments

  • Anonymous
    April 08, 2004
    Wow, doesn't seem like this is the ulitimate solution. So if a message fails in the Pipeline, is the message stored anywhere or does it just go away? If an error occurs, we need access to the incoming message so we can determine what is incorrect and resubmit it.

  • Anonymous
    April 08, 2004
    With this method, any messages that fail the XmlReceive pipeline will be suspended. You can register for the Suspended WMI message and then pull the message bodies out to work on.

    My earlier blog on suspended messages has some code to do this...

  • Anonymous
    June 08, 2004
    Hi Darren,
    I wrote you before about a MSMQT problem and wanted to let you know that my issue is fixed. I have found some extra information that might interest you: BizTalk MSMQT also sends back reach ACKs to the sending node (but no receive AKCS). The only thing you have to do is set up the admin queue and use the proper acknowledgement settings + dead-letterq for the MSMQ message you send. For example I had a MSMQT receive location with a FFDASM pipeline. If the validation or parsing of a message fails the sender receives a negative ack message in the admin queue and MSMQ places the bad message in the dead-letter queue. The result is that you have a level of traceability at the sender's side: not perfect but it works.
    Regards,
    Gregory (Gregory@eai.be)

  • Anonymous
    August 05, 2004
    This is all very handy info to have - especially since I've just stated down the MSMQT road and just hit this bump myself. I'm wondering if Gregory's solution would work in this example if the sending queue only gets a reach ACK but nothing else from MSMQT. Thanks,
    ~Brett

  • Anonymous
    May 31, 2009
    PingBack from http://outdoorceilingfansite.info/story.php?id=5123

  • Anonymous
    May 31, 2009
    PingBack from http://outdoorceilingfansite.info/story.php?id=22759