DEMO: Input Bindings
Start course

This course is an introduction to Azure Functions. It explains how Azure Functions are little bits of your application logic that live in the cloud. The course includes how to activate—or what we call trigger—your Azure Functions, how to pass data to and from them, and also how to tie different Azure Functions together using an extension of Azure Functions called Durable Functions. 

This course provides hands-on demonstrations of how to create different kinds of Azure Functions, how to create bindings to other Azure Services from those functions, and how to create a Durable Function to manage state from one Azure Function to the next.

If you have any feedback related to this course, please contact us at

Learning Objectives

  • Create Azure Functions with different types of Triggers
  • Implement input and output bindings to different types of data resources
  • Create Durable Functions to orchestrate related Azure Functions
  • Log the results with Dependency Injection

Intended Audience

Software developers who want to learn how to implement Azure Functions as a part of their cloud software design.


To get the most out of this course, you should have some experience will the following:

  • Event-driven programming
  • Servers and APIs
  • Coding with C# and JSON
  • Project creation in Visual Studio


The GitHub repository for this course can be found here.


To implement an input binding in your Azure Functions, let's go ahead and return to our queue trigger function and provide an attribute to that function so that we can create our binding. 

Now remember that a queue trigger will be activated by any entry placed into the specific queue that is referenced. So although in our previous example, we were using our timer to create a queue entry, any connection to your queue from anywhere in your enterprise software that creates an entry in your queue will activate this trigger.

So let's suppose that somewhere in your enterprise, you have a security application that takes a photograph every time a secure area or restricted area is violated, and that at the moment that that violation occurs an image is taken and sent to your blob storage. And that at the same moment, a queue entry is created saying, "Hey, there's a new security image that somebody needs to review or that we need to process in order to find out what's going on." So what we need is an input binding that is expecting that data to be there, and then a queue trigger activated off of that queue entry, that will then go look for that image inside of our storage.

Here's a quick look at what that activity does inside of your function, .json file, here you can see the direction of the input binding and the same specifications that we applied inside of our function parameter. So we've provided a blob attribute which references this container and this specific image.

So assuming that this image is here, we will not get a null value return. Let's just go check our Cloud Explorer real quick and make sure yes, we do have an image in our Cloud Explorer that I put there earlier, QR2.jpg, which will match this name.

So when this trigger is fired, we should be able to have a valid log entry created that says, "New image was found," and then just the size of the picture in this case, will help us separate which picture was found. Keep in mind that just for the moment that I have hard-coded that value, QR2.jpg so that we can verify our connection to blob storage and that when an image exists, we can actually effectively process it. We'll soon be creating a dynamic value in there as a variable but in this case, we expect it QR2.

So let's go ahead and run that function. Azure will pop up your console as usual to let you see what's going on inside of your Azure function. We can see that it has found two functions, both one and two. And we can also see that because we have a timer triggered, queue trigger firing, that we know was created by our timer, it has gone in and it has found the image that we were looking for QR2, 4388 bytes, we can go in, we can go back to our blob container, and we can verify that yes, the size of that image was 4.3 K.

So we know that in this particular case, the function has run properly, our connection to our storage is working. And now we can get on to an actual real-world example, in which we would not be providing a hard-coded value here. The key to this is that this value can be dynamic, based on the text content of the queue item that came in.

So we would want to have the queue item that had just come in from your security application, indicating some specific information in the queue, an image name that would help us go into our blob container and fetch that image.

So how do we do that? And the answer is by using special syntax, and a special argument called queue trigger, that is going to provide us with the text information that came into the my queue item argument that we have the queue trigger attribute applied to.

So now what we are expecting is that our blob will have an image of the same name as whatever the item was, that was created inside of our queue. So let's go back into our Cloud Explorer, and we'll pop open our blobs container again. And we'll see that we have an image in here, an image in here that has been created in this case manually, but could have been sent in by our security application. That is called SecurityViolation.jpg.

So assuming that we create an item in our queue of the same name, we should now be able to see that a security image was found and with the actual length of that particular picture. So our queue item has to contain the word security when we create it. And of course, we need to actually have our function running to make sure that our Azure function will be responsive when we create our item in the queue.

So now that we know that we have that up and running, we just head back over to our queue and we create a message with very specific text called security violation, because that is the name of the image that we are expecting to be able to match. So we go ahead and we create that text entry in our queue. And as soon as we do, we can see that our queue trigger is immediately processed, and that it has indicated to us that it is in specific a security violation that it executed.

So now we have been able to see that our queue trigger Azure Function can be responsive to multiple ways of inputting information to our queue, that we can narrow down inside of that function, the specific item information that we've received from the queue, and that we can use that information to apply specific logic for that situation. And so you have effectively combined your input binding of expected data with your queue trigger function.

About the Author

David Gaynes is a software and cloud architect for .NET, NodeJS, Azure and AWS. He has been developing .NET and Cloud software for more than 20 years, with some of that time spent at Microsoft, and has authored both technical and non-technical teaching materials as books and in other formats. He enjoys physics, meditation, and experiencing the natural wonders of Hawaii.