James Mann takes a look at Dialogs using the Microsoft Bot Framework, as a sneak peek of his session at Tech Days Online at the end of February!
One of the challenges for Bot Makers is delivering business benefits while providing boilerplate behaviour for state management and persistence. Writing this boilerplate code is potentially risky, as it relies on data segregation to ensure that conversation data does not leak between security boundaries. Not to mention that the Bot needs to be capable of seamlessly maintaining its state when it is scaled out or migrated to new hosts. It therefore can be time consuming to write and test.
To address these challenges and more, Microsoft Bot Framework provide an affordance called Dialogs. These components are C# classes (note: Dialogs also exist in Node JS), which encapsulate business logic and any persistent state that is required to model a conversation.
What does this mean? Well, you can model a conversation with just a few lines of code and not have to worry about how the Bot maintains the state of these conversations.
A simple example of a Car Insurance Aggregation conversation will illustrate:
Modelling this conversation is straightforward. For those of you using Dialogs for the first time, there are two things you need to do:
1. Create a Dialog to model the conversation.
2. Transition into the Dialog. This can be from another dialog or straight from your Web API controller:
When you run it, it should look like below. Notice how Bot Framework automatically took care of persisting local variables registrationNumber and startDate so that we can use them in subsequent conversation states!
I use the word State Transition a lot when I am talking about Dialogs. It’s helpful to understand that Bot Framework maintains a Dialog Stack to manage a conversation that flows between dialogs.
When you call a Dialog using IDialogContext.Call, you are pushing to the Dialog Stack. When you complete a Dialog using IDialogContext.Done, you are popping from the Dialog Stack. In both cases, you are passing control to the Dialog on the top of the stack after the push/pop operation.
Finally, when you use IDialogContext.Wait, you are telling Bot Framework to wait until the user sends another message, at which point, direct it to the appropriate method as instructed. This is the thing I like to call State Transitions, and it is the magic of Dialogs :).