Question

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 types?
• is #2 error handling logic described good enough?
• how to handle and simulate #3?

Answer 1

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.