다음을 통해 공유

BizTalk multi-part messages and the BizTalk WCF Adapter

  • 아티클

At MVP Summit 2007, a couple of attendees asked about how the WCF LOB Adapter SDK surfaces and handles BizTalk multi-part messages.

Well, the short answer is – since Multi-part messages are not supported in BizTalk WCF Adapter Beta 2, they are not handled by WCF LOB Adapter SDK Beta 2.

(Disclaimer: these answers are subject to change with the future releases of the BizTalk Server 2006 R2 and BizTalk WCF Adapter.)

Here is a partial Q&A on this topic.

Q. [Matt Milner] I did some training at MS India and got a question about the LOB adapter framework (i.e. WCF LOB Adapter SDK) in R2. They were working on an adapter that would process multi-part messages. In the old adapter framework, that was pretty easy as the BTS message object model surfaces the parts very simply. Is there a recommended pattern or utility class with the WCF message model to get at the part as streams of data, or get a collection of the parts? How does one identify the different parts of the message?

A. [Ehab Sobhy, Lead SDE, WCF LOB Adapter SDK] Multi-part messages concept is not exactly there in WCF / WCF LOB Adapter SDK as it was in the old BTS messages. If you are writing a WCF-based adapter and using the BizTalk WCF adapter to hook it up to BizTalk, you will deal with the WCF Message which has one body and is streamed via handling it through XMLReader / XMLWriter. You can have sub nodes each with a real Base64Binary stream (eg, a picture) that should work fine with the WCF Adapter, the only trick will be if you used this adapter with WCF client (in .Net) it will not map more then one stream to (System.IO.Stream). If there are more then one in a defined message as in this case, it will map them to Byte arrays which are read in memory.

A. [Tapas Nayak, Principal SDE, BizTalk Adapter Pack] The reason support for multi-part message in WCF adapter is not being recommended is because WCF does not support it and the model proposed is that whoever wants to use something equivalent, need to aggregate the messages into one xml and send it as one single-part message.

Q. [Matt Milner] Ehab, Thanks for the response. So it sounds like what you are saying is if I want to be able to send multi-part messages from BizTalk (e.g. from an orchestration) to a new LOB adapter, I’m out of luck? Doing a simple test with a custom adapter on the new framework, I’ve witnessed that only the first message part gets sent to the adapter and the others appear lost.

A. [John Taylor, Senior Technical Lead, BizTalk Server] Multipart messages are a marginalized feature in BizTalk, the pipeline components like the flat-file and xml don’t understand them, same story for the majority of the adapters. So we decided to not support them in the WCF Adapter too – as you point out doing differently would have implied introducing a particular framing schema for the WCF message. The feature set for the WCF Adapter was potentially very large indeed and we were under some pressure to make cuts where we could. In general our approach was to do what was necessary and sufficient in the runtime. Still we have a ton of features.

Here is an example of our decision process for a couple of features in this area:

1. For multipart messages you can support them in your scenario by writing a Pipeline component to take the whole message and frame it in a compound XML document. Put the document in the BodyPart of the new message. Pipeline is a great approach.

2. For WCF sessions few scenarios are meaningful (because BizTalk’s sessions are long running and WCF’s aren’t) but if you have a scenario that is you can use a Layered Channel to either map a series of correlated BizTalk messages or even take a single BizTalk message and divide it off into your session of WCF messages. We saw a few such scenarios but no generic feature. The Layered Channel is a great approach.

3. Imagine you want to write a FILE Adapter (or something similar) as a Channel and you want that FILE binary data to be streamed directly into the BizTalk MessageBox. Well this scenario we had to do in the WCF Adapter code because it’s the only piece in the chain to see both Messages. (We wanted to keep each message object to its own domain because we didn’t want to be exposed to any lifetime issues.) The adapter is the marshaller. You can see this feature surfaced as the Message Marshalling modes in the adapter’s configuration. So we took the feature in the WCF Adapter because you couldn’t do it in a Pipeline Component or Layered Channel.

The WCF Adapter makes WCF Bindings first class citizens in the BizTalk world. With the WCF Adapter you are now free to write Channels where before you only had Pipeline Components and Adapters. The very rich WCF extensibility story is now the BizTalk extensibility story. Check out the samples that ship with WCF, it’s amazing what you can do.