Part 1 of this article can be found by navigating to the following link.
Going Serverless on Azure Platform – #3 Creating a Function Pipeline Using the Azure Portal – Part I
In the last article of the Azure Functions: Going Serverless on Azure Platform series, we created the first function ReceiveNotification, which is the first part of the function pipeline. In this article, we will start creating the second function which is the SendEmail function. We discussed in detail about how to configure the triggers and bindings in the part 1 of this article. We will move a bit fast in this article creating the second function in the simple notification pipeline we are creating. Let’s start by creating the SendEmail function.
The SendEmail function is a Queue Triggered function, to create a queue trigged function you can click on the new Function button (Blue Plus icon) then select the language as C# and select Queue Trigger – C# template from the list of available templates, as we discussed in part 1. But there is a quicker way of creating the next function using a feature provided by the ReceiveNotification function.
Navigate to the Integrate section (1) of the ReceiveNotification function and click on the Azure Queue Storage Output binding (2). In the Actions section bellow the configuration options for the output binding, you can see a button to Create a new function triggered by this output. This makes it easy to create the next function that is triggered by the Azure Queue Storage trigger.
This method is quicker because SendEmail function is triggered by the message put in to the queue by the ReceiveNotification function and this method will automatically wire up everything for you for your queue trigger to work properly. Click on the GO button (3) to create the next function.
Now you can see you are taken to the screen where you choose the template, but the difference is all but one configuration options are automatically configured for you. Notice the blue outlined configuration options. The template type is set to Queue Trigger – C#, the queue name is set to notification and the storage account connection is selected as AzureWebJobStorage which was the one we used. Only change we need to do is change the function name to SendEmail (1). And then click on the Create button (2) to create the function.
The function is created and you are taken to the code editor for the SendEmail function.
You are given some boilerplate code to bind to the message coming from the Storage Queue and the message is logged in to the console. If you expand the Logs section you can see that the function already executed and the content of the queue message is logged in the log output. So, we know that this function is already working and successfully triggered.
It’s good that we get the JSON string from the message as a string in to the function, but what we need is that to be an object of the custom type Notification. We need to add the Notification Class to the function. And then we can user Json.Net to de-serialize the JSON string to a notification object. But azure functions make it easy for us. If the incoming message payload is a valid JSON string, the binding has the ability to de-serialize the JSON string to a provided Type, so it’s just a matter of changing the string type of myQueueItem to a type Notification. The binding will be automatically de-serialized. Let’s add the Notification type and modify the function a bit.
Replace the code in the editor with the above code segment. So, your function should look something like above. If save the code and trigger the ReceivedNotification function by triggering the webhook using Postman you will see an output like this.
Now let’s add the output binding to the function to send the email to the recipient. For this we can use SendGrid. SendGrid is a popular email communication service that Azure Functions has built-in support for. Azure Functions support SendGrid as an Output Binding and can be easily used to send emails. Let’s add the SendGrid output binding now.
Navigate to the Integrate section (1) of the SendEmail app and then click on the New Output button (2). From the available output binding options select the SendGrid output binding (3) and click Select button (4) to continue. You will be taken to the configuration options of the SendGrid output binding.
As usual the Message parameter name is the parameter that is added to the run method signature where the binding happens. We’ll keep the parameter name message without changing it. One of the most important configuration options is (highlighted in blue) the SendGrid API key. The value in the input field SendGridApiKey needs to correspond to an Application Setting key and the value of the setting which is the API Key taken from SendGrid. (You can get a SendGrid API key by registering for an account at SendGrid) We’ll keep the SendGridApiKey as the App Setting name. The next 4 input fields are related to the email sent by SendGrid output binding, where you can put in To Address, From Address, Message Subject and Message Text for every email that is sent out by the output binding.
We don’t need to add anything here. We’ll do this programmatically from within the function. Click on the Save button to complete the configuration. Next, we need to add the SendGrid API key in to the Application Settings.
Copy your SendGrid API Key from the SendGrid Portal. Then in the Azure Portal, click on the simplenotificationservice Azure Function (1) and click on Platform Features tab (2) then click on Application Settings (3) to access the app settings for the function app. Then scroll down to App Settings section and Add SendGridApiKey as the key and the copied API key as the value (4) (see the screenshot). And finally click Save button (5) on top to save the changes.
Then navigate back to the SendEmail function. Next, we need to add the code necessary to process the queue message and send the email. Copy the following code segment and replace the code in the editor to complete the function.
In the line 6, the method signature is modified with the output binding parameter with the Type Mail. Since this method is not a async method, we can use the out keyword to do the binding. The Mail type is a type coming from SendGrid. That means we need to reference an external library and should have a using statement importing the necessary namespaces.
Since SendGrid is supported by Azure Functions, the necessary DLLs are already available for the function app. We only need to reference the SendGrid DLL in to the run.csx file. This is done in the line 1, where we reference the already available SendGrid library. Since azure functions are C# scripts, the syntax to reference a library is to use #r followed by the name of the DLL. After referencing the SendGrid DLL, in the line 4, the using statement is added to reference the namespace where the Mail type is available.
After that all we need to do is use the SendGrid API to create the Mail object. Lines 10 – 19 performs this. In line 10 & 11 creates a Personalization object and populates it with the destination email address. In line 13, creates the message Content and populates the content from the queue messages Content property with the type text/html.
And in the lines 15 -19 we new up a Mail instance and add the Personalization object, Content object and set the Subject of the email. Finally, we add the From email address as a type Email. That is all we need to do. After the function executes successfully, the email will be send out. We don’t need to intervene in the email sending process.
Click on the Save button and save. Check the log tab for any compilation errors. Then you can trigger ReceiveNotification function using the Postman client using the same JSON payload.
In the log section, you can see that the function was successfully executed and completed. We can now check the email inbox to see if the email has arrived.
Here you can see in the destination email inbox, the email has arrived with the proper sender Email, Subject and the email body. So, our function pipeline was successful in sending an email to the recipient, when the webhook is triggered by a 3rd party.
This completes the article discussing how we can create a function pipeline using Azure Function taking in to consideration a simple scenario. But this scenario is a real-world scenario where this can be used in an actual application. For example, there can be multiple types of notifications line emails, SMS, push notifications etc. And there can be more functions to handle each of the notifications.
There are a lot more topics to talk about related to Azure Functions and I will see you with the next one.
Azure Functions: Going Serverless on Azure Platform – All Articles
- Going Serverless on Azure Platform – #1 Introduction
- Going Serverless on Azure Platform – #2 Creating a Function App in the Azure Portal
- Going Serverless on Azure Platform – #3.1 Creating a Function Pipeline Using the Azure Portal – Part I
- Going Serverless on Azure Platform – #3.2 Creating a Function Pipeline Using the Azure Portal – Part II