Bot builder comes with LuisRecognizer and other inbuilt classes that does the work of posting the message and getting back the intents and entities.
like replaceDialog helps to start a new waterfall/closure, is there a way to use in built botbuilder classes to post to Luis and based on the match invoke the respective waterfall sequence?
I tried the following.
session.replaceDialog('/'). This does not seem to invoke the luis recognizer again and therefore dialog.matches are not even invoked.
bot.receive(message). this does not do the luis call nor match the intent for the message well. plus, it also seems to go into a wrong sequence ( parent sequence which invokes bot.receive ) again, by default.
IntentDialog.recognize and intentDialog.invokeAction. recognize fails to recognise the message.
What am I doing wrong? is there a way to reuse botbuilder classes?
I can think of writing a simple rest client to invoke Luis api. but that is the last resort, as the purpose of botbuilder's recognizer and intentdialog classes are exactly the same.
flag setting does the trick. Now the modeller gets invoked on every beginDialog.
dialog = new builder.IntentDialog({
recognizeMode : builder.RecognizeMode.onBegin,
});
Related
Trying to figure out how I can take the intent from LUIS and insert it into the response from the bot. I cannot seem to find the variable/path to this value. I've tried:
#intentName
turn.recognized.intents.intentName
luisResult.intents[0]
The docs are not helping since it just shows java classes, doesn't directly translate to the Composer app afaik.
You can pull the first intent via the following adaptive expression:
${foreach(turn.recognized.intents, x, x.key)[0]}
I am working on designing a lengthy approval system in CRM using a combination of OOB workflows (designed using CRM UI Workflow Designer) and custom actions (actions written using .NET code). Idea is to keep the entire branching/simpler logic in OOB workflow and call custom Actions wherever necessary. However I have few questions with this approach:
How can I handle run-time errors generated in the action code?
For example, one of my Actions contain the code to push data to an external system via web service. In case this web service call fails, I need to perform some steps in the parent workflow.
How can I handle 'if conditions' which can't be handled by 'Check Condition' step? For example, suppose that before performing a certain workflow step I need to check some data which can't be queried within CRM. I can create an Action which will return true/false based on the custom logic which can then be checked in parent workflow.
An alternate approach would be to use plugins but I am inclined towards using OOB functionalities as much as possible. Any inputs would be helpful.
First of all let's clear the semantics, because I'm not sure if you understand what are you talking about - there are Actions (you can refer to them as custom actions, but then you should refer to every workflow you create as custom and I figured out of your post that you are describing them as OOB, which also is semantically wrong - every workflow you create is a custom workflow, maybe it's using OOB steps, but that's a different story) and Custom Workflow Activities. I'm assuming that you want to use Custom Workflow Activities, because the are more suited for what you are trying to achieve here. Also you tagged your question as CRM 2011 and CRM 2013 - not sure what you meant, because Actions were not available for CRM 2011.
So basically Custom Workflow Activities can have Input and Output parameters. Output parameters are answer to both your questions, because you can use them to get the error message after your custom processing or use then in conditional statements later in your workflow. Output parameters can be defined like that:
[Output("Error message")]
public OutArgument<string> ErrorMessage { get; set; }
You can find more examples here:
https://technet.microsoft.com/en-us/library/gg327842.aspx
You can of course set this properties simply by calling
ErrorMessage.Set(executionContext, messageText)
So now when you define your workflow, wherever you need something not configurable in OOB blocks, you can put your Custom block, after it's done simply check it's output for the error (this is just an example, you can pimp it up by adding additional output parameters, to make it more generic), if it's empty then do something, if not then do something else for example send email with the error message. It all depends on what are you trying to achieve.
Actions are serving different purposes, they are useful to create a logic that can be easily called through plugin or javascript (webAPI) and allows you to also put a plugin on it alongside doing everything within one transaction. Maybe it will be useful somewhere in your workflow, but as far as I remember in CRM 2013 actions could not be called from a workflow...
UPDATE:
Ok so if we are dealing with CRM 2016, we can call Action from a workflow. What is best in this situation really depends on the scenario and what we are trying to achieve, but to make it easier to decide let me highlight main differences:
1) Activities are simply a blocks of code that can be put inside your workflow. Actions by themself are not code, they are custom Messages that you can call. Of course you can register a plugin on this custom Message and do there any custom logic you want, but this is another step to take
2) Actions can be run in transaction, Activities not (but you can run Activities inside Actions, so in this case they can run in transaction)
3) Actions can be called directly from Javascript, plugins and workflows. It's a great thing, but if you will make let's say 10 custom Actions which you will be using ONLY inside you one workflow, they will be visible when you will be registering plugins (and also any js developer will be able to call them with JS)
So basically Actions are a big, fat feature that can serve many purposes (including running Activities on their own!), Activities are much simpler but in your case they will also do their job. So you should ask yourself questions:
Do I need my logic to run inside transaction?
And
Do I need to call this logic somewhere else than my workflow?
If you have any "Yes" then go for Actions, of no, then go for Activities, because you will be overcomplicating things without any good reason.
Dialog can do almost everything according to the bot framework documentation, but it will take a lot more time to investigate than FormFlow. I failed to find a place that have lots of samples of bot framework yet. At the moment, before I spend a lot of time to try dialog, anyone know if it's possible to chain commands using FormFlow.
The work I am trying to do is to code a chain of commands:
query records
select a record from the results
actions/operations on the record
etc...
Really appreciate if anyone familiar with Bot Framework can help me on this.
Use the IDialogStack.Call method in your FormFlow handlers to call another dialog and push it on the stack.
Then use the IDialogStack.Done method to pop it off the stack. Both described here.
I'm trying to build my Parse iOS project in a way that'll be more easy to migrate later on for the client should he desire it.
To that end, I'm trying to use the REST API instead of relying on PFUser and PFObjects.
But I love the PFLoginViewController-- it's such a time saver. Is there a way I can use that pre-built login/sign-up flow with the REST API instead of PFUser?
I don't think that u could use it without PFUser but u could create similar to that and time will be consumed.
Still One thing might work out, check this link and I hope you have already but this will show how to integrate the PFLoginViewcontroller so in that they have logInView which will provide you access to all component like loginButton, usernameTextField, passTextField and etc. So you could access to these component your own explicit component.
Like, you could create your own UIButton(namely, logInBtn with action selector and all) then access it to logInView.LogInButton = logInBtn(your own button) and in this button's action you could make Rest api calls for login, and similarly for other component which needs to be modified for your requirement.
I'm using the latest ASP.Net WebAPI Nightly builds (dated 2013-01-16).
I have a simple EF database first model at the moment that has two entities - Patients and Visits. Each patient can have many visits.
I'd like to be able to query for my list of patients and have the visits entities for each patient returned inline. I know that WebAPI's OData implementation doesn't yet support $expand. I'm hoping that just means that optional client-controlled expansion is not supported and that I can force expansion server-side.
At the moment I'm not getting any of the visits inline.
For example, my PatientController's() Get() method looks like
[Queryable(AllowedQueryOptions=AllowedQueryOptions.Supported)]
public override IQueryable<Patient> Get()
{
var query = this.entities.Patients.Include("Visits");
return query;
}
I've verified that the query executing against my database does indeed include the visit information.
To use a publicly available OData service as an example, if you use the service at http://services.odata.org/OData/OData.svc/, you can get a list of Suppliers. This is http://http://services.odata.org/OData/OData.svc/Suppliers.
You can also ask for a list of suppliers that includes the list of products using http://http://services.odata.org/OData/OData.svc/Suppliers?$expand=Products
Stepping through the ASP.NET code (via the symbols server) I've got to the System.Web.Http.OData.Formatter.Serialization.ODataEntityTypeSerializer and can see that it's CreatePropertyBag method, which builds up the list of properties to be serialized, just doesn't include the navigation properties, and they don't seem to be enumerated anywhere else apart from being written out as NavigationLinks.
I'm quite new to the ASP.NET world in general and have spent a week or so getting my head around the way things work (particularly with the changes made to OData at the end of 2012 and further changes made so far in 2013).
I suspect that if the ODataEntityTypeSerializer was to be modified (I'm happy to try) to embed this extra information in the appropriate spot (within each navigation link as an nested inline feed as best I can tell) then I'd be set.
Questions:
Have I overlooked something obvious and there's a flag I can set to turn on this behaviour? I can see why, if such a flag exists, it would be off by default (EF lazy loading and this flag wouldn't get on well)
If #1 is no, is there some other ODataEntityTypeSerializer that I could use? If so, how do I switch to it?
If #2 is no, any pointers for where I should start writing my own? Is there a place I can substitute in my own serializer or do I have to maintain my own fork of ASP.NET's Extensions project (as opposed to the Runtime project)
Thanks very much!
$expand is very high on our list of things to support for OData. But as far as I know, we don't have any flag to turn it on server-side. The formatter doesn't currently allow you to substitute your own serializers either. So I'm afraid your only option in the meantime is to create a fork and add support for $expand. If you manage to get it working, please consider sending a pull request our way:
http://aspnetwebstack.codeplex.com/SourceControl/network
You can try it already in webapi nightly builds.
Here is how to install it with nuget:
http://aspnetwebstack.codeplex.com/wikipage?title=Use%20Nightly%20Builds