ESB Toolkit: Building a Custom Adapter Provider

Introduction

ESB Toolkit supports a number of adapters out-of-the-box, but the WCF-NetTcp and WCT-WebHttp adapters are noticeably absent from the list in the itinerary designer and the transport type vocabulary BRE. According to the documentation, it's possible to build your own adapter providers to add support for additional adapters to ESB Toolkit. Recently I had a client who wanted to use WCF-NetTcp to communicate with web services using ESB Toolkit, so I took some time to see how hard it is to build a custom adapter provider. It turns out that it is a fairly simple process to add a custom adapter provider, but the process is not very well documented.

Build the Adapter Provider

  1. Open Visual Studio and start a new class library project. Be sure to configure the project to sign the assembly with a strong-name key.
  2. Add a reference to the Microsoft.Practices.ESB.Adapter assembly in the ESB Toolkit installation folder.
  3. Implement the WCFBaseAdapterProvider interface. There is also a BaseAdapterProvider interface that can be used to implement support for non-WCF adapters, like the HTTP adapter, in BizTalk. Here is my sample code that implements the interface for the WCF-NetTcp adapter:

    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;
    using System.Threading.Tasks;
    
    using Microsoft.Practices.ESB.Adapter;
    
    namespace SD.ESB.Adapters
    {
        public class WcfNetTcpAdapterProvider : WCFBaseAdapterProvider
        {
            public override string AdapterName
            {
                get { return "WCF-NetTcp"; }
            }
        }
    }
    
  4. Build the project and install the assembly in the GAC.

Register the Adapter Provider

Add an entry for the new adapter provider to the esb.config file located in the ESB Toolkit installation folder. Here is a sample entry for the WCF-NetTcp adapter provider:

<adapterProvider name="WCF-NetTcp" type="SD.ESB.Adapters.WcfNetTcpAdapterProvider, SD.ESB.Adapters, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f6c9c5befea65e79" moniker="nettcp" />

The moniker attribute is taken from the protocol section of the URL. For NetTcp this becomes nettcp.

Build the Manifest

The manifest files are located under the Visual Studion installation folder in the \Common7\IDE\Extensions\Microsoft.Practices.Services.Itinerary.DslPackage subfolder. Since we are adding a new WCF adapter, I made a copy of the WCF-CustomProviderManifest.xml file and renamed it to WCF-NetTcpProviderManifest.xml. If your particular adapter requires additional context properties, just add the entry for the appropriate assembly to the manifest file.

Final Steps

Once the above steps have been completed, restart Visual Studio and bounce the BizTalk host instances. At this point you should be able to see the new adapter in the itinerary designer. Please note that the new adapter will not exist in the transport type BRE vocabulary. If you are using the BRE resolver for routing you will need to either update the vocabulary or set the transport type using a static string.

Conclusion

As you can see, building new custom adapter providers is pretty straightforward once you know what needs to be done. I hope this helps anybody else who needs to add support for additional WCF adapters to ESB Toolkit. Since it was so simple to add support for the WCF-NetTcp and WCF-WebHttp adapters, it raises the question as to why Microsoft has not made it a standard part of ESB Toolkit themselves. Hopefully we will see these two adapters included when BizTalk 2016 is released next year.

Category
Social
Tagcloud
.net activemq adapters akka amazon amqp apache api appfabric architecture asp.net authentication azure biztalk bpm caching camel cep cloud cloud computing cqrs data formats design eai edi esb esb toolkit events governance hateoas html http hypermedia integration java jax-rs jms json linked data links linux mapping masstransit media types messaging microdata monitoring msmq mule node.js nservicebus oauth odata open source orchestration patterns powershell pubsub python queues rabbitmq rdf rdfa resources rest resteasy routing rpc ruby security semantic web service bus services sesame signalr soa soap sparql spring streaminsight testing topics transactions transformation uri versioning videos wcf wcf data services wcf web api web web api web services websockets wf windows workflow xml xsd zeromq