In a previous introductory post to Azure functions I mentioned that there were more than just the HttpTrigger.
The current list of triggers available (at least for C#/.NET developers) are
- HttpTrigger – triggers a function based upon an HTTP request, like a REST service call
- HttpTriggerWithParameters – triggers a function based upon an HTTP request, like a REST service call
- TimerTrigger – triggers a function based upon a CRON like time interval/setup
- QueueTrigger – triggers when a message is added to the Azure Queue Storage
- BlobTrigger – triggers when a blob is added to the specified container
- EventHubTrigger – triggers when a new event is received via the event hub
- ServiceBusQueueTrigger – triggers when a message is added to the service bus queue
- ServiceBusTopicTrigger – triggers when a message is added to the service bus topic
- ManualTrigger – triggers when the Run button is pressed in the Azure Portal
- Generic Webhook – triggers when a webhook request occurs
- GitHub Webhook – triggers when a GitHub webhook request occurs
Many of these are pretty self-explanatory, but let’s have a quick look at some of them anyway.
Note: I’m not going to cover the triggers that require other services, such as queue’s, event hubs, web hooks etc. in this post as they require more than a short paragraph to set-up etc. So I’ll look to dedicate a post to each as and when I begin using them.
HttpTrigger
The HTTP Trigger is analogous to a REST like service call. i.e. when an HTTP request is received the Azure function is called, passing in the HttpRequestMessage object (and a TraceWriter for logging).
Here’s a bare bones function example.
public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log) { log.Info("C# HTTP trigger function processed a request."); return req.CreateResponse(HttpStatusCode.OK, "Hello World"); }
The HttpTrigger supports a lot of HTTP methods, including the obvious GET, POST, DELETE along with HEAD, PATCH, PUT, OPTIONS, TRACE.
Note: Everything we can do with HttpTriggerWithParameters, i.e. changing the HTTP method type, adding a route to the function.json and adding parameters to our method to decode the route parameters, can be implemented with the HttpTrigger. At the time of writing this post, I’m not wholly sure of the benefit of the HttpTriggerWithParameters over HttpTrigger.
HttpTriggerWithParameters
An HttpTriggerWithParameters trigger is similar to an HttpTrigger except when we create one via the Azure Portal, by default we get the following code
public static HttpResponseMessage Run(HttpRequestMessage req, string name, TraceWriter log) { log.Info("C# HTTP trigger function processed a request."); return req.CreateResponse(HttpStatusCode.OK, "Hello " + name); }
Notice the return is not wrapped in a Task and includes the string name parameter which, via Azure Portal we need to set the HTTP method to GET. GET is not the only supported method for this function but appears that way by default. To add HTTP methods we need to go to the function’s integrate menu option and add supported HTTP post methods and parameters can be passed in via the Azure portal’s Query parameters. More interestingly though a route is automatically created for us in the associated function.json file. The route looks like this
“route”: “HttpTriggerCSharp/name/{name}”
This obviously means we can navigate to the function using https://(app-name).azurewebsites.net/api/HttpTriggerCSharp/name/{name}
Let’s add an age parameters to the Query using the Add parameter option in the portal. If we change our route to look like this (in the function.json file)
“route”: “HttpTriggerCSharp/name/{name}/{age}”
and the source to look like this
public static HttpResponseMessage Run(HttpRequestMessage req, string name, int? age, TraceWriter log) { log.Info("C# HTTP trigger function processed a request."); // Fetching the name from the path parameter in the request URL return req.CreateResponse(HttpStatusCode.OK, "Hello " + name + " " + age); }
we can now navigate to the function using https://(app-name).azurewebsites.net/api/HttpTriggerCSharp/name/{name}/{age}
TimerTrigger
As the name suggests, this trigger is dependent upon a supplied schedule (using CRON format). Obviously this is very useful in situations where we maybe run reports every day at a set time or could be used to periodically check some source (which is not supported as a trigger) such as a file location.
The code generated by the Azure Portal looks like this
public static void Run(TimerInfo myTimer, TraceWriter log) { log.Info($"C# Timer trigger function executed at: {DateTime.Now}"); }
ManualTrigger
The manual trigger is a trigger which is executed via the Azure Portal’s Run button. One might view it a little like running a batch file or simply a function which you do not want others to have access to, the code generated by the portal looks like this
public static void Run(string input, TraceWriter log) { log.Info($"C# manually triggered function called with input: {input}"); }
and values are supplied as input (to the string input via the Request Body input box as plain text.