Wednesday, August 21, 2013

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 Method: POST (set by the adapter)

· Header Content type: text/xml (set by the adapter)

· Body: xml (handled by the adapter)


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;

2) Flexibility

The flexibility of WCF is the ability to add custom behaviors, how to do this is also described in detail;





1 comment:

Silvia Jacinto said...

I love your blog. Keep it up.Visit my site too.