I build a bot using bot composer. After deployment, I able to see some exceptions in Application insights regarding System.Collections.Generic.KeyNotFoundException , These are the Outer message :
No adapter registered and enabled for route jsonws.
No adapter registered and enabled for route index.html.
No adapter registered and enabled for route swagger.json.
No adapter registered and enabled for route swagger.yaml.
No adapter registered and enabled for route swagger-resources.
No adapter registered and enabled for route swagger_doc.json.
How to fix this exception ?
New to Azure bot.. Any help would be appreciated, Thanks!
Related
I created a bot, deployed it on azure via GitHub actions and tested in the emulator, everything works fine, but when i try to connect the channel "Webchat" i keep receive errors like
There was an error sending this message to your bot: HTTP status code GatewayTimeout
There was an error sending this message to your bot: HTTP status code Unauthorized
There was an error sending this message to your bot: HTTP status code BadGateway
but it kinda changes randomly without me changing anything. Of course i set messaging endpoint in the Configuration tab (The same as i was testing in the emulator, https://appservicename.azurewebsites.net/api/messages) and the check for Enable Streaming Endpoint.
The question is: how to i fix this or how can i even find a solution when the errors are not always the same?
UPDATE More info: I made my app from basic code, i have my
const adapter = new BotFrameworkAdapter({
appId: process.env.MicrosoftAppId,
appPassword: process.env.MicrosoftAppPassword
});
ID is taken in Azure Bot Configuration Tab.
Password is created in App Secrets Key Vault, manually created under Secrets.
What im doing wrong?
According to this MSFT documentation, this can happen if you use a self-signed certificate.
If the chat window indicates one or more errors, click the error(s) for additional information. Among the most common issues are:
The bot's endpoint is specified incorrectly in the emulator settings. Ensure that the URL contains the correct port number and the correct path at the end of the URL.
A bot endpoint that starts with https is specified in the emulator settings. The endpoint on localhost should start with http.
The Microsoft App ID field and/or the Microsoft App Password fields in the emulator settings do not contain valid values. Both fields should be filled in, with each field containing the corresponding data.
Security has not been enabled for the bot. Verify that the bot configuration settings specify values for both app ID and password.
Also, try modifying the App Service's Protocol Setting. If you used Bot Composer to deploy your bot, you'll notice two App Services in the resource group: one with a 'qna' suffix and the other without. Choose the one that does not end in 'qna.'
Select the App Service --> TLS/SSL settings --> HTTPS Only --> On
References - Ref1, Ref2, Ref3.
The Microsoft documentation states:
Provide a notification endpoint URL: In the Notification Endpoint URL
box, provide an HTTPS Webhook endpoint to receive notifications about
all CRUD operations on managed application instances of this plan
version.
I created a simple Logic App and copied the HTTP endpoint into my MPN App Plan under the
It looks like this and has the sig at the end:
https://prod-08.australiaeast.logic.azure.com:443/workflows/fe287d1b9a8c48619a1b44765dad6dc7/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=C9JYfNPjvq-efsLwW66A4K4zTgx6qxGT1oH0RZZRsI0
To test it I hit it with PostMan and confirm that it is getting an HTTP200 as per the MS Docs.
I publish the app to the marketplace:
(you can see the app live here - https://azuremarketplace.microsoft.com/en-us/marketplace/apps/data-drivenai1581501556049.cloudmonitor-analytics-engine)
However - the endpoint never gets called at all. I can see in the logs that no attempt (failed or past) has been made to call it.
I raised a Microsoft Support Ticket and asked a Technical Specialist, however no one can tell me how to debug it or why it is not calling back on installs or failed installs.
Has anyone seen this working?
Update
I found out that each PLAN has a GUID that is automatically used for deployment. Mine is "pid-34881ea9-xxxx--xxxx-xxxx-2cf731e06ef7-partnercenter" - should I be putting this on the callback notification URL as sig=ThisGUID?
In the example for Managed apps with notifications, it shows that managed applications will send a post to https://{your_endpoint_URI}/resource. Can you try adding /resource to your listener and see if it triggers your logic app? I believe that should fix this.
I'm new to Azure. I had published a bot (developed locally) to Azure, e.g. named MyBot. It was shown as web service. Then I had created a bot channel registration on Azure e.g. named MyRegistration. As instructed, I wrote down the AppID and client secrete value from MyRegistration. In My Registration->settings, I put https://MyBot.azurewebsites.net/api/messages to the messaging endpoint. In MyBot->Configureation->Application settings, I added "MicrosoftAppId" and "MicrosoftAppPassword" and their values. I turned on "Web sockets" in MyBot->Configureation->General settings. I saved all the changes.
When I run "Test in Web Chat" in MyRegistration, nothing happened. In MyRegistration->Channels, there was "Issues" saying "There was an error sending this message to your bot: HTTP status code InternalServerError".
Can anybody help to point to what the reasons of failure were? Thank you very much.
Not sure the root reason, but I deployed my bot and go through this process but everything works perfectly for me. This is my steps below:
Deploy my bot service to Azure as a web app.
Create a Bot Channels registration, config my bot-message endpoint and Note Microsoft App ID:
Create a new secret, and note its value by clicking "Manage" Link:
Go to app service, and config App ID and App Password
Back to bot channel and have a web test. everything works as excepted:
I am in the process of evaluating HONO for IOT stack. We have scenarios where an intermediary device would send telemetry data for other devices. Communication through an Intermediary device is referred as a Gateway in Hono. I have found how to send messages through Gateways.
I am not sure on the following queries.
How to register the Gateway? Should it be registered as an ordinary device or anything else should eb done?
How would Hono verify if the message is indeed sent from the device whose device ID is specified? Any option to authenticate the real sender of the message?
Yes, a gateway needs to be registered as a normal device with its own device ID and credentials.
In order for a gateway to be allowed to publish data on behalf of another device, that other device needs to have its via registration property be set to include the gateway's device ID. Example: your gateway device has ID GW1 and you have a device with ID DEV1. Then the registration information for the device should look like this:
{
"via": [ "DEV1" ],
...
}
When the gateway then connects to the adapter and is successfully authenticated, it can publish data on behalf of another device by means of indicating the device ID in the URI, topic, address as described by the user guides of the adapters. The adapters then verify, if the gateway ID is listed in the device's registration information's via property and if not, rejects the data. The adapter thus delegates authentication of the device to the gateway.
Each time that a new device connects to an IoT agent, the IoT agent sends an updateContext to the context broker and a new context entity is created. And if this device has some lazy attribute the IoT agent will send a contextentityRegistration in order to create a context registration, to indicate to the context broker how can connect to the device.
But when the Context Registration is created, I'm not sure about the value that will be assigned to the providingApplication attribute.
It is used the ip:port of the IoT agent where it listens to the context broker requests?
or should it be the URL of the device?
Although I'm not sure, I believe the correct one it's the first option, because the device normally won't understand the NGSI protocol, and the IoT agent should translate the request before sending it to the device. If that's the case, then:
It is necessary some initial configuration, or when the IoT agent creates a new context Registration automatically establishes itself as the context provider?
Regarding the property "commands" used when a new device is registered by the IoT agent, what's their functionality? Are they used by the IoT agent to translate any request from the context broker addressed to the device?
Thanks in advance, any help would be grateful.
2) The property "commands" is used to define attributes of the ContextBroker entity that will actually tirgger a command to the device if they are updated using the NGSI API. This means tahta developers are able to read observations and also send commands just using one API (NGSI) with no knowledge of the specific device technology or protocol.
1) In UL2.0 lazy attributes are not supported so far. Please refer to the other IoT Agents for that.
Normally the IoT Agent IP:Port should be used for that.
Cheers,