Service Broker error handling simulation

I work now in project in which multiple POSes should be synchronized to main server by using Server Broker feature. Now i prepare error handling for this solution and want to show to client how it works. That means i will prepare test scripts for every kind of errors and client runs it on test POS to see if it errors processed correctly.

We will use SQL Server 2008R2 with poison message = OFF.

Message type=XML (but inside can be different type of data, some nodes will contain BLOBs).

POSes will be outside of domen so transport will be secured (but no dialog encryption).

I divide errors on several sub-groups:

1. Logical error (e.g. string instead of number) .It will be processed by TRY-CATCH block on server side.It is easy to simulate

2. Service Broker configuration error (message or will be not returned or cannot reach destination). I think it can be handled by using SQl Server Service Broker events and simulation will be some kind of "bad configuration" (SB GUID,service name etc)

3. Transport error. This is when we have a broken message. In fact it is client opinion to test such kind of error. I do not know if we have secured transport level (certificate) we are protected from such kind of error. Another question how can I simulate this.

Questions:

• are there another error ty开发者_如何学Gopes?
• is #2 error handling logic described good enough?
• how to handle and simulate #3?

---

The second part of my article here goes into a discussion of Service Broker errors, how they occur and how to handle them. The important thing for you is to distinguish between two categories of errors:

• recoverable: transport problems, most configuration errors like bad routing, an unreachable server. All these will result not in a SSB error, but in a delay. Messages will stay in transmission_queue expecting that the problem is transient and can be solved, including some configuration problems. Once the problem is solved, SSB will retry and the message gets delivered.
• unrecoverable: these are problems SSB deems as non-recoverable, eg. a bad message format. In such a case the conversation will be aborted and both endpoints receive a Error message.

I also have an article Error Handling in Service Broker procedures that discusses some of the topics particular to exception handling in SSB activated context.

A final note: I strongly discourage you from turning poison message detection OFF. It is much better to disable the processing than to spin ad-nauseam w/o making progress because of a poison message.

As on the topic on how to simulate a corrupted message: is hard to simulate (you can try with setting up a port forwarder that lets all traffic pass by, but randomly corrupts some of it) but is rather pointless. All SSB traffic, even when in clear text, is cryptographically signed and any message corruption would result in an abrupt disconnect due to message signing validation failure.