Unpacking the magic behind Azure Bot Service (Part 2)
Recap
Previously I’ve shared on the what Azure Bot Service is and unpacking the services running behind Azure Bot Service. Today, we’ll be exploring more towards creating our own Bot Service with Azure services.
Azure resources
When you create a bot by using the Azure Bot Service templates (Basic, Form, Language Understanding, Proactive or Q&A), several Azure resources are automatically created and added to your resource group. By default, these Azure resources are already configured to enable a very simple proactive messaging scenario.
Resource | Description |
---|---|
Azure Storage | Used to create the queue. |
Azure Function App | A queueTrigger is an Azure Function that is triggered whenever there is a message pushed in the queue. It communicates to the Azure Bot Service by using Direct Line. This function uses botframework binding to send the message as part of the trigger’s payload. The function forwards the user’s message as-is from the queue. |
Azure Bot Service | Your bot. Contains the logic that receives the message from user, adds the message to the Azure queue, receives triggers from Azure Function, and sends back the message it received via trigger’s payload. |
Process overview
This is the architecture diagram on how triggered events work and how user messages are handled end-to-end.
Step 1 - The process begins when the user sends a message to your bot via Bot Framework Servers.
Step 2 - The bot receives the message from the user.
Step 3 - The bot adds the message to the Azure Storage Queue.
Step 4 - The bot notifies the user (via the Bot Framework Servers) that the message has been queued.
Step 5 - The queueTrigger
Function will be triggered automatically after the message has been added to the queue storage.
Step 6 - The message is removed from the queue storage and sent back with the attached recipient info via DirectLine endpoint.
Step 7 - The bot receives the message from the trigger function.
Step 8 - The bot sends a proactive message to the user.
Code Walkthrough
Now that you have seen the resources required to build Bot Service, let’s try to deploy the resources on our own. However, that being said, the manual creation requires some additional work to be done. The breakdown is as follows:
Step 1 - Create an Azure Function to host your bot server.
Step 2 - Create a Storage account with Queue Storage for queueTrigger
.
Step 3 - Create an Azure Function to receive the queueTrigger
from Queue and send the message to Bot Framework.
Step 4 - Link Bot Framework credentials to Bot Function.
What’s different?
Let’s break down the process. Based on the architecture diagram below, Bot Service places the entire template or bot server codes into Azure Function. Inside the Bot Function codes, each message that is received from Bot Framework is queued into Azure Queue Storage. Subsequently, the other Function will be used to trigger on new message in queue, sending it directly to Bot Framework via DirectLine. Additionally, you could use Visual Studio Team Services (VSTS) or Git repository to ensure continous integration to your Functions or App Service. This is Azure Bot Service’s deployment.
We decided to dive deeper into our research and explore an alternative solution.
Why did I thought of that?
I wanted to keep Azure Function doing just one task – which is to forward the message to my existing App Service that runs my bot server. Without disrupting the current architecture, I wanted a solution that could achieve just that. Hence, I came up with this idea.
The architecture diagram below uses TWO Azure Functions and an App Service to function the bot. The only difference here is, instead of putting the entire bot logic and bot codes in a Function, we deploy that to Azure App Service. User messages get sent to Microsoft Bot Framework will be send a post request of the message to Azure Function. Azure Function will forward the message to the App Service. Here, App Service will process the business logic and then trigger the reply to Azure Queue Storage. From this point on, it functions the same as the earlier scenario.
Issue 1:
If you attempt to forward the message to App Service, there are a few things to take note of:
- Ensure that you require the
https
module - Posting ONLY Body request will not work. You will need to also capture the Authorization Headers from Bot Framework and forward that to App Service as well
A sample gist is provided here, Azure Function Gist.
Issue 2:
For the second Azure Function which is used to send the message back to Bot Framework via DirectLine, you have to configure under Function Apps Platform features
.
Click on Application Settings
. You must add the DirectLine Secret Key here as AzureWebJobsBotFrameworkDirectLineSecret
together with the secret key under Value
. This secret key can be retrieved from Bot Framework Channel Settings under DirectLine.
By default, you should be able to enter your DirectLine Key under Bot Framework Output which should be retrieved by the Function. However, as to the date of testing, Bot Framework output is still in Preview, hence it might not work as designed yet.
Now, here are the “secrets” behind building Azure Bot Service manually. Feel free to try it out!
Moving on from here, you might have further questions and thoughts on, which architecture is better, which design serves me better, hich architecture would you recommend, what’s the speed consideration and so on. I will discuss these thoughts in another article.
Cheers!