Monday, January 16, 2017

Publishing the Traffic Cam Bot to Azure

After leaving the Traffic Cam Bot on the shelf for a few months while I was busy with other things, I finally came back to it last week.

First I brought it up to speed with the latest version of the Microsoft Bot Framework. Then I set out to publish the bot to Azure following along with the instructions given here in the section entitled "Publishing your Bot Application to Microsoft Azure". All in all, it was a fairly smooth process. But I did run into three issues at this stage that I want to bring up here in case anyone else runs into similar things.

403 Forbidden (App Service Instance)
This was the first thing I ran into when I published my bot from Visual Studio using the steps in the Getting-Started guide -- an HTTP 403 "Forbidden" error. I went through the various steps of ensuring that my appId and password were correct, and that I entered "https" for my service URL (something that you need to pay close attention to when first publishing). None of that helped.

What I finally realized was that when I deployed, I picked an Azure "Free" app service instance because, hey, who doesn't like "free"? However, upon closer inspection of the instance types, I noticed that "Free" instances don't have SSL support. If you poke around the Bot Framework docs, they state (correctly) that the framework handles SSL for you. However, apparently no so much if there is no SSL on the instance. So I redeployed to a B1 instance and got a little further.

"Test Connection" Failure (Ping)
The next thing I noticed on my bot details page, the web chat widget started working. But the "Test Connection" button always reported a failure. That seemed particularly strange, because clearly I could "connect" to my bot, as I was actually sending it messages and receiving responses.

This one had to do with how my ApiController implemented the ActivityTypes.Ping system message. In earlier versions of the Bot Framework and Bot Application Visual Studio template, this message was handled with a string response. It seems that in more recent Bot Frameworks, you are supposed to explicitly not reply to the message with a body, but merely return HTTP 200 (OK).

Duplicate Messages in Skype/Teams (Extra await)
Lastly, after getting my bot running on Azure, I wanted to try chatting with it using Skype. This worked great, except for the fact that in certain situations, I was seeing duplicated requests coming from Skype, a behavior that I was also able to replicate using the Teams client. The thing that made this problem especially flummoxing was that the Web Chat and emulator clients did not display this behavior.

It turned out that my ApiController's Post handler had a bug in it such that I was calling await twice along some code paths. I still don't understand the differences in behavior between Skype/Teams and the Web Chat / emulator clients under these conditions. But suffice to say, once I cleaned up my code, the problem went away.

Perhaps these notes will help somebody. I hope to be able to get the Traffic Cam Bot in the Bot Directory soon. But in the meantime, feel free to watch the code on Github.

No comments: