Hosting a generic BizTalk netTcp endpoint in IIS

This post was originally published here.

This blog post contains all needed steps to create a generic BizTalk ESB endpoint, hosted in Internet Information Services, using the netTcpBinding. Windows Activation Services is required.

Lately, I had the task to create a generic WCF netTcp endpoint within BizTalk. The purpose was to create a single BizTalk ESB endpoint for each front-end application. BizTalk has the task to route and transform the SOAP requests to the corresponding back-end services.

I already had experience with hosting such an endpoint in-process (with the Custom adapter), but now it was required to host the endpoint in IIS (with the Custom-Isolated adapter). The reason for this decision is the fact that IIS, in combination with Windows Server AppFabric, adds extra tooling and manageability.

Enable Windows Activation Services

  • Add WAS as a Windows feature:

clip_image002

  • Turn on WCF Non-HTTP Activation

clip_image004

  • Start all WAS Windows Services. Change their startup type to Automatic. You can do this via Properties.

clip_image006

Create IIS endpoint

  • Create a web service directory: C:\inetpub\wwwroot\BlogService
  • Open IIS Manager and convert the folder to an application

clip_image008

  • Choose an application pool which is configured with the BizTalk isolated host user for .NET Framework 4.0

clip_image010

  • Enable netTcp for the Default Web Site, via the Advanced Settings:

clip_image012

  • Enable netTcp for the BlogService application, via the Advanced Settings:

clip_image014

  • Add GenericEsbEndpoint.svc to the web service directory

clip_image015

  • GenericEsbEndpoint.svc tells IIS to use the ServiceHostFactory of the BizTalk WCF adapter:
<%@ ServiceHost Language="c#" Factory="Microsoft.BizTalk.Adapter.Wcf.Runtime.CustomWebServiceHostFactory, Microsoft.BizTalk.Adapter.Wcf.Runtime, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
  • A web.config can be added, but all service behaviors (e.g. serviceDebug) can be configured on your BizTalk receive location too.

Create BizTalk receive location

  • Create a two-way receive port

clip_image017

  • Create a two-way receive location and configure with the Custom-Isolated Adapter

clip_image019

  • Configure the adapter URI with the format /<IIS Application Name>/<Service.svc>. Don’t use the scheme “net.tcp://” here!

clip_image021

  • Configure the netTcp binding. Disable transport security (for performance reasons).

clip_image023

  • Enable the BizTalk receive location
  • Now you can additionally set up send ports and filters, to route the submitted SOAP request to the correct back-end services. Routing can be based on multiple properties, but the SOAP Action (WCF.Action) seems most suitable. Also transformations must be added in some cases.

Update client binding

  • The client needs to be updated to send to the generic BizTalk endpoint, instead of directly to the back-end service. Update the client with the following address format:net.tcp://<machinename>:<tcpPortNumber>//<IIS Application Name>/<Service.svc
<client> 
   <endpoint 
      address="net.tcp://machineName:8888/BlogService/GenericEsbEndpoint.svc"
      binding="netTcpBinding" bindingConfiguration="NetTcpBinding_ICoditService"
      contract="PersonSvc.ICoditService" name="NetTcpBinding_ICoditService" />
 </client>
  • The tcpPortNumber can be configured in the Site Bindings of the Default Web Site

clip_image027

About me

Hi! I’m Toon Vanhoutte, a hands-on Azure architect – based in Belgium – with a big passion for teaching and helping people out. I’m happy to assist you during your Azure journey with high-quality advisory and I would love to teach you Azure’s possibilities via my tailored training courses.

Subscribe to the blog