As always, using the BizTalk wizards frustrates you and makes you want to tear out the last string(s) of hair.
At least the BizTalk WCF Service Publishing Command line tool is some help. It's from the 2006r2 release, but also a part of the 2010 (beta) decumentation.
http://technet.microsoft.com/en-us/library/bb245933(BTS.70).aspx , so even though the download says BizTalk 2006. It works fine with newer versions, and is a huge time saver when updating WCF publications. Thanks to Lars for giving me a hint ;)
Kasi Srinivasan, has provided a great example
http://geekswithblogs.net/kasi/archive/2009/02/12/automating-the-biztalk-wcf-service-publishing-wizard.aspx
Kasi' link is broken. This one works at the moment :
http://go.microsoft.com/fwlink/?LinkId=92955
BUT BUT BUT, It doesn't work with BizTalk Server 2010 Beta at least :
I guess it is because BizTalk 2010 is build on .net 4.0 and the console is build on an earlier framework.
Let hope MS can fix it before the BizTalk 2010 release. (Open project, change target framework to 4.0, Build and publish)
In a WCF Basic Http Adapter Messaging "ONLY" scenario we have a problem with "mapping" Receive Soap action with the Send Soap actions.
A simple and pratical workaround is to make one send port for each action and make a filter based on receive location and WCF.Action.
It's a mess, and in a heavy biztalk scenario with 100 services and each with 10 operations you would be drenched in send ports.
So custom pipelines to the rescue and the BtsActionMapping to the rescue.
<BtsActionMapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Operation Name="SubmitMessage" Action="dk.xxxxx.integration.BizTalkWCFTest/OneWayContractTest/WriteMessageToEventlog" />
<Operation Name="SubmitMessage2" Action="dk.xxxxx.integration.BizTalkWCFTest/OneWayContractTest/DoStuffNOW" />
</BtsActionMapping>
Unfortunately the BtsActionMapping only resolves on the property BTS.Operation. Which derives from the Orchestration port name. Im trying to avoid orchestrations. The solution is quite simpel :
A custom pipeline compoent that grabs the WCFAdapter Action property and promotes it to BTS.Operation.
public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext pc, Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{
//extract the WCF action value
Object oValue = inmsg.Context.Read("Action", "http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties");
if (oValue != null)
{
inmsg.Context.Promote("Operation", "http://schemas.microsoft.com/BizTalk/2003/system-properties",oValue);
}
return inmsg;
}
Lo and Behold, One Receive Port, One Send port, and one pipeline component to bind them all..(in darkness !!!)
Awesome !