A few days ago Scott Guthrie announced yet another update to Windows Azure. The great thing about this update is that it adds job scheduler support to Mobile Services. This means you can now create scripts that run every X minutes/days/hours/months. The Windows Azure website explains in detail how you can start using the job scheduler in Mobile Services.
The primary goal of the job scheduler is that you can schedule backend tasks that interact with your Mobile Services data and users. This could mean that you might want to clean up data, send newsletters, send push notifications, … Let’s see how easy it is to go beyond Mobile Services and have these jobs interact with your Windows Azure Web Sites / Cloud Services / …
Keep your Windows Azure Web Sites alive
If you’re running your Windows Azure Web Site in free or shared mode you probably noticed that your site can be slow from time to time. After some time of inactivity (between 5 and 20 minutes) your web application will shut down to free up resources on the server and this one of the reasons why your site could seem slow (the first user visiting the site after the shut down will need to wait for the application to start again). This is something you’ll typically see with a low traffic site.
How about using the job scheduler to make a request every 15 minutes in order to keep the site alive? Start by creating a new Mobile Service in the portal. We don’t need a database for this, but the wizard will force you to link the Mobile Service to the database so go ahead and create an empty database or link it to an existing database.
What you also need to remember is that – at the time of writing this article – Mobile Services running in free mode are only allowed to have maximum 1 scheduled task. Now that’s not really an issue since you can do multiple things in a single task or you could simply create multiple Mobile Service applications with each their own scheduled task.
After having created your Mobile Service navigate to the Scheduler tab an press Create to create a new job:
Once the job is created you can open it and go to the Script tab. This is where you can make it do whatever you want. So if you have 2 Web Sites and 1 Web Role you can warm them all up in a single script:
After writing the script you’ll need to make sure that you enable it, or it will never run:
Next to the Enable button you can see the Run Once button. The advantage of this button is that you don’t need to wait at least 15 minutes to see if the script works, you can test the script right away.
As you can see I’m logging a few events with console.info and console.error. The Mobile Service application picks this up and stores the information in the Logs tab. This allows you to check up with the scheduled tasks to see if and when they ran:
It’s clear that the job scheduler makes it very easy to interact with any kind of web application (even outside of Windows Azure).
A little more interaction
Since we have access to request (an HTTP request client) we can virtually do anything we want, like sending data to a Web Application. This is something you might want to do if you want the business logic to run in your Web Application and not in the scheduled job script.
In your Web Application you can create a Controller that receives information from the task and does the required work:
Your scheduler job script on the other hand can then POST data to the Controller:
Delegating work to Worker Roles
We’ve seen how to call any type of Web Application and this can cover most things you could want to do with a scheduled job. But we don’t need to stop here. What about interaction with Worker Roles? Maybe you’re using a Worker Role to generate PDF documents, to send out emails, … You typically use queues to give some work to your Worker Roles and guess what… job scheduler scripts allow you to work with the azure module. This module allows you to do many things, including communication with storage queues:
On the receiver end of the queue you can have a Worker Role which empties the queue and executes the work that needs to be done based on the content of the message:
This can be really useful if you have tasks that run every X days/months for example. Instead of having to implement this scheduling system yourself (where you need to think about concurrency when working with multiple instances), you can simply leverage the existing infrastructure provided by Windows Azure.