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

Comments

yaklibber924 said…
I am usually to blogging and i really respect your content. The article has really peaks my interest. I am going to bookmark your web site and hold checking for new information. casino slots
Jhon mac said…
Thanks for shearing about this I thinks its very hopeful post and very important post for us. Thanks for your great and helpful presentation I like your good service.I always appreciate your post.
htpp portal

Popular posts from this blog

Azure implementation guidelines

Focus and innovation - recap of the last 2 years

BizTalk Pub/sub vs Topics based routing–discussion