We, at KTL Solutions, provide continuous Dynamics Consulting and more, but can you imagine having your own personal Dynamics Consultant/Assistant? Your new Virtual Assistant can answer your Dynamics 365 Sales questions in a jiffy. How do you like that?
In Part 1 of my blog I am going to talk about the technologies involved in building a Bot. Part 2 will describe step by step process to build a Conversation Bot that can talk to Dynamics 365 Sales.
Buzz Words: #Bots, #VirtualAssistant, #CognitiveServices, #MicrosoftBotFramework, #LUIS, #AzureWebBot, #DynamicsConsultant, #Dynamics365Sales.
What are Bots?
‘Bot’ is derived from ‘Ro-bot’ and they both mean the same thing. They both are entities built and programmed to perform a set of tasks. Unlike Robots which are tangible machines with moving parts, Bots are more of an abstract concept. Bots are software programs.
So, what makes a ‘Bot’ different than any other Software Application or a Service? The biggest difference is that Bots are Smart! They are intelligent and can learn new skills over the time. They can ask questions and give answers. They can perform repetitive tasks, faster and better (and without getting bored or worn out!). The overall attempt is to make Bots behave like humans … Virtual Humans.
How do Bots Communicate?
There are 2 major parties involved in Bot Communication, Channels and Bots. Channels are different mediums that a user can use to communicate with the Bot. Some examples are, Skype, Facebook Messenger, SMS, Email, Chat, etc.
In the previous paragraph I said Bots are programs, now I am going to throw a curve ball. I am going to refine my definition and say that Bots are REST API’s or Web APIs. If you are a developer than you may know what REST API is. In simple words, REST API is a resource(function) that you can request over the internet using Http protocol. RESTFul API’s are a popular choice to make a software solution available to the outside world. Suppose I have built a big enterprise Solution that integrates with Dynamics 365 Sales. Now I want to make one single function GetCustomer() available for everyone to use, I would make a Web API and host it somewhere and make the endpoint available to the outside world. Here is a snippet of my Web API.
This Web API can be utilized by various Channels by making specific requests to my endpoint by providing CustNumber as a parameter. This is a typical model of exposing functionality using endpoints. But a Web API does not look anything like a Bot. To make it work like a Bot, we would need to encapsulate it and make it ‘Generic’ enough to pass any “Data” which can hit any “X” endpoint. Essentially build a black Box around it. This encapsulation will turn Web API into a Bot accepting Data, hitting various endpoints and giving back Data.
Now let’s move our focus towards Channels, they speak their own language, which Bots may not understand. So, we will need an Adapter that takes in a Channel language and translates it to a Bot language and vice versa on its return journey. See figure below to see the complete communication chain.
Figure 1 Overview of Bot Architecture
Although it is possible to do all of this ourselves, Microsoft has realized the emerging market for Bots and have built a Framework called ‘Bot Framework’ that does all the heavy lifting of encapsulating and translating so that Channels can communicate with Bots.
Microsoft Bot Framework
At Build conference 2016, Microsoft introduced an SDK for building Bots known as Microsoft Bot Framework. It is an open source project which can be used to build solutions in .Net and Node.js. It provides libraries that can help in creating Bots from WebAPI’s which can communicate with various Channels. Now it would be ideal to build a Bot only once which can communicate with all the existing Channels, but sadly we will have to wait for such a uniform platform. While Microsoft Bot Framework can communicate with a list of Channels such as website, app, Cortana, Microsoft Teams, Skype, Slack, Facebook Messenger, etc., to name a few.
Here are the basic concepts behind Bot Framework:
- Activity: It is an object that gets passed between a user and Bot. In Figure 1, Activity is represented by the generic encapsulated data called ‘Bot Data’ that gets passed during communication. It has special properties such as who the sender is, what message is sent, attachments, service URL, etc. which can be used by the Bots to program logic.
- Connective Service: It is the equivalent of an Adapter show in Figure 1. Connector service takes in Channel specific data and translates it into an Activity. This means that data from Facebook messenger, or Skype, or any other Channel will look the same and will be translated to an Activity. Connector Service is also responsible for translating it back into Channel specific data.
Figure 2 Connector Service
- Dialog: Just like a movie dialog (or rather a scene), it is one or more sentences from one or more actors/parties that can be tied together. It is usually a piece of conversation not the whole conversation. The purpose of breaking conversation into smaller dialogs is multifold, it keeps related information together and can also be re-used in another context. Various Dialogs can be chained into a Dialog Chain which will become a full-blown conversation.
E.g. Greeting Dialog may consist of ‘Hello, how are you?’, followed by ‘Fine. Thanks. How about you?’
Is our Microsoft Bot Smart enough?
So far, we figured out how a Bot is built using Microsoft Framework and how it can communicate with a Channel. But for a program to become a real Bot it needs to be ‘Smart’.
The biggest challenge while building any interactive system is to interpret the ‘asks’ of a user. We can think of 1st generation robots as systems that take in predetermined inputs. E.g. Automated Phone system, press 1 to dial Pharmacy, 2 to dial Bakery, 0 if you want to speak to a representative. A user cannot choose an option out of the ones presented to him. Next Generation bots accept plain human language and it gets challenging to interpret the request or the intent behind it. It involves Natural Language Processing (NLP) and Artificial Intelligence. A sentence needs to be parsed, and tagged appropriately depending on its Lexical Semantics.
e.g. ‘What is your name?’, will be parsed into list of keywords ‘what’, ‘name’, ignored words will be ‘is’, ‘yours’. Assuming you have built logic to understand the intent of user behind this sentence, it will still not be complete. As user can also ask this question in a different manner, ‘Your name please?’.
Fortunately, highly educated engineers at Microsoft have spent a lot of time making our lives easy by developing Cognitive Services. Under the umbrella of Cognitive Services is, LUIS. LUIS is a Language Understanding service that helps us understand the commands from users. And Microsoft Bot Framework provides a way to tap into Microsoft’s Natural Language Processing using LUIS. This makes understanding natural human language super simple.
LUIS (Language Understanding Intelligence Service)
With Azure subscription, you can build domain-specific LUIS models. We can list out the intentions of our App, utterances that we expect to go with our intentions and the entities involved.
- Intents: It means the intentions behind plain text. In case of CRM Querying App, intentions can be ‘Query Customer’, ‘Get Account Details’, etc.
- Utterances: Text that a user would enter to express his intention. E.g. “Give me details for Customer A”, or, “What is the outstanding balance on Account X001?”
- Entities: They are nouns used in a sentence. Customer A is an entity. Similarly, account X001 is an entity.
Here is a diagram I picked up from Microsoft’s website that shows how plain text in processed to determine an intent. LUIS returns Jason result with percent score for every intent.
LUIS is smart enough to use its in-built intelligence to determine an intent. E.g. If I built a ‘Greetings’ intent with utterances as ‘Hi’ and ‘Hello’. If a user enters ‘Hey’ then LUIS is smart enough to put it with Greetings intent. LUIS Model needs to be trained every now and then. It won’t be an exaggeration to say that a dedicated person is needed to work on making LUIS model mature. He will verify if LUIS is interpreting new utterances under correct intents, and if not then he would train the model accordingly.
Now that we have our piecemeal ready, I will show how to build an actual working Bot querying Dynamics 365 Sales in my next Blog. Stay tuned.
