#botframework custom #webchat control and #websockets hacks

Hi,

At the time of writing, the default online webchat control (https://webchat.botframework.com/embed/…) isn’t websocket enabled at all. It seems that Microsoft will change that in a near future but I don’t know about the timing.

However, if you’re in a hurry and need to work with websocket right away, because for instance you know all your users use a company browser that is websocket compliant, then you have the opportunity to build your own webchat control as Microsoft made it available on GitHub. It is pretty straightforward to rebuild you own, just follow the instructions on the GitHub page.

That said, I wanted to try websockets but I encountered multiple problems:

  • my chat box remained empty and when digging further with the developer tools, I realized that the streaming URL returned by the Direct Line wasn’t correctly reused by the control. Thanks to Bill Barnes’ support (the developer of this control), I realized that the host header (wss://directline.botframework.com) including the protocol was missing and it ended up with an invalid stream url. I managed to amend the code a little bit in DirectLine.ts (hack #1):
    if(this.streamUrl.indexOf('wss')==-1)
    {
      this.streamUrl = 'wss://directline.botframework.com/'+this.streamUrl;
    }
  • Once that was ok, my websocket channel worked but I quickly faced another issue as my messages (POST) kept failing:errobotI tried with various browsers and different machines too and even different bots and I kept getting the same result…Then, I simply amended the code of my bot to send a basic answer like “hello” and no more issue…I realized that I was facing a timeout issue, although Bill says it shouldn’t be a timeout since bots are asynchronous.However, I believe what I see and I noticed that whatever the actual reason is, whenever the bot takes more time to respond then what is set as timeout value, I face the issue. The default timeout is 5 seconds which isn’t that bad. However, when working with LUIS dialogs, 5 seconds is not so much. Indeed, your bot first needs to resolve which LUIS intent has to be triggered and must perform an action accordingly. On top of that, my bot was also sending a ‘typing’ kind of reply to instruct the user that it is working on it, which caused the 5 seconds timeout to be systematically reached, thus causing the above issue. As I couldn’t improve the bot performance, I decided to increase the timeout in directline.ts (thanks Bill for pointing me in the right direction):
    const timeout = 15 * 1000; //instead of 5 * 1000
    

    Note that this timeout issue is not specifically bound to the webSocket mode, I managed to see it as well with the polling get but it is more visible with websockets as only new messages generate HTTP POST requests so we see directly that there is a problem while monitoring the network.

Discussion on GitHub is probably to be continued so if you’re also fighting with the webchat control and websockets and can’t wait, you can read it and interact with Bill  here.

Happy Coding!

Advertisements

About Stephane Eyskens

Office 365, Azure PaaS and SharePoint platform expert
This entry was posted in Azure, NLP and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s