We are building a bot using the MS Bot Framework. Sometimes when the bot is not used, it takes too much time to respond and we get a [500] Internal Server Error. We see this issue when we try to access the bot on our app (we are using Direct Line to interact with the bot).
I've read other answers about making sure the Microsoft Azure setting for application activity is set to "Always On", and we have done this. But as Always on is pinging the root of our bot web app, I think it may not be enough to keep the bot / directline alive...
And I don't have any rewrite rules from http to https preventing the ping request to be successful..
Anybody had this issue?
UPDATE to ask a specific question : How can we make sure that our bot is ALWAYS alive if all the settings explained above do not work ? Should we ping our bot thru the directline framework ?
One way to do it would be to send a ping every 15 minutes. The default code even gives you a place to handle the ping in the message controller
else if (message.Type == ActivityTypes.Ping)
{
}
please also take a look at this post as it may work for you and is a very simple solution with no code.
I had to create an azure function that pings my service, as I was having this same problem. I have Always On for all my services, and still find the bot going to sleep. With the ping service, it establishes a new conversation, sends the utterance, and then closes after receiving the response. This has seemed to work, but is only a week into practice. Note, I am pinging every five minutes.
Related
I had a local bot which I wanted to test in WebChat client instead of Emulator. After researching for a while and failing to connect normally, I stumbled upon a package called offline-directline which helped me connect my local bot successfully. My directline runs on 4000, webchat runs on 3000 and local bot runs on 3979.
I took a peak in the network tab later and I see my client keeps making GET requests to /directline/conversations/ endpoint. At first I thought it happens when I am sending messages in my WebChat client but it keeps sending them repeatedly. Around 50 GET requests in a minute.
I am not sure if this is a normal behavior. Would really appreciate an input. Thank you.
For some security reasons that I can't have a public accessible server to receive data from slack.
So, this is what I'm planning to do:
Inbound message from slack: using RTM API
Outbound message to slack: using RTM API or Web API
Questions:
Any better alternatives?
Any restrictions? (AFAIK, buttons and drop downs can't work)
If Web API reach rate limit, can I use incoming webhook as a backup plan?
RTM only approach
Yes, that would work. With only the RTM API you are limited to:
receiving and responding to messages
Other RTM events.
You can't use any interactive functionality like:
Interactive components (buttons, menus, datepickers)
Dialogs
Rate limit on message posting
Using the webhook as "backup" to circumvent the rate limit is not an option, since the rate limit of posting max 1 message per second applies to all form of message posting.
From the documentation:
In general, apps may post no more than one message per second per
channel, whether a message is posted via chat.postMessage, an incoming
webhook, or one of the many other ways to send messages in to Slack.
Alternatives
You did not give any details about the reasons why your app can't expose an endpoint to the public Internet. But you might want to consider using a VPN tunnel like ngrok.
Yes! Socket Mode
There is a new alternative from slack, Socket Mode, which doesn't require a publicly accessible server.
Note: this is only for private apps.
With Socket Mode you have an API token and your server uses it to communicate with Slack's servers and create a two way socket connection. This means your Slack Bot's code can run on a machine behind a firewall and not require any inbound ports to be opened.
Slack message delivery requires an acknowledgement once you get the message, or else they may retry to deliver it.
Limitations
Socket Mode has two main limitations:
Apps using Socket Mode are not currently allowed in the public Slack App Directory.
Socket Mode is only available for apps using new, granular permissions. If you created your app on or after December of 2019, good news: your app already uses the new permissions. Otherwise, you may have to migrate your classic Slack app to use granular permissions before turning on Socket Mode.
We have embedded a Bot on a web page through the web chat channel, if the Bot is idle for 10 minutes or so and then a question is asked, the Bot does not respond to it, however when the same question is asked again immediately it responds as expected.
On investigating the network capture, we observed the response received when the question was asked for the first time was 500: Internal Server Error with message as "failed to send message"
Are you running the bot in Azure? If so, make sure you have "AlwaysOn" enabled; otherwise the web app will be unloaded if it's idle for a period of time. Check this for a similar problem.
Always On. By default, web apps are unloaded if they are idle for some period of time. This lets the system conserve resources. In Basic or Standard mode, you can enable Always On to keep the app loaded all the time. If your app runs continuous web jobs, you should enable Always On, or the web jobs may not run reliably.
You can read more about the web sites configuration here.
I've try to create a slackbot. Works fine, but my problems are calls from slack to my rest api. My app is an internal service, so it's not available from the internet. I have seen that outgoing webhooks is possible to set, but I have to forward the request back to the internal service which I don't like very much. As far as I know slack is based on websockets, so is it possible to write a bot which run behind my “firewall“ and get it's commands via websocket?
Greetings
Tonka
You can use services like Localtunnel for receiving webhooks behind a firewall.
We use it with a docker container to develop our slack bot in local env.
Webhooks, slash commands, interactive messages, events etc. are based on HTTP.
Only bots use websockets.
But even this bot websocket session still needs to be initiated with an HTTP call.
Not entirely sure how your firewall is set up, but you may want to make your endpoint public to make things easier.
Currently we have a few test servers which connect to test.sagepay.com to process transactions. However, on 2 of the servers, we could successfully register transactions on sagepay, but then we didn't receive any sagepay notification coming back at all. However, on different servers (running on different IP addresses), it is working perfectly fine.
I've got the error code "5006 - Unable to redirect to Vendor's web site. The Vendor failed to provide a RedirectionURL". It used to work perfectly fine on those servers, and only stopped working since last Thursday although we are sure that we didn't touch those servers during that period of time at all. Besides, we do see a few occasional notifications coming in from sage which we believe are the REPEAT notifications, not the original ones. We could see all those transactions registered on our accounts, but of course all of them are failed due to the fact that we haven't got any notification coming back.
And we also do make sure that our firewall is opened for the whole range 195.170.169.* from which we expect to receive the sage notification
So my questions are:
Does Sagepay have some sort of mechanism to block some IP addresses and stop sending back notification?
Is the Sagepay-serer which sends out original notifications different from the one that sends out Repeat notifications?
I've faced the very same issue. Our script was handing https:// address over to SagePay as a NotificationURL, but https was not setup, hence the notification script could not be reached. Once I changed to http and ensured that the notification script response is correct it worked.
Also it seems that when SagePay could not reach RedirectURL it tried 8 more times.
I'm not exactly answering your questions, but perhaps it will help. I'd add this as a comment, but I can't...