On a recent project I was exposing a BizTalk orchestration as WCF for a Windows Forms client and a Windows Mobile client. For simplicity, a single BizTalk receive port was being used with multiple WCF receive locations. The BizTalk WCF publishing wizard allows this type of functionality through running of this wizard more than one time. This is by far one of the coolest WCF capabilities in BizTalk – the ability to expose multiple bindings (like you can do in WCF) for each BizTalk orchestration. For example, one BizTalk orchestration can be exposed for both a WCF-BasicHttp binding and a WCF-NetMSMQ binding through running the WCF publishing wizard twice, once choosing to publish a service endpoint for the WCF-BasicHttp binding, and then a second time as a Meta-data endpoint (MEX) for the WCF-NetMSMQ binding.
The message body properties for both of these receive locations was set to "Body" which is supposed to pull out the contents of the SOAP:Body from the WCF service call. When testing both of these bindings the contents of the SOAP:Body were being output but they were being wrapped in a part element like in the message given below:
<part i:type="a:string" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:a="http://www.w3.org/2001/XMLSchema">Hello World!</part>
The application that was being implemented was one in which the body data needed to be passed along intact and not further wrapped. The MSDN documentation on the Message Body properties (http://msdn.microsoft.com/en-us/library/bb226478.aspx) did not mention that additional data would be passed along to wrap the content that was passed to the WCF receive location. The additional part element caused problems with the next system to receive the message. So I used the Path option rather than Body for the message body and used the XPath expression of /*[local-name()=’part’] to remove the additional wrapping of the data. This provided what I would expect to be included in the body part of the SOAP:Body – the data passed to the WCF operation and nothing more.
This tip should help you avoid one challenge of working with the new WCF features of BizTalk. Thanks!