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.

clip_image001

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;

clip_image003

HTTP vs WCF-WebHTTP Adapter Send 

HTTP

clip_image004

· 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

clip_image005

We need to set 2 aforementioned properties manually;

· HTTP Method: POST

clip_image006

· HTTP Method: POST (set by the adapter)

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

clip_image008

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

image

Selecting the protocol WCF-WebHTTP

image

You will get an Endpoint hosted in IIS, however with the WCF-WebHTTP instead of the HTTPReceive dll (which requires ISAPI extensions etc)

image

In the configuration screen, I use the BtsHTTPUriMapping, which implies POST instead configured otherwise;

image

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

1 comment:

Silvia Jacinto said...

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

n8fan.net

www.n8fan.net