This blog post describes how developers can do local development using the recently announced an alpha release of WebJobs SDK (aka SimpleBatch). The client side code is just pulling down JobHost class from the Microsoft.WindowsAzure.Jobs.Host nuget package, so you can develop inside a console app and run them locally. In fact, since the SDK is just a nuget package, you can include it in any type of application, such as a console app, class library, ASP.Net webpage (useful for your background processing!), or even an Azure Worker Role. The ideal flow here is that you start with local development and then publish your code to run in Azure.
Although the client framework can be run anywhere, the SimpleBatch dashboard (eg, the cool website that gives you the awesome diagnostics) currently only runs as an Azure Websites Site Extension. However, all communication between your app and the corresponding dashboard is done entire through an azure storage account, to which you provide the “AzureJobsRuntime” connection string or via the JobHosts ctor.
That means there’s a decoupling between where your JobHost runs and where the dashboard runs. You can run your JobHost locally while developing it, and still use the same dashboard from your site extension.
Multiple JobHosts can share the same logging storage account, so you can have a single SimpleBatch dashboard service multiple programs. However, be careful about multiple instances of your jobhost running when you use [QueueInput] attributes since the queue message will only go to the one instance that dequeues the message. Normally, that’s exactly what you want. But it can backfire if you’re trying to do local development of a [QueueInput] function and you have a cloud instance running that’s stealing all your messages.
This is just an Alpha release, and I’m expecting getting to the dashboard will get much easier in our Beta. But I wanted to share out a tip to use in the meantime.
1) Get the storage connection string you are using for JobHost to log to. This could be from “AzureJobsRuntime” connection string in your app.config or via the “runtimeConnectionString” parameter explicitly passed into the JobHost ctor.
The connection string is a single string that will include both the account name and password, and it looks something like this:
2) Create a new Azure Web Site (that lives in the same datacenter as your storage account).
3) Point the site to that storage account by setting the “AzureJobsRuntime” connection string in the site’s “Configure” tab.
4) Get the site’s publish credentials (username and password). Access to the SimpleBatch dashboard is protected using your site’s publish credentials. Get these credentials so you can log into the site.
You can get the credentials form the publish profile. Some steps from the tutorial:
<publishData><publishProfile profileName="webjobssite - Web Deploy" publishMethod="MSDeploy" . . . msdeploySite="webjobssite" userName="$webjobssite" userPWD="StjxBlJXnrfahHvbWs92MA6HKlvvLEZznr1EFA6kzSGKbY4v" . . .
Note that the publish file may have multiple username and passwords in it.
5) Go to the dashboard URL. You can manually get this URL based on your site’s URL. If your site URL is:
Then the dashboard is a site extension that lives at:
The transform here is: a. HTTP –> HTTPS b. The “.scm” in the URL c. The “/azurejobs” suffix
This URL will also show up in the webjobs page. However, when doing local development, you won’t have a WebJob so it can be useful to know how to jump to the SimpleBatch dashboard directly. Save this URL for future usage.