I'm wondering how I would connect a microsoft bot written in c# with a signalr chat.
To be specific: I have a signalr chat in which users can talk to "coaches". But the bot has to listen to these chats in case the user asks the bot something (or other reasons the bot needs to do something). How would I do this?
Check out these resources that should give you enough combined information for you to build a connector for your bot to interact with SignalR.
This tutorial details how to build an ASP.NET Core app that integrates SignalR. Utilizes the SignalR client library.
This doc discusses how to build an Azure Function that "can leverage the Azure SignalR Service bindings to add real-time capabilities." I don't know if you are using the Azure flavor of SignalR and you don't mention Azure Functions, but this could give insight in how to design and implement.
You may need to use the BotFramework REST APIs (docs here) to forward and receive activities to your bot (depending on how you structure it all). If you build the connector as part of the same project as your bot, then this is less likely.
You will need to understand the activity schema so you an correctly interpolate the data being passed to and from your bot.
Lastly, here are some connectors from the Botbuilder-Community repo that you can use as a reference (Alexa, Google, Twitter) for development.
As you are probably aware, you need to build a service that allows your bot to connect to SignalR. This means authenticating against your SignalR service to retrieve a token or similar. Once that is complete, then it's a matter of the data being passed around. If you can successfully pass data, then it's configuring your bot to reply and send activities that SignalR can accept (for instance, a hero card may render while an adaptive card may not).
Hope of help!
Related
I've created a interactive chat bot using the Microsoft Bot framework (.NET Core). I want to consume it in my website as widget. Is there any way i can do it. I don't have azure subscription nor i can afford it so please suggest an alternative way.
Ex: like converting the bot project to a web service or micro service and consuming it or may be creating a API of this and consume it
PS: I'm not sure about this.
Please help me with this
Bot Framework SDK documentation says that Web App Bot is deprecated. But there is no information about the difference between development with Azure Bot and (deprecated) Web App Bot. What exact changes should be done if we migrate form one service (Web App Bot) to another (Azure Bot)?
In regards of other contributor's answer, I think main concept and
queries has not explained accordingly, so I felt it requires more
explanation in addition to clear the OP's main concern.
Questions: But there is no information about the difference between development with Azure Bot and (deprecated) Web App Bot.
The Bot Service behind Azure Bot and Web App Bot/Bot Channels Registration is the same; the change is in how the resources are
created that you use in your bot such as web apps, language
understanding, and more.
Rather than the one size fits all templates that the Web App Bot used,
Bot Framework Composer can be used to create resources for the Bot
with much more flexibility than the Web App Bot templates allowed.
Bot Channels Registration and Azure Bot are basically the same
capabilities renamed. The UX is slightly different in the Azure Portal
to help customers connect to the Bot Framework Composer.
Its clearly documented here in the official document you can get here
Questions: What exact changes should be done if we migrate form one service (Web App Bot) to another (Azure Bot)?
Currently migration from Web App BottoAzure Bot isn't supported.
If your Web App Bot isn't being used in production, you can delete
your old Web App Bot resource and reuse the bot name and app ID in a
new bot resource (after some time for the old record to get deleted).
The new Azure Bot is designed around creating your bot using
Composer, Bot Framework SDK, and so the gains from such a migration
would be minimal. You can get the official explanation here
Note:
Now you might be wondering, what about your existing Web app bot. Your bot and other resources will continue to work without any problem and you don't need to migrate your old web app bot in this aspect.
One question may arise,then why its been depricated or no longer be used?
The answer would be, Functionally though Azure Bot, Web App Bot, and
Bot Channels Registration all utilize the Bot Service in the same way
"under the hood". The Azure Bot path is easier, and more
configurable for developers in comparison of Web app bot
Hope above explanation will redeem your concern.
The Azure Bot is like the Bot Channel Registration. It is a global resource that identifies your bot to toher Azure resources and contains configurations and settings for the bot's external messaging endpoint, channels (Teams, Web Chat, Email, etc.), Exposing APIs, OAuth settings, and more.
To actually host the bot, you would use an Azure App Service. You would create one during the deployment process.
As the stated in the linked docs, existing resources will continue to work. Note that the docs specify that migration is not supported. Moving forward, when you build a new bot, you should use a combination of an Azure Bot for identity and configuration and an App Service to host and run the bot.
I would like to understand how payments work as far as Microsoft Bot Framework is concerned.
This is my scenario: In Visual Studio Code I wrote an bot app using Microsoft Teams Toolkit to use it as a chatbot in Microsoft Teams. My company has an Azure Active Directory subscription, so my bot app appeared there. This app communicates with an endpoint which is NOT hosted on Azure.
So my question is - will it generate any extra costs? Should I worry about this 10000 messages per month limit?
https://azure.microsoft.com/en-us/pricing/details/bot-services/
As I understand I'm not using Azure Bot Services as I host my endpoint and I'm taking care of the logic, am I right?
My endpoint is written in .Net Core using Bot Framework SDK. So I use their classes and also MicrosoftAppId and MicrosoftAppPassword is also sent to the endpoint (obligatory to use with Teams).
Thanks for clearing it for me.
You can see in the link that the limit only applies to premium channels. Your Teams bot should be fine.
I see that I can either connect directly (through Rest HTTP requests) to Google Firebase API but I can also connect it to Azure Notification Hub. I also understand that Firebase is free while Azure isn't.
Can you kindly describe what is the benefit of connecting Firebase to Azure rather than directly connecting to Google's API (if any)?
I'm using ASP.Net Core MVC as my backend.
Thank you
If you are doing one push platform only (Firebase in your case) and only considering basic scenarios, then there's not much difference between using it directly or via Notification Hubs (NH).
However, NH provides you with a set of really powerful features:
Cross-platform SDKs to allow device registrations from all major OSes and a unified way of sending pushes no matter which platform they are on
A feature that is unique across similar services is tagging and routing
Templating
Basic or extended telemetry
And some other features.
So, in short, yes you can do everything that NH does by yourself. It's just you'll spend a lot of time (and money on resources required to run it) while doing it. And this is an out of the box solution that has been tested through years and is used by some of the largest products on the market.
We've built an MS Bot Framework bot that consumes our existing, internal, on-premises APIs during conversations. We'd like to release this bot by dropping a Web Chat Component into the DOM of our existing, internally-facing, on-premises application.
With our existing architecture, naturally, we want to host this bot internally too--to leverage all our existing configuration and deployment processes. We understand that, regardless, the bot will have to communicate with LUIS--which is fine by us; it doesn't require the more complex (larger attack surface, less central IT buy-in) setup of Azure connecting directly to our internal business data API.
I think this diagram makes it more clear:
Can we achieve what's depicted in the bottom hosting configuration?
EDIT 1: Can we also host the direct line or a similar connector on-premises without having to write a custom connector? Additionally, can we chat with our bot over such a connector without having to write a custom chat component/widget for the DOM? (The web chat component would work just fine as long as it's pointed at our channel.)
The end goal here is to get all of our chat traffic to stay on-premises because this is a data-driven chatbot serving sensitive numbers. It will take less time to redevelop this in another framework that can run wholly on-premises than get approval from our central IT.
Side Note: I'm aware of the Azure Stack Preview. The minimum hardware requirements (and probably subscription costs too) are extreme overkill. (We're talking about a single Node app, after all.)
This is not a duplicate of this question because this question also addresses the key element of direct/line connector on-prem hosting where the other question assumed that the connector would still run on Azure.
First of all any chatbot is going to be the program that runs along with the NLP, Its the NLP that brings the knowledge to the chatbot. NLP lies on the hands of the Machine learning techniques.
There are few reasons why the on premise chatbots are less.
We need to build the infrastructure
We need to train the model often
But using the cloud based NLP may not provide the data privacy and security and also the flexibility of including my business logic is very less.All together going to the on premise or on cloud is based on the needs and the use case of the requirements.
How ever please refer this link for end to end knowledge on building the chatbot on premise with very few steps and easily and fully customisable and with all open stack frameworks and tools (Botkit, RASA etc).
This also explains how to host the BOT framework on premise.
Complete On-Premise and Fully Customisable Chat Bot - Part 1 - Overview (https://creospiders.blogspot.com/2018/03/complete-on-premise-and-fully.html)
Complete On-Premise and Fully Customisable Chat Bot - Part 2 - Agent Building Using Botkit (https://creospiders.blogspot.com/2018/03/complete-on-premise-and-fully_16.html)
Complete On-Premise and Fully Customisable Chat Bot - Part 3 - Communicating to the Agent that has been built (https://creospiders.blogspot.com/2018/04/CompleteOn-PremiseandFullyCustomisableChatBotpart3.html)
Complete On-Premise and Fully Customisable Chat Bot - Part 4 - Integrating the Natural Language Processor NLP (https://creospiders.blogspot.com/2018/07/complete-on-premise-and-fully.html)
I am currently facing a similar architectural dilemma. From what we've managed to establish - in principle, yes. How? A bot is just a web service. You can deploy it anywhere you want, but you will have to have another web service to intermediate between the bot framework app and a client - a custom connector.
If you want to use various connector services of the Bot Service (web chat, Skype, Slack), you have to deploy to Azure though.
If you want to connect to some of these channels from on-premise - again you need to write your own connectors.
How to write a connector? Taking a peek at how bot emulator application from Microsoft simulates the "DirectLine API" is a good start, and in my particular context we may do it, if we exhaust legal/security avenues to deploy to Azure.
We are doing a similar work - jira-journal - and we use ngrok to host the bot. The bot resides on-premise and uses the ngrok to expose the endpoint which we have updated on the bot portal.
The pain point we face currently is that in case we rehost the bot, we get a new endpoint which we have to go and update on bot portal :(