Tuesday, December 31, 2013

Configure BizTalk Receive Location with net.tcp

I just spent ages trying to change a receive location from basic Http to use net.tcp. When I tried to access the web service in IE I kept getting the message "The Messaging Engine failed to register the adapter for 'WCF-CustomIsolated' for the receive location...".

As usual it asks whether the receive location was started (it was) and if the isolated adapter runs under an account that has access to the BizTalk databases (which it does).
I had already followed the step to add the non-HTTP protocols and configured the web site to support net.tcp. I also configured the virtual directory to support http and net.tcp protocols.

To recap when creating the Receive Location I used the WCF-CustomIsolated adapter. I set the Binding to netTcpBinding and set the security mode to None to match the Anonymous access setting in IIS.
The problem was with the address Uri. I was using the address of net.tcp://localhost:808/path/service.svc which is shown in the examples. Changing the address Uri to /path/service.svc solved the problem.

Now when openeing the service in IIS I was able to see the usual service screen (using the http address) and view the wsdl. BTW, I wasn't able to get this to work with the WCF-NetTcp adapter because that too insists on the net.tcp:// address format.

But the next problem came when trying to create a client application to send messages to the net.tcp endpoint. I created a console application in Visual Studio but could not add the Service reference because it would not recognise the wsdl. So I switched the endpoint back to basicHttp and created the service reference in my console application and checked that it worked with basicHttp.

So then I switched the Receive Location back to net.tcp and changed the bindings and client endpoint in my console app to use net.tcp. I thought that was it but when I sent the message it would just timeout.

That's when I looked at the settings on the Receive Location again and realised maxConnections was 0 and the ReadQuota values were all zero.

These are what I set in the app.config of my client
<binding listenbacklog="16" maxconnections="16">

< maxDepth="32" maxStringContentLength="2147483646" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="2147483646"/>

I also added the security section to match that of the server.
<security mode="None">
Finally that did the trick and I was able to submit messages with net.tcp.