I want to know in my fulfillment what was the language the user was spoken when the intent was triggered.
Is there a way to know that? I didn't find that information in the request header or in the request data.
Thanks
Guzman
This information is part of the user locale and is part of the JSON body that is sent. You can get this in one of a few ways:
If you're using the node.js library, you can use app.getUserLocale()
If you're using the Action SDK, this is in the JSON at user.locale
If you're using Dialogflow, this is in the JSON at originalRequest.data.user.locale
In each case, the value returned will be something like en-US specifying the language and locale the user is using.
Keep in mind that you will still need to register your Action to handle these languages or language/locale pairs in the Action console.
Related
Link to the HATEOAS This is the link to the Hateoas article (snapshot below) where the identifiers of the resource is part of the URL i.e. 12345. Here the API response has the final API relative URL i.e. /accounts/12345/deposit and the client just needs to hit it.
Link to the Github Users API This is the link to the Github API (snapshot below) where there are lots of placeholders for identifiers. How will clients modify these URLSs and add a value in these placeholders? For example, {/gist_id}, {/other_user}.
Isn't passing the URL with id value instead of placeholder better? Why and when to rely on different clients to add values in these placeholders?
Hypertext as the engine of application state (HATEOAS) is a bit more than just the usage of links. In essence it enforces the interaction model that is used on the Web for two decades quite successfully. On the web a server usually "teaches" clients (browsers) to achieve something via the help of link relations, that can be used to automatically download related resources or give a hint on the reference resource, and Web forms, that define the syntax and semantics of each of the respective supported (input) elements, i.e. a text field, an option element to select one or multiple choices, a drop down or even a slider widget. Based on the affordance of each of the elements a client knows i.e. that a button wants to be clicked or pressed while a text fields wants some user input and stuff or a link annotated with the prefetch link relation name may be downloaded automatically once the current page finished loading as a client might invoke it next or a preload link relation might instruct a user agent to load the referenced resource early in the current page loading process.
The form not only teaches a client about the supported fields a resource has but also about the target URI to send the request to, the HTTP method to use wile sending the request as well as the media-type, which in the case of Web forms is usually implicitly set to application/x-www-form-urlencoded.
In an ideal world a client just uses the information given by the server. Unfortunately, the world isn't perfect and over time people have come up with plenty of other solutions. Among one of them is URI templating that basically allows clients to use a basic URI and fill out certain placeholders with concrete values. As making use of templating requires some knowledge of the URIs intention or the parameters you need to pass, such capabilities make only sense as part of media-type support.
Plain JSON (application/json) has by default no support for URIs whatsoever and as such a user agent receiving a plain JSON payload might not be able to automatically replace a template URI with a concrete one out of the box. JSON Hyper-Schema (application/schema+json) attempts to add link and URI template support to plain JSON payloads. A user client though needs to be hinted with the appropriate media-type in order to automatically resolve the full URI. As such, the user agent also has to support that respective media type otherwise it won't be able to process the document (resolve the template URI to a real URI) successfully.
JSON Hypertext Application Language a.k.a HAL JSON also supports URI templates for links. application/collection+json does support two kinds of templates - query templates and objects-template. The primer one is similar to a URI template by allowing to append certain query parameters to the target URI upon sending the request while the latter one allows to define a whole object that contains all the input elements used to add or edit an item within the collection. JSON-LD does not really support URI templating AFAIK though it uses the concept of a so called context where certain terms can be used to abbreviate URIs. As such something like name can be used within the context for a URI like http://schema.org/name.
As you can hopefully see, the support for URI templating depends on the media-type used for exchanging data. In the case of the outlined github example GET /users/:username this more or less resembles a typical Web API documentation, similar as it is done in a Swagger API documentation, that unfortunately has hardly anything to do with HATEOAS.
For your top example (banking), you should absolutely include the complete URL, with account numbers (IDs), so that the client does not need to translate/substitute anything. This is the most common scenario with HATEOAS. However, GitHub does have those "placeholders" for endpoints that could contain multiple values. You can't include the "following_url" for every user in the response, it's not practical. So you have to determine the "other_user" value another way and make the substitution. Personally, I haven't even had this use case with any of my applications and all of my HATEOAS URLs resemble you first example (though I prefer full URLs not relative). Unless you have specific cases like GitHub does, it's not necessary to use any of these placeholders. Even GitHub only uses that where they could be multiple values. For fixed value URLs, they have the username (like your account number) in the URL ("octocat").
According to me we should not give the direct url in the body
We should always parameterized the api and get details form there.
In simple case if Id of data change than every time data need to update for detail url.
Else if it’s dynamic you will never face this issue.
And this also come under best practices.
In the DialogFlow console, you can set an input and output context for an intent.
I would like to have the same functionality using the Actions SDK.
Since I can set the context in my fullfilment webhook in the code, the output SDK is covered.
However, how do I set the input context for an intent to only trigger if that context was fetched?
I could not find this in the documentation examples.
I don't believe you can in the same way, which is part of why they added Dialogflow.
Although as part of your response you can indicate the ExpectedInput for the next Intent, the documentation for the ExpectedIntent makes it clear that your Intents are only used for speech biasing - you'll always get the built-in TEXT Intent.
In fact, this documentation says that you'll only get custom Intents for the initial call - later Intents are always triggered with a built-in one.
Update: One thing you can do is to include information in the response that will be sent back to you in the next request.
If you're using the JavaScript SDK, this is done with the second parameter to ask() and is available via the getDialogState() function.
If you're sending back JSON, this is done using the conversationToken attribute and is available in conversation.conversationToken in the request object you're sent the next round.
The Facebook SDK has the ability to record both custom events and standard events. The standard events are things like "Purchases" "Add to cart" "Completed Registration" etc...
Recording these standard events gives you access to specific bidding features on Facebook ads that you don't get without the events.
I have an app that has the React Native FBSDK
There are two methods for defining an event - one for purchases and one for everything else as seen here
There is zero documentation for standard events on react within the SDK on Github or on the event tracking docs on Facebook's developer platform.
Right now I'm trying to track the standard events by using their various names, as recorded across FB's documentation. I've tried the following:
AppEventsLogger.logEvent('FBSDKAppEventNameCompletedRegistration');
AppEventsLogger.logEvent('CompletedRegistration');
AppEventsLogger.logEvent('Completed Registration');
All of these just create custom events with those names, but aren't recognized as standard events.
Has anyone gotten standard events to work using the React Native wrapper for the FB SDK? If so how do you name the events to get FB to recognize them?
Update: As the comment below highlights, the more recent link is https://developers.facebook.com/docs/marketing-api/app-event-api/
It looks like you'll have to pass the strings that those standard events get evaluated to, i.e. instead of 'FBSDKAppEventNameCompletedRegistration', you'll have to use: 'fb_mobile_complete_registration'.
Here's the source:
Sorry if this is a bit late. Hope this helps.
I managed to find the actual event name by generating standard event code using tool on Facebook's documentation, run the code in AppDelegate.m, and get the exact key-values from Events Manager. With this roundabout way, I realized the actual name of Add to Cart event was fb_mobile_add_to_cart. From there I googled for the name and found the list documented in Marketing API (why not App Events?).
I don't know if it is the right place, but you can refer to https://developers.facebook.com/docs/marketing-api/app-event-api/ for actual standard event names and parameter names. At least it worked in my case. Here's my Add to Cart event code:
function logAddToCart(totalPrice, contentType, contentId, currency) {
const params = {
'fb_content_type': contentType,
'fb_content_id': contentId,
'fb_currency': currency
};
AppEventsLogger.logEvent('fb_mobile_add_to_cart', totalPrice, params);
}
I made a simple package with all events. Just import like
import FBEvents from "react-native-fbsdk-events";
// ...
AppEventsLogger(FBEvents.COMPLETE_REGISTRATITON, params);
TLDR; # bottom
I asked the following question in the Facebook bugs section
NOTE: This is more of a platform design suggestion than a bug, as I failed to find a Chat API feedback portal
Currently I'm building a Chat bot that allows the user to track a goal. It will say something like "Did you go for a walk on July 12, 2016 ?" and have Yes/NO buttons below.
Currently in order to pass the intent, the day and the achievement boolean I need to template a string like this "==GOAL== achieved? <<<{goal_achieved}>>>, date tracked [[[{date_tracked}]]]" and use regex to capture the delimited variables. This is prone to parsing error in other cases where the templated strings in the payload are user-input variables i.e. if the '{goal_achieved}' were replaced with the goal variable '>>meditated" then the regex that captures the templated variable could fail.
One could use the postback payload to store a JSON-encoded string but the problem with this is that the payload string gets logged into the user output and JSON strings are a bit ugly and confusing. The challenges I face could be easily remedied if the payload was not logged to the user Instead log the text for the button to help the user confirm the button was clicked.
If that is not possible, is there any other advice for encoding data into button payload ?
The following answer was offered (Mark Wiltse)
Hi Justin,
Unfortunately at this time our payload structure does not support the functionality that you are trying to implement. From my understanding you want to use the Payload to inform your backend if the user accomplished their 'goal' on that specific date. I would suggest that you create your payload response for the button on your end before passing it to us, which is basically the JSON idea that you had initially.
I know this is a bit cumbersome to handle but the payload response passed back is independent of the text that was provided with the messenger thread.
I would suggest that you also attempt to sanitize your strings if you are worried a user has previously provided you would cause an issue with your regex. You should be able to implement this functionality if the prior user data is sanitized to avoid any issues with regex/json parsing.
Since this is an implementation question I will have to close this report as Invalid. If you are still looking for additional insights and concrete tips for implementing this flow please post to our stack overflow where we have Facebook Engineers and a wide range of community members who also contribute.
http://facebook.stackoverflow.com/
Take care and best wishes with your messenger bot.
Mark
This sentence was particularly unclear:
I know this is a bit cumbersome to handle but the payload response
passed back is independent of the text that was provided with the
messenger thread.
TLDR;
Can anyone inform me of how to prevent the button from logging the payload string so that I can use it to pass JSON to my app without the user seeing it ?
Make sure to comment out sendTextMessage() in your receivedPostback() call :
function receivedPostback(event){
sendTextMessage(senderID, event.postback.payload);
}
From my understanding you're saying that when you press a button the PAYLOAD instead of the button's text is showing up.
Are you defining your buttons like this?
{
type: "postback",
title: "View Details",
payload: "details:12345"
}
I'd recommend removing any special characters that would mess with the parsing of your payload. As long as the special characters are not crucial to the user experience this is probably a fine solution.
If this doesn't solve your issue:
Can you add a screenshot showing the button you are pressing, and the log message you are talking about? From my understanding you're saying that when you press a button the PAYLOAD instead of the button's text is showing up. That's not the case for me, my buttons text shows up when I press a button.
I'm trying to send a POST request from iPhone to Django, but for some reason I can't. The request is sent, but the server doesn't receive it properly.
What is the regular expression that accepts POST? In my case, I use this one: /messages/a/s=person1&r=person2&c=hello/.
How do I retrieve the POST arguments in the Django view? request.POST['s'] should work?
Thanks.
POST parameters are not part of the URL, so your regex should simply detail the main part of the url you want to receive it on. To take your example, change it to /messages/a/. Then, in your "messages" app, have a view/function called a: that one will be reached on receiving any POST (or GET, which you're currently (almost) depicting in your url) to that location.
The arguments can then indeed be retrieved using request.POST['keyname']. To make things more convenient, supply a default value when getting the data so you need less error checking: request.POST.get('keyname', None). This will get the value of keyname when available, or None otherwise.
The posting itself... depends on more code then you're currently showing. Can't say anything about that with your current question.
That URL you've pasted in will pass the data through the request.GET dictionary. If you want to change your iPhone app to POST data, you'll have to share your code.