Hello bot developers,
I have recently decided to write blogposts about Bot framework technology to reflect my perspective on the subject, provide ideas on how it works and to troubleshoot common scenarios. The best start for this, is to make a good definition of "Bot Framework SDK", and in general "Azure Bot Service", that Microsoft offers.
Apart from the fancy description here, a bot can be defined as an application , which uses "Bot Builder" and "Bot Connector" libraries, to communicate through the Connector services and channels. While doing that, the dependent services being used on that bot application, like "LUIS" (Language Understanding Intelligent Service) or "QnA Service", makes the bot behave like an intelligent entity, since it will be able to understand your intentions easily and reply to them. All the communication between the human and the bot, is packaged into a serializable JSON based objects called "Activity", and it flows through different channels. "Bot Builder" libraries create a reply "Activity" to these incoming "Activity" objects, considering the state of "Conversations" and "Dialogs", to provide you meaningful suggestions based on your previous interactions. Most popular type of an "Activity" is a "Message", but activities can also provide meta information, like adding/removing users to a conversation. When activity reach out to bot, it will be put inside a "TurnContext" object, together with the state information of User and dialog. A Turn context , will be processed by the bot code, and it will be valid until the Turn of the bot is completed. You can find the activity processing stack with a nice diagram here if you want to see more on the activity processing. Note that, these diagrams focus on the bot side of the communication and abstract the channel/connector side.
To get more acquainted with the conversation based Bot communication, I can recommend you to start reviewing the REST API's documented here. Also, you can surf inside the Bot Builder 4.0 Namespace, to understand what an activity object is, or how a TurnContext object relates with an activity, etc.
We can finish the definition part here and If you want to play around with bots, you can start creating bots, and try understanding how they work. Assuming that you have an active Azure Subscription, you can deploy your bot to Azure or alternatively you can use our "Bot Framework Emulator" tool, to debug to bots locally. For the latter, I can give you a recipe below, to start with:
#1 - Clone the Bot Builder samples repo to get all available samples. In my posts, I will mostly use "dotnet core" based samples, since I am more used to work with that language. But we have other SDK's available and associated samples with these SDK's as well.
#2 - Once you clone the samples repo, you can locate to the easiest sample, which is "02.echo-bot" which just echoes back, whatever you write to the bot. In the GitHub article, "To try this sample" section defines how to build and run this sample.
Inside all the bot samples, you will find a folder called "Bots" which contains the bot classes, that are derived from ActivityHandler classes. These classes are injected as a dependency in the "Startup.cs" file. Once you find your bot class you can try putting a breakpoint to "OnMessageActivityAsync()" function which represent the bots turn.
#3- After you run the sample, you can go to "Bot Framework Emulator" and start communicating with your bot. you can visit this article here, if you want to understand how you can define your bot endpoint and connect to your bot using the bot framework emulator. Once you connect, you should be observing that your breakpoint is hit. You can check the contents of "TurnContext" object with your debugger, and try understanding the structure of an activity.
If you check more complex samples, you can see that the bot classes also implement other methods for activity handler class. Ie. one of my favorites "21.corebot-app-insights" sample also implement "OnTurnAsync" method of activity handler class. As you see, my ultimate recommendation for a bot SDK developer in this blogpost is: get more familiar with the samples, since they represent many different use cases for bot development.
What do you think can be the next step? That's right, you can now consider deploying your bot code to Azure, and start discovering the endless opportunities of cloud technologies :) Here is our standard documentation on deploying your bot to Azure. I think that is all for today. Hope you enjoyed the read.
Stay tuned for the next blogpost,
See you soon,
Mert