Seroter has given two examples of exposing REST endpoints from BizTalk that except POST, PUT and DELETE. I was surprized that when I searched for some examples of people exposing a REST endpoint that used a GET ,I could not find any. I have decided to write about my experiences here.
Why did I want to do this? Some of my colleagues had been set the task of using BizTalk as a “man in the middle” attack on a very old legacy application that does HTTP POSTs and GETs to Cold Fusion. They could not change the legacy application and wanted use BizTalk to alter the workflow before the message got to Cold Fusion. The original plan seemed simple and involved re-directing the HTTP requests at a proxy server to BizTalk instead of Cold Fusion. BizTalk would receive these requests using the good old HTTP adapter. In their development environment they did not have a proxy server to redirect the HTTP requests but could do this with a mixture of host files and other trickery. They asked me for some help because some of the HTTP GET requests did not contain a query string e.g.
http://<host>/accp/p057_eportal/P05719_alive.cfm
The BizTalk HTTP adapter rejects the request. The BizTalk documentation explains why;
If “The HTTP GET request for the client: http://servername/vroot/BTSHTTPReceive.dll?LocationID=1&MyParam=My%20Value
The action taken by the HTTP receive adapter: Set the InboundTransportLocation property equal to /vroot/BTSHTTPReceive.dll, and the BizTalk Message object body part equal to LocationID=1&MyParam=My Value. “”
If “The HTTP GET request for the client: http://servername/vroot/BTSHTTPReceive.dll
The action taken by the HTTP receive adapter: Reject the request due to incorrect formatting of the HTTP GET request.”
My younger colleagues were all set to break out the HTTP Adapter SDK and roll their own, when I suggested that they try the new WCF-WebHTTP adapter in BizTalk 2013 instead of the HTTP adapter. We set up a schema and orchestrations similar to Seroter.
The KeepAlive request message was a System.Xml.XmlDocument and the IAmAlive message was a String. I created the web service using the WCF Service Publishing Wizard and then opened the service in explorer and changed Service1.svc to P057_eportal like this;
The receive port was set up like this;
After testing the HTTP GET using Fiddler I got this;
It is interesting to put a debug point in the orchestration and look at the receive System.XML.XMLDocument. It is NULL but has a distinguished property called Page. This could be used to do stuff within the orchestration if you wanted.
The final step was to get “ rid of the pesky .SVC Extension”. I followed West and installed the IIS 7 Url Rewrite Module. I set up the following rule;
Now if I remove the .svc from the fiddler request, I get;
Voila. If any one is interested in the code you can get it from here. For some the reason the web service is not included in the msi export. You will have to add this manually to IIS.
I am rather impressed how you could have one receive location to intercept all cold fusion requests and then use the distinguished page property in an orchestration. I am going to tell my colleagues to throw the HTTP adapter into the dust bin and use the WCF-WebHTTP adapter instead!
