Don't use XMLTransmit on SOAP Ports

This one's short and simple: Don't use the XMLTransmit pipeline (or any other pipeline with an XML assembler) on the send side of a SOAP port.

The SOAP adapter receives the message to send in pieces, and knows how to assemble it. The XML assembler (which really only serves a few purposes, none of which are very important, and all of which are easy to achieve via other methods or workarounds) can get confused by these pieces and will fail.

Using the XMLReceive pipeline (or any pipeline with an XML disassembler) on the receive side of a SOAP port is fine, because the adapter has already delivered the full XML message.

How to examine your messages in BizTalk

This tip is more for the BizTalk newbies than the seasoned veterans (a group that I don't include myself in, by the way). If you need to get a good look at a message in BizTalk that's hit the MessageBox, including all of its context properties, simply create a Send Port that subscribes to the message and set it to the "Stopped" state (not "Unenlisted").

BizTalk 2006 send ports have message queues attached to them. The filters that subscribe the send port to messages in the MessageBox actually subscribe the queue to those messages, and the send port then processes messages off of the queue. If you unenlist a send port, it's message queue gets shut down and any subscription information becomes invisible to BizTalk. However, if you only stop the send port, the queue and its subscription remain active. Any messages that reach the queue become suspended and will automatically be resubmitted and subsequently processed if the send port is turned back on.

So, subscribe to your message, stop (not unenlist) the send port, run a message through, and then you'll be able to find your message in the suspended instances view. From there, you can examine the message and it's properties in detail.