In the Part 1 of this series we have explored on how to configure the development environment and run the Bot Framework template to get the “Hello World” kind of reply from the Bot.

Now in this part, I would like to discuss about the development concept of Bot Framework. Behind the scene Bot Framework is an API that is encapsulated within Bot Connector library. The focus of the API itself is to provide a conversational context. Each conversation that come from the user is captured as “Activity”. “Activity” class is part of Bot Builder library. So, be careful not to mixed up with the other “Activity” class on Microsoft .Net framework or even from Dynamics CRM SDK. (Ref: https://docs.botframework.com/en-us/csharp/builder/sdkreference/activities.html).

So far there are 6 activity types that the Bot Framework has:

From the above activity types, “message” probably will be the most commonly used activity type.

Now, let’s drill down to the Activity class. The fundamental basic of Bot is to reply the message that is typed by the end user.

Now, let’s take a look at the code that is generated by the template to understand the basic of message reply from the Bot.

The highlighted part of the code above is the basic on how the Bot Framework is constructing the reply to the activity.

Ok, we might have the reply from the bot, but it is just the same reply all the time, it is not useful. Bot should be able to engage the user with something meaningful. So, to start a meaningful conversation there are some concepts that we can use: Dialog, FormFlow and Luis.

Note: In this post, I will cover just the high-level concept first and will deep dive with the code examples on the next post.

1.     Dialog

Dialog is the basic model of conversational process. Each Dialog in Bot Framework is encapsulated in a C# class that implements IDialog. The overview of Dialog provided by its documentation (https://docs.botframework.com/en-us/csharp/builder/sdkreference/dialogs.html):

Dialogs model a conversational process, where the exchange of messages between bot and user is the primary channel for interaction with the outside world. Each dialog is an abstraction that encapsulates its own state in a C# class that implements IDialog. Dialogs can be composed with other dialogs to maximize reuse, and a dialog context maintains a stack of dialogs active in the conversation. A conversation composed of dialogs is portable across machines to make it possible to scale a bot implementation. This conversation state (the stack of active dialogs and each dialog’s state) is stored in the state service provided by the Bot Connector service, making the bot implementation stateless between requests. (Much like a web application that does not store session state in the web server’s memory.)

In short, Dialog is the simplest conversation building block for Bot to communicate/reply. Dialog can be meaningful with its Chain method. To make it simple analogy, Chain can be illustrated as a series of command prompt dialog that will handle the reply from the user.

2.        Form Flow

Dialog is good for a starter piece of conversation. However, it can be really tedious job to build the Dialog that might have some aspects of ambiguity. Form Flow, as the name suggests, is based on the idea of a form, where there is a collection of fields to be captured throughout the conversation. Form Flow share the same principle as Dialog, where a “Form” is built through a C# class. Where it is using basic C# data types, such as: Integral, Floating Point, String, DateTime, Enum and List of Enum.

3.        LUIS

Now, with Dialog and Form Flow, the bot can handle basic conversations, however the bot itself will only understand the command based on the pattern of the message. With LUIS (Language Understanding Intelligent Service) from Microsoft, the Bot can be smarter to predict what is the intent of the user. To use LUIS, in code, it will be similar to the normal Dialog class, but we will inherit LuisDialog instead of the IDialog class.

A comparison of normal Dialog vs LUIS Dialog is applicable when we need to handle a conversation that initiates a car interest. With the normal Dialog, we need to put some hard-coded If-Else conditions and regex patterns to predict what is the user wants. But with LUIS, it will provide an output of the possible intents based on the conversation reply analysis.

Part 2 – Conclusion

So, I hope this post helps you to get the basic understanding of Microsoft Bot Framework and get the understanding of the toolset that the SDK provides. Stay tuned for the Part 3 – Development Deep Dive + Integration Through CRM API.