On the latest version of BizTalk (2013): a new adapter was introduced for natively working with REST endpoints, using WCF technology: the WCF-WebHttp Adapter.
After the beta version was released we could find some very good articles about this adapter, but since it is a new adapter there’s a lot of ground to cover.
At the moment of my writing, the MSDN website has very few information about it, so time to give something to the community…
On this small article I will focus on using HTTP headers with the new adapter.
In this scenario I wanted to set HTTP content type at the header level. This could be done in two ways: using the adapter properties or writing in the message context.
Using the adapter properties is a fairly simple task, we just need to go to our port properties and then adapter properties. On the last tab « Messages » we have a text area destined to Outbound HTTP Headers. Every HTTP header that we place here will be included on the message that will be sent (I’m using a send port for this example).
By default, WCF-WebHttp sends your message with as « Content-Type: application/xml; charset=utf-8 », if you want to invoke a REST service with a GET request, for instance, you will have to insert the following code in the HTTP Outbound Headers:
And use a PassThruTransmit pipeline component, or another component that doesn’t validate XML.
If we need to set the HTTP headers at runtime we could do this mainly on orchestrations or pipeline components by writing the property on context
We have two properties available to set in the headers:
|Property Name||Property Schema||Adapter|
Both options will not raise any error if you try to write/promote them, but it won’t work!
UserHttpHeaders is for HTTP adapter only, if you use it you will send the message as application/xml since the property isn’t read by the adapter and since we are assuming that there is no HTTP header configured on the adapter properties.
The same goes for the OutboundCustomHeaders, it’s for SOAP messages only (and using an XML structure), if you try to use it you will have the following error:
System.InvalidOperationException: Envelope Version ‘EnvelopeNone (http://schemas.microsoft.com/ws/2005/05/envelope/none)’ does not support adding Message Headers.
If you happen to have an XML error it’s probably because OutboundCustomHeaders is expecting an XML structure and you are not passing one.
So after dwelling on this issue for some time I inspected the new Biztalk 2013 property schema for WCF, and we can clearly see some new properties related to the WCF-WebHttp adapter:
|InboundHttpHeaders||xs:string||The HTTP headers present in the inbound message received over a HTTP transport|
|InboundHttpStatusCode||xs:string||The HTTP status code of the response message|
|InboundHttpStatusDescription||xs:string||The HTTP status description of the response message|
|InboundHttpMethod||xs:string||The HTTP Verb of the request message|
|OutboundHttpStatusCode||xs:string||The HTTP status code of the response message|
|OutboundHttpStatusDescription||xs:string||The HTTP status description of the response message|
|SuppressMessageBodyForHttpVerbs||xs:string||Removes the Message Body from the outbound request message, for the specified HTTP Verbs|
|HttpHeaders||xs:string||Sets HTTP headers for the outbound message|
|VariablePropertyMapping||xs:string||Provides the URL Template Variables and Message Context Properties mapping configuration|
|HttpMethodAndUrl||xs:string||Provides the HTTP Method and URL mapping configuration|
In my scenario I wanted to use a send port, so the property that suits my purpose was HttpHeaders.
All I had to do was write the content type into the property, without the need of promoting it.
Here’s part of my Execute() method of the custom pipeline component, where I set the message content type to application/atom+xml.
public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(IPipelineContext pContext, Microsoft.BizTalk.Message.Interop.IBaseMessage pInMsg)
// Some non important logic here
pInMsg.Context.Write(« HttpHeaders », « http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties », »content-type: application/atom+xml »);
Another important note that I should add, is about the adapter HTTP header limitations:
If you are planning to change the HttpHeader per message it won’t work with a standard port, since by « design » the adapter uses the properties by port and not by message. If you need to change the header at runtime (per message) you will need to use a dynamic port instead.
And that’s it!
S'abonner au flux RSS