I am working on a small project with LUIS integration. I am using the using Microsoft.Bot.Builder.Luis namespace for communication with the api. i was inspecting all intents i got back but since last week i only get back one intent per luis-call. Is there any (by me) unseen change to the verbose mode i did not get? Is there a way to still call for all intentresults or giving the luismodel some kind of settings on its way to the server?
i did not change any settings on luis.ai and i was wondering why this happens. Thanks in advance!
meq
This worked for me. In the LuisRecognizer constructor there is an optional parameter with a flag called IncludeAllIntents. Just set it to true and add it to the constructor.
var luisApplication = new LuisApplication(
configuration["LuisAppId"],
configuration["LuisAPIKey"],
"https://" + configuration["LuisAPIHostName"]);
var predictionOptions = new LuisPredictionOptions();
predictionOptions.IncludeAllIntents = true;
_recognizer = new LuisRecognizer(luisApplication, predictionOptions);
Generally, LUIS still returns an array of intents with the result set so there must be something specific going on with your model.
If further experiments don't determine the cause, contact us at luservice#microsoft.com with your LUIS App Id and we can investigate.
I am assuming you are using LuisDialog, you need to set Verbose = true to get all the intents.
public RootLuisDialog() : base(new LuisService(new LuisModelAttribute(
Settings.Default.LuisAppId,
Settings.Default.LuisAPIKey,
domain: Settings.Default.LuisAPIHostName
)
{
Verbose =true,
Log = true
}))
{
}
Related
I figured I'd upgrade my LuisRecognizer to use LuisRecognizerOptionsV3. However I can't seem to set prediction options the way I like - how do I set the timezone? The v3 prediction options lack this field.
In my bot I am currently doing:
var predictionOptions = new LuisPredictionOptions();
predictionOptions.TimezoneOffset = turnContext.Activity.LocalTimestamp.Value.Offset.TotalMinutes;
and I can't figure out the equivalent in v3's version of the data structure.
The timezoneOffset parameter was mostly provided as a way to determine what day it is for the user in case they say something like "today" or "tomorrow." It also helps when the user enters a relative time like "in three hours." When using the timezoneOffset parameter, the returned entity is in the provided timezone rather than universal time.
In LUIS v3, instead of providing an offset you provide a DateTime reference and LUIS uses that to process relative time. You can see that documented here. Note that the datetimeReference property is only available in POST requests and not GET requests because you provide it in the request body and not as a query parameter.
Also note that the datetimeReference property is not currently available in the Bot Builder SDK. You can write your own code to access the LUIS API directly with an HttpClient, but if you'd still like a prebuilt SDK to handle things then you can use this NuGet package: Microsoft.Azure.CognitiveServices.Language.LUIS.Runtime 3.0.0
Here's an example of how to use it:
var appId = new Guid("<LUIS APP ID>");
var client = new LUISRuntimeClient(new ApiKeyServiceClientCredentials("<SERVICE KEY>"));
client.Endpoint = "https://westus2.api.cognitive.microsoft.com";
var options = new PredictionRequestOptions(activity.LocalTimestamp.Value.DateTime);
var request = new PredictionRequest("Book a flight in three hours", options);
var response = await client.Prediction.GetSlotPredictionAsync(appId, "PRODUCTION", request);
Console.WriteLine(JsonConvert.SerializeObject(response.Prediction.Entities, Formatting.Indented));
I am attempting to update the tags of an installation within Azure Notification Hub after registration. I am following several guides for this, notably here and here.
Both of these guides suggest that the following code should work however it is plainly not; the tag never gets updated. There are no errors, and I can guarantee that the installationId is correct. I am guessing I am setting the path/value of the tag incorrectly.
// in constructor:
var _notificationHub = NotificationHubClient.CreateClientFromConnectionString(Settings.ConnectionStrings.NotificationHub, Settings.Defaults.NotificationHubName);
// in WebApi endpoint:
var installationUpdates = new List<PartialUpdateOperation>();
var userDetail = _userDetailRepo.Get(id);
installationUpdates.Add(new PartialUpdateOperation
{
Operation = UpdateOperationType.Replace,
Path = "/tags/interestedin", // is this incorrect?
Value = interestedIn.ToUpper()
});
userDetail.InterestedIn = interestedIn;
await Task.WhenAll(
_userDetailRepo.InsertOrReplace(userDetail),
_notificationHub.PatchInstallationAsync(installationId, installationUpdates));
Here is the installation object's tags, as per VS:
I also tried hardcoding the path to Path = "/tags/interestedin:W" but it made no difference.
Can someone tell me if I am doing something wrong here, and if so how I should amend my code. Thanks.
Unfortunately, Path = "/tags/interestedin" is not going to work as of now. We are currently working on wildcards' support. Once it is done, something like "/tags/interestedin*" will work fine for you.
While Path = "/tags/interestedin:W" should be OK. If you could provide namespace name, hub name, and a timeframe, then I'll take a look at logs to check what is going on there.
I am having a problem with the ExpandDynamicLinks in Sitecore.
I am using the following method passing true for siteResolving. The problem is the site is not being resolved as promissed.
bodyExpandedLinks = Sitecore.Links.LinkManager.ExpandDynamicLinks(email.Body.Value, true);
I did set in my provider to never resolve the site because that is what I want for the whole site except for this email body above.
alwaysIncludeServerUrl="false"
Does anybody know how to force that?
Thank you...
I know this post is tagged with sitecore7, but I would like to share a solution for Sitecore 8.1. I don't know if it works for 7 or not. It is adapted from Sitecore.Links.LinkProvider.ExpandDynamicLinks():
var linkParser = new LinkProvider.LinkParser();
var urlOptions = LinkManager.Provider.GetDefaultUrlOptions(); // returns a clone.
urlOptions.SiteResolving = true;
urlOptions.AlwaysIncludeServerUrl = true;
text = linkParser.ExpandDynamicLinks(text, urlOptions);
This does not work for media links because Sitecore.Links.DynamicLink.BuildMediaUrl() and Sitecore.Links.MediaLinkExpander.Expand() completely ignore their UrlOptions parameter. If you need full media urls, wrap your code with this:
using (new SettingsSwitcher("Media.AlwaysIncludeServerUrl", "true"))
{
phrase = linkParser.ExpandDynamicLinks(phrase, urlOptions);
}
one option might be to check if AlwaysIncludeServerUrl is set to False before your call to ExpandDynamicLinks. If it's False you can explicitly call Sitecore.Links.UrlOptions.DefaultOptions.AlwaysIncludeServerUrl = true and then set it back to False after you have called ExpandDynamicLinks.
I found an alternative method.
I did add a extra link provider, with the same configurations but the alwaysIncludeServerUrl which I set to true.
<add name="sitecore_expandlinks" alwaysIncludeServerUrl="true" (...) >
Then I got the provider using the API.
bodyExpandedLinks = Sitecore.Links.LinkManager.Providers["sitecore_expandlinks"].ExpandDynamicLinks(email.Body.Value, true);
If someone else has a more cohesive option I would much appreciate
Thanks.
I am attempting to perform some basic integration using Acumatica's web services. Unfortunatly, I'm having problems logging in. According to their documentation, this process should look something like:
apitest.Screen context = new apitest.Screen();
context.CookieContainer = new System.Net.CookieContainer();
context.AllowAutoRedirect = true;
context.EnableDecompression = true;
context.Timeout = 1000000;
context.Url = "http://localhost/WebAPIVirtual/Soap/APITEST.asmx";
LoginResult result = context.Login("admin", "E618");
Simple enough. However, after creating and importing a WSDL file from Acumatica into Visual Studio, I found I don't have a Screen object. I do, however have a ScreenSoapClient object, which has a similar Login() method.
ScreenSoapClient context = new Acumatica.ScreenSoapClient("ScreenSoap");
LoginResult result = context.Login("username", "password");
That part works. In fact, the LoginResult give me a session ID. However, if I try to make any calls to the service, such as:
CR401000Content cr401000 = context.CR401000GetSchema();
I get an error: System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> PX.Data.PXNotLoggedInException: Error #185: You are not currently logged in.
While the version of Acumatica we're using does appear to be slightly newer, I'm unsure why the Screen() object isn't available. Consequently, if I try a bad username/password, Login() does fail (as it should). From what I can the tell, the ScreenSoapClient class is using service model details from web.config, so it's getting the endpoint address and other details there.
Is there something I'm missing or doing wrong?
As i see, you use WCF to create your service reference.
So you should enable cookies in service binding:
var binding = new BasicHttpBinding()
{
AllowCookies = true
};
var address = new EndpointAddress("http://localhost/WebAPIVirtual/Soap/APITEST.asmx");
var c = new ServiceReference1.ScreenSoapClient(binding, address);
Or, you can use old asmx web service reference (http://msdn.microsoft.com/en-us/library/bb628649.aspx).
Then everything will be same as in Acumatica`s documentation.
As noted in a comment above, I was able to make contact with a representative from Acumatica. He had me remove then recreate the service references in our project and try again. That apparently did the trick and the "Error #185: You are not currently logged in" error went away.
Problem:
We've upgraded the AD server from 2003 to 2008 and due to some "bad code", where developer has coded in such a way that, he directly casts "badPwdCount" property value to INT and it blows up because of NULL value conversion - NULL reference exception - NULL cannot be converted to INT.
Bigger problem:
We cannot do a deployment at this point because there are over 100 individual apps that depended on this change and we're looking for a least involved way of dealing with it for now.
Background:
Now the way this "badPwdCount" property works is, that when user logs on to the domain, it will get set to zero, otherwise it's NULL. The problem is that none of these users are ever going to log on interactively because they're external and we authenticate them via API and they cannot log in using the API either..
Question:
Does anyone know if this value is in the registry or somewhere, where I can get to it and set it to zero? Was also thinking of initiating a log in per user via a script, but wanted to gather other ideas too...
MSDN page for badPwdCount:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms675244(v=vs.85).aspx
Normally this would be easy, all you would need to do is update all the users in active directory and set the value to 0 if it is null. There are various ways you could do this, for example a script or code, or a bulk update tool.
In this case, badPwdCount is a special property that is not replicated (i.e. it is different for each domain controller) and so far as I can tell, there is no way to update it manually or by script, however, I think I have a solution for you.
You should be able to easily trigger a single failed login for every user in active directory against each domain controller, causing the value to be incremented.
Since you tagged your post with C#, here is some C# code that will do the trick for you:
using System.DirectoryServices.AccountManagement;
using System.DirectoryServices.ActiveDirectory;
...
using (Domain domain = Domain.GetComputerDomain())
{
foreach (DomainController domainController in domain.DomainControllers)
{
using (PrincipalContext context = new PrincipalContext(ContextType.Domain, domainController.Name))
using (UserPrincipal userPrincipal = new UserPrincipal(context))
using (PrincipalSearcher searcher = new PrincipalSearcher(userPrincipal))
using (PrincipalSearchResult<Principal> results = searcher.FindAll())
{
foreach (UserPrincipal user in results.OfType<UserPrincipal>())
{
context.ValidateCredentials(user.SamAccountName, "THEREISNOWAYTHISISTHECORRECTPASSWORD");
}
}
}
}
PS. If this screws up your AD I take no responsibility for it!