MSMQT: Debugging and Getting hold of malformed messages
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