Chat using Twilio WhatsApp API, SignalR Service & Azure Functions Series - Part 2  -  The Code
Tags: signalr, twilio, azurefunctions
Published: 2019-10-23 18:36:01

---
title: Chat using Twilio WhatsApp API, SignalR Service & Azure Functions Series - Part 2  -  The Code
published: true
description: This is part two of a three-part series that shows you a way to combine several Serverless technologies, creating an online chat system that sends messages between users of WhatsApp and a real-time web app.
tags: signalr,
  twilio,
  azure_functions
cover_image: https://blogs.siliconorchid.com/images/coding-inspiration/whatsapp-signalrservice-azurefunction/lady-using-mobile-for-devto.jpg
series: Chat using Twilio WhatsApp API, SignalR Service & Azure Functions
canonical_url: https://blogs.siliconorchid.com/post/coding-inspiration/whatsapp-signalrservice-azurefunction/part2-look-at-code/
---

This article was originally published  at [blogs.siliconorchid.com](https://blogs.siliconorchid.com/post/coding-inspiration/whatsapp-signalrservice-azurefunction/part2-look-at-code/) on 19-May-2019


**This is part two of a three-part series that shows you a way to combine several Serverless technologies, creating an online chat system that sends messages between users of WhatsApp and a real-time web app.**

> In [part 1 of this series](https://blogs.siliconorchid.com/post/coding-inspiration/whatsapp-signalrservice-azurefunction/part1-setup), we introduce you to the scenario and walk through the configuration of an entire solution, ready for local testing.

> In [part 2 of this series](https://blogs.siliconorchid.com/post/coding-inspiration/whatsapp-signalrservice-azurefunction/part2-look-at-code), we look at the various pieces of code that make up our solution in detail.

> In [part 3 of this series](https://blogs.siliconorchid.com/post/coding-inspiration/whatsapp-signalrservice-azurefunction/part3-deploy-to-cloud), we walk through the additional steps needed to set up and deploy the solution to the cloud.


<br/>
<hr/>


## Let's look at the code

In the previous article, we spent a while looking at how to set up and run the project. Let's look at some code next!

If you haven't done so already, you should [clone this repository](https://github.com/SiliconOrchid/WhatsAppSignalRDemo).

Our Visual Studio project is comprised of two projects - an Azure Function project (`WhatsAppSignalRDemo.Function`) and an ASP.NET Core Web Application (`WhatsAppSignalRDemo.Web`).  

Parts of the code in this demo originated from the example provided in the [Microsoft SignalR Quickstart guide](https://docs.microsoft.com/en-us/azure/azure-signalr/signalr-quickstart-azure-functions-csharp), so this would be a recommended read.

Another recommended resource from Microsoft is the tutorial  [Get started with ASP.NET Core SignalR
](https://docs.microsoft.com/en-us/aspnet/core/tutorials/signalr?view=aspnetcore-2.2&tabs=visual-studio) - whilst it doesn't cover *SignalR Service* specifically, it does show you how to write a chat client using "Hosted SignalR" and introduces most of the concepts you need to know.

<br/>

## The web client project

In this demo, we've gone out of our way to make the Web Client as simple as possible.   

The Web App consists purely of static web content.  There is no MVC, Razor, Controllers nor any other server-side logic.  Instead, we have a single `index.html` and a small amount of accompanying static content (such as JavaScript and CSS).

The purpose of doing this is twofold:-

* We don't want to distract you with any implementation details that are specific to a UI framework (whether that be ASP.NET MVC or one of the many JavaScript frameworks/libraries such as Angular or React).    We want to focus upon the essentials, meaning that we have a very basic UI and minimal code (which includes any code needed to interact with SignalR).

* We specifically wanted to have purely static web content (i.e. just `.html`, `.css` and `.js` files) so that, later in the article when we come to publish the Web App to the cloud, we can show you how to use *Azure Storage Static Websites*.  One considerable benefit to this approach is that the hosting cost is a fraction of what it could otherwise be. 


For development and testing purposes, we will still need a development web server, so we have opted to use an "ASP.NET Core Web Application" project as a starting point.    This is still essentially the same as you would find for a conventional [MVC](https://docs.microsoft.com/en-us/aspnet/core/mvc/overview?view=aspnetcore-2.2) or [RazorPages](https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-2.2&tabs=visual-studio) project, except it has been pared back to the absolute minimum.    

* For example, there is no longer a `Pages` folder (for `.cshtml` views, in general) and none of the usual MVC constructs (such as `_Layout.cshtml`).   
* Static content has no need for configuration, so `appsettings.json` has been discarded.
* The template includes the *JQuery* library, but that is not being used so has been removed from the `wwwroot/lib` folder.   
* We have retained the `site.css` stylesheet and the *Bootstrap* library.
* We needed to include the  *[SignalR Javascript Client](https://docs.microsoft.com/en-us/aspnet/core/signalr/javascript-client?view=aspnetcore-2.2)* library.  You can find that in `wwwroot/lib/signalr`    


<br/>
<br/>
   

Moving on to the small amount of C# code in this project:-

* `Program.cs` remains untouched
* `Startup.cs` has significant changes:-   
    * Pretty much the entire content that was provided by the new-project Template has been discarded.
    * We need to explicitly tell ASP.NET core to use the `index.html` and we need to explicitly tell it to serve up static content.    The revised code looks like this:-

```csharp
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;

namespace WhatsAppSignalRDemo.Web
{
    public class Startup
    {
        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            DefaultFilesOptions options = new DefaultFilesOptions();
                options.DefaultFileNames.Add("index.html");
            app.UseDefaultFiles(options);

            app.UseStaticFiles();
        }
    }
}
``` 

<br/>
<hr/>

### Javascript code on the client

The script that runs in the browser can be located here:  

```
….\WhatsAppSignalRDemo\src\WhatsAppSignalRDemo.Web\wwwroot\js\chat.js
```

We briefly looked at this piece of code earlier in the article, when we checked that the API endpoint `serviceEndpoint` was correctly defined.

This particular piece of code started off life as being a copy of the sample code presented in the aforementioned Microsoft chat-application Tutorial [Get started with ASP.NET Core SignalR
](https://docs.microsoft.com/en-us/aspnet/core/tutorials/signalr?view=aspnetcore-2.2&tabs=visual-studio), so any similarities are due to this.   That original sample was intended to work with *Hosted SignalR*,  so along with other customisations, we've adapted the code to work with our *SignalR Service*.

As an overview, the code uses the Microsoft SignalR JavaScript library to create a “connection” object (named `signalRconnection` in this demo). The MS library does all the heavy-lifting work for us.  

<br/>
<br/>

The code found in `....\WhatsAppSignalRDemo\src\WhatsAppSignalRDemo.Web\wwwroot\js\chat.js` does the following:-

* Defines a handful of configuration values, identifying the API endpoint of the service and a specific API name to be used for broadcasting messages.
* Calls the `signalR.HubConnectionBuilder()` function to establish a connection to either a SignalR Hub or SignalR Service (we use the same JavaScript client, regardless of how the backend is implemented).   
    * The "HubConnectionBuilder" code **is hardcoded to look for an API which is called `negotiate` by convention.  We need to provide this in our Azure Function backend.**  This part is quite an important point to be aware of.   You can read about it on [Microsoft: Azure Functions development and configuration with Azure SignalR Service
](https://docs.microsoft.com/en-us/azure/azure-signalr/signalr-concept-serverless-development-config).


```javascript
var signalRconnection = new signalR.HubConnectionBuilder()
    .withUrl(serviceEndpoint)
    .build();
```

<br/>

* We have an event listener, which reacts to messages being broadcast from the SignalR Service.   When they arrive, the message object is separated into component parts (a username and user message) and simply appended to a UI list:-


```javascript
signalRconnection.on(signalRTargetGroupName, function (broadcastMessage) {
    console.log(broadcastMessage);

    var encodedMsg = "<b>" + broadcastMessage.User + "</b> : &quot;" + broadcastMessage.Message + "&quot;";

    var li = document.createElement("li");
    li.innerHTML   = encodedMsg;
    document.getElementById("messagesList").appendChild(li);
});
```

<br/>

* We have a startup handler, that is responsible for updating the UI when the client established a connection to the SignalR Service (it enables the "send" button and removes the "please wait" message):-


```javascript
signalRconnection.start().then(function () {
    document.getElementById("sendButton").disabled = false;
    document.getElementById("connectingMessage").style.display = "none";
}).catch(function (err) {
    return console.error(err.toString());
});
```

<br/>
<hr/>


### With SignalR Service, instead of "invoking" Hub methods, we send HTTP messages to a restful API endpoint.

The way we interact with *SignalR Service* is different from traditional *Hosted SignalR*.  

Previously, with *Hosted SignalR* we would have a server-side "Hub" that contained [C# proxy] methods.     In our client-side [JavaScript] code, we would "invoke" these methods using the `SignalR` connection object itself.    

Such a piece of code would have looked like this (where "SendMessage" would be a corresponding  C# method of the Hub class):-


```javascript
signalRconnection.invoke("SendMessage", user, message).catch(function (err) {
    return console.error(err.toString());
});
```

In contrast, when using the "serverless mode" of *SignalR Service*, we still have the concept of Hubs (e.g. will still need to identify a "HubName" to group connections together)  - but those Hubs are generic and no longer contain our [C# proxy] code.  This means that there is no longer anything to "invoke".  

Instead, we need our [web] client to POST separate HTTP messages to an API that we provide ourselves.   In our serverless architecture, this would be another HTTP-triggered Azure Function.     

Any APIs we create that provide SignalR functionality will have a connection string tying that Azure Function to our SignalR Service.  We'll talk about the C# API code itself, later in the series.

> This change is worth underlining because, at the time of writing, I felt that this was slightly ambiguous in the MS documentation.   When researching this article, I wasn't confident that I should have been abandoning the use of the `invoke` function of the `signalRConnection` object - having to make separate REST calls felt like I awkwardly working around their solution.

> To be sure that I have presented the correct solution in this article, [I asked Microsoft Cloud Advocates directly](https://twitter.com/bradygaster/status/1119288198125903872). Thank you [Brady Gaster](http://www.bradygaster.com/) and [Anthony Chu](https://anthonychu.ca/) for clarifying that I was indeed, doing it right!!     

> Something interesting that they pointed out, was that they are currently looking for a way to harmonise the experience, so there is a good chance that this current approach may change again in the near future.  

<br/>

<br/>

Returning to the code in this demo, the need to make separate HTTP call(s) represents the most significant shift away from the [ Microsoft sample code](https://docs.microsoft.com/en-us/aspnet/core/tutorials/signalr?view=aspnetcore-2.2&tabs=visual-studio) that this file was originally based upon.


* The following encapsulates a vanilla JavaScript `fetch` request into the function `postMessage`.   In the future, if our code expands to require other HTTP calls, we could then easily reuse this function.


```javascript
document.getElementById("sendButton").addEventListener("click", function (event) {

    var userMessage = new Object();
        userMessage.User = document.getElementById("userInput").value;
        userMessage.Message = document.getElementById("messageInput").value;
    
    postMessage(serviceEndpoint + signalRBroadcastApiMethod, userMessage);

    event.preventDefault();
});


function postMessage(url = ``, data = {}) {
    // Default options are marked with *
    return fetch(url, {
        method: "POST", // *GET, POST, PUT, DELETE, etc.
        mode: "cors", // no-cors, cors, *same-origin
        cache: "no-cache", // *default, no-cache, reload, force-cache, only-if-cached
        credentials: "same-origin", // include, *same-origin, omit
        headers: {
            "Content-Type": "application/json",
            // "Content-Type": "application/x-www-form-urlencoded",
        },
        redirect: "follow", // manual, *follow, error
        referrer: "no-referrer", // no-referrer, *client
        body: JSON.stringify(data), // body data type must match "Content-Type" header
    })
        .then(response => response.json()); // parses JSON response into native Javascript objects 
}
```

<br/>
<hr/>






## The Azure Function project

Broadly speaking this project is comprised of just three main elements:-

* **Models** - there are only two models in the project, a container for some configuration items `GenericConfig.cs` and a very simple container for user messages `UserMessage.cs`
* **Common Code** - this represents a handful of classes that are shared across all functions.
* **Functions** - there are four HTTP-triggered Azure Functions .

> If you have worked with Azure Functions in the past, you may be expecting to declare each function as a `static`.       A very recent change to the SDK means that this is no longer a requirement and you can create function as an instance class.    This is all due to scoping changes being made in order to accommodate the [upcoming introduction of Dependency Injection](https://github.com/Azure/azure-functions-host/issues/3736).


<br/>
<hr/>


### Project Dependencies

There are only a handful of dependencies to other libraries.    It would be simplest to add these dependencies using the NuGet Package Manager, but here is the library listing as seen in the `....\src\WhatsAppSignalRDemo.Function\WhatsAppSignalRDemo.Function.csproj` file:-

```xml
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.WebJobs.Extensions.SignalRService" Version="1.0.0" />
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
    <PackageReference Include="twilio" Version="5.28.2" />
  </ItemGroup>
```

<br/>
<hr/>

### GlobalConstants.cs

One of the things that struck me when looking at much of the sample code available for both Azure Functions and SignalR, is that there seems to be a heavy reliance on string literals for identifying things in the code.

For example, functions typically have a `[FunctionName="xyz"]` attribute to define their exposed API name.  

Similarly, if we wanted to pass messages between functions (over HTTP), we find ourselves identifying the function we want by the URL - again, another form of string.

I feel that these various examples make for [brittle code](https://en.wikipedia.org/wiki/Software_brittleness)  - it would only take a typo for things to break.   

Additionally, by using string-literals, we lose things such as compile-time checks and intellisense [to hint at mistakes].  If there is a problem, it will only manifest at runtime.   

Therefore I have implemented a simple solution to address this issue. We create the static class `GlobalConstants` and within this, define a small selection of string [constants](https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/const).  The `globalConstants.cs` class looks like this:-

```csharp
namespace WhatsAppSignalRDemo.Function.Common
{
    public static class GlobalConstants
    {
        public const string SignalR_HubName = "Chat";
        public const string SignalR_TargetGroup = "AllUsers";

        public const string FunctionName_Negotiate = "negotiate";
        public const string FunctionName_BroadcastSignalRMessage = "BroadcastSignalRMessage";
        public const string FunctionName_SendWhatsAppMessage = "SendWhatsAppMessage";
        public const string FunctionName_ReceiveWhatsAppMessage = "ReceiveWhatsAppMessage";

        public const string Config_TwilioAccountSid = "TwilioAccountSid";
        public const string Config_TwilioAuthToken = "TwilioAuthToken";
        public const string Config_TwilioWhatsAppPhoneNumber = "TwilioWhatsAppPhoneNumber";
    }
}
``` 

Creating and using this class means that we can define string values in just one single place and then we can use those strongly-typed values across the rest of the project.  

Aside from greatly reducing the possibility of making a silly mistake caused by a typo, it means that if you want to do something such as rename a keyname in your configuration, you don't have to then make this change all over your codebase.

To use these values, we can substitute them anywhere where a string literal would otherwise be used.  So where previously we would have code that looks like this:-

```csharp
public class SendWhatsAppMessageFunction
{
    [FunctionName("SendWhatsAppMessage")]
    public async Task<IActionResult> Run(
    ...
```

We can instead replace it with the following:-

```csharp
public class SendWhatsAppMessageFunction
{
    [FunctionName(GlobalConstants.FunctionName_SendWhatsAppMessage)]
    public async Task<IActionResult> Run(
    ...
```

<br/>
<hr/>

### HttpHelper.cs

This class is a component that helps our functions make HTTP requests.  It is a common, reusable component that can be shared by several separate Azure Functions. 

Making RESTful calls is one mechanism for communicating between different functions (there are other, more reliable, ways such as using a queuing mechanism, but that is beyond the scope of this article).     For example, in this demo, when a message is received from WhatsApp to the `ReceiveWhatsAppMessageFunction`, the message is relayed onward to the `BroadcastSignalRMessageFunction` by way of an HTTP call.

```csharp
using System.IO;
using System.Net;

using Newtonsoft.Json;

namespace WhatsAppSignalRDemo.Function.Common
{
    public static class HttpHelper
    {
        public static void PostMessage (string apiUrl, object message)
        {
            //send request
            var httpWebRequest = (HttpWebRequest)WebRequest.Create(apiUrl);
            httpWebRequest.ContentType = "application/json";
            httpWebRequest.Method = "POST";
            using (var streamWriter = new StreamWriter(httpWebRequest.GetRequestStream()))
            {
                streamWriter.Write(JsonConvert.SerializeObject(message));
                streamWriter.Flush();
                streamWriter.Close();
            }

            //get response
            var httpResponse = (HttpWebResponse)httpWebRequest.GetResponse();
            using (var streamReader = new StreamReader(httpResponse.GetResponseStream()))
            {
                var result = streamReader.ReadToEnd();
            }
        }
    }
}
```

<br/>
<hr/>

![image showing ignition](https://blogs.siliconorchid.com/images/clipart/clipart-ignition.jpg#shadow)




### StartupHelper.cs

Azure Functions are self-contained units that are instanced as demand requires.  This is why they can scale without issue.   

In contrast,  ASP.NET APIs exist on a common platform - a constantly provisioned App Server.  

One benefit of using an ASP.NET Web Application is that you only need a single application startup (with that code literally being in the `Startup.cs` file).  This means that any setup and configuration needs happen only once and the results can then be made available until the application is recycled.  

In contrast, an Azure Function requires you to run configuration on each and every use.   If you look at many of the code examples for Azure Functions, you tend to see often those examples repeating boilerplate code for things like configuration.

Looking at an Azure Function in isolation, this probably doesn't appear to be much of an issue.  However, as soon as you have a suite of different functions, you'll start to see a pattern of repetition, which isn't ideal.

As developers we aspire to produce, what we hope to be well-considered code, therefore, we should try and follow software design principles where possible.   Amongst these recommendations is the [DRY Principle](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) - which basically says "don't repeat the same code everywhere - try and reuse it".

So, the code in `....\src\WhatsAppSignalRDemo.Function\Common\StartupHelper.cs` is an effort to try and encapsulate some of that code which is common between each of the four Functions.

```csharp
using System;

using Microsoft.Azure.WebJobs;

using WhatsAppSignalRDemo.Function.Models;

namespace WhatsAppSignalRDemo.Function.Common
{
    public static class StartupHelper
    {
        public static GenericConfig GetConfig(ExecutionContext executionContext)
        {
            string functionHostName = Environment.GetEnvironmentVariable("WEBSITE_HOSTNAME");

            return new GenericConfig
            {
                TwilioAccountSid = Environment.GetEnvironmentVariable(GlobalConstants.Config_TwilioAccountSid), 
                TwilioAuthToken = Environment.GetEnvironmentVariable(GlobalConstants.Config_TwilioAuthToken), 
                TwilioWhatsAppPhoneNumber = Environment.GetEnvironmentVariable(GlobalConstants.Config_TwilioWhatsAppPhoneNumber),
                ApiEndpoint = $"http://{functionHostName}/api/"
            };
        }
    }
}
```

<br/>

Within the Function class (such as `ReceiveWhatsAppMessageFunction`), the `StartupHelper` is made available a little bit like an ASP.NET Core Configuration Item.  It would look like this (partial code, for brevity):-

```csharp
... 

private GenericConfig _genericConfig;

... 

_genericConfig = StartupHelper.GetConfig(executionContext);

... 

HttpHelper.PostMessage(
        _genericConfig.ApiEndpoint + GlobalConstants.FunctionName_BroadcastSignalRMessage, 
        userMessage);

... 
```

The *intent* of the `StartupHelper` class is to demonstrate a way to encapsulate all of the requests for configuration information, into one place (which can then be re-used by multiple different functions).  The mindset behind this idea is to emulate the effect of having all of your configuration code in a startup class.

The *practical* use of the above class is to define and populate the field `ApiEndpoint`, which is genuinely re-used in three of the four functions.

The inclusion of the three Twilio configuration items into `StartupHelper `, is a little bit more tenuous to justify.   Those particular fields are only actually used in `SendWhatsAppMessageFunction`, so you could argue that those configuration items may have been better placed directly into just `SendWhatsAppMessageFunction`, using `Environment.GetEnvironmentVariables` as appropriate.

The point of this article is to talk about and demonstrate some ideas, so take all of this into consideration and choose a solution that suits your purposes best.

<br/>
<hr/>

### NegotiateFunction.cs

This function is fundamental to the operation of the *SignalR Service*, so you need to know that it's both required and how works.

Previously, with *Hosted SignalR*, the [web] client would negotiate directly with the Hub.   This would all be managed transparently  by the SignalR JavaScript client code - we only needed to provide the hostname of the service.

With *SignalR Service*, the concept of a Hub still exists, but it is all dynamically provisioned and managed by Azure.   The upshot is that our [web] client can't make the first connection directly.    To make this work, we need to provide a static HTTP API, which will negotiate with the SignalR Service, and return connection details and a user-access token.

The good news is that the SignalR JavaScript client software, provided by Microsoft, understands the differences between working with *Hosted* and *Service* modes,  so will explicitly be expecting you to provide an API called "negotiate".   You can read about that in their own documentation [here](https://docs.microsoft.com/en-us/azure/azure-signalr/signalr-concept-serverless-development-config).

When it comes to writing the C# for the "negotiate" API, fortunately, the code itself is really straightforward and we didn't even need to write it ourselves, as it comes directly cut+paste from [Microsoft's documentation](https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-signalr-service).

In our demo, we've tweaked it slightly, so as to provide consistency and make use of our  `GlobalConstants`:-

```csharp
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Extensions.SignalRService;
using Microsoft.AspNetCore.Http;

using WhatsAppSignalRDemo.Function.Common;

namespace WhatsAppSignalRDemo.Function
{
    public class NegotiateFunction
    {
        [FunctionName(GlobalConstants.FunctionName_Negotiate)]
        public SignalRConnectionInfo Negotiate(
            [HttpTrigger(AuthorizationLevel.Anonymous)]HttpRequest req,
            [SignalRConnectionInfo(HubName = GlobalConstants.SignalR_HubName)]SignalRConnectionInfo connectionInfo)
        {
            return connectionInfo;
        }
    }
}
```

One part of the code to draw your attention to is the need to be consistent with your use of the SignalR `HubName`.     This needs to be shared across any of the references that you make - so in the case of this demo, be conscious that this HubName is also used in the `BroadcastSignalRMessageFunction` (which is another good reason to use string constants, rather than literals)

<br/>
<hr/>

![image showing broadcast studio](https://blogs.siliconorchid.com/images/clipart/clipart-broadcast.jpg#shadow)

### BroadcastSignalRMessageFunction.cs

The `BroadcastSignalRMessageFunction` class is an HTTP-triggered Azure Function, which receives a message from the web client and relays it onto both:- 

* The SignalR Service, which In turn, broadcasts the message to every connected client.
* The `SendWhatsAppMessageFunction` API, which in turn, broadcasts the message to every subscribed WhatsApp user.

Earlier in this article, we've explained that although *SignalR Service* has Hubs, they no longer accommodate having methods written against them.

The `BroadcastSignalRMessageFunction` is the stand-alone HTTP API, that effectively replaces code that would previously have been a method within the Hub class.

The *SignalR Service* extension is added as an argument to our Function and the object is named `signalRMessages`.    This handles all the operational details, such as locating a connection string, automatically for us.

We send messages into the Service by calling `signalRMessages.AddAsync(...)` like this:-


```csharp
using System.Threading.Tasks;

using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Extensions.SignalRService;

using WhatsAppSignalRDemo.Function.Common;
using WhatsAppSignalRDemo.Function.Models;

namespace WhatsAppSignalRDemo.Function
{
    public class BroadcastSignalRMessageFunction
    {
        private GenericConfig _genericConfig;

        [FunctionName(GlobalConstants.FunctionName_BroadcastSignalRMessage)]
        public Task SendMessage(
            [HttpTrigger(AuthorizationLevel.Anonymous, "post")]object message,
            [SignalR(HubName = GlobalConstants.SignalR_HubName)]IAsyncCollector<SignalRMessage> signalRMessages,
            ExecutionContext executionContext)
        {
            _genericConfig = StartupHelper.GetConfig(executionContext);

            // relay the message to the WhatsApp API
            HttpHelper.PostMessage(_genericConfig.ApiEndpoint + GlobalConstants.FunctionName_SendWhatsAppMessage, message);

            //relay the message to the SignalR Service
            return signalRMessages.AddAsync(
                new SignalRMessage
                {
                    Target = GlobalConstants.SignalR_TargetGroup,
                    Arguments = new[] { message }
                });
        }
    }
}
```


<br/>
<hr/>

### SendWhatsAppMessageFunction.cs

This Function is not intended to be called directly from the [web] client, but instead triggered by the `BroadcastSignalRMessageFunction` Function.

This particular Function is probably the most complex in terms of different tasks that it performs:-

* The incoming JSON message is deserialised and ultimately end ups in the C# `dynamic` type (for simplicity) named `requestObject`. 
* The Twilio client is created and initialised using credentials originating in our configuration.
* Using the Twilio library method `MessageResource.ReadAsync(...)` we obtain a list of all WhatsApp messages that have been added to our sandbox in this session.   This will contain a list of every single message, including each phone number of the user involved.  This collection is named `messageCollection`.
* We use a LINQ query to filter the list of every phone number in `messageCollection`,  down to a list of  unique phone numbers.  This resultant collection is named `distinctPhoneNumbers`.
* We iterate over the list of unique phone numbers, using the Twilio library method `MessageResource.Create(...)` to send a message to each.
    * We test that the phone number of the recipient is not the same as the phone number in the message (i.e. the sender) - we don't want to send a WhatsApp message straight back to the user who sent it!

 

```csharp
using System.IO;
using System.Threading.Tasks;
using System.Linq;
using System.Collections.Generic;

using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;

using Newtonsoft.Json;
using Twilio;
using Twilio.Base;
using Twilio.Types;
using Twilio.Rest.Api.V2010.Account;

using WhatsAppSignalRDemo.Function.Models;
using WhatsAppSignalRDemo.Function.Common;


namespace WhatsAppSignalRDemo.Function
{
    public class SendWhatsAppMessageFunction
    {
        private GenericConfig _genericConfig;

        [FunctionName(GlobalConstants.FunctionName_SendWhatsAppMessage)]
        public async Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = null)]HttpRequest httpRequest,
            ExecutionContext executionContext
            )
        {

            _genericConfig = StartupHelper.GetConfig(executionContext);

            string requestBody = await new StreamReader(httpRequest.Body).ReadToEndAsync();
            dynamic requestObject = JsonConvert.DeserializeObject(requestBody);

            // connect to Twilio
            TwilioClient.Init(_genericConfig.TwilioAccountSid, _genericConfig.TwilioAuthToken);

            // query twilio api ... and get distinct phone numbers of whatsapp users subscribed to chat
            ResourceSet<MessageResource> messageCollection = await MessageResource.ReadAsync(to: _genericConfig.TwilioWhatsAppPhoneNumber);
            IEnumerable<PhoneNumber> distinctPhoneNumbers = messageCollection.GroupBy(a => a.From.ToString()).Select(b => b.FirstOrDefault().From);

            foreach(var phoneNumber in distinctPhoneNumbers)
            {
                if (phoneNumber.ToString() == requestObject.User.ToString())
                {
                    // if the message originated from whatsapp, don't send a copy straight back to sender
                    continue;
                }

                // send message to whatsapp user
                var message = MessageResource.Create(
                    from: new Twilio.Types.PhoneNumber(_genericConfig.TwilioWhatsAppPhoneNumber),
                    body: $"{requestObject.User} : {requestObject.Message}",
                    to: phoneNumber
                );
            }

            return (ActionResult)new OkResult();
        }
    }
}
```

<br/>
<hr/>


### ReceiveWhatsAppMessageFunction.cs

This Function is the endpoint we identified in the Twilio Dashboard.   Its purpose is to simply receive a message sent from Twilio and extract some of the fields that we receive.   

That extracted information is then used to populate our Model Class  `UserMessage`.   The fields are simply a username (the WhatsApp phone number) and message.

The processed message is then sent onward, via an HTTP POST, to `BroadcastSignalRMessage`.

```csharp
using System.IO;
using System.Web;
using System.Threading.Tasks;

using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;

using WhatsAppSignalRDemo.Function.Models;
using WhatsAppSignalRDemo.Function.Common;

namespace WhatsAppSignalRDemo.Function
{
    public class ReceiveWhatsAppMessageFunction
    {
        private GenericConfig _genericConfig;

        [FunctionName(GlobalConstants.FunctionName_ReceiveWhatsAppMessage)]
        public async Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = null)]           
            HttpRequest httpRequest,
            ExecutionContext executionContext) 
        {
            _genericConfig = StartupHelper.GetConfig(executionContext);

            string requestBody = await new StreamReader(httpRequest.Body).ReadToEndAsync();

            UserMessage userMessage = new UserMessage
            {
                User = HttpUtility.ParseQueryString(requestBody).Get("From"),
                Message = HttpUtility.ParseQueryString(requestBody).Get("Body")
            };

            HttpHelper.PostMessage(
                _genericConfig.ApiEndpoint + GlobalConstants.FunctionName_BroadcastSignalRMessage, 
                userMessage);

            return new OkResult();
        }
    }
}
```

## Summary

We've now had an in-depth look at the code and you should be in a good place with your understanding of what's needed in the system.

In the final article of this series, we'll look into the additional steps needed to get our development system published to the cloud.

See you there!


<a href="https://blogs.siliconorchid.com/post/coding-inspiration/whatsapp-signalrservice-azurefunction/part3-deploy-to-cloud" class="button is-primary">
  <i class="fas fa-file-alt ml-1" style="margin-right:10px;" > </i> NEXT:  Read part 3</a>