The Microsoft Bot Framework makes it pretty easy to get started creating Chat Bots. If you haven’t gotten started yet, I recommend checking out this site: Bot Framework.

For a recent Bot that I created, we had the need for the Bot to expand. What I mean is, I want my bot chat UI to start out collapsed like a search box but then expand once a user starts talking to my bot.

7F9021F8-69F8-40A0-A26B-8EEC0CD32A1B

 

There are lots of examples for getting started with the Bot Framework. For this post, I will assume you already know how to do that. Hopefully you already know how to hook up the Web Chat control to communicate with your bot – here are some details about that.

I’ll start with the client-side code for this feature

For this feature, we will utilize the Web Chat’s backchannel using the DirectLine connection to the Bot. Then we can respond to events sent to the Web Chat from the bot. Here is the JavaScript needed to do this.

First, create a connection to the Bot with DirectLine:

        var directLine = new BotChat.DirectLine({ secret: "YOUR KEY GOES HERE" })

Next, subscribe to the event. All I am doing is listening for the event named “init” and when it occurs, add a class “fullSize” to the HTML element that hosts the bot.

        directLine.activity$
            .filter(isInitEvent)
            .subscribe(changeSize);

        function isInitEvent(activity) {
            return activity.type === "event" && activity.name === "init";
        }

        function changeSize(activity) {
            console.log("here")
            var container = document.getElementById("bot-chat-container");
            container.classList.add("fullSize");
        }

Lastly, create the Web Chat:

        BotChat.App({
            botConnection: this.directLine,
            user: { id: 'user' },
            bot: { id: 'bot' },
        }, document.getElementById("bot-chat-container"));

I’m just using a little CSS to hide and show the rest of the Web Chat UI. Feel free to enhance this part a little, it could be better. Hopefully you get the idea.

        #bot-chat-container {
            border: 1px solid #333;
            height: 50px;
        }

        #bot-chat-container.fullSize {
            height: 300px;
        }

        .wc-header {
            display: none;
        }

        .fullSize .wc-header {
            display: block;
        }

        .wc-console svg {
            fill: black;
            margin: 11px;
        }

        /* These styles are used to hide the upload button...*/

        .wc-console label {
            display: none;
        }

        .wc-console .wc-textbox {
            left: 10px;
        }

All that is left to show of the UI is this DIV. But this isn’t too exciting:

<div id="bot-chat-container" />

Here is the Server-Side Code

This whole thing is based on an event coming to the Web Chat UI from the Bot on the server. I’m using C# and it is pretty simple stuff. When you create a Bot, the MessagesController is stubbed out for you to handle various Activity Types. In this case, I am concerned with ActivityType.ConversationUpdate. Check to see if the a new member is added to the conversation and if so, send event named “init”.

private async Task&lt;Activity&gt; HandleSystemMessage(Activity message)
        {
            if (message.Type == ActivityTypes.DeleteUserData)
            {
		// ...
            }
            else if (message.Type == ActivityTypes.ConversationUpdate)
            {
                using (var scope = Microsoft.Bot.Builder.Dialogs.Internals.DialogModule.BeginLifetimeScope(Conversation.Container, message))
                {
                    var client = scope.Resolve&lt;IConnectorClient&gt;();
                    if (message.MembersAdded.Any())
                    {
                        foreach (var newMember in message.MembersAdded)
                        {
                            if (newMember.Id != message.Recipient.Id)
                            {
                                var reply = message.CreateReply();
                                reply.Type = ActivityTypes.Event;
                                reply.Name = &quot;init&quot;;
                                await client.Conversations.ReplyToActivityAsync(reply);

                            }
                        }
                    }
                }
            }
		// ... etc. etc.

That’s all.

I wanted to point out one difference between ConfigurationManager and WebConfigurationManager. I know there are other differences but here’s an issue I ran into recently.

I’ve been working on some Bot Framework stuff (really cool and fun, by the way). The Bot uses a QnAMakerService and QnAMakerDialog which worked great when I ran the Bot locally (debugging in Visual Studio) but it didn’t work when I deployed it to Azure. I knew that a lot of features of my bot were working but when it needed to use the QnA features it was just bombing out. A coworker helping out said he fixed my problem by putting settings in for the QnaSubscriptionKey and QnaKnowledgebaseId via the Azure Portal (navigate to your App Service, then Settings > Application Settings)

image

 

Yeah, I knew those were needed of course, but I had already added them. The settings were in my web.config file:

image

I was glad the Bot was working and I had a major clue to my issue. I wasn’t going to let it end there. Why weren’t the web.config settings being used? I took a close look at my code:

[Serializable]
public class QnADialog : QnAMakerDialog
{
public QnADialog() : base(new QnAMakerService(
new QnAMakerAttribute(
ConfigurationManager.AppSettings[“QnaSubscriptionKey“],
ConfigurationManager.AppSettings[“QnaKnowledgebaseId“],
Sorry, I couldn’t find an answer for that“,
0.5)))
{
}
}

The code seemed pretty straightforward. As a matter of fact, I recalled copying it from a sample on the web! Then I noticed that the code was using “ConfigurationManager” which was not the normal thing for me. I usually create web applications and I therefor use “WebConfigurationManager” to read from web.config files. And since my bot runs as an App Service in Azure, it IS a web application. I proceeded to make the major refactor of adding the text “Web” to the word “ConfigurationManager”. I then removed the Application Settings from the Azure Portal, leaving the values I had previously entered into the web.config file. And it worked perfectly.

As developers we have a variety of options to access configuration data and that data can be stored in several places. In addition to the two previously mentioned, there is also the CloudConfigurationManager class. My understanding is that this would have worked similarly to WebConfigurationManager. And, in fact, good old plain ConfigurationManager would have worked fine for this Azure App Service if I used the Portal to set my app settings instead of the web.config file. So, choose carefully and get to know the differences between the ConfigurationManager classes

Well, this was one of those bugs that took a while to figure out and of course the solution was pretty simple.

It turns out that this:

[EnableCors(origins: “http://MyWebsite.com”, headers: “*”, methods: “*”)]

is not the same as this:

[EnableCors(origins:”http://mywebsite.com”, headers: “*”, methods: “*”)]

I have some JavaScript that calls an ASP.NET web API method on another domain. Let’s pretend that the API is on myservice.com and the website is on mywebsite.com. As you can guess, I was having some issues and getting an error similar to this:

Failed to load http://myservice.com/api/SomeController/SomeMethod: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://mywebsite.com is therefore not allowed access.

I tried a lot of things to figure out what was going on. I knew that I had the CORS attribute on my controller and I had config.EnableCors(); set up in my Web API configuration. This is one of the first times I’m using CORS on Azure so I thought it had something to do with Azure, but that was not correct. After trying many, many hacks with no success and staring at my EnableCors Attribute, I had the “crazy” idea to change “http://MyWebsite.com” to ”http://mywebsite.com” and of course, everything worked fine. From now on, I’ll use all lowercase!

I hope you won’t get stuck wasting as much time as I did trying to figure this one out!