2

I try to find in document of ApiAiApp and ActionsSdkApp, they do not have property or function to get conversationId. I can see this from the JSON request. Do I have to parse the request myself to get the conversationId? conversationId should be commonly used.

user3423762
  • 81
  • 4
  • If you can update the question to explain why you think you need the conversationId, I can possibly update the answer better. – Prisoner Jul 21 '17 at 03:25
  • to explain why I need the ConversationID instead of saving the state to Context. The reason is another app (cloud function) is watching the firebase change and do some other logic as long as new conversation on going. That function is out of this ApiAiApp, and running totally different logic. I try to not put those non-related functions inside one ApiAi App. I hope my explanation makes sense. Or, if there is a better idea solving my problem? – user3423762 Jul 21 '17 at 04:08
  • To make the use case clearer, so that you can understand why I need it. I would like to make the app to have real human involved in the conversation. Another web app (not ApiAi App) connect to the same firebase. A real people can watch the on going conversation. If they found the conversation goes wrong or machine cannot answer correctly, he can actually take over the conversation immediately before the user goes away. I've got answers from Prisoner, that helps a lot. Thanks – user3423762 Jul 21 '17 at 04:44
  • There is a new REQUEST.sessionId, which i think is the same as conversationId. I am using this. – wolfram77 Apr 19 '18 at 04:15

1 Answers1

3

Although it isn't documented, there is a getConversationId() that is part of the ActionsSdkApp object, but not part of the ApiAiApp object. If you're using Node.js (which you would be if you're using the library), it should be easy to handle the JSON object as well, however. For API.AI you should find it in originalRequest.data.conversation.conversationId.

Keep in mind, however, that there is no "end" event for the conversation. So while you will know when there is a new conversation, and when it is updated, you won't know when the user stops that particular conversation.

Depending on your needs, you may want to use the userid instead of the conversationid. It doesn't provide information about when the conversation ends, but it can track the same user between different sessions and devices.

For most users (tho probably not in your case), the conversationid probably isn't as used as you might think. While it might make sense to use this as a key to save state in a database or something along those lines, it is easier to let Google save the state itself.

You can save the state in a Context in API.AI using the app.setContext( name, lifespan, parametersObject ) method. On the next time through, you can get the data from the app.getContext() method.

In the ActionsSdkApp object, you can do something equivalent using a dialogState object that is the last parameter for most of the ask-like methods (such as the app.ask() method). This will then be available on your next call through the app.getDialogState() method. (This page also talks about an app.data field that can be used for the same thing, but I can't find any more documentation about it.)

Prisoner
  • 49,922
  • 7
  • 53
  • 105
  • To answer your question why do I need the ConversationID. I will need to save the state to firebase instead of Context. The reason is another app is watching the firebase change and do some other logic as long as new conversation on going. – user3423762 Jul 21 '17 at 04:03
  • Sounds like an excellent (and clever) approach in your case then. {: I've updated the answer with a little more info and some other things to consider, but I think you're on the right track with your solution. If this provides a workable answer, please accept and/or upvote it. – Prisoner Jul 21 '17 at 04:11
  • Yeah, saw your update. Thank you very much. I need to get 15 reputations to upvote. I will try to answer more questions these days and come back to upvote for you. – user3423762 Jul 21 '17 at 04:37