Intermediator Bot Sample

This is a sample bot, built with the Microsoft Bot Framework (v4),
that routes messages between two users on different channels. This sample utilizes the
Bot Message Routing (component) project.
The general gist of the message routing is explained in this article:
Chatbots as Middlemen blog post.

A possible use case for this type of a bot would be a customer service scenario where the bot relays
the messages between a customer and a customer service agent.

This is a C# sample targeting the latest version (v4) of the Microsoft Bot Framework. The sample
did previously target the v3.x and you can find that last release
here.

If you prefer Node.js, fear not, there are these two great samples to look into:

• botframework-v4-handoff
• Bot-HandOff (v3)

Contents

• Getting started
• Deploying the bot
• App settings and credentials
• Testing the hand-off
• About the implementation
• Custom agent portal
• Helpful links

Getting started

Since this is an advanced bot scenario, the prerequisites include that you are familiar with the
basic concepts of the Microsoft Bot Framework and you know the C# programming language. Before
getting started it is recommended that you have the following tools installed:

• Visual Studio IDE
• ngrok
• Bot Framework Emulator (download)
  • Debug bots with the Bot Framework Emulator

Altough the bot can be practically hosted anywhere, the deployment instructions (below) are for
Azure. If you don’t have an Azure subscription yet, you can get one for free here:
Create your Azure free account today.

Deploying the bot

This sample demonstrates routing messages between different users on different channels. Hence,
using only the emulator to test the sample may prove difficult. To utilize other channels, you must
first compile and publish the bot:

1. Open the solution (IntermediatorBotSample.sln) in Visual Studio/your IDE and make sure it
   compiles without any errors (or warnings)
2. Follow the steps in this article carefully:
   Deploy your bot to Azure
   • Top tip: Create a new Azure resource group
     for the app so that if stuff goes wrong, it’s really easy to just delete the whole group and
     start over
   • Having issues testing the bot (as in “The dang thing doesn’t work!!”) - check the following:
     • Did you remember to include /api/messages in the messaging endpoint
       (Bot Channels Registration/Settings)?
     • Did you remember to create and add the credentials (MicrosoftAppId and MicrosoftAppPassword)?
3. Add the credentials (MicrosoftAppId and MicrosoftAppPassword) to the
   appsettings.json file and republish the bot - now
   all you need to do to republish is to right-click the app project in the Solution Explorer in
   Visual Studio, select Publish… and click the Publish button on the tab (named in the
   sample “IntermediatorBotSample”).

App settings and credentials

App settings and credentials are available in the
appsettings.json
file of this sample. The file contains both bot and storage credentials as well as the settings that
can be used to tailor the experience. The default content of the file looks something like this:

{
  "MicrosoftAppId": "",
  "MicrosoftAppPassword": "",
  "BotBasePath": "/api",
  "BotMessagesPath": "/messages",
  "AzureTableStorageConnectionString": "",
  "RejectConnectionRequestIfNoAggregationChannel": true,
  "PermittedAggregationChannels": "",
  "NoDirectConversationsWithChannels": "emulator, facebook, skype, msteams, webchat"
}

Settings

• BotBasePath and BotMessagesPath can be used to define the messaging endpoint of the bot. The
  endpoint by default is http(s)://<bot URL>/api/messages.
• RejectConnectionRequestIfNoAggregationChannel defines whether to reject connection requests
  automatically if no aggregation channel is set or not. Pretty straightforward, don’t you think?
• PermittedAggregationChannels can be used to rule out certain channels as aggregation channels.
  If, for instance, the list contains facebook, the bot will refuse to set any Facebook
  conversation as an aggregation channel.
• The solution allows the bot to try and create direct conversations with the accepted “customers”.
  NoDirectConversationsWithChannels defines the channels where the bot should not try to do this.

Credentials

• MicrosoftAppId and MicrosoftAppPassword should contain the bot’s credentials, which you
  acquire from the Azure portal when you publish the bot.
• The bot needs to have a centralized storage for routing data. When you insert a valid Azure Table
  Storage connection string as the value of the AzureTableStorageConnectionString property, the
  storage automatically taken in use.

Testing the hand-off

This scenario utilizes an aggregation concept (see the terminology table in this document). One or
more channels act as aggregated channels where the customer requests (for human assistance) are
sent. The conversation owners (e.g. customer service agents) then accept or reject the requests.

Once you have published the bot, go to the channel you want to receive the requests and issue the
following command to the bot (given that you haven’t changed the default bot command handler or the
command itself):

@<bot name> watch

In case mentions are not supported, you can also use the command keyword:

command watch

Now all the requests from another channels are forwarded to this channel.
See the default flow below:

Teams	Slack

Commands

The bot comes with a simple command handling mechanism, which supports the commands in the table
below.

To issue a command use the bot name:

@<bot name> <command> <optional parameters>

In case mentions are not supported, you can also use the command keyword:

command <command> <optional parameters>

Although not an actual command, typing human will initiate a connection request, which an agent
can then reject or accept.

Implementation

The core message routing functionality comes from the
Bot Message Routing (component) project.
This sample demonstrates how to use the component and provides the necessary “plumbing” such as
command handling. Here are the main classes of the sample:

• HandoffMiddleware: Contains all the
  components (class instances) required by the hand-off and implements the main logic flow. This
  middleware class will check every incoming message for hand-off related actions.
• CommandHandler:
  Provides implementation for checking and acting on commands in messages before they are passed to
  a dialog etc.
• MessageRouterResultHandler:
  Handles the results of the operations executed by the MessageRouter of the Bot Message
  Routing component.
• ConnectionRequestHandler:
  Implements the main logic for accepting or rejecting connection requests.

What if I want to have a custom agent portal/channel?

Well, right now you have to implement it. There are couple of different ways to go about it. It’s
hard to say which one is the best, but if I were to do it, I’d propably start by…

1. …implementing a REST API endpoint
   (see for instance Create a Web API with ASP.NET Core).
   Then I’d hook the REST API into the message routing code and finally removed the text based
   command handling altogether.
2. Another options is to use back channel messages and hook them up into the current command
   pipeline. Granted some changes would need to be made to separate the direct commands from the
   back channel ones. Also, the response would likely need to be (or recommended to be) in JSON.
3. Something else - remember, it’s just a web app!

See also

• Bot Message Routing (component) project
  • NuGet package
• Chatbots as Middlemen blog post