I added an authoring resource in the Luis Portal and imported a few apps. The added authoring resource appeared both in the Azure portal and the Luis portal initially. Then suddenly the resource disappeared in the Luis portal and now I am unable to select the resource using the drop down in the Apps page as it is no longer showing in there. (screenshot below) What is going on? The resource still shows up in the Azure portal. I tried logging out and in and refreshing the page multiple times.
I have faced this issue myself in the past - the solution was to make sure you are using the correct LUIS portal that matches the data centre you deployed your LUIS resources in:
westus: https://www.luis.ai/
westeurope: https://eu.luis.ai/
australiaeast: https://au.luis.ai/
This is documented here: https://learn.microsoft.com/en-us/azure/cognitive-services/luis/luis-reference-regions
Related
I am using C# SDK to create the LUIS apps with required Intents, Utterances and Entities, and then training and Publishing the apps using an Authoring key created in Azure portal. After this, I use the REST Prediction endpoint for Intent matching, and till now I used the free Starter Prediction Key. After a month since the Starter key gets expired, I created a Cognitive service in Azure to be used as the Prediction resource. Now, how to add this new Prediction resource(Cognitive service) to my LUIS apps via SDK or REST? I am able to do so from LUIS Portal though, but don't want manual intervention.
Once you create the prediction endpoint resource, the resource should be only used for endpoint prediction queries and not for authoring changes to the app. If you want to add the prediction resource to your app by not going through the portal and automate the assignment of the resource to a LUIS app for purposes like CI/CD pipeline, then you can follow the steps below:
Get an Azure Resource Manager token from this website. This token does expire so use it immediately. The request returns an Azure Resource Manager token.
Use the token to request the LUIS runtime resources across subscriptions, from the Get LUIS azure accounts API, which your user account has access to.
This POST API requires the following settings:
This API returns an array of JSON objects of your LUIS subscriptions including subscription ID, resource group, and resource name, returned as account name. Find the one item in the array that is the LUIS resource to assign to the LUIS app.
Assign the token to the LUIS resource with the Assign a LUIS azure accounts to an application API.
This POST API requires the following settings:
When this API is successful, it returns a 201 - created status.
Hope this helps.
Thanks, accepted. The only issue being, since I am doing every thing using SDK, it takes a lot of API calls to get things done. I mean to solve this, first I am generating a Token and then calling this API. A simple add default "Prediction Resource" for all apps on LUIS portal would have helped a lot. Anyways, thanks for this answer. – user3868541 Feb 3 at 9:45
Agreed that an Add default Prediction Resource would have made everything much better. I'm still not sure how to do this programmatically. I'm trying to do it in my service using the SDK
I have a LUIS api app id and key defined in my current project when I try to find this service in LUIS.AI its not visible. But when I test using LUIS API 2.0 console swagger, i can see response as successful. But my question is, I want to train and build using LUIS.AI website. I want to see list of intents present in my luis service and improve it accordingly. Please help me out.
You're likely visiting the wrong LUIS URL for your authoring region. For example, if you author your apps in westeurope, you need to visit eu.luis.ai and not www.luis.ai
If that still doesn't work, try using another browser. For me, strangely the app eventually disappeared from Chrome, but when I tried in Edge, it appears.
Looking into building some Gsuite Marketplace apps, but we have having issues at the publish time already.
Publishing an app following these steps makes the app to be accessible from the Chrome Marketplace.
(e.g. https://chrome.google.com/webstore/detail/qwertzuiopasdfghjkl/publish-accepted)
Using Chrome web store app link (e.g. https://chrome.google.com/webstore/detail/app-name/qwertzuiopasdfghjkl)
redirects to a Gsuite link (e.g. https://gsuite.google.com/marketplace/app/qwertzuiopasdfghjkl?pann=cwsdp&hl=en-US) but brings a 404 page.
Waiting seems to do the job (url works after a couple of days - approval)
Changing app type from "Private" to "Unlisted" break it completely; even waiting up to a week, the link never works again.
My questions are:
How do you switch between "Visibility options" without breaking your
app?
How do you guys deal with updating publishing apps on Gsuite
Marketplace and keep it working?
Cheers!
Every new update requires a new installation. So everytime you make changes whether feature or visibility settings, treat it as if you were uploading a new app.
If you change the visibility, it will undergo a review process as if it were a new app.
Users who have already installed your app will still be able to use it.
I have created a bot service app in Azure that works fine when I create it. I go through the Microsoft App ID, password screen and it loads the chat emulator and code in browser (using the LUIS template and node.js language). After sometime, if I go back to load that app service from Azure dashboard, it keeps giving me "An Internal error occurred at the server" error message. I am not sure if I shouldn't be going to the newly created Bot Service from dashboard? I did this 3-4 times already, with new names, new RG etc., it's the same issue every time.
Thanks
Unfortunately this looks like a bug, there are are two open issues right now on the SDK's repo that look very similar to yours. Here is one of them; 'InternalServerError - Bot & QnA Maker'.
Regarding the downvote, it might be because there isn't a screenshot of the issue which usually helps in answering questions. Also, explaining the steps you undertook or compared against would have helped give a clearer picture for the community to answer.
We are in the process of creating our new app for v2 of the apps marketplace. Recently we have run into quite a major issue and we are having a lot of trouble resolving it.
We are testing the workflow where a domain admin installs via the chrome webstore listing. The actual installation of the app works, insofar as the app is installed on the domain and the scopes appear to be granted when looking at the "Manage API client access" section in the domain admin panel (http://i.stack.imgur.com/a63nv.png).
However, when we attempt to use the service account to get calendar or contacts info, we are getting "Requested client not authorized" errors.
{
"error" : "access_denied",
"error_description" : "Requested client not authorized."
}
However, if we manually add our service account + scopes to the domain in question, then accessing the data programmatically works fine (http://i.stack.imgur.com/g6pRg.png).
So, clearly we are missing something here, with how installing a marketplace app via the chrome web store is supposed to work.
Other things to note:
Chrome webstore listing is marked as unlisted.
New marketplace app is not approved (obviously) as the tester received this specific error when attempting to install the marketplace app.
We got it figured out. The issue was in how we declared our contacts API scope in the marketplace sdk setup screen.
In the marketplace setup screen, we declared using the contacts scope without a trailing slash ("https://www.google.com/m8/feeds").
However in our app, we were sending oauth requests for the calendar feed with the slash at the end. ("https://www.google.com/m8/feeds/"). This mismatch caused the whole request to fail with the error message above.
If anyone runs into this and is baffled at why their service account requests are failing, make sure you are consistent with your slashes at the end!
I would suggest to Google that you should update the marketplace sdk screen to also be consistent and reject scopes that do not have a slash at the end. That would have saved us days of frustration.