Extending Power Virtual Agents with Skills – Part 2

In part 1 of this series, I mentioned the “Bot Framework Composer” and “Bot Framework Emulator." The ideas we are attempting to demonstrate are hosting and extending bots without directly using programmatic tools such as “Visual Studio” or “Code,” yet being able to leverage more advanced capabilities. As mentioned in part 1, capabilities in the pro developer version of creating bots (using the SDK) are not directly usable in Power Virtual Agents (PVA).

Note: Alas, as of 11/2020, a new version of the bot composer had been made available. Unfortunately, publishing skills to PVA bots appear to have issues in my current setup. So, my attempt in this post to walk through the basic steps to deploy skills from composer will not be complete with regard to extending PVA bots, just yet. That will remain for yet another follow-up post. In any event, I’ll provide the steps that “should work” – and may work – in your environment.

The next two sections should provide sufficient background regarding both installing and starting the required tools.

Installing and Starting the Bot Framework Emulator

The emulator allows for testing your skill bot locally on the desktop. When you develop your skill bot locally, using the Bot Framework SDK or Bot Framework Composer, you’ll generate a localhost address. Its that address you feed back into the emulator to run your skill bot. The Bot Framework Composer provides for automatically linking your bot to the emulator when its run. Eventually, when you go on to publish your bot to Azure, the URL and other parameters will need to change.

You can download and install the latest emulator from this link- https://github.com/Microsoft/BotFramework-Emulator/releases

If you are creating a skill bot via Visual Studio (beyond the scope of this series) or using the composer (this series) you will also need to download the SDK at this link- https://github.com/microsoft/botframework-sdk

When you start the emulator as a stand-alone application from the desktop you are presented with a dialog that specifies you enter the URL of the bot you are working with. The URL must be of the form /api/messages so for example, http://localhost:5342/api/message

Adding the URL manually is not required when using the Bot Framework Composer as the application itself generates the URL and calls the emulator from the composer window.

Installing and Starting the Bot Framework Composer

The following link is to the Git page for downloading and installation of the Bot Framework Composer-  https://github.com/microsoft/BotFramework-Composer/blob/main/README.md#get-started

The Bot Framework Composer is installable on Windows, Mac, and Linux. After installing you can start composer. In the first image you will see two options, the left button is for [New] bots and the other is our sample skill bot called “SpaceNews,” containing our “soon to be” skills. The “SpaceNews” bot was prebuilt as the first demo in this series. However, for now, we will start a New bot in the next few steps to help validate everything is working as expected. Click on “New” and select the Echo Bot example provided. Admittedly, this is the standard “Hello World!” bot sample, so nothing all that exciting yet.

The “Next” button is located towards the bottom of the Create dialog.

Again, click the “Ok” button and at the bottom of the dialog and you will see the next screen.

The following design surface is presented. Click “Start Bot” and approve the security dialog if you see one. This will start the EchoBot and queue up the emulator to test everything out.

You will see “reloading” just to the left of the start button in the upper-right screen.

Check the Firewall settings to allow access from this application.

Click on the “Test in Emulator” link to use the new bot interactivity

The following test screen should appear, this is the Bot Framework Emulator. At this point you type into the message area near the bottom and you will see your text echoed back.

Yes, this is rudimentary, but now you’re ready to move on to some of the next steps in the process. It’s important to note that every time you make a design change in the composer, you need to restart the bot. Also, you need to be mindful that you’re actually testing the latest change to your bot in the emulator. Typically, I just close the emulator until I’m ready to restart my bot with the latest changes using the “Test in Emulator” button in composer.

A Quick Tour of the Composer Design Surface

This post will not attempt to be a tutorial on how to create bots using these Microsoft tools. Plenty of good material is already online. My hope in this series is to highlight some of the more interesting features, including some of the necessary administrative tasks. That is, just because this is a no-code/low-code development environment does not mean a few technical hurdles still need to be overcome and understood.

The architecture of all bots is virtually identical and depends on just a few concepts. They are a dialog, trigger, action, and some source of knowledge. Of these concepts sometimes knowledge can be integrated into the dialog itself, if small enough. The actions these dialogs can execute based on specific triggers the designer creates are fleshed-out bots. Each concept has many parts, but the large-scale architecture is just these simple ideas. The following image depicts these choices in the design surface.

As a couple of examples, lets add a new dialog. As you can see, another “node” is added in the left tree. Dialogs are separate branches that represent a particular conversation a user is having with the bot. When a new bot is created an opening dialog starts off the process. When a certain key word or sentence is entered by the user, the opening dialog may switch over another dialog that can better handle that area of knowledge. You will not see two dialogs in action, only one dialog handing off to another. The designer will add the necessary elements in each created dialog to hand off one from the other.

The next image depicts the ability to branch into some other dialog when certain criteria are met. Looking at “Dialog Management” you can see the option to “Begin a new dialog." The “why” a new dialog is executed depends on the trigger used and how its defined. I won’t go into that level of detail as this is intended to provide an overview of the high level pieces.

Lets now take a quick look at the bot prepared for this series, I call it “SpaceNews.” It's interesting in that it calls a REST service external to the bot that returns, well, some space news. Here is the design surface – as you can see its overall architecture is barely beyond the Echo bot, with the addition of another dialog. The difference is in the actions it takes.

Let’s run this bot in the emulator.

The opening dialog is shown ”Welcome to the interactive space news bot”

The dialog inquires for a search term that narrows the search.

The final emulator image is the output based on the keyword “spacex.” You can also see the log output on the right side.

Hosting Skills and Bots and Knowing the Difference

Dialogs that are started/called within a bot depend on the user’s interaction with the bot. It is these self-contained interactions within a bot that represent its design decisions. For example, a bot designed to create a conversational calendar entry is certainly a vertical use-case. The same bot would typically not be used to surface company white papers, for example. It’s also fair to say that distributed teams may want to create several vertical bots as “tools” for their team to use but may not necessarily overlap with other teams use-cases. However, all teams likely share some common use cases and would have a need to pull information from several areas.

The same tried and true patterns developed around publishing code to the cloud is also at work for bots in the form of skill bots. Even a small company may have several use-cases that could be tied together from a central location and exposed through a conversational bot interface. No actual repository exists as such, but the idea is to publish the various bots into your tenant. That is, publish them but make them callable from other bots.

So, what is the difference between a bot and a skill bot (or skill)? Really just two differences, the first is simply having all bots deployed to the same tenant and made available for other bots to integrate. The second difference is having some way to specify what parts of any previously published bots can be included in your bot. The good news is that the Bot Framework Composer is intended to allow for both publishing your bot and provide the necessary tooling to expose pieces of itself for use by other bots.

At this stage you may be wondering why not just use Power Virtual Agents (https://powervirtualagents.microsoft.com) to do everything with bots? PVA bots, as already indicated, are intended as a no-code, low cost of entry into the world of bots. In fact, this is a great start. However, PVA bots have limits on what they can do. To start harnessing more advanced skills, a PVA bot needs to pull in skills that cannot be designed as part of the PVA design experience. Also, PVA bots are intended as stand-alone entry points. How do we import skills to PVA bots? To do this, a skill bot must be already published. It is a two-step process. In the following image we see a bot I named “PortalBot.” This is what the design environment looks like. You can see the left menu contains a “Manage” node, and under that selection you see “Skills.” This is where you start the import process.

Click on Skill and you will see the “Add skill” button just in the upper-right next to the chat window.

In the next image, you see a dialog with a URL being requested to something called a manifest. The manifest is a JSON file that describes the pieces of another already published bot you wish to integrate into your bot.

Let’s take a step back now and see how this may look from the perspective of our “SpaceNews” bot already constructed. If we go back into the Bot Framework Composer, you can see what its manifest file looks like by exporting it. The file will contain a description of what you allow other bots to use. This is depicted in the following image.

“Export as skill” will bring you through a couple of dialog windows then allow you to save the export as a JSON file. The actual exported manifest looks as follows.

The method discussed in the last two images assumes you’ve published your Bot Framework Composer bot to Azure (our “SpaceNews”). This means SpaceNews is available as a stand-alone bot via the several channels offered by Azure or just a webpage that can host the bot. However, more importantly, SpaceNews can be imported as a skill into PVA bots as well.

A second method of importing SpaceNews as a skill is to publish directly to our PVA bot and avoid some of the step with regard to publishing in Azure. This option is shown the Bot Framework Composer as a publishing option. See the next image and note the highlighted cloud icon.

Click on the cloud icon and “Add new profile”, the following options are presented. You will see the highlighted option for “Publish bot to Power Virtual Agents (Preview)”

To summarize, the Bot Framework Composer provides two options for integrating your bots skills into PVA bots. The first, is to publish your bot to Azure and expose those skills as a manifest file to your PVA bot. This first options means all bots can have access to your skills in the organization. The second, is to publish your composer bot directly to your PVA bot. This approach is simpler but it remains to be seen how useful this is to a wider audience.

As a reminder,

Note: Alas, as of 11/2020, a new version of the bot composer had been made available. Unfortunately, publishing skills to PVA bots appear to have issues in my current setup. So, my attempt in this post to walk through the basic steps to deploy skills from composer will not be complete regarding extending PVA bots, just yet. That will remain for yet another follow-up post.

I won’t be able to demo the full importation process and will need to skip deploying a bot from the Bot Framework Composer to Azure. Both walkthroughs are subject to change. If you would like to see the details of doing so, please refer to the below link. I’ve stepped through the process successfully, but it's tedious to be sure. This may be the subject of another post, so keep your eyes open. Deployment is subject to change as these tools are actively being worked on by Microsoft.

https://docs.microsoft.com/en-us/composer/how-to-publish-bot

If you have any questions about this post or would like to discuss the topic more, please reach out to us today!