I decided to move away from wordpress.com for reasons. Attracted to a static site generator, wanting some more flexibility and control, planning to build out my github repositories etc. signs were pointing towards Jekyll. I forked a theme I liked, started migrating some old blog posts, and after some modifications I felt it’s time to go ahead and make the initial commit.

Working on a little dashboard / status report for AM I wanted to include some information on the dispatchers. Most of it is straightforward stuff from the tblDispatchers table but I found another one of these RES peculiarities. Some of the settings for a dispatcher can be defined at a global level (Infrastructure -> Datastore -> Settings -> Global Settings) which can be overridden for a specific dispatcher (Dispatcher Properties -> Settings). So how can we include the effective setting straight from SQL?

To gain a better understanding of the communication protocol between agents and dispatchers we can use a couple of different tools. Ideally we capture the communication in bulk and store it in such a way that we can analyze it with a variety of different tools. Using command line tools and scripting will allow us to start and stop the capturing with relative ease so we can set up different usage scenarios and focus on specific interaction. Let’s get to work.

Dispatchers and consoles talk directly to the database, using standard DB clients. In the case of MS SQL Server, used in the vast majority of implementations, this is the SQL Native Client (SQLNCLI). Protocol details are not of much interest, since we can run a profiler on the SQL server to see exactly what queries are performed. According to the Administration Guide:

The Agent contacts the Dispatcher at regular intervals. If a new Job is available, the Agent will download all necessary data from the Dispatcher and perform the Job.

Great, but how does this communication work? What does a conversation between an agent and a dispatcher look like?

Often it is interesting, sometimes necessary, to do some analysis of the tasks you ran on your machines using RES AM. If everything went right, you can click around a little, but for more serious analysis and reporting you need data, not colorful pixels. Information about the results of scheduled jobs can be obtained in several ways.