BizTalk Orchestration Subscriptions

I have recently encountered a problem in developing a loosely coupled web-service for BizTalk 2006.

My requirement is to create an untyped service (i.e. one which will accept any XML document), and will route to the appropriate Orchestration based on content. I have the further issue that my main client application is unable to handle the XML 'Any' type (see Complex Types). In order to workaround this issue we have to create a web-service that will accept a single string element, which the calling application can embed the real XML document in. This though, will prevent BizTalk from identifying the contents of the XML and route correctly.

The solution is to create a custom Pipeline component, which will extract the real XML document out of the string prior to identifying the message type.

Simple so far, providing you are happy writing Pipeline components. I went about creating a prototype for this solution, in which I created two schemas (A and B), and two corresponding Orchestrations, which, for the sake of testing, just deposited the messages into file drops.

The Issue

My pipeline worked fine, decoding/disassembling the message, but both my Orchestrations subscribed to the message, resulting in two messages in the output. Oddly enough this only happened with the SOAP adapter; when using the FILE adapter messages were routed correctly. I spent a great deal of time pulling out hair until I figured out what was going on.

The Cause

I was under the impression that Orchestrations subscribe to messages in BizTalk based on the "MessageType" and which receive port they came from. The type you set at design time in Visual Studio, and the port either in Visual Studio or BizTalk Administrator.

Although this seems to be correct, there is an additional subscription created when using SOAP messaging, which is based on the receive port and the "MethodName". As I had only been prototyping I had left the method names on my virtual ports as "Operation_1". This meant that each orchestration subscribed to the message, despite having different expected message types.

I changed the method names and redeployed and encountered the next problem. The web-service is specifically calling Operation_1 as it's method. Which meant that different Orchestrations couldn't subscribe to messages of a different type.

The Solution

To get round this issue, I have had to use Direct Binding on my Receive Location, which means that the subscription is based entirely on "MessageType" and will collect any message from the Message Box. This worked, just too well and landed up spawning numerous Orchestration instances. Not good.

By using Direct Binding you can specify filters on the Receive shape in an Orchestration. You need to use this to ensure that you only pick up the first instance and not any other messages from the message box. I have used BTS.ReceivePortName, although I'm sure there are other better ones to use.