Web Service Wizard

So, I have been working hard of late, getting right into the ole BizTalk, and have come across a couple of issue and solutions that I think are worth a blog....

I have been looking at exposing orchestrations as webservices. A simple and straight forward task as you may think!

However to be typically awkward, I do not like early binding ports (configured during orchestration development) I like my logical ports to be bound to schemas and the freedom of binding to a particular transport mechanism after deployment time during the configuration stage.

Anyway, skip to the end I hear you say....

So while creating a web service to launch my orchestration using the web service wizard, I wanted my web service to be bound to schemas only, and not be created directly from the orchestration. Easy right???

No.

It transpires that the orchestration binding that gets created when the port is wired to a soap port the subscription looks like this

http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {32F1E5D2-04C1-4608-AD01-08019E8BB4DB}
And
http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == http://btstest.AsynchSample.MessageHeader#MessageHeader
And
http://schemas.microsoft.com/BizTalk/2003/system-properties.InboundTransportType != SOAP
Or
http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {32F1E5D2-04C1-4608-AD01-08019E8BB4DB}
And
http://schemas.microsoft.com/BizTalk/2003/soap-properties.MethodName == wsTestFunction


Now as you can see, the first subscription is a catch all for everything that is from the port, of the message type and the transport is not soap.

The second is the soap binding. as you can see it is based on the methodName being set to a value (in this case 'wsTestFunction'). This value is actually the name of the operation of the port within the orchestration you are binding to (see below).

Now here is the issue. If you create the web service using the wizard and use schema binding you can name the web service method whatever you like and this may not be the same as the port operation named in your orchestration.

There is a way around this. Open up the generated web service and look at the code for the web service method you have created. You should be able to identify the call to invoke that is responsible for putting your data into biztalk and reading out the result....

object[] invokeResults = this.Invoke("wsTestFunction", invokeParams, inParamInfos, outParamInfos, 0, bodyTypeAssemblyQualifiedName, inHeaders, inoutHeaders, out inoutHeaderResponses, out outHeaderResponses, null, null, null, out unknownHeaderResponses, false, false);

As you can see the first parameter in the Invoke function passes in the name of the orchestration logical port operation. Change this and you are away!

Now once this is edited, your exposed service can have a different name to your logical port. The question you now have to ask yourself is if the service ends up being implicitly bound to the orchestration what is the point of anything!

For that I do not have an answer!