In the Trenches with Service Broker

Perhaps I need glasses.  Actually, I've had glasses for many years.  But I never wear them.  But now I do.  Except they are only good for seeing things far away.  So when I work on the laptop with really tiny screen, I can barely see.

I think it's time to get a new prescription.  One that allows for both near and far distances.  Because the strain of working 12 hour days is great.

So what did I work on all day?  Service Broker.  I got two new servers today, for different project.  And although I had scripts already written, it was still quite a challenge.  Suffice to say, at the end of the day, we got data flowing from Source to Destination server which land in a SQL Server table.

Now that it's working, the next step will be to get External Activation working, where it calls a c# windows services as opposed to Internal Activation which calls a Stored Procedure.  And that requires an install of a project for CodePlex and configure the config file.

And when that's ready, we'll be passing in c# objects to the Source Queue instead of regular text.  So there's still quite a bit to work on.

I'll admit, Service Broker is a bear to set up.  Secondly, there's no easy way to monitor the flow of data with a GUI visual tool.  Other than that, it's a solid tool for guaranteed delivery of asynchronous objects between SQL Servers, which by the way, don't need to reside within a network.

It seems to be a recurring pattern throughout my career, that I get to work on code that is not 100% mainstream.  Would it be cool to be doing cutting edge technology, perhaps.  But I'd have to admit that this Service Broker is not for the faint of heart.  Because there's about a hundred or more configuration settings, and if just one of them is incorrect, it doesn't work.  And when that happens, you really have to put on your troubleshooting hat and dig in the trenches.

And there you have it.  An entire blog with no central theme or main point.