In many scenarios, it could be required to have a send port with a dynamic behavior:
- Send messages to a FILE location, containing the date of today
- Send a notification mail to many different recipients
- Dynamically change the URL of the backend web service, depending on the incoming request
- …
Many developers would solve this by using dynamic send ports. These ports allow you to configure all adapter properties, even the adapter type, at runtime. I’m not a big fan of dynamic send ports, because it introduces some drawbacks:
- Dynamic send ports are very difficult to troubleshoot (a hell for your operations team)
- Dynamic send ports require your port configuration to be stored in a secure way (custom SSO application)
- Dynamic send ports have a bigger performance hit (solved in BTS 2013)
- Dynamic send ports don’t allow to specify an adapter handler (solved in BTS 2013)
That’s why I prefer using static send ports. With a very easy trick, you can make static send ports partially dynamic. Mostly it’s only the connectionstring, URI, path that must be changed at runtime. This can be achieved in a custom pipeline component in the send pipeline:
- inmsg.Context.Promote(“OutboundTransportLocation”, “http://schemas.microsoft.com/BizTalk/2003/system-properties“, URL);
This dynamic behavior works smooth for FILE and FTP adapters. However, when using this mechanism on WCF send ports, there’s a caveat. You will find out that the BTS.OutboundTransportLocation of the first message will be cached on the WCF send port. So all subsequent messages will be sent to the same location. This port configuration is cached until your send port configuration is modified or until your adapter send handler is restarted. Luckily: there’s a way to disable this caching:
- inmsg.Context.Promote(“IsDynamicSend”, “http://schemas.microsoft.com/BizTalk/2003/system-properties“, true);
- inmsg.Context.Promote(“OutboundTransportLocation”, “http://schemas.microsoft.com/BizTalk/2003/system-properties“, URL);
By setting the BTS.IsDynamicSend property to true, you force the WCF send adapter not to use the cache, but the runtime value instead. More information on this setting can be found on MSDN.
Subscribe to our RSS feed