BizTalk 2013, replace HTTP adapter by WCF-WebHttp REST
The WCF-WebHTTP is designed to support REST, with support for the verbs GET, POST, PUT, and DELETE. We can use the POST verb to replace the HTTP adapter functionality, and use WCF custom behaviors to tailor the adapter to our needs.
This post explains how I migrated the HTTP adapter and why I decided to look at this approach. This should give a summary of how to do this.
Problem with the HTTP Adapter
1) Error handling
The BizTalk HTTP adapter hides away the logic of HTTP status codes, thus an error is handled in the adapter. Returning a custom error in a request response call, which calls a solicit-response HTTP port is therefore quite challenging, and at this moment I have not found a way to do this, except abandoning the Messaging only approach.
2) Flexibility
The HTTP adapter is somewhat limited in functionality, yes you can use a custom pipeline, client/server certificate authentication and stuff, but adding custom behavior is limited;
HTTP vs WCF-WebHTTP Adapter Send
HTTP
· HTTP Method: POST (set by the adapter)
· Header Content type: text/xml (set by the adapter)
· Body: xml (handled by the adapter)
WCF-WebHTTP
After choosing the adapter
We need to set 2 aforementioned properties manually;
· HTTP Method: POST
· HTTP Method: POST (set by the adapter)
· Header Content type: text/xml (set by the adapter)
HTTP vs WCF-WebHTTP Adapter Receive
Using the HTTPReceive adapter (POST) works the same way as the WCF-WebHTTP adapter will be used; it is hosted as an EndPoint in IIS. However, one of the advantages is that you can add custom behaviors which could the migration to WCF-WebHTTP a good solution for received HTTP requests.
After running the wizrad
Selecting the protocol WCF-WebHTTP
You will get an Endpoint hosted in IIS, however with the WCF-WebHTTP instead of the HTTPReceive dll (which requires ISAPI extensions etc)
In the configuration screen, I use the BtsHTTPUriMapping, which implies POST instead configured otherwise;
Where the Operation Name = “Test” should map to the Operation name in your Orchestrations Receive Port.
Solution with the WCF-WebHTTP Adapter
After migrating to the WCF-WebHTTP adapter, you are able to use custom error handling, functionality. How to implement this is already described in detail.
1) Error handling
Although changing the HTTP to WCF-WebHTTP, I could not get the setup working to provide error handling in the request-response scenario with custom mappings. This because the HTTP status code is not wrapped inside an Error message. Although I expect that you can get it working using a custom behavior, I have not developed a solution at this point.
A good starting point is provided here, which uses an Orchestration;
http://social.technet.microsoft.com/wiki/contents/articles/16625.biztalk-server-rest-services-error-handling.aspx
2) Flexibility
The flexibility of WCF is the ability to add custom behaviors, how to do this is also described in detail;
http://msdn.microsoft.com/en-us/magazine/cc163302.aspx
HTH,
Sander
Comments
htpp portal