How to perform slot validation in an intent using backend code (webhook).
I have seen how to perform slot filling using the webhooks but I want to know how to validate the slot data and re-prompt the user if validation fails.
Example:
User: I want to know the your services in London.
Bot: We do not provide service in London, please enter some other city name.
In short: If validation fails, reset the dialog contexts, trigger your intent again, and optionally use default values to keep other parameters that were actually valid (so you don't need to re-prompt the user for those again).
You don't need to declare an incoming context on that intent to achieve this. Note that you can use contexts in intents, even though they are not declared as incoming/outgoing contexts on that intent.
In this example, I'm requesting 2 parameters from the user (car make and model). Of course, Enable webhook call for slot filling needs to be set in your intent.
Steps:
On Dialogflow, in the intent, declare an Event. This can be used to trigger this intent from your fulfillment code:
In your parameters, declare a Default Value for each parameter you want to be able to keep after resetting the intent:
Set the Default Value to a parameter in a helper context. If this helper context does exist, the default value will be set, otherwise, it'll be kept empty. This will allow you to reset the intent and keep other parameters you already had. In this example, I'm using the context show-car-details-data, and setting the default value of parameter model to _model in that incoming context:
In your slot-filling fulfillment method, you can validate your parameter and re-prompt the user by reseting the intent. To do that, you need to 1) clear the current dialog contexts, 2) call setFollowupEvent to trigger your intent again, and 3) optionally set up some helper context you can use to assign default values (so you don't need to re-prompt user for those that were valid).
I'm using Dialogflow Fulfillment Node.js Library:
// clear dialog contexts:
agent.contexts.forEach( e => {
if ( e.name.endsWith('_id_dialog_context') ) agent.context.delete(e.name);
});
// workaround bug: https://github.com/dialogflow/dialogflow-fulfillment-nodejs/issues/160
agent.add('');
// set follow up event: this triggers your intent again
agent.setFollowupEvent('show-car-details');
// optionally set helper context to set default values and avoid re-prompt of already valid values
// in this example, keep make since it was a valid parameter
// clear model because it was invalid. User will be prompted again on model, but not on make
agent.context.set('show-car-details-data', 1, { '_make': make, '_model': '' });
Steps
Enable webhook for slot filing in Dialog flow with Entity set as "Required".
Get entity from arguments.
Programmatically check if it is not null and as per your requirement.
If it is correct, proceed further.
Else, RESET THE CONTEXT and ask the question as per the wrong slot input. Programmatically, set the output context same as input so that user can again respond back slot/entity. If the correct context is not present, the slot will not get captured. When a slot is captured as per set Entity, the context for that slot captured is finished and to recapture it you need to increase the lifespan or create it again.
Related
I would like to use Conditions to dispatch the conversation through different Routes depending on the intent entity that appeared in the last user's message:
But it only enables me to use the condition $intent.params.entityX != null; when I try to extract the exact value of that entity like: $intent.params.entityX = "some_value" it does not match. I have also try $intent.params.entityX.original and $intent.params.entityX.resolved. It seems that the intent param values can apparently only be read in the Route response.
If what you're looking for is to evaluate a parameter that may have been filled through entity detection, you may wanna check in session rather than the intent:
$session.params.entityX
There is a new feature in the conversation service where you can define slots/ entities for specific intents to extract the relevant information from the user input like currencies or specific string inputs. Those slots can be set mandatory in case you need them to proceed and the user will be asked for missing slots until he provides them.
Is it possible to define sth. like quit parameter so I can easily interrupt this conversation? The general documentation does not provide any information regarding this problem.
https://console.bluemix.net/docs/services/conversation/entities.html#defining-entities
You can do it by adding node-level handler which will listen to your cancellation intent and fill the slots with dummy values.
You can read more about this approach in the documentation: https://console.bluemix.net/docs/services/conversation/dialog-build.html (paragraph "Handle requests to exit the process")
if you have a REST API that is hypermedia-driven (HATEOAS) you can easily change a client's behavior by including or omitting links in the response (_links). That enables a client to completely forget about testing permissions for the operations that are possible in the current state of a resource (the link to the operation is present or not).
Additionally you can leave out properties in the response if the current user doesn't have permission to see it.
That way authorization is done entirely on the server (and controls actions and properties that are eligible to execute/view).
But what if I want to a have a read-only property? It is no problem for the REST API to ignore the property if it is present in the request (_POST_ OR _PUT_). it just won't get saved. But how can a client distinguish between write and read-only properties to present the user appropriate controls (like a disabled input field in HTML)?
The goal is to never ever have the client request a user's permissions, but to have a completely resource driven client/frontend.
Any help is greatly appreciated :-)
If I misunderstood your question, I apologize upfront. With that being said...
But how can a client distinguish between write and read-only
properties to present the user appropriate controls (like a disabled
input field in HTML)
Well, there are multiple solutions to this. The simplest one I can personally think of is to make each property an object having a simple structure of something like:
...
someProperty: {
value: 'some value',
access: 'read-only'
},
someOtherProperty: {
value: 'some value',
access: 'write'
}
...
You can obviously get as creative as you want with how you represent the "access" level of the property (using enums, booleans, changing access to be isReadOnly or whatever).
After that, the person using the API now knows they are read-only or not. If they submit a "write" value for a "read-only" property as part of the POST payload, then they should expect nothing less than a 403 response.
Edit:
In case you can't alter the properties in this manner, there are a number of other ways you can still achieve this:
write documentation that explains what access each property has
create a route that the user can submit 1 or more properties to in order to receive a response that indicates the access level of each property (response: { propName: 'read-only', propName2: 'write', etc.)
Return a propertyAccess map as part of the response (mapping properties to access levels).
end of the day, you just need a way to map a property with an access level. however that's done depends on what your restrictions and requirements are for the api, what changes you can make, and what is acceptable to both your client(s) and the business requirements.
I have a policy which checks whether a request has complete and valid body. I want to send a value to the controller to determine whether the result is passed or failed. Is there anyway to achieve that?
Why pass control to the controller at all if the policy fails? Usually the point of a policy like the one you described is to divert program flow if the policy fails, perhaps to an error page. In any case, what you're looking for is best done using req.options:
req.options allows altering of (or providing defaults for) request parameters without modifying the original object.
You can set a value in req.options in your policy, then read it back in your controller without having to modify the actual request.
Policy gets the request object as input and you can modify that object before sending it to the controller, ie piggyback your data over the request object.
You can do something like this in the policy :
req.body.paramname = 'newval';
And in the controller, you can get the value
var paramFromPoliy = req.body.paramname;
As for tracking in AEM I am using CQ_Analytics for a scenario. We have a requirement like, I have to capture a value called "sort type" which is on the page when a user clicks on a button on that page and store it in ClientContext. I have written the below Javascript function which accepts a name argument. Using some code I am able to get hold of sort type value and passing it to the below function. Now my query is, how do I validate whether the name variable is assigned to the Client Context???
I have kept an alert statement and tried checking with multiple combinations but I am unable to figure out what is the correct way to conclude that my name value has been assigned to Client Context or not. Please help with my query.
function myFunction(name) {
CQ_Analytics.record({event: 'sorttype',
values: {'sortSelectedOption': name },
componentPath: '<%=resource.getResourceType()%>'
});
alert(CQ_Analytics.record.sorttype.sortSelectedOption);
}
You can see this post how to make your custom client context and how to store your data. http://blogs.adobe.com/aemtutorials/2013/07/24/customize-the-client-context/
After you create your client context, you have in the example CQ_Analytics.CustomStoreMgr.setTraitValue function that will save your parameter into client context.