I am using an exteranl API that do some work for 15min, when it finish it will call any URL you define in your initial request to send the results to.
Is it possible for dialogFlow to accept this result in 15min? Is there like a built-in async response handler in DialogFlow?
If you are calling external APIs via webhook, it would be subject to the maximum webhook timeout limit of 30 seconds. After the response timeout is exceeded, Dialogflow invokes a webhook error or timeout built-in event and continues processing as usual. Therefore, Dialogflow would no longer accept webhook responses more than the set timeout limit.
Note that conversational interfaces are meant to be designed as a continuous message exchange between the end user and the app/bot. If your web service requires more time for executing operations in the background and this cannot be optimized, consider redesigning the conversation flow in such a way that end users don't wait for the app/bot to reply for more than the set webhook timeout limit.
If you have your own custom application (integrated using APIs or Client Libraries), you can instead call/invoke the function that needs 15 minutes of work (let’s call this function_1) from your custom application.
Here’s a basic setup:
User enters a query from the interface of your custom application.
Your custom application sends the user query with the Detect Intent
request to the Dialogflow agent (using APIs or Client Libraries).
After your custom application receives a Detect Intent response from
the agent, you can create code to get the intent name or event name
from the detectIntentResponse.queryResult.match.intent.displayName
or match.event response json respectively and then call/invoke
function_1 based on the intent or event matched.
Once function_1 is finished processing, you can either send a direct response to the
user in your custom application’s interface or send a Detect Intent
request to your agent so it matches an Intent and sends the intent
response back to your custom application.
No, it won't be possible as you describe it. The only way to call external services is through webhooks, but these are thought as calls that return a very specific object which Dialogflow then returns as an answer to the user directly, so they are inherently synchronous.
What you could do instead is think of a workaround. I don't know the specific of what service you're calling, but you could set up a small server to handle the webhook response from dialogflow which doesn't do anything except trigger the call to the external api, and when you get the answer you could process it (put the relevant content inside a "fulfilment" object as per Dialogflow specification) and trigger an event in your agent through the dialogflow API.
so the final process could look something like this.
user asks for e.g. "pizza": the right intent is triggered and the route for that intent calls a webhook server
your webhook server receives the call from dialogflow and calls the external api asking for the list of all pizzas ever created. it returns an empty fulfilment to the server
when the webhook server receives the response after 15 mins it triggers an event in the agent (look into the dialogflow api for your programming language of choice: python, node, java) and injects some parameters in the request, which you can then use to form a sentence in the agent
when I was just starting out I found this very useful to get a grasp of what the platform expects you to do in terms of interacting with external services, take a look at the graph especially which I think makes it clearer
Related
I have a GraphQL Websocket based application in which I need to wait for customer payment. The subscription handler is supposed to
Send a request to the payment gateway to activate the payment terminal.
Wait for a webhook that gets called after payment for further processing.
I am sorry I am not able to post any code since, after step 1, I am unable to find details on which constructs (like a Mono or PubSub) to use to "wait" in this use-case.
How can I associate the outgoing request with the webhook call?
I can provide any other details needed to make my question clearer.
There is still too little information but let me give you a rough sketch of how it could work.
After a request to the payment gateway has been sent we need to do two things.
Create a stream (e.g. a Mono) to which you can send a signal
Create a mapping between the (device or transaction) ID and the stream. For starting you can use a simple Map that is also accessible (through a service) by the webhook. For production, you may think about a more sophisticated way.
When the webhook receives a request you look up the stream for the ID and send a signal to it (could also be an error signal). Whoever has subscribed to the stream now receives that signal and can continue.
Now to what construct to use. There may be several alternatives, one is to use a Sink. Here is some pseudo-code(!):
In the method that sends the payment request:
activateTerminal(paymentDetails);
transactionSink = Sinks.empty();
transactionMap.put(deviceId, transactionSink);
return transactionSink.asMono();
Inside the webhook:
transactionSink = transactionMap.get(deviceId);
transactionSink.tryEmitEmpty();
The last statement completes the Mono, so whoever "waits" for it gets notified.
Please understand this answer only as a concept. The things you need to take a closer look at are:
How to store the association
The most appropriate way for you to send a signal to a stream (Mono).
If you have any specific question after that I recommend to create a new one.
I am using a third party API to provide Agent Handover (human chat) capabilities to my v4 based bot. The API requires a call back hook/ endpoint where it can send the messages/events back from the agent, and I have to get messages from it and display to users. When ever a new chat session is established a new session id is generated. And thus Session Id is passed back in all messages and events. Essentially they are sending events as Fire&Forget with a retry on failure.
For now I had implemented an eventstore (in Cosmos dB) to store events/messages and then poll Cosmos periodically display message back to user and mark them processed.
Is there any way to make it more real time or pub-sub kind of analogy?
I would like to know if some one have already implemented scenario like this. What should be the way to respond the incoming messages from agent to bot user.
Please suggest.
I would recommend creating a client using the Direct Line API to handle routing messages between the third party agent handover and the bot. Then in the bot you can pair the third party Direct Line conversation references with the user's conversation reference to forward the messages accordingly with proactive messages. For more details take a look at this Stack Overflow question.
Hope this helps!
It is my very first time to write a slack bot and i am wondering how to design it.
The bot supposed to be available and respond to end-users' messages immediately.
The thing is that I need that the bot will also send schedules messages to registered users with automation results.
Use case example:
A user sends a message to the bot and registered to a service that
will check for changes in X. On a specific interval, my backend will
call an automation that checks for those changes and will send a
message to the user with the results.
What will be the best practice for this scenario?
Here is a basic outline.
1. Basic setup
Slack app with bot user
Database
Scheduler (e.g. local CRON service, or web-cron like cron-job.org)
2. Registration
Use Events API to listen to messages from users send via mention (app_mention) or direct message (message.im)
You app needs to store the received "registration" from each user in a database
Respond to user request directly if needed with chat.postMessage
3. Scheduled response
Scheduler calls your app
Your app check if responses are due with a database query
If yes: App sends responses to users via chat.postMessage (but not more than one message per sec due to rate limiting)
Let suppose the following simple UC based on a CQRS architecture:
We have a backend managing a Business Object, let says a Movie.
This backend is composed of 2 Microservices: a CommandManager (Create/Update/Delete Movie) and a QueryManager (Query Movie)
We have a frontend that offer a web page for creating a new Movie and this action lead automatically to another web page describing the Movie.
A simple way to do that is:
A web page collect movie information using a form and send them to the frontend.
The frontend make a POST request to the CommandManager
The CommandManager write the new movies to the datastore and return the movie key
The frontend make a GET using this key to the QueryManager
The QueryManager looks for the Movie in the Datastore using the key and return it.
The frontend deliver the page with the Movie Information.
Ok, now I want to transform this UC in a more Event Driven way. Here is the new flow:
A web page collect movie information using a form and send them to the frontend.
The frontend write a Message in the BUS with the new movie information
The CommandManager listen the BUS and create the new movies in the datastore. Eventually, it publish a new message in the BUS specifying that a new Movie has been created.
At this point, the frontend is no more waiting for a response due to the fact that this kind of flow is asynchronous. How could we complete this flow in order to forward the user to the Movie Information Web page? We should wait that the creation process is done before querying the QueryManager.
In a more general term, in a asynchronous architecture based on bus/event, how to execute Query used to provide information in a web page?
In addition to #VoiceOfUnreason's answer,
If the two microservices are RESTFul, the CommandManager could return a 202 Accepted with a link pointing to the resource that will be created in the future. The client could then poll that resource until the server responds with a 200 OK.
Another solution would be that the CommandManager would return a 202 Accepted with a link pointing to a command/status endpoint. The client would poll that endpoint until the status is command-processed (including the URL to the the actual resource) or command-failed (including a descriptive message for the failure).
These solutions could be augmented by sending the status of all processed commands using Server Sent Events. In this way, the client gets notified without polling.
If the client is not aware that the architecture is asynchronous, a solution is to use an API gateway that blocks the client's request until the upstream microservice processes the command and then to respond with the complete resource's data.
At this point, the frontend is no more waiting for a response due to the fact that this kind of flow is asynchronous. How could we complete this flow in order to forward the user to the Movie Information Web page? We should wait that the creation process is done before querying the QueryManager.
Short answer: make the protocol explicit.
Longer answer: a good place to look for inspiration here is HTTP.
The front end makes a POST to the origin server; as a result the origin server places a message on the queue and sends a response back.
The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.
The client can then poll the endpoint to find out what progress has been made.
For instance, the endpoint might be a query into the data store, that looks for evidence that the command manager has processed the original command; or it might be an endpoint that is watching the bus for the MovieCreated message, and changes its answer based on whether or not it has seen that.
It may help clarify things to look into idempotent request handling; when the Command Manager pulls a message off of its queue, how does it know if it has previously processed a copy of that message? Your polling endpoint should be able to use the same information to let the consumer know that the message has been successfully processed.
In addition to #Constantin Galbenu's answer, I would like to put in my two cents.
I would strongly advise you to look at a microservices pattern called "BFF" (Backend-For-Frontend) pattern. Instead of having a thick API gateway doing all the work, you can have an API per use-case. For Example: In your case, you can an API called "CreateMovieBFFHandler" which would receive the POST request from front-end and then this guy would coordinate with other things in the system like message queues, events etc. to track the status of the submitted request. UI might have a protocol with this BFFhandler that if the response doesn't come back in X seconds, then the front-end would consider it as failure and if this handler is able to get a successfully processed messaged from message queue or "MovieCreated" event for this key, then it could send a 200 OK back and then you can redirect the page to call write side and then populate the UI.
Useful Link: https://samnewman.io/patterns/architectural/bff/
I am developing a Google Actions project for Google Home using api.ai.
Is it possible to pass a state parameter as part of the response to api.ai and have it included in the next request?
The Amazon Alexa API handles such a flow and it came in handy.
Thanks
EDIT:
I did not mention this before: I have api.ai sending requests to a webhook after google assistant triggers my intents. The response api.ai expects is defined here. I've tried including extra fields in the response but these are not included in any future intent requests from api.ai. I've also tried adding fields and values to the google specific portion of the response (defined here) to no avail.
As an example of what I am interested in, when responding to Alexa requests we can include a json field "sessionAttributes" which are then passed by Amazon in any future requests that are part of that interaction.
In this instance I query a database key on the first intent (which is subsequently used to pull a record) and pass that key in sessionAttributes to avoid performing that lookup for every intent request I receive.
The equivalent that you are looking for to sessionAttributes in Alexa dev depends on whether you are using an API.ai webhook or a conversation webhook. Reference this doc for more info on the differences.
Since you are using API.ai, assuming you are using the Node.js client library, use the snippet below. 'Contexts' can store data, not just serve as a flag of sorts to establish where you are in a conversation. Call setContext just before you call 'ask' and close out your webhook fulfillment.
app.setContext('<context name>', <lifespan of context>, <JSON to store>)
Then for the next round of fulfillment, retrieve the JSON from the parameters object within the Context. Get it with:
var myContext = app.getContext('<context name>')
Reference the examples in these docs for more info.
You could create an optional parameter in API.ai to catch/store this value and append any message being sent to API.ai with a marker and then the database value you want to cache, so API.ai recognizes from the marker the value to be cached as the parameter, and this would be passed back out of API.ai as well, so if you needed to chain/loop this, on your side you again just check if it has the special 'append' parameter value to append that to the next user message.
That being said, contexts can likely achieve the same end-goal you are trying to achieve in a much more straightforward fashion