In the previous part, I described how to use artificial intelligence and Microsoft Cognitive Services to create our bot. Let’s move on to programming it. Microsoft Bot Framework is a set of tools and services, which allows for designing, creating and publishing bots. This solution contains two parts – Bot Builder SDK and Developer Portal.
Bot Builder SDK
In a case of SDK, we can use one of two languages: C# or Javascript (NodeJS). In both cases, we will deal with the same application structure and concepts. The basic structure is a channel, which is a defined connection between our bot and a particular communicator, like Skype, Slack or Messenger. Communication with those external programmes is possible thanks to a Bot Connector.
Bot Connector is a service which can handle many channels, through which messages from users may be delivered. Our bot archives those messages by grouping them in the form of dialogues. Conversations are arranged so that a dialogue at the top of the pile is this one which processes new messages coming from a particular user to the end of the dialogue or a moment of creating a new one.
I won’t describe every Bot Framework feature in this article, but instead of that, I will focus on a way in which our example AutomatedCheckin has been implemented. Two elements are crucial –connecting our bot with previously created in Cognitive Services LUIS application and creating conversation scenarios between a bot and a user. The bot must lead the user through a whole process, asking him proper questions to collect all the data needed to conduct online check-in. Because the user can proceed few operations by using our bot (check-in, modification of a reservation, etc.), recognising an intention correctly during an initialization of conversation with a bot is crucial.
Our bot is actually WebAPI application, and as every application it has controllers. In that case, we use made-up template delivered by Microsoft for Bot Framework (http://aka.ms/bf-bc-vstemplate) with default MessagesController which contain two basic methods. We are particularly interested in Post method, which is responsible for receiving and sending communicates to a user.
The basic objects in a case of Bot Framework are Dialogues, represented by classes implementing IDialog interface, which contain all logic. In a case of our bot, we care mostly about integration with LUIS server and our application for text analysis. Microsoft made that connection much simpler, because proper libraries are available as a part of SDK, and we can use them.
The first step is to create a new dialogue class, which this time will inherit after LuisDialog class. Then we mark this class with LuisModel attribute by giving model id and subscription key in a constructor. Both parameters are available after publishing our application in LUIS service. The last essential material is methods mapping in our dialogue class into intentions in LUIS application. To do that, we mark proper methods with LuisIntent attribute by giving an intention name in a constructor.
Dialogues are a very flexible solution, but they demand from programmer to put a lot of effort into implementation. In every point of a conversation, there are a lot of options regarding next steps, which user can make, e.g. to check actual status, to bring on a hint, to step back to one of the previous questions or to move on to any of the next questions directly. Bot Framework makes it easier by sharing FormFlow mechanism, which can base on a model, automatically generate dialogue scenario with all questions and options of jumping between them.
By using such an approach, we sacrifice some of the flexibility of our solution for simplicity and shortening of development time. Additionally, we can link conversation scenarios generated with the usage of FormFlow with other types of dialogues. In a case of our bot, we will link them with LuisDialog, which will refer to our application created with LUIS and Cognitive Services. FormFlow Dialog will be responsible for leading a user through a series of questions, which will be aimed at getting proper data. LuisDialog, on the other side, has a task to process user’s requests and to detect his intentions.
To create a scenario for our bot, we need to specify what data do we need to check-in online. The most relevant information is a reservation or ticket number. The next information we need is a flight number, sex, email and preferences regarding a seat, a travel class or luggage. Every information is represented in scenario class as a public field. FormFlow supports basic types, i.e. Integer, Float, Double, String, DataTime, Enumeration and List of enumeration.
A Prompt attribute above the field defines the way in which our bot will ask users about a particular information. In a constructor, apart from the text itself, we can hand over different tags, which will be showing what statement should be displayed.
In a case of fields defined as Enumeration, “{||}” option informs bot that while asking users this question, the bot should also list every possible option. The next thing we have to do is to create a scenario. Below a BuildForm method has been presented. This method allows for describing how a conversation should go by using Fluent API. The order of method calling is mapping the order of statements and asked questions displayed by a bot.
Message method allows for displaying a statement by a bot, while Field takes a field name in a constructor and allows for displaying a particular question to the user. But what if we want some questions to be displayed under particular conditions?
Let’s take a look at BoardingPassEmail field, which contains only an optional email just for receiving a boarding card. This field will be displayed if the user answered in the affirmative to the question “Do you want to provide different email for getting a boarding pass?” In that case, we only use FieldReflector class, which has a SetActive method, in which we can provide a condition of displaying particular question.
The last step we need to finish, so our bot will be complete is to send a form to the user. To do that, we need to step back to TravelDialog class and Checkin method.
Checkin method is connected with proper intention in our application created earlier by using LUIS and Cognitive Services. It’s being called when application detects that user’s intention is to check-in online. The first line of code of that method allows for downloading all the data that our bot could get from user’s message.
As we remember, we defined a basic entity – a reservation number – in the application. In a case of detection, it will be provided by the application to Checkin method as a “result” parameter (LuisResult type). In the next step, we create a new dialogue based on FlowForm, and we call Call method on a context object, which initiates a dialogue with the user.
As it can be seen, our bot didn’t ask us about a reservation number, because we provided it in a welcome message. The user can move freely between questions – it’s also possible to return to those already answered by using “back” command. “Status” command is also a useful function because it shows all the already given answers.
You can download our AutomatedCheckin bot fromautomatedcheckin.com.
