I am using actions-on-google ApiAiAssistant node.js library with API.ai for designing my chatbot.
I have created a German API.ai Agent specifically for it. So, I need to get the locale value from the request to webhook to know which locale the request is coming from.
I have seen a method something like ApiAiAssistant.getLocale to get the locale information from the request but I am not able to find the specific one from the documentation.
Is the method deprecated? And how can I get the locale information from API.ai webhook request?
You're probably looking for the getUserLocale() method. https://developers.google.com/actions/reference/nodejs/AssistantApp#getUserLocale
For example:
const app = new ApiAiApp({request, response});
const locale = app.getUserLocale();
It returns the language/locale combination (such as "en-AU").
If you're just using the JSON object and not the API, you can find the value at originalRequest.data.user.locale. This is the same value returned by the method.
If you just want a non-standard language field that is returned by API.AI, you can use the lang field. This isn't available through the API, just by reading the JSON directly, and only contains language information - not locale information. On the other hand, lang is available if you're using it for multiple platforms, not just Actions on Google. (But if you're using it for other platforms - you probably don't want to be using the actions-on-google node.js library.)
Related
I'm using the Docusign Java SDK and I'm curious if anyone else noticed it's NOT typesafe. Are there at least constants for the value I can use instead of generic String values.
for example, to send a JSON webhook payload when you use request an envelope signature:
// configure a connect notification
EventNotification eventNotification = new EventNotification();
// Set up the endpoint URL to call (it must be using HTTPS and at least TLS1.1 or higher)
eventNotification.setUrl("my-webhook-url");
// DocuSign will retry on failure if this is set
eventNotification.setRequireAcknowledgment("true"); <---- the String "true"?????
// This would send the documents together with the event to the endpoint
eventNotification.setIncludeDocuments("false"); <---- the String "false"?????
// Allows you to see this in the DocuSign Admin Connect logs section
eventNotification.setLoggingEnabled("true"); <---- the String "true"?????
// send an event when the envelope is sent and completed.
EnvelopeEvent sentEvent = new EnvelopeEvent();
sentEvent.setEnvelopeEventStatusCode("Sent"); <---- the String "Sent"?????
sentEvent.setIncludeDocuments("false");
EnvelopeEvent completedEvent = new EnvelopeEvent();
completedEvent.setEnvelopeEventStatusCode("Completed"); <---- the String "Completed"?????
completedEvent.setIncludeDocuments("false");
eventNotification.setEnvelopeEvents(List.of(sentEvent, completedEvent));
ConnectEventData eventData = new ConnectEventData();
eventData.setVersion("restv2.1"); <---- surely these should be constants....right?
eventData.setFormat("json"); <----
eventNotification.setEventData(eventData);
envelope.setEventNotification(eventNotification);
this documentation led me to use Strings like envelope-completed instead of Completed....which cost me hours of trial and error.
Isn't the whole point of an SDK in a language like Java to be type safe? What am I missing here?
This is not an issue with the Java SDK, but with the swagger file that has definitions for various fields in the DocuSign eSignature REST API.
The swagger file defines many things as strings, even if they do not have to be strings. Changing this now would be a breaking change for many integrations and developers that rely on this (buggy or not) behavior.
This may be fixed in a new version of the API to avoid having backward compatibility issues.
Creating a chatbot using IBM's Watson Assistant, and I need to make a determination I'm trying to send the zip code to a third party API that will return the city and state so I know where the client is located so I can (a) know which services are available and (b) have a better idea on how to direct the conversation from there. But I am at a loss as to how to do this.
I can do this from within Python, but trying to code it in a JSON editor doesn't work.
Webhooks are used to do this from inside the Dialog skill in an Assistant.
IBM Watson Assistant webhooks documentation
The docs do not mention it, but the Assistant will POST to the URL with a JSON body containing the parameters you specify as key value pairs. For example if in the Dialog Node the context variable $zipcode equals '99501' and you specify the parameters "key" = zipcode and "value" = "$zipcode".
Then the HTTP post body is
{ "zipcode" : "99501" }
The response from the service is put into another context variable, and this can then be used for other things. For example in the Dialog Node which calls the webhook, in the "Return variable" section put webhook_result_zipcode to put the response into that context variable.
You can also in the dialog node Assistant responds section, return a message which contains some part of the webhook response. For example in the Dialog Node editor
"If assistant recognizes" $webhook_result_zipcode "Respond with" The code is "$webhook_result_zipcode.response.result.sent" This will tell the user the code which is returned deep within the webhook response in response.result.sent in the response body.
You can also click the Cog next to the response, and in the dialog, click ... next to "Assistant responds" and open the context editor. This opens a context editor (at the top of the dialog) which allows setting of another context variable from part of the webhook response. For example under "Then set context" for "Variable" set zipcode and for "Value" set "$webhook_result_zipcode.response.result.sent.zipcode". This will extract a zipcode value from deep within the webhook response and place it in the context variable zipcode.
Of course then you must find a zipcode location service which accepts a HTTP post and looks for the code in the body.
Is it possible to format a conversation so that the bot initiates conversation using dialogflow in a web demo integration?
The objective is to say something like “Hi, I’m a bot, I can do x” to establish that it’s a chatbot rather than a human.
Can anyone suggest any idea for this?
You can set a welcome intent, then send a /query request containing an event parameter. Set the event parameter to WELCOME and your chatbot will respond with whatever conversation opening you set.
More info here: https://dialogflow.com/docs/events
If you are using something other than the API for interacting with your Dialogflow agent (Slack, Facebook Messenger, etc.) you will need to add an appropriate event under "intents" in your console (such as the "Facebook Welcome" event).
For interacting with your Dialogflow agent via the API, see below.
In the API interaction quickstart documentation, Dialogflow gives you the SessionClient's detectIntent method for sharing messages with your bot.
Each language has a different solution. But on an abstract level, you want to change the request object that you send to Dialogflow to include a "Welcome" event (no input message required), as Omegastick described.
For example, in Node.js, your request object would look like this:
// The text query request.
const request = {
session: sessionPath,
queryInput: {
event: {
name: "Welcome",
languageCode: languageCode
}
},
};
This assumes you have an appropriate intent set up in your Dialogflow console to handle Welcome events. One is provided by default that you can observe.
You can also add contexts, so that your agent gives a different greeting message based on some condition.
SDK
Homepage: https://github.com/Microsoft/BotBuilder
SDK Platform: Node.js
SDK Version: 3.14.0
Issue Description
Hi, I searched for this for a long time now but I haven't found an answer.
I was wondering if there is a way to bind some URL parameters to the User's Bot Session.
For example, if for a specific chat dialog, I set my Endpoint URL to:
http://localhost:3978/api/messages?pronuntiation=british
is there a way to get that url parameter named "pronuntiation" down in the session object like...
bot.dialog("/", function(session){
var desiredPronuntiation = session.someUrlParameters.pronuntiation;
if( desiredPronuntiation == "british"){
///blah
}
});
I think it is possible in C# SDK but I was trying to do this in NodeJS...
I already debugged the proces from the server.post('/api/messages', connector.listen()) down to the ChatConnector.verifyBotFramework() where at the end I found it calls _this.dispatch(req.body, res, next); (ChatbotConnector.js on line 149) passing only the post body but not the request object itself...
So at a first glance I think this is not possible, I just wanted to be sure that I didn't miss anything...
Thanks,
Luis
As far as I know, this isn't supported by the Bot Framework, however I don't see why you need to do it this way. This is something you want to store in the state, for example the userData. You can read more here about managing state in the Bot Framework.
If you want to pass user data to the bot, it depends on the channel. For example Facebook and Webchat allow you to pass data direct to the bot, without user input.
I would like my Actions on Google agent to store and retrieve certain pieces of information across invocations - like a cookie. How do I do this?
You have a lot of options on how you want to do this, depending on exactly what you're trying to do. It isn't exactly like a web cookie, although there are similarities.
If you want the equivalent of a session cookie, information that is retained during a single conversation, then your options are
Using the Session ID provided as part of the information sent to you on each invocation and tracking this in your fulfillment.
Storing information you want retained using a Dialogflow context
If you are using the actions-on-google JavaScript library, storing this in the app.data object created for you.
If you want the equivalent of a long-lasting cookie to retain information between conversations then your options are
Using the anonymous User ID provided as part of the information sent to you on each invocation and tracking this in your fulfillment.
If you are using the actions-on-google javascript library, storing this in the app.userStorage object created for you.
Storing it as part of the string in the JSON response under data.google.userStorage.
Some more information about each of these
Session ID
A different Session ID is created for each conversation you have. You can get this Session ID by examining the JSON sent to your webhook in the sessionId parameter.
You can then look this up in a data store of some sort that you manage.
Dialogflow context
Contexts are powerful tools that are available with Dialogflow. You return a context as part of your fulfillment webhook and indicate the name of the context, its lifetime (how many more rounds of the conversation it will be passed back to your webhook), and any parameters associated with the context (string key/value pairs).
Contexts are especially useful in helping determine what intents may be called. You can indicate what contexts must be active for an Intent to be recognized by Dialogflow.
If you're using the actions-on-google node.js library, you can set a context using something like this:
var contextParameters = {
foo: "Something foothy",
bar: "Your local bar."
};
app.setContext( "remember_this", 5, contextParameters );
You need to do this before you call app.ask() or app.tell().
Or you can do the equivalent in the JSON as part of the contextOut block of the response
"contextOut": [
{
"name": "remember_this",
"lifespan": 5,
"parameters": {
"foo": "Something foothy",
"bar": "Your local bar."
}
}
]
The next time your webhook is called, you can fetch this context either by looking at the result.contexts array or by using the app.getContext() or app.getContextArgument() methods in the library.
Using app.data
If you're using the library, Google has done some of the work for you. The app.data object is created for you. Any values you set in the object are available for the lifetime of the session - you just read them in later calls to your webhook.
(Under the covers, Google uses a context for this, so there is no magic. The two work together and you're free to do both.)
Anonymous UserID
When a user first uses your action, a user ID is generated. This ID doesn't give you access to any specific information about them, and isn't used for any other action, but every time you see it, you can be assured that it was the same user that used it on a previous occurrence. Just like a cookie, however, the user can reset it and a new ID will be generated for them for your action.
You get this from the JSON at originalRequest.user.userId or by using app.getUser().userId. Once you have it, you'd use a data store of some sort to store and retrieve information about this user.
Using app.userStorage
Similar to app.data, there is also an app.userStorage object that is created for you for each user. Any changes you make to this object are saved in between conversations you have with this user.
Unlike app.data, however, this doesn't get stored in a context. It has its own storage method. Which leads to...
Storing it in JSON
If you're not using the actions-on-google library, you still have access to userStorage through the response and request JSON directly. You need to store this as a string, but if you need to store a more complex object, a common method is to stringify it as JSON.
You'll store this value under data.google.userStorage in the response and can retrieve it under originalRequest.data.user.userStorage in the request your webhook receives.
You can save the information in Context with a key value parameter.
SAVING VALUES IN CONTEXT :
agent.set.Context({
name:'context-name',
lifespan: 5,
parameters:{
'parameter-name':'parameter-value'
}
});
GETTING VALUES FROM CONTEXT
agent.getContext('context-name');
For more Details : https://dialogflow.com/docs/contexts/contexts-fulfillment
You could also use a Google Cloud database like BigQuery or Firestore
Sounds like you may want to checkout out Account Linking: https://developers.google.com/actions/identity/account-linking. With account linking you can collect end-user information which you exchange with Google by providing a unique key. This unique key becomes part of every request you receive from Google, so when you get that unique key you lookup the information you collected from the end-user. In your case, you would store credentials or whatever key is required to access the end-user information. After the initial linking, any new data you obtain could be stored along with the original information collected, based on the unique key obtained during account linking.
For this purpose, i just did a node module just for that, in external json file from api call, i need to store and add additional informations to retrieve later. I thing that you can do a lot with this module, Store object, array, json, value, Navigation history?, back to previous page.
It work like localStorage or Cookies.
There's no limit, you can create multiple storage by name (key) an value. It's new and i'm testing it for bugs right now on my own project.
Test on Runkit
On npm
vStorage = require('virtual-storage');
vStorage.set('name', '{title:'Title 1', description:'Descriptions 1'}')
let getStorage_name = vStorage.get('name');
console.log(getStorage_name.title);
vStorage.get('name')