WCF-WebHttp adapter in BizTalk

Configuring a WCF-WebHttp send port for calling a REST service in BizTalk is pretty straight-forward. On the General tab specifiy a base URL and a BtsHttpUrlMapping. For instance:

Base URL: https://service.local:8443
<BtsHttpUrlMapping>
<Operation Method=”PUT” Url=”/api/Contact/{UID}” />
</BtsHttpUrlMapping>

In this case the URL contains a variable which can be specified via the variable mapping. Note that you have to promote the property on Http request message that is sent to the REST service. Might seem obvious, but you can’t use promoted properties defined on another message, like the incoming message that needs to be processed.
Example: Promoted property: UID, namespace: https://Kw1c.BizTalk.Presto.Schemas.Contact_JSON_PS

Next problem I had, was whether to use a one-way send port or a sollicit-response port. First I used an untyped System.Xml.XmlDocument as a response, but that gave me an error: “System.ServiceModel.CommunicationException: An error occurred while receiving the HTTP response to https://service.local:8443/api/Contact/317126. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details. —> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive”. I didn’t know how to resolve this issue. You might try to use a custom pipeline with an XMLDisassmbler and a JSOnDecoder or just a standard XMLReceive pipeline. You don’t receive a response with a body anyway, so it doesn’t matter that you send a request in JSON format. What’s important, is that you specify to allow for unrecognized messages in the XMLDisassemble stage. I didn’t test it, to be honest, so I don’t know for sure if it works. In the end I used a one-way send port myself, because I receive a response with an empty boby and the statuscode (200, 400, 500, etc.) in the header.

Error handling is an outstanding issue. I don’t implement error handling in the orchestration at the moment. I just Enable routing for failed messages on the (one-way) send port. I think you can also use a two-way send port, catch a System.Exception and then check promoted properties WCF.InboundHttpStatusCode and WCF.InboundHttpStatusDescription on the response message. I also found posts that mention WCF.OutboundHttpStatusCode and WCF.OutboundHttpStatusDescription. I would suggest to try both although the Inbound properties make more sense.

Final note. Don’t forget to specify the Outbound Http Headers on the Messages tab. If you don’t specify the content-type, the REST service will return a Http 204 – No Content message. This is a successful response for a Http PUT, but when checking the destination system, I found that data had not been updated. A bad request error had been better, but was not returned.
So, don’t forget to specify the Outbound Http Headers on the Messages tab (default is application/xml). Application/xml might also work by the way. Most of the times REST services accept both JSON and XML.
Outbound Http header: Content-Type: application/json

Leave a Reply

Your email address will not be published. Required fields are marked *