Sometimes dynamic send ports
I think you'll all agree that the most common scenario when configuring send ports is to configure the transport details in advance (static send ports).
This is pretty much at the heart of configuring any BizTalk scenario.
Then, for more dynamic cases we have the ability in orchestrations to use role links to dynamically select which send port(s) should be executed or we can even use dynamic ports to provide the transport details at runtime.
Surely we've got all our corners covered.
Alas - these dynamic options come with a cost, mainly around performance.
What if we have a messaging only scenario? Invoking an orchestration just to use dynamic ports is an over kill. Also - what if in most cases the address is known, and it is only in rare occasion that the dynamic ability is required? are'nt dynamic ports are more expensive then static ones? Should we have two ports? One static and one dynamic?
Well, luckily we don't have to, we can configure our send port to use the frequently used address - say http://some-url.com, and in the send pipeline, after executing whatever logic is required to decide if the message should be sent to another address (and to which one) we can promote the new address, - say http://some-url2.com, to the system context property "OutboundTransportLocation" under the http://schemas.microsoft.com/BizTalk/2003/system-properties namespace
At least with the HTTP and FILE adapters this will instruct the adapter to send the message to the provided address (I did not check other adaprers, but this should be correct for most adapter implementing dynamic sends)
Things to note:
This has to be done in the send pipeline, if you promote this property in the receive pipeline you will notice it gets overwritten and by the time the message gets to the send port the transport details of the send port are promoted.
When you look in HAT in the message flow the log will still show you the message was going to the address specified in the adapter although in reality it was send to the address specified in the message's context. (I guess this is a scenario MS should address as it kind of makes this whole solution bad practice from a manageability perspective)