We've been using SSSB 2008 for the past year, and it's been wonderful. (Well, compared to MSMQ anyways.) However, we've only been using same-database queueing, not the routing features.
Some changes in our app now require that we route messages. Up until now, we've been doing "fire and forget" - SEND a message and end the conversation. I'm not worried about the receiving app failing as much as one of the databases getting misconfigured. If someone messes up the certificates, then we'll get an Error message back from SSSB.
When we get these errors, is there any way to get the original message object? For immediate errors when the message is still in the transmission queue, it's easy. But after going over the network, it appears that the message is "gone".
If this is the case, what's the common way to deal with it? I'm thinking of writing the message and ID to a "QueuedMessages" table, then having a procedure activated on the sending queue to either delete the message on receiving an EndDialog, or setting a flag/logging when an error is received. Alternatively, if I can loosen the business requirements, I might just be able to keep send items in the sending process's RAM, and have it check the queue for Error/EndDialog. (Motivation for in-RAM would be performance -- we plan on doing about 400 messages/sec outbound with very little resources, running SQL Express.)
Any comments in general?