Impact of Database Availability on BizTalk Web Services

My buddy Victor asked me the other day about the relationship between IIS and the BizTalk databases.  That is, if we restart the SQL Server service or server, what happens to messages that are still submitted to the BizTalk web services on an active IIS server?

So, I put together a really quick application where I tested four scenarios: downstream host unavailable, IIS unavailable, receive location offline, and SQL Server unavailable.

Also, to legitimately gauge service behavior, I exposed both classic ASMX services and WCF services for my BizTalk application.  Both services were built as one-way HTTP services hosted in IIS.  The published data is then routed to a single FILE send port via message-type routing.

Scenario: Processing Host is Unavailable

For this scenario, I simply disabled the in-process host that runs the send port subscribing to messages published by the services.

Result: Messages are published with no problem, and everything is queued up until the in-process host comes online.  No message loss and no errors to the service callers.

Scenario: IIS is Unavailable

Here I turned off the IIS website hosting the services.

Result: As expected, both the ASMX and WCF services returned errors to the client application.  The ASMX service returned an error saying:

error: System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it

The WCF service returned the following error:

error: System.ServiceModel.EndpointNotFoundException: Could not connect to http://myserver/Blog.Biztalk.AvailabilityTestWCF/ContractService.svc. TCP error code 10061: No connection could be made because the target machine actively refused it  —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it

So the client gets an error, no message is submitted to BizTalk by either service, and the client will be expected to try again later.

Scenario: Receive Location is Offline

Now I’ve turned off the actual receive locations.  The website is up and running, but the BizTalk receive locations aren’t listening for the inbound messages.

Result:  The ASMX service returns a success message (HTTP 202), even though no message is published to BizTalk.  There is an error in the System Event log stating:

The Messaging Engine could not find the receive location for URI:”/Blog.Biztalk.AvailabilityTest/ContractService.asmx”.\
Please verify the receive location exists and is enabled.

However, the client does NOT get an error even though no message was published (or suspended) by BizTalk.

The WCF service returns an HTTP error and the following message to the client:

error: System.ServiceModel.ServiceActivationException: The requested service, ‘http://myserver/Blog.Biztalk.AvailabilityTestWCF/ContractService.svc’ could not be activated. See the server’s diagnostic trace logs for more information.

In this case again, no message is published, BUT, at least the client knows that a problem occurred.  Much better than the ASMX behavior.

Scenario: SQL Server is Offline

In this case, I’ve shut down the SQL Server service and the in-process hosts that are running.

Result: The ASMX service continued to return HTTP success messages, even though it could not publish to the MessageBox.  The IsolatedHost (which runs the Message Agent) can’t connect, but the client isn’t told this.

The WCF service, however, returns the same error it did on the previous scenario.  So it did not publish the message either, but, again, it returned a proper exception to the client.

Looking at the IIS logs, I wanted to confirm the service response.  For the ASMX service call when the database was offline, I can see the following entry:

POST /Blog.Biztalk.AvailabilityTest/ContractService.asmx – 80 – 202 0 0

Notice the HTTP 202 returned to the client.  The next entry in the log file represents my call to the WCF service while the database was still down:

POST /Blog.Biztalk.AvailabilityTestWCF/ContractService.svc – 80 – – 500 0 0

Notice the HTTP 500 error which represents an internal server error returned to the caller.


So, we can conclude that ASMX services do a lousy job of reporting what actually happens after it tries to publish messages to the BizTalk bus.  Unless the IIS server is explicitly taken down during database server maintenance or restarts, you run the real risk of losing messages without the client being aware of it.  For WCF services, we see much better handling of message publishing problems.   This is probably due to the fact that the BizTalk WCF service host relies heavily on the BizTalk configuration database and receive location availability to complete its operations.  While it still can’t save the inbound requests, it at least tells the caller that something went wrong.

Anyone else have different experiences than the ones I demonstrated above?

Technorati Tags: , BizTalk

Author: Richard Seroter

Richard Seroter is Director of Developer Relations and Outbound Product Management at Google Cloud. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former editor plus former 12-time Microsoft MVP for cloud. As Director of Developer Relations and Outbound Product Management, Richard leads an organization of Google Cloud developer advocates, engineers, platform builders, and outbound product managers that help customers find success in their cloud journey. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

3 thoughts

  1. Hi Richard,

    Great post! We ran into the “Receive Location is Offline” scenario the other day with a BizTalk orchestration exposed as a web service. Our backup transport was FTP if the web service didn’t work so it was quite worrying that it was returning a 202 back. But then I found this blog post by Michael Stephenson:

    After updating the web service’s .cs file to OneWay=false BizTalk started throwing an “Internal SOAP Exception” or something similar when the receive port was disabled. Much better than a 202! We also updated the client with OneWay=false.


  2. Great post Richard (and quite worrying), thanks!

    If anyone needed another reason to move to R2 (for us poor souls who are still “stuck” on earlier versions…)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.