Category name:Blog

BizTalk WCF-WebHttp adapter does not detect 500 error

Update 2016-11-17: Microsoft has fixed the bug in CU5 for BizTalk 2013 R2:

Original post:

For a project at my current client, we use a REST-based API to retrieve some data using the BizTalk 2013R2 WCF-WebHttp adapter. We tried this in a message-only scenario, but soon noticed that errors did not give the desired result. It seems the port sending the response from the API back to the caller did not realize that an error had occurred. In other words: the WCF-WebHttp adapter does not detect all errors.

To further debug this behavior, we tried to call the same API using a simple orchestration. In this orchestration a request is received from a Filedrop location, mapped to the request for the API (to promote the required properties for parameter mapping in the port) and sent to the MessageBox using a two-way send port. Around the send and receive shape is a scope with an exception handler on System.Exception. The exception that occurs is then output via a System.Diagnostics.Trace() statement.

To further assess the behavior, the WCF.InboundHttpStatusCode context property of the API response message is also written to the trace.

Finally, the response of the API is sent to disk via a FILE send port.

The part of the orchestration that does the REST API call is depicted below:


If we test this solution with a happy flow message, all is well.

If we test this solution, with a call that gives a 400 error in the API, it also works: the exception handler kicks in and the error is written to a trace statement.

However, if we test this solution with a call that gives a 500 error in the API, the orchestration thinks that the call was successful and will not enter the exception handler. There is no data in the response message, only an error. In a regular orchestration, not a test like this one, we would now try to process the data received and fail. Also, in a message-only scenario this will cause unexpected behavior.

If we check the HTTP status code in the different scenario’s, we find the following:

In case of a HTTP 200 StatusCode, the ContextProperty value is “OK”.
In case of a HTTP 400 StatusCode, the ContextProperty is not available.
In case of a HTTP 500 StatusCode, the ContextProperty value is “InternalServerError”.

We would expect that the BizTalk engine would recognize a HTTP 500 error and act on it, but it does not. As a work around you could develop orchestrations to check for the WCF.InboundHttpStatusCode ContextProperty and its value.

Since I am unable to find anywhere that this is the expected behavior, I assume this is a bug in the WCF-WebHttp adapter. A bug report is on its way to Microsoft, so hopefully it will be fixed soon. Does anyone find the same behavior or is this the behavior that is expected?

Update 2016-07-12: Microsoft support has responded and the product team has verified the bug. However, since not a lot of users are affected and we have provided them with a workaround, they do not intend to fix it at the moment. If you have the same issue, please report it to Microsoft as well, so they are more motivated to fix it :). You may refer to our bug registration: (number removed, since it is fixed).

Start to blog on BloggingAbout.Net

Today I have started a blog on BloggingAbout.Net. Here I will be posting my findings on Microsoft BizTalk Server and .Net development.

For the past five years I have been working with .Net (mostly ASP.NET) and Microsoft BizTalk Server and many times I turned to blogs for finding answers to tech related questions. I decided I would like to give back to the community I have turned to many times. From of today I will be posting my findings and hopefully help someone out the way blogs have always helped, and will always help, me out.

Expect the first technical post later today. Please do not hesitate to comment, so I can make this blog better!