Overview of Dialogs for Bot Framework v4 2

One of the main building blocks to creating a conversation is by using a Dialog defined in the bot framework v4. Dialogs can process inbound Activities and generate outbound responses. In addition, business logic can run directly or indirectly within the Dialogs.

If you are developing your bot with the bot framework then there is a high chance that you are going to use dialogs. For this post, I am going to introduce briefly at a high-level of how Dialogs work.

Dialog Structure

At runtime, Dialog instances are arranged in a stack. The dialog at the top of the stack is the “ActiveDialog”. The current active dialog is the one that processes inbound Activity.

In addition, the bot must define a DialogSet before dialogs can be used. A DialogSet contains all the dialogs that the bot can call. If you are using any prompts, those need to be added into the DialogSet as well.

Dialog Lifecycle

A dialog has three main functions which are BeginDialog, ContinueDialog, and ResumeDialog.

BeginDialog

BeginDialog is initialization code and can take in initialization properties (“options” in the code). This method will add the dialog with the passed in id to the top of the dialog stack. The newly added dialog then becomes the active dialog.

ContinueDialog

ContinueDialog is the code that runs to continue execution of the arrival of an Activity following persistence. For example, consider a simple dialog where you ask the user a question and then expect a response. In this case, the question is a “BeginDialog” and then the answer is the “ContinueDialog”.

ResumeDialog

ResumeDialog is to support nesting of dialogs (where a dialog has child dialog). When a child Dialog completes, the ResumeDialog on the parent dialog will be called.

Waterfall Dialog

The dialog library comes with a “WaterfallDialog” class. It is a specific implementation of Dialog that is used to collect information from the user or to guide them through a series of tasks. The tasks are implemented as an array of functions where the result of the first function is passed as an argument to the next. Each function typically represents one step in the overall process. A step consists of the bot prompting the user for input, waits for a response, and then pass the result to the next step.

A waterfall dialog is composed of a sequence of waterfall steps. Each step is an asynchronous delegate that takes a waterfall step context parameter. A common pattern is that the last thing done in a waterfall step is to either begin a child dialog (usually a prompt) or end of the waterfall.

Different Types of Prompt

A prompt is a two-step dialog. First is to ask for input and the second is to return valid value or ask for an input again (re-prompt).

You are probably thinking, there are some prompts that you’ll use over and over again and it would be annoying to develop them yourself. Guess what, the Dialogs library offers a number of basic prompts each used for collecting a different type of response. At the time of writing, there are six types of prompts. They are the following:

1. Attachment: asks for one or more attachments (document or image) and returns a collection of attachment objects
2. Choice: asks for a choice from a set of options and returns the chosen choice
3. Confirm: asks for a confirmation and returns a boolean value (true for yes and false for no)
4. Date-Time: asks for a date and time and returns a collection of date-time resolution objects
5. Number: asks for a number and returns the numeric value of the input
6. Text: asks for general text input and return the string

It is important to note that in order to use any prompts you will need to add them into the dialog set. In addition, the ID needs to be fixed and unique for every prompt. If the default validation of the prompt is not enough, you can define your own validator for each prompt.

I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.

To get in touch, you can follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.