Why BotFramework Emulator needs ngrok to connect to bots hosted on Azure Web App Service - botframework

I am trying to use the BOT simulator to connect and test my Bot SDK application that I've deployed to Azure App Service.
When I run the bot web api propject locally, I can test it with the simulator no problem.
However, when I try to test the same application that is hosted remoely, the simulator fails. After investigation, I found that the simulator needs ngork to be able to connect to bot service that are hosted remotely
https://github.com/Microsoft/BotFramework-Emulator/wiki/Getting-Started#connecting-to-bots-hosted-remotely
If your bot is hosted remotely, ensure that ngrok tunneling software
is installed and configured. The Bot Framework Emulator is tightly
integrated with ngrok and can launch it for you when needed.
The matter has confused others and they asked questions here:
https://github.com/Microsoft/BotFramework-Emulator/wiki/Getting-Started#connect-to-a-bot-hosted-remotely
Why the simultor has dependance on ngork to connect to remotely hosted bots? It seem conter intuitive since the dns name is publicly available

When you're running the emulator locally and debugging in the cloud, you need to be set up for traffic to flow bi-directionally. By default without NGROK you can post to your bot, but for it to POST back to your client, it needs an IP address to post to. NGROK provides that without you having to set up local ports, etc.

Related

Testing issue with LUIS bot on Bot framework emulator

I am following this guide to develop chatbot:
https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-howto-v4-luis?view=azure-bot-service-4.0&tabs=csharp#test-the-bot
When I tried to test the bot with Bot Framework Emulator, I am unable to get a response.
[15:17:43]Emulator listening on http://[::]:60595
[15:17:43]ngrok not configured (only needed when connecting to remotely hosted bots)
[15:17:43]Connecting to bots hosted remotely
[15:17:43]Edit ngrok settings
[15:17:43]-> conversationUpdate
[15:17:44]POST500directline/conversations/<conversationId>/activities
[15:17:51]-> messagehi
[15:17:51]POST500directline/conversations/<conversationId>/activities
Is this have to do with my company security blocking ngrok?
My Echo bot works fine, but seems like I am having issue with the LUIS function. Is there a way to make it work and link it to MS teams?
Help needed

Using botframework emulator or bots hosted remotely without internet connectivity

I am trying to test my bot. It is hosted remotely but on a server that has no internet connectivity but is reachable within the LAN. I want to use the Botframework emulator to test. The emulator relies on ngrok. But I have two restrictions :
1) I cannot install ngrok on my corporate machine.
2) Even if I somehow managed to cut through the red tape and install ngrok , without internet connectivity on the server that hosts my bot, the responses would still not reach my emulator.
How can I use a service url that hits my emulator directly without using ngrok ?
First, ngrok is only necessary for connecting to bots hosted remotely. If you are looking to run everything locally on the closed server, then ngrok is not required.
With regards to options, you have a couple that may work for you.
One, you can look at utilizing offline-directline. This option allows you to generate a token locally without having to connect to the public direct line offering on Azure. Be aware that this npm package is configured for the v3 "BotChat" web chat tool. So, utilizing this will require your modifying the configuration to work with the newer v4 Web Chat (not to be confused with the v3/v4 SDKs).
Two, consider using this Browser Bot sample, located here, from the Botbuilder-Samples GitHub repo. In this instance, the bot and web chat adapters are fully contained within the browser and, as such, do not require a connection to direct line to run. The bot adapter uses the v4 Node SDK while the web chat adapter uses the v4 React-based implementation.
Hope of help!

Publishing and debugging Microsoft Bot Service

I have developed a bot that works perfectly on my local machine and accessible through all channels via ngrok.
However, the Bot doesn’t work on its deployed Azure url which is https://mybot.azurewebsites.com/api/messages A test with the webchat or bot emulator returns an error 500 without further information on exact cause of the issue. How would I debug so that I can find out more information on what's causing the breakdown?

Debugging Azure Mobile Service Authentication

I'm new to azure mobile services development and any help will be greatly appreciated.
I have created sample mobile service application and could successfully launch and debug it locally. As a next step I've added google authentication. Everything works fine when the service is Published and running in the cloud. But, I could not make the service to run locally so that I can debug the service for cases when the user is authenticated.
So for I have wrestled with IIS Express and made it work with HTTPS on port 44300. But Google authentication services complained because of redirect URLs mismatch, even though I've added https://localhost:44300/signin-google to redirect list.
I feel like I'm not doing something correct here. Something does not make me believe that debugging locally is not possible.
Thanks,
Ruben
Is possible to debug in localhost, but the google/facebook/Microsoft authentication should not be tested, because it is provided out-of-the-box by Azure Mobile Service team.
you should configure it in Azure Portal and then you should implement it in your application like documentation provides.
The following resources has the references to the Authentication articles:
Azure Mobile Services for Client Apps

Debugging a Windows CE application which uses a Microsoft Azure service

This question has probably less to do with actual programming and more to do with environment setup.
I'm developing an application for a Windows CE device, which will use a service hosted in Microsoft Azure. Obviously, this is all under development, and the service itself has not yet been uploaded to Azure. So I'm using the emulators provided by MS to deploy the service locally. Also, I don't think uploading the service to Azure just to debug it is a good idea, as that could net us a bill for Azure we don't yet want to pay.
Also, please note, I'm using VS2008 for the Windows CE project and VS2010 for the Azure project (thank you MS for dropping support for mobile devices -_-).
The problem is, the service seems to be accessible only via 127.0.0.1 or localhost, and if I physically connect a Windows CE device or use an emulated one, it becomes a new entity on the network, and cannot access that service any more.
How can I debug my Window CE application and have it see the service, whilst still being able to debug the service itself?
You are correct, the development fabric (the compute emulator that allows you to build an azure application and debug it locally) is only meant for local development. There are some hacks that allow you to get around that, but I wouldn't recommend it.
My recommendation would be to spin up the service in a more traditional hosting environment, at least in these early stages. You can define it as a web app just as you always would have, and get it functioning. Then, when you know its mostly complete, create a cloud service project and do an add existing to bring your web app into the cloud service solution. Once in, its a simple matter to add the web app as a web role.
From there, you can complete testing of the service in both the local and hosted azure environments as needed. This allows you to minimize your development costs while still leveraging the power of the cloud. As an upside, you also have done most of the basic work to ensure your service is compatible with multiple deployment scenarios giving you a greater degree of choice for its final production state.
OK, I don't know if this was intentional, or if I found one of the mentioned hacks, but I saw that IIS hosts the Azure site I created on port 5100, and the binding for this site is *, so it accepts all connections.
Using this I could access the service from my emulator, and I could still debug all Azure related stuff.

Resources