BizTalk Dynamic WCF-WSHttp Send Port reverting to Http Adapter

Question

I'm trying to send a message to the WCF-WSHttp adapter with a dynamic send port from an orchestration, but BizTalk seems to always be reverting back to the HTTP Adapter.

According to the docs that I've been able to find, I should just need to set the transport type from my expression shape to get BizTalk to use the WCF-WSHttp adapter, and I AM, but it still seems to be reverting. Below is an example of my expression shape that's setting the properties (as you can see, I've tried both Microsoft.XLANGs.BaseTypes.TransportType and BTS.OutboundTransportType):

Body(BTS.OutboundTransportType) = "WCF-WSHttp";

SendMessagePort(Microsoft.XLANGs.BaseTypes.Address) =
System.String.Format("{0}/Accept{1}", "http://myserver/myservice/
myservice.svc/Accept{0}", messageInfo.MessageType);
SendMessagePort(Microsoft.XLANGs.BaseTypes.TransportType) = "WCF-
WSHttp";

Answer 1

Probably are Craig :-)

When using a dynamic send port, BizTalk uses the "scheme" part of the url to decide which adapter to use.

When your url starts with "Http://" or "Https://" BizTalk would always use the HTTP adapter. Similarly url's begining with ftp:// will use the FTP adapter. Same works for custom adapaters as well - when you install the adapter's configuration you register the moniker to use; for example - the open source Scheduled Task adapter uses schedule:// (I believe).

Using dynamic send ports with WCF is slightly more involved than most other adapaters because of the various configuration that's required but you can find detailed explanation here, just scroll down to the "Dynamic Send Ports" section about half way down.

Answer 2

I ended up resolving my issue, but am still unsure of the reasoning for the behavior I saw.

The Expression shape mentioned in the question was located inside of an Atomic Scope. Once the Orchestration exited the scope containing the Expression shape, the Transport Type was reset back to its original value. Moving the Expression out of the atomic scope resolved the issue, in that the TransportType was set correctly.