Did anyone deploy Azue Web App Bot using Application Service Environment?
are there any key considerations to be noted? I know we have ASE ILB and ASE External;
Is it possible to host multiple azure webapp bots in one ASE; my question is primarily due to the default lockdown of internet traffice in ASE ILB model and what type of firewall exceptions we will need to ensure
functinally the communication to Azure Bot Service/ Directline happen smoothly.
It is possible to host multiple azure web app bots in one ASE. However, care should be taken on how to have the bot dynamically looks up the pipe name as there a multiple bots inside the same ASE. Also, the normal DirectLine or other channels would require a lot of whitelisting to allow traffic into the ILB, and bot services IPs can change so it would be difficult to maintain long term.
'Test in WebChat' is not expected to work within an ILB ASE. It calls out to the DirectLine channel and causes the channel to send a call to the bot's messaging endpoint. In most ASE or VNET scenarios that call will be blocked, but since we don't have static IP addresses so the customer can't whitelist the incoming calls, either. Other than that, Directline channel and Direct Line App Service Extension(DL ASE) should typically work as expected from within an ILB ASE setup. If you are implementing additional features such as OAuth or SSO, then you will need to add a rule to enable service tags for AzureAD.
For more info on DL ASE, please refer to https://learn.microsoft.com/en-us/azure/bot-service/bot-service-channel-directline-extension?view=azure-bot-service-4.0
Related
I am working on MS Teams development. I installed the MS Teams toolkit in VS Code, set up my subscription with Azure and sideloading is active in my tenant.
When I run the app, it tries to install ngrok. This step fails as my organization does not allow running ngrok or other words tunnelling from our company laptop. We can run this on a VM to go around this but VM is not always available.
I am looking for a resolution for below scenarios:
Is there a way to debug MS Teams application without ngrok?
If we need a https URL, is it possible to configure a web app to facilitate that?
I tried removing install ngrok step from: /.vscode/tasks.json, but there are subsequent steps it the file dependent on that
I've done quite a bit of research on this question myself as I'd been getting a lot of pushback from our IT department regarding the security threats that come with using a tunneling service like ngrok. It eventually led me to this video posted on the MS forums from a Microsoft engineer who explains it clearly.
What it comes down to is that the Teams client (browser/desktop) approaches webservices (configured in the manifest file) differently depending on the type of interaction. If you're testing configurable tabs, task modules or configuration pages, then you can easily route the app to those sites running on your localhost through the manifest. The Teams client will approach them directly. Problems start to arise when you want to debug what happens when you use a bot or message extension, outgoing webhook or MS Graph change notifications (just quoting the video here, there might be other scenarios).
Basically, what happens is that the Teams client goes through a Microsoft-hosted service first, called Microsoft Teams Services, which will then approach your bot framework cloud service (typically an Azure Bot resource). This then forwards any incoming messages to whatever endpoint you have configured. What happens in these separate stages isn't completely clear to me, but what I do know is that whatever is typed by the user in the Teams client is translated to a JSON structure that can be interpreted by your server-side bot code (for C# apps, this is typically your CloudAdapter-derived class working with your TeamsBot-derived class). These messages are then routed to the relevant TeamsBot class method based on properties in the JSON.
Now the issue that ngrok solves is that, when the Teams client goes onto the public internet to reach the MS Teams Services server and then the Azure Bot resource, it then needs a public address to route the traffic to. It doesn't know about your local network anymore. As ngrok sets up a TCP tunnel between their server and your local PC, it is able to route traffic coming to their server to your PC. The Azure Bot now has a public address to send the messages to.
To my knowledge, there is no way to circumvent this as long as Teams client inner workings always make it go outside of your local network. For chat scenarios, the Bot Framework Emulator might offer a solution for unit testing. As far as I can see it performs the translation of chat input to the JSON message model of the Bot Framework and routes it to a local address for your chatbot to process it. Unfortunately, this doesn't work for chat message extension type messages.
As for the question whether ngrok can be avoided, I think the answer is definitely yes but you would need an alternative. There's several alternatives around that you might be able to host yourself if you have the technical know-how. Depending on your IT department, being in control of the public-internet-facing server might be a more viable solution for them. Another option is to host ngrok on a VM or cloud machine with less access to your internal network's resources than your PC/laptop has and test the code there.
TL;DR: If the the feature you're testing is approached directly by the Teams client, you can enter localhost in the manifest and debug it. If you're testing a feature that the teams client approaches through Microsoft Teams Services and the Bot Framework, you need to find a way to expose your code to the public internet. You can use ngrok or host your own alternative depending on requirements.
use mkcert to generate a certificate for ex. localhost.test
add losthost.test to your host file
use https://localhost.test for debugging
I want to develop a product which simplifies the way of creating conversational chat bots using Microsoft BotFramework SDK. As we can build and host web application on-premise completely.
So can we build the similar thing using bot framework on a self hosted environment?
Here is the link for Microsoft Bot Framework: https://dev.botframework.com/
You can, indeed, build a bot entirely on-premises/self-hosted, provided that you don't need to connect to a Channel like Teams.
Background
Basically, bots communicate via:
User interaction with DirectLine Client (like Web Chat) ->
DirectLine API receives data and sends to bot ->
Bot hosted anywhere receives message
Note:
WebChat is just a DirectLine client. If you want to build your own WebChat, you can clone the repo and build it yourself. However, that all this does is make it so you can host your own webchat.js file, if you really want to be self-hosted.
Steps
With that in mind, all you need is:
A Direct Line client like Web Chat (specify domain property with your own endpoint when you call createDirectLine), or you can write your own client
You own DirectLine API implementation like offline-directline (more info)
Host your bot somewhere
Security
With this approach, you won't be able to use the typical appId/password setup.
You can manually implement our security protocol by following this document
Even though it is possible to manually implement the security protocol, we recommend reusing our existing open-source libraries
Based on answers, putting a more complete answer here. Since the option exists to have internet connectivity, I'd definitely suggest creating the solution as a "regular" Bot Framework bot, using the Azure Bot registration. Importantly, there are TWO options to do this - the most obvious one creates a "registration" for the bot but ALSO defaults to hosting it in an Azure Web App, which has a cost associated that can be quite significant. HOWEVER, there's another option, to create just a "Bot Channel" registration, which means you get a bot registered in Azure, but not necessarily hosted in Azure.
I've described this more in this post and you want to use the "Bot Channels Registration" in Azure, not the "Web App Bot". Then, on the "settings" screen you can define what the bot's actual address is (see here for a view of the Settings screen).
So, overall that should help - basically the bot just needs to have an HTTPS, internet-accessible endpoint. HOWEVER, that said, it's possible to host your bots inside Azure Functions, rather than Azure Web Apps, and the cost is dramatically cheaper (cents vs dollars, especially with low traffic). It's a bit of work, especially as the default samples default to the more standard options, but it works quite well.
I've recently launched a new blog, by the way, and I've got a post describing some of what I've learned so far about how bots work, that would be good to know as part of this. See How Bot Calls Actually Work.
We're in the process of migrating from an entirely on-premise solution with our own DirectLine server to Azure Bot Channels Registration because of the requirement for MS Teams integration.
I am looking to create a Bot integrating the Bot Framework DirectLine API that they offer.
But, I wanted the service to be Cloud Service agnostic. So, the idea is to use the BotFramework capability to start the conversations and persist the conversation cache using the conversation id it generates but the business logic can be on any cloud service (AWS/Google/IBM Cluod) etc.
Is it possible to design the same using the DirectLine API's with out getting bound to using Azure Bot Service?
https://learn.microsoft.com/en-us/azure/bot-service/bot-service-channel-connect-directline?view=azure-bot-service-4.0
https://learn.microsoft.com/bs-latn-ba/azure/bot-service/rest-api/bot-framework-rest-direct-line-3-0-receive-activities?view=azure-bot-service-3.0
The Bot Framework works with bots deployed on any cloud hosting service, as long as you have an internet-accessible endpoint and a valid HTTPS cert.
This issue explains on how you can run your bot on IIS or any other bot hosting service.
One example of an unofficial implementation of directline that does not require Azure is offline-directline. This example sets up a local web server that emulates the DirectLine API and tunnels the requests through to your bot.
With respect to hosting your bot on IIS or any other cloud services, keep in mine that
'The Bot Framework requires that the x.509v3 certificate exposed by your endpoint be current and valid. Most of the checks for "current and valid" are standard checks for server certs: the CN must match the hostname, it must not be expired, it must not be listed in a CRL, it must have the correct set of EKUs, etc.
Most importantly, your cert must chain to a root certificate authority trusted by Microsoft. The latest list of these CAs is available here.'
Note: offline-directline is an unofficial private package and bot framework container support is not officially supported. Refer to this answer on using localized version of Direct Line API with botframework.
Hope this helps.
I am setting up the MS Bot framework service environment in Azure. I was able to successfully set up the channel which connects to single bot service for a single app. Now, we would like to scale this environment globally (all over the world) and we would like to setup multi-region environments. When a user connects from the channel app (MS Team) then they should be able to connect to their nearest Azure region and get the response back. How can we set up the geographic load balancer for Microsoft bot framework web app bot service?
We tried to set up the traffic manager however we have constraint since Microsoft bot channel registration service has Microsoft APP ID (ClientID) and Password and it can only connect to only one messaging endpoint URL
Actual results:
Microsoft Bot channel registration app cannot connect to more than one messaging endpoints of the different region and how can we load balance MS Bot Service.
Expected results:
How can we load balance (latency by region) MS Bot Application?
Sample Scale out diagram
Amit,
Azure bots typically run as Azure App Services. The Azure App Service has built in scaling capabilities. Depending on the pricing tier you select for the App Service, you can scale out to as many as 20 instances. You can go to 100 instances if you're in an 'Isolated' tier. You can also scale up to add memory and cpu. That's some really powerful resources you can bring it to.
I realize that you're trying to reduce latency but I wanted to point the scaling feature out first. You have another challenge I don't think if possible to overcome at this time.
If MS Teams is the only channel you're users will be using, then trying to manage traffic on your own is probably going to be ineffective. You're constraint is going to be where the MS Teams service is located. Teams is what's talking to your bot, not the user directly.
The path is something like this:
User -> MS Teams -> Azure Bot Service -> Azure App Service.
Since you have no control over the Teams to Bot connection, you cant manage the traffic.
You could deploy multiple bots to different regions, then instruct your users to connect to the appropriate regional bot channel in Teams. This isn't an automatic traffic management but would at least provide some of the region support you're looking for.
I have created an BOT with Microsoft BOT Framework and published in local IIS. Now I want to connect that from my web application, So far I found this could be only possible through direct line from azure portal. Is there any other way to do that?
Now I want to connect that from my web application, So far I found this could be only possible through direct line from azure portal. Is there any other way to do that?
In my opinion, the Microsoft BOT Framework application is just a service which provide the bot endpoint. You could host it in anywhere.
If you want to connect to your web application or something else. You need to use a channel to connect the bot with other application. You should register the bot and enable the channel to let your bot work. The Azure provide multiple chanels to register the bot like webchat. You could also build the channel by yourself, but you should think about a lot of things.
More details, you could refer to below answer:
How to connect local hosted Azure BOT from your web application