I'm currently struggling with the following:

I have a simple orchestration that is sending a message to a webservice (request-response) using WCF-basichttp.
When the webservice throws an exception I receive a soap fault and the orchestration handles it perfectly fine. 

In cases where I don't receive a soap fault but just an ordinary HTTP 500 the message sent to the webservice gets stuck on active forever. (orchestration dehydrated) The http 500 is not caught in that case. To simulate this you can make a typo in the web.config of the webservice. When calling the webservice a http 500.19 occurs and the message gets stuck on Active. Using a WCF-Custom binding makes no difference.

I also tried this using the 'old' HTTP adapter and the HTTP adapter handles it perfectly fine.

To me this feels like a bug in the WCF adapter. Any thoughts?

(WIN2012, BTS2013)

• Edited by _FJ_ Friday, June 19, 2015 11:27 AM

The error occurs on IIS level so I indeed don't get a soap fault but a HTTP 500.19. However the WCF adapter is unable to handle this gracefully while the HTTP adapter can.

What can I do to prevent that my messages and orchestration remain active/dehydrated forever? This behavior is of course not acceptable.

By the way, the typo in the web.config is just an example to easily reproduce the behavior. We also have some other situations where a server exception is raised that produces the same 'active message behavior' in BizTalk.

• Edited by _FJ_ Friday, June 19, 2015 1:23 PM

Adjusting the host recycle options is not an option because in our production environment the webserver lives on a different machine. I have no influence on the webserver.

Lets do a step back. Why is the WCF(-BasicHttp) adapter not correctly responding when it receives an HTTP 500 from the webserver (not the application)? As I said, the normal HTTP adapter works perfectly fine in this scenario. Shouldn't it just handle the HTTP error correctly??

The connection timeout settings are all default and set in the send port. I can of course set transaction timeouts in the orchestration but that is silly in this situation since (at least in my opinion) the adapter should just do its work. The web.config is on the server side and not my domain so little influence on that.

In my test scenario it is also not an option because there I intentionally corrupted the web.config of the webservice to reproduce the behavior.

Thanks for your suggestions but at this point I refuse to believe that the WCF adapter cannot handle HTTP 500 errors in this situation. Maybe you or someone from Microsoft can reproduce this?

I just added some WCF tracing and it seems the BizTalk process is actually throwing a ProtocolException. So it does respond to an HTTP 500 from the webserver. However the exception is somehow not reaching my orchestration.

Also adding an explicit ProtocolException (next to System.Exception) as an errorhandler is not helping.

Hi ,

As per your error screen shot your web server is not responding to the request send from your BizTalk Server . 

I would suggest to test the service through WCF Test client or SOAP UI first and then validate your BizTalk request against what you are sending with SOAP UI.

Thanks

Abhishek