Skip to content

Binding Extensions Overview

Jump to bottom
Mathew Charles edited this page Jul 7, 2015 · 35 revisions

The core WebJobs SDK contains bindings for Queues, Blobs, Tables, ServiceBus Queues, etc. However, there are many other potential sources of data for the SDK to bind to, and they can't all be baked into the core SDK. However, the SDK exposes an extensibility model that allows 3rd party extensions to be written. When registered, these extensions are integrated into the SDK binding pipeline in the same way the built in bindings are, meaning they enjoy the same level of support, Dashboard integration, etc.

There are two main types of binding extensions:

  • Trigger Bindings are bindings that monitor external event sources and cause a job function to be executed when they occur. An example is the QueueTriggerAttribute binding (e.g. [QueueTrigger("myqueue")]).
  • Non-Trigger Bindings are bindings to an external storage system. An example is the TableAttribute binding (e.g. [Table("mytable")]) which allows a job function to read/write to an Azure Storage Table.

In addition to being able to author new custom binding types, existing bindings can also make themselves customizable. For example, the TableAttribute binding can be customized to allow it to bind to types other than the built in types supported. We'll cover examples of that in this wiki as well (see Binding Customization).

In summary, these pages are a short tutorial on how to write your own binding extensions. The fully functional binding extensions contained in this repository serve as code samples on how to write extensions. This repo also includes a project Sample.Extension containing template extensions that demonstrate the minimum scaffolding necessary to get binding extensions up and running. The ExtensionsSample driver app exercises the bindings in Sample.Extension, so you can debug through them, etc. It is recommended that you use these templates as a starting point by copying them and modifying them for your domain. For example, say you want to write a new "Foo" trigger binding you would do the following:

  1. Create a new class library to hold your extension(s) (e.g. WebJobs.Foo). This is the library that your users will reference to use your new binding.
  2. Reference the Microsoft.Azure.WebJobs.Extensions nuget package from the AppService myget feed. For this to show up, you'll have to add https://www.myget.org/F/azure-appservice/api/v2 as package source in VS. You'll also need to choose "Include Prerelease" from the dropdown.
  3. Copy files SampleTriggerAttribute.cs, SampleTriggerAttributeBindingProvider.cs and SampleJobHostConfigurationExtensions.cs to your WebJobs.Foo class library project
  4. Modify the SampleJobHostConfigurationExtensions.cs file by removing binding types that you didn't copy over (you'll get compilation errors)
  5. Add a console driver app to the solution to test your new extensions, having it reference WebJobs.Foo, and also add a nuget package reference to Microsoft.Azure.WebJobs (the same version that is referenced by WebJobs.Foo)
  6. In Program.cs, new up a JobHost and start it, ensuring that you call config.UseSample(). See Program.cs for an example.
  7. Add a new class Functions.cs to the driver project, make it public static, and add a job function using the SampleTrigger attribute. See SampleSamples.cs for an example.
  8. Finally, set a breakpoint in the job function, set the Driver project as the startup project and debug
  9. Your job function will get hit every 5 seconds! Now that you have something up and running, you should start renaming, and implementing your domain specifics. The details below will help with that.

While the above template can get you up and running quickly, you will likely want to understand the details. Authoring an extension boils down to the following steps:

Clone this wiki locally