If you worked with the Windows Azure SQL Database in the past you’ll know that there is no support for SQL Server Agent jobs. According to the official guidelines you should use a SQL Server Agent which runs on-premises and connect it to your Windows Azure SQL Database. But this only works if you have the required infrastructure available to you on-premises (or you could host it in a VM).
Besides that you also have the SQL Azure Agent project on CodePlex which is the result of a series of blog posts on the SQL Azure blog (part 1, part 2 and part 3). This project is just a proof of concept but it’s a good base to go and build your own SQL Azure Agent. The downside to this is that you need to run it in a Web/Worker Role which might be overkill in some cases.
Let’s look at how the (Mobile Services) Scheduler can be used to create an alternative to the SQL Server Agent. Before we get started I advise you to check my previous post which covers the basics of the Scheduler: Job scheduling in Windows Azure
The database
Take the following scenario: you have a customer which would like to move an application to Windows Azure. It was pretty easy to move their web application to Windows Azure Web Sites. The migration of the database also worked out pretty well and here is the result:
Now the only thing that didn’t work was migrating a SQL Server Agent job. The customer has a job which runs once a day and deletes records in the Logs database which are older than 1 month (not very original, I know). The job is actually very simple: it calls the sp_ClearOldLogs stored procedure. If your jobs contain lots of code I suggest you move this to a stored procedure first. If all the logic which we want to execute resides in a stored procedure, then the only thing we need is a way to schedule when this stored procedure should run.
Scheduling the stored procedure
At the moment the Scheduler is only available in Windows Azure Mobile Services (WAMS). Before we can start configuring the scheduler we’ll need to set up a new WAMS application. When you do so, make sure you choose the database which contains the stored procedure you want to execute:
After you created the WAMS application you’ll see a new login and user appear in the database. The scheduler will use this new user to execute the stored procedures:
Keep in mind that the new user won’t have the required permissions to execute the stored procedure. That’s why you’ll need to grant the EXECUTE permission first:
You can now open the WAMS application and go to the Scheduler tab. This is where you’ll be able to create a new job and choose the schedule. In free mode you are limited to 1 job for each WAMS application (but you can create 10 free WAMS applications which means you can create up to 10 free jobs).
Open the newly created job and go to the script tab. This is where you’ll be able to write code which will execute the stored procedure. Here is an example which does some logging and executes the stored procedure:
Even if you’re not familiar with this Javascript syntax that shouldn’t be a problem. You can write all your logic in a stored procedure and just create a small script like I did.
One last thing, after you save the script make sure you also press the Enable button. If you don’t, the script will never run.
To test if everything works I just press the Run button and look at my Logs table. After a few seconds the stored procedure was executed and removed all records in the Logs table older than one month. And that’s all you need to run a job!
Alerts and Notifications
When you work with the SQL Server Agent you can configure alerts and notifications for your jobs, let’s see what we can do about that.
If you look back at the script you’ll see that I call console.log, which will write to the log of your WAMS application. If you open the application in the portal you can view your logs under the Logs tab:
This is a great way to keep track of when your job was executed and if there were any issues. If you’re more a command line person you can also use the Windows Azure CLI to fetch the logs: azure mobile log
At the moment the scheduler script supports 3 modules: “azure”, “request” and “sendgrid”. But the request and sendgrid modules allow you to do virtually anything. You can use the request module to send SMS messages with Twilio (this is something you might want to do in case of an issue):
And the sendgrid module allows you to send emails with SendGrid:
And there you go. You can now hook up a WAMS Scheduler to your database, schedule the execution of stored procedures, follow up on these jobs through the logs and even send out notifications. In most cases this should cover everything you need to replace the SQL Server Agent and make it easier to move your database to the cloud. And once you see that this doesn’t cover all your requirements you can always move to a full-blown Worker Role solution afterwards.
Enjoy!