Join Sahil Malik for an in-depth discussion in this video Key concepts for bots, part of Microsoft Teams Bot Development.
- [Instructor] As I mentioned earlier, this is not an in-depth course on bots. But I will cover enough concepts that you can get a basic understanding of bots. So we need to understand some key concepts, just enough so you can follow through the Teams Bots concepts that I'll be talking about later. Of course, there are many other courses on LinkedIn and other places on the Internet where you can learn more about the bot framework. So at a very high level, there are at least three concepts that we need to know about.
Yeah, there are more than three concepts in the bot framework, but let's start with these three. Dialogs, channels, and state. Let's start with dialogs. Think about how would you talk to a bot, or for that matter, how would you talk to a person? The bot can ask, "What is your name?" "Hi, I am Sahil." "What is your age, Sahil?" So it knows my name by now. I say, "I am 12 years old." "What can I do for you?" "I'd like to book a car." So you see how I'm having a conversation here.
Dialogs is how we organize conversations. So, dialogs, the user interacts with the bot using a conversation, and generally speaking, a conversation is organized into dialogs, and dialogs contain waterfall steps and prompts. Think from a programming point of view, that these dialogs are organized as a sequence or a stack. And when the entire dialog chain finishes, like a waterfall, then it returns the results so they can be worked upon.
So at the end of this conversation, the bot knows that Sahil, who is 12 years old, needs a car. So in this conversation, each one of these steps is a dialog. And the important thing is that based on the conversation, you could skip a dialog, you could advance to the next dialog, run in a loop, replace a dialog. I mean, think about it this way. Like, if I'm booking a flight, and it says, "Where would you like to fly to?" And suddenly, I would say, "Can you check my calendar "and see what date I'm flying out on?" So right there, what we did is that we interacted a conversation.
At that point, do you remember the previous conversation? Do you want to get back to it? Or do you replace the entire conversation? Or perhaps we'd run it in a loop, like, "Tell me the name of all of your guests." "One, two, three, four," all the way to 50. There could be many things to consider here. Let's think of what it is like talking to a human. But every conversation starts with a default dialog. When you pick up the phone, what is the first thing you say? Hello. So yeah, every conversation starts with a default dialog.
Hello, or whatever you may choose. And it's easy to think of this as a waterfall. At the end of the waterfall, you send back the results to the program. Now, the interesting thing, I keep saying program. That's your bot. The bot is nothing but a web service. Yes, sorry to puncture the enthusiasm here. It's just a web service exposed on REST API. And we'll see how it writes this website shortly as well. Next, let's talk about channels. Users interact with bots via channels.
So, Skype is a pretty good example for a chat-based interface. Yes, the consumer version of Skype can host bots, no problem. There's another channel that you may have heard of called Cortana. Cortana, as you may think, is better suited for voice. Yeah, it can understand typed text as well, but it's designed to work better with voice. SMS is another channel, as long as you restrict yourself 170 characters. And yes, Teams is just another channel.
So you may have guessed that a web-based version of a bot, just a simple chat-based UI on a website, is slightly different than Teams, which could be slightly different than Skype, which is different than Cortana. So each channel introduces newer concepts and tops. So yeah, Microsoft Teams is a channel. So what does it look like as a channel? It supports one-to-one chats. I can have a chat with a bot in Microsoft Teams. What would be a good example of that? For instance, there could be a bot called Document Watcher.
I could say, "Hey, Document Watcher, "if a document appears with the words 'pay raise for Sahil,' "please alert me." That's a good example of a bot. A bot alerting a user, yeah. Or a bot participating in a group chat. Imagine that you use VSTS or GR. And you open a GR issue, and multiple team members are talking about the GR issue. So you can say, "Open GR issue 131." "The issue is open." "What branches did we create and get for this issue?" "The following branches were created." So you can see that three or four developers could be talking to a bot.
At some point, you can say, "Now open issue 132," and that closes one conversation and opens a new conversation with the bot. The bot can present some actionable cards. For instance, it can say, "Sahil, I found three flights "matching your criterion." "Which one would you like to pick?" And I can say, "Show me the details of that flight," and the bot could open a tab where it could show me the details of that flight. A bot also needs to remember state.
And states could be user data, which is specific to the user across multiple conversations. For instance, when I say hello to the bot, it can say, "Hi, Sahil, welcome back. "Last time, you were working on this. "Would you like to continue?" Or you can have private conversation data, which is specific to the user for this conversation. So, as I'm going through the conversation, and I say, "Okay, now book a car for me," it can say, "I see that you booked a flight "from the first to the fifth.
"Would you like the car from first to the fifth?" Conversation data. It's specific to a conversation, but across multiple users. "I see that you have GR issue 131 open. "Would you like me to tell you what branches "were created for this?" Or if we say, "What branches were created for this issue? "What does this mean?" Well, that comes from the conversation data. Individual dialogs themselves can also have state. And that is stored in dialog data.
Now, is it user data, private conversation data, conversation data? All of these are properties on the session object. So, you talk to the bot via session object in session.userdata, session.privateconversationdata, that's really where you store this info. State is managed in the bot framework using a provider-based model. For dev purposes, you can just use inMemoryStorage. But when you deploy the bot, hopefully in Azure, you deploy it across a number of stateless nodes.
So you could host the bot yourself, but at the same time, the bot could be spread across multiple nodes. And over there, you don't want to keep things in memory. So you want to externalize this in Azure Table Storage, Cosmos DB, or you can write your own storage as well. So those are some key concepts regarding the bot framework, and now with that background, let's dive into some actual code.
- What are bots?
- Creating bots
- Testing using ngrok
- Deploying bots to Microsoft Teams
- Testing bots
- Bots as Azure AD applications
- Updating bot registration in Azure
- Building the bot package