Is the Azure WebJobs SDK specifically meant for working with Azure Storage?

Question

All the documentation (eg http://azure.microsoft.com/en-us/documentation/articles/websites-dotnet-webjobs-sdk-get-started/) and sample projects for the Azure WebJobs SDK refers to hooks and bindings to Azure Storage (Tables, Blogs and Queues). I am interested in using WebJobs for functions that have nothing to do with these storage mechanisms, for example running calculations, calling services, or using them with other storage services that the WebJobs SDK doesn't have hooks for. In these cases is there any value in using the WebJobs SDK at all? I was under the (maybe incorrect) impression that the sdk gave you a number of other benefits for managing execution of the jobs themselves, like control over running with blocking in a single thread vs. running in background, etc, maybe operational hooks related to starting and stopping jobs, and some hooks into Visual Studio, etc. I know that I can upload standalone EXEs and script files and run them as WebJobs but I further assumed that running in this way was more opaque and gave you less visibility into the job executions as well as giving less programmatic ability to control them.

Is there a reason to use the WebJobs SDK outside of it's hooks to Azure Table, Blog and Queue storage services? If so, where is that documentation?

Answer 1

Following are some more details which I hope will answer your question.

The WebJobs SDK has a binding and trigger system which works with Microsoft Azure Storage Blobs, Queues and Tables as well as Service Bus. The binding system makes it easy to write code that reads or writes Microsoft Azure Storage objects using BCL types. The trigger system calls a function in your code whenever any new data is received in a Queue or Blob.

The SDK also provides a rich diagnostics and monitoring experience without having the developer write any diagnostics and logging code.

Right now we have Triggers for specific systems such as the ones mentioned above but you can write more Triggers and Bindings yourself. We will build upon this scenario and provide a rich extensibility story in the future so you can write Triggers for your own system/ scenario such as SqlServer and more.

An example of a case where you do not have to use Azure Storage is as follows. This prototype shows a FileWatcher which shows how you can Trigger a function when a new file is detected in a directory. https://github.com/rustd/WebJobsSDKSamples/tree/master/FileWatcher

You can also use JobHost.RunOnBackgroundThread or JobHost.Call() to process anything in the background. The SDK will give you the benefit of logging, managing the execution of these functions such as cancelling these functions if they are long running and never finish, without having to kill the process. We are adding async support soon so your functions can return Task as well.

You can use the SDK in WebJobs. The WebJobs platform gives you process management such as starting/ stopping a WebJob and other benefits such as scaling a WebJob and more.

As you mentioned if you just upload standalone EXEs, you will not get as much visibility into function details and logging.

Answer 2

To use the Azure Websites WebJobs feature you don't have to use the WebJobs SDK.

WebJobs SDK currently supports Azure storage queues, blobs, table and Azure service-bus queues, if you don't require any of these you don't need to use it.