geekswithblogs.net

El Grego

BizTalk blog


News

My Stats

  • Posts - 26
  • Comments - 24
  • Trackbacks - 55

Twitter










Recent Comments


Recent Posts


Archives


Post Categories


Tuesday, June 16, 2009

Configuring a Static WCF Port to Behave as a Dynamic Port



Yesterday I've tried to reproduce the scenario 'Configuring a Static Port to Behave as a Dynamic Port' from the excellent MSDN article 'Consuming and Hosting WCF Services with Custom Bindings in BizTalk Server' but with a twist: instead of writing the BTS.OutboundTransportLocation context property inside a custom pipeline component I've tried doing this from inside orchestration.

It didn't work. I had to do it differently. Let me explain...

If you manually promote a custom value for the BTS.OutboundTransportLocation on your outgoing message inside an orchestration message construct and send the message to a static send port, the BTS.OutboundTransportLocation property is magically overwritten with the address from the statically configured send port. The fact that this property is automatically set by the engine seems logical because it is necesarry for a regular static send. I only hoped it wouldn't be overriden when already present. 
Why magically? Because it doesn't show up like that in HAT! If you look into HAT the message-context 'before pipeline execution' you can see that the custom value is there: it was successfully written to the context inside the orchestration.
But by adding some traces to a dummy pipeline component I can CONFIRM that those custom values are indeed already erased and reset to the address from the send port configuration @pipeline-execution. This indicates that there is an additional step after tracking and before the adapter triggers the pipeline execution, where the engine adds all sorts of properties from the port configuration. So even when you are using a passthru send pipeline the message 'after pipeline execution' has a different context then 'before pipeline execution'. Another clear case of opacity ;-) And that's where my confusion came from. One might wonder why they didn't choose to track the 'before pipeline execution' right after the engine added its properties. There is probably a good reason for that...

Anyway, I needed to take a step back and reconsider the approach from the article ie setting the value inside a pipeline component. But hardcoding or configuring an address inside a pipeline isn't really 'dynamic'.

So here is the final piece of the puzzle:

Roll in your own 'address' property that is written on the message context inside orchestration and is re-written into the BTS.OutboundTransportLocation property during pipeline execution.