Xamarin & .NET Developer Events in August
Bots! They’re everywhere! And on March 30, 2016 – Microsoft introduced its Bot Framework – a bet that bots will succeed apps and websites as the next “big thing”. This series of posts will explore the Bot Framework entirely, from looking at the framework in general, creating bots, adding intelligence to a bot, to adding a bot into a custom mobile app. But before we dig into what exactly the Bot Framework is, let’s first take a look at what exactly makes a bot … a bot.
Bots?
What Are Bots?
Bots have been with us for quite a while. In fact every time you call a large company and get stuck in a labyrinth of voice prompts saying things like “press 1 for yes, 2 for no” – that could be considered a bot. But bots are more than that … quite a bit more. Another example would be Slackbot. It’s always there listening and can provide in-context help for using Slack. For example, if you reply to a message with an emoji, it will helpfully suggest, and show you how, to add a direct reaction to it, instead of a full on new message.
Then there are the more fantastical versions of bots … imagine a Slack team at a large company – where people may or may not know each other. You and another developer are talking back and forth about what a certain requirement really means. A bot notices the back and forth with all the questions around a single business area – it also knows who the business owner is for that particular area. The bot then can loop the functionality’s owner into the conversation – getting the question answered quicker.
Or maybe even better … a bot could order a pizza anytime somebody tells it to.
You can think of bots as micro-applications running within another, larger application. That larger application will have something of a chat interface in order to invoke the bot. Since people are spending more and more time inside applications such as Slack, Facebook Messenger, Telegram, Kik and any number of other apps and websites that have a chat-like interface – it only makes sense that we, as developers, would want to get our applications … or bots … in front of them.
And this is where the Microsoft Bot Framework comes in.
Microsoft Bot Framework
At the heart of it, the services above, Slack, Kik, Facebook Messenger, all do the same thing … they send messages back and forth. They provide additional functionality that distinguish them from one another, but they all enable communication via messaging. Unfortunately, they also all expose a different API for developers to tie bots into. The Microsoft Bot Framework aims to solve this problem by giving developers a single API to develop against, and then it takes care of integrating into the various services. This abstraction frees the developer to concentrate on creating a great experience without having to bog down in service specific implementation details.
However, because each service provides unique features that a developer may want to take advantage of – the Bot Framework also provides a means to send “raw” code to the service. For example, this would be code only intended to work on Facebook Messenger and nothing else.
We can use one of two APIs to write bots with the MS Bot Framework. As you can imagine – since Microsoft maintains it – there is a .Net API to develop against. However … since JavaScript is taking over the world – there also is a node.js API as well. Once node.js gets involved, it’s usually a pretty safe guess that the entry point to the framework will be a REST service – and that indeed is the case.
So let’s now take a look at some of the key concepts of the Bot Framework.
Connector Service
Everything in the Microsoft Bot Framework revolves around the connector service. It provides the abstraction that allows developers to use a single API to develop a bot and then it connects it to various channels or services such as Slack, Facebook Messenger, Skype or even SMS messages.
The connector service provides a connection between the single API and various services.
So we know on one end all of the various channels plug into the connector service. But let’s explore what it provides developers on the other end.
Activities
Activities model the actual communications between the bot and its human counterpart. They contain properties for the sender, recipient and conversation they belong to. Activities also can contain rich content – images or these things called cards. Think of a card as something of a pretty, formatted message. Another attribute of a card is that it provides an action, so for example it could be possible to launch a website by clicking a button on the card.
Activities can also maintain state … although one should design bots to be stateless by default. This means in order to maintain state, the class that models the state will need to be serializable. Finally, the activity contains functionality to invoke service specific features.
All in all, the activity is the “message”.
Bot Builder
The Bot Builder is not a single thing, rather it is composed of many parts. These parts provide a means to easily create an entire conversation flow. One could model and create a conversation only from Activites, but the Bot Builder makes the process easier and more robust. The most significant concept within Bot Builder is the Dialog.
We can use dialogs to model an entire conversation. Dialogs have the ability to be composed together fluently – and that means we can use LINQ to put together a conversation flow.
We create dialog classes by implementing the IDialog interface. That interface allows us to hook into different lifetime events to provide context appropriate responses for the bot.
There are also a couple of framework provided dialogs, including one based on LUIS – or Language Understanding Intelligence Service. Ahh… now our bot is able to understand natural language – out of the box!
And More…
We covered the core concepts that apply to both the .Net and node.js APIs. The .Net API get some additional love in the form of FormFlow (see what I did there … form of FormFlow … hilarious). FormFlow will take a normal C# class with properties and create a bot whose purpose in life is to get those properties filled in. So a fully functional bot from a single class.
Direct Line. Technically this isn’t a way to create a bot, rather a way for an app to consume a bot created with the Bot Framework. So if you created your own app that needs a bot – this is the way to integrate it.
Summary
Microsoft’s Bot Framework is a new framework aimed at developers to help them create bots for multiple services using a single API. It provides a rich feature set that most services have in common, and a means to invoke service specific functionality when needed. Of all the terms thrown at you – remember that the Connector Service connects your code to the services where the bots will live. Activities are the raw messages. And Dialogs abstract activities away and provide a means to model an entire conversation experience.
In the next post we’ll take an in-depth dive with Dialogs and see how you can use them to create a full bot and integrate it into several different services.
Matthew Soucoup
Matthew is a Xamarin MVP and Certified Xamarin Developer from Madison, WI. He started Code Mill Technologies and is the founder of the Madison Mobile .Net Developer’s Group.
Matt regularly speaks on .Net and Xamarin development at user groups, code camps and conferences throughout the Midwest, including Xamarin Dev Days – Madison, That Conference, St. Louis Days of .Net, and CodeMash.
When he’s not developing cross platform apps, writing blog posts, or creating the next great talk, Matt enjoys brewing beer with jalapeños from his garden and playing 80s tunes on the piano.
Related posts
