BizTalk WCF-WebHttp adapter does not detect 500 error

By vincent

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).

Comments: 4

  1. AndyMidd says:

    Experiencing the same issue here…seems to be a fundemental part of Biztalk to have detection of errors and the retry/suspend behaviour. I see their point that not many users are affected, but this is how ports should work – it is broken!

  2. Yes, one of several issues with the WCF-WebHttp adapter that we also came across.
    I’ve linked to your blog from my blog post entitled BizTalk 2013 R2 known bugs, issues & quirks

  3. Aaron Kim says:

    I have also experienced the same and resolved it by detecting the response code in wcfbehavior and if 500, make/return a fault message. This was BizTalk 2010 WCF-WebHttp adapter enabling REST with fiddling messages in WcfBehavior. I wasn’t sure if this was a bug but now I know. Thanks for sharing, I’ll also report to Microsoft to fix.

  4. Stefan says:


    We detected the same bug, and we are contacting Microsoft to have a fix for it

    Thanks guys

    I hope it will work


Leave a Reply

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


pingback from BizTalk 2013 R2 known bugs, issues & quirks | BizTalk musings August 18, 2016