Hey there! 👋 I am back with the bot post again.
The Conversational AI has witnessed a tremendous growth just in past 2-3 years. According to latest research, Gartner predicts that by 2022, 70% of customer interactions will involve bots — an increase of 15% from 2018. This does not come as a surprise, considering a good amount of consumers say they prefer chatbots to other virtual agents.
Last couple of months must have been super overwhelming for the overall Conversational AI team at Microsoft. Whether it’s the Bot Framework SDK or Composer with tons of new features, Power Virtual Agents seamless integration with Composer or the new channels and improvements at the Azure Bot Service; there have been significant updates for businesses. Cherry on the top is Build 2021 goodness!
As I said in my previous blog post where I discussed the automatic generation of the Form Dialogs that every new feature deserves the whole blog post because of their explorative nature and productive use-case.
Therefore, today I am going to write about something which is freshly baked, super hot from the oven and that is the way of creating packages for your bots for better sharing, re-usability and cost-effective solutions. Before we get into the details of packages and their implementation, let us first understand why is it so important that a dedicated team worked on this new model for months to bring this goodness to you.
If you’re relatively new to the Bot Framework (or Composer) then I’d suggest you to have a look here as in this post, it is assumed that you’re familiar with the concepts and implementation of Bot Framework.
Challenges with the Current State
If you’ve built a sophisticated bot using Bot Framework Composer (< v2.0.0) which is responsible for booking and tracking the food orders from your customers and you want to extend your bot to incorporate some middleware, custom adapters and other actions; you may have to face a lot hurdles to sort that out and that won’t be straight forward at all.
Even if you get successful by addressing all of these challenges, you may have to go through the same issues again for another bot. Lacks re-usability.
Furthermore, if you create your bot using (Enterprise) Virtual Assistant Template, QnA Maker or just simple Echo bot using Visual Studio, you may end up having different experiences with each of them and building a common functionality around them may lead to a dead end.
Therefore, the Bot Framework team realized and this became the reason of the evolution of Bot Framework Component Model.
Meet Bot Framework Component Model
The Bot Framework Component Model is the new framework to share and re-use bot’s functionality in the form of bot templates (Empty bot, Core bot with Language), packages (Custom Adapters, Middleware) or complete bots as skills. You can now create the bots with confidence as you won’t find yourself in a situation where you can’t customize or find it difficult to share the portions of your bot with others (unless it’s poorly designed 🤐)
Bot Framework Composer is now considered as the standard go-to approach for all sort of bots.
This model is comprised of a few essential pieces;
Adaptive Runtime
Adaptive Runtime is the core of this model which wraps up the Bot Framework SDK and provides the extensibility points to add any functionality by importing packages, adding your custom coded extensions or even connecting to skills. This means that you just have to take care of your business logic rather than worrying about the runtime code.
Templates
Templates such as Empty Bot, Core Bot with QnA Maker etc. are created on top of Component Model. Since they’re built by composing the packages (discussed below) therefore you can always edit / extend them according to your needs. For example, if you create a bot using Core Bot with QnA Maker, you can then add other packages such as Custom Adapters (Google, Zoom etc.) or Declarative Assets (LG) such as Welcome, Help & Cancel. Flexibility is the key.
Skills
Skills are just regular bots with the plug and play functionality. These bots can be connected to your existing bots to process the messages for you. This is done through the Skill manifest which establishes the contract that bots can follow and communicate with each other.
Packages
Packages are the components (or bits as per the product team) of a bot you want to re-use and share. Packages can be in the form of Declarative Dialogs (LG templates such as Welcome, Help etc.), Custom Adapters (Google, RingCentral, WhatsApp or Zoom etc.), Custom Actions (Adaptive Cards, Microsoft Teams etc.), Middleware and more. They can also be built in the combination of one another such as Custom Actions with Declarative Assets and so on.
Packages are just regular NuGet / npm packages depending upon the code language of your bot. On NuGet / npm, these packages are tagged with msbot-component to be displayed in Bot Framework Composer.
With Bot Framework Composer v2.0.0 release, the creation experience is now based upon Adaptive Runtime and that’s why you can see a new little icon on your left hand side of the Composer which indicates a whole section of Packages.
These packages can easily be added to your bot by just clicking on the Install button. If they’re custom actions, you’ll be able to see them right away in the Menu. For other types of packages such as Middleware, Custom Adapters, Skills etc. they can be used as described by their creators.
Did you notice that the team at Microsoft has done a great job in bringing up all of those packages upfront which were essential for bot development. For example, Adaptive Cards, Teams, Telephony and so much more.
But is it just Microsoft who is doing it? What if I want to connect it to some external middleware (as we discussed in start) or surface our bot to Google Assistant? Do we have something for that? Short answer is yes.
Community Packages
Bot Builder Community, with the awesome collaboration and contributions from Microsoft, has done a great job in developing all of these fantastic packages which includes several Custom Adapters, Recognizers and Hand-off packages. You can easily have a look at the community packages by selecting the community options from the list. Right now, they are not filtered properly but you can always identify the Community packages with BotBuilder.Community.Components.<type>.<name> pattern.
Community Packages are 100% opensource and you’re most welcome to get some inspiration from the existing implementation or provide your feedback by opening an issue
Local Packages
Now if you are like me and you’d like to create your own or use packages developed by your team internally, then you’d want to test them before you actually publish them to either npm or NuGet. So, to address this issue, we’ve got to set-up the local feed (same as we do for other .NET / js packages) and we just have to add a new feed by clicking on the Edit feeds button inside Package manager. Once you’ve setup the local feed, your packages will start showing up and you can easily install / use them in a similar way as shown above.
Packages are the game changer esp. for Composer first bots. They definitely eliminate the need of re-writing code and increase the extensibility with better sharing capabilities. Not only this, it also allows you to connect with Skills seamlessly. In my upcoming post, I’ll walk you through how you can create different types of Packages using Bot Framework Component Model.
Until next time.