Category name:R2

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

Exposing BizTalk Schemas as a SOAP-RPC/Encoded webservice

Yesterday I had to connect a Delphi back-end system to the BizTalk 2006 R2 environment of my customer. Since this Delphi system could only call webservices exposed as SOAP-RPC/Encoded, I had to expose the needed schemas as such.

While searching on this subject I found a good post of Tomas Restrepo on consuming SOAP-RPC/Encoded webservices:

This explains how you have to work with multipart messagetypes to call a SOAP-RPC/Encoded webservice. At first I figured I would have to do something alike to expose my schemas as a SOAP-RPC/Encoded webservice. However, this is actually very easy.

With the .Net framework you can easily expose a webservice as SOAP-RPC/Encoded by setting the correct attribute on the webmethod. To achieve this you should do the following to the generated webservice code after exposing your schemas as a webservice using the default BizTalk Web Services Publishing Wizard:

  1. Comment out (or delete) the SoapDocumentMethodAttribute on the WebMethod and the SoapDocumentServiceAttribute on the class that are set by default by the wizard.
  2. Set the SoapRpcMethod attribute on the WebMethod and the SoapRpcService attribute on the class.
  3. You can set parameters on both new attributes to change the behaviour and settings of the SOAP-RPC/Encoded service

That’s it. Since the .Net Framework creates an object based on your schema of the webrequest and uses this to call BizTalk, you don’t have to change anything on the BizTalk side to expose your schema’s as a SOAP-RPC/Encoded webservice. Now that is easy!

While on the subject of exposing schemas as a webservice: the generated webservice has ‘ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Default‘ set on the SoapDocumentMethodAttribute by default. This causes an extra node in the envelope body named like the WebMethod’s name. If you don’t want this extra node, you can set the ‘ParameterStyle’ to ‘System.Web.Services.Protocols.SoapParameterStyle.Bare‘ and the extra node is not used anymore.