I need a Dialogflow agent to query multiple times a REST webservice (endopoint) outside the Google Cloud.
Documentation, tutorials, everything points to enable fullfillment and on the intent that will trigger the network request, enable "webhook call for this intent".
Well, on the fulfillment panel, enable Webhook, and paste custom endpoint URL, and pass parameters from the context, auth parameters (to the endpoint, ), headers...
However when calling the intent, I noticed no network activity related to the webhook. So, the custom webhook is not invoked. Which is the first point of my question: How to trigger or make that when an intent is succesfully matched, the desired webhook is invoked.
I have no issues with the backend, endpoint, it's OK, works well via Postman, curl,... from any service.
My real issue is why, my custom webhook is not triggered, say no network activity, no fetch, no ajax, no nada. NO webhook request. I need to see at least a network request to the custom endpoint, no matter the type of response or the payload, this is not the matter of my question. Just how to send custom webhooks requests and send many, triggered for different intents. As far as I can see, only one custo webhook/endpoint is available.
Should it be invoked via events?
It sounds like you have several questions in there. Let's try to break them down.
Why isn't my webhook being called?
You don't show screen shots of your Intent or your configuration, but the most common reason why a webhook isn't called is because, although you have set the fulfillment URL, you haven't specifically enabled it for the Intent.
Make sure in the "Fulfillment" section at the bottom of your Intent, you have turned on "Enable webhook call for this intent".
That's good for one Intent. How do I set a different webhook for each Intent?
You don't.
Each Dialogflow agent can only call one webhook. The information sent to that webhook includes the Intent Name that is triggering it, and the webhook is expected to take appropriate action based on this name. The exact function that the webhook calls is sometimes referred to as the Intent Handler.
What if I need to?
Then you'll need to write a layer that handles the fulfillment dispatch from Dialogflow, verifies the request, extracts the Intent Name and other parameters from the JSON that is sent, makes the call to the other REST endpoints as appropriate, get the result back, and possibly format the results back to Dialogflow.
Can events help with this?
I don't see how.
Intents that are triggered by an Event work the same way as those that are triggered by user phrases. All Events in an agent still call the same webhook passing the same information.
Events are really most effective to represent exactly that - a user action rather than a the spoken or typed input from a user.
Related
Let's say I have a desktop app that listens to a user, and leverages Dialogflow to determine intent.
In the app, we just call:
https://dialogflow.googleapis.com/v2/projects/my-project-name/agent/sessions/123456789:detectIntent
Let's also say the active user is "UserX" in our system, and we need to retrieve information specific to the account.
I understand that Dialogflow utilizes webhooks for fulfillment as described here:
https://dialogflow.com/docs/fulfillment/how-it-works
However, I'm unclear how user information can be sent to our webhook such that we'll be able to tell that "UserX" was the one who made the call to Dialogflow.
Can anyone explain if/how communication of user information is supported in fulfillment webhooks?
It is supported by fulfillment. There are a number of ways you can do it. Assuming that the user has communicated with the agent, the agent can then store the users response i.e. lets assume the agent asked the user what their name is. Since the agent can store that info (UserX) in a parameter, that parameter can then be passed to the fulfilment. The agent can also store user responses in context parameters and they can also be passed to the fulfilment. Finally even if the user does not provide info to the agent you can also use the dialog flow API to pass data to the agent which in turn can be passed to the fulfillment.
I am trying to build a bot service using google's dialogflow. I have already written an intent and that is having a web hook and static responses also. My question is how does dialogflow decides between static responses and whether to invoke the webhook?
If you have a webhook defined, and you have the "Enable webhook call for this intent" switched on, it will call the webhook. If your webhook returns a response, it will send that response to the user.
If you have the switch off, or if your webhook does not return anything (either because it times out or you choose not to send anything), then it will use the replies you have set in the Intent.
I have an intent in which I have few responses and webhook enabled. I don't understand how the webhook gets triggered all the time and not the static responses mentioned within intent.
How does the API.ai differentiate when to trigger webhook and when to return static response.
Thanks,
Janmajay
API.AI allows you to connect to third party services using webhooks. If you enable the webhook, then the API.AI will always ask the webhook for the response and will show you the response received from webhook.
If for some reason, the webhook query failed, then only the static text response will be displayed.
If however, you don't want to use webhook and instead want to show the static response then you just need to uncheck the webhook checkbox. After that, the static response will be displayed to the user always.
I wanna build a small workflow using Azure Logic Apps that contains an "Approval" step, which is simply an API call in my own system, similar to office 365 approval connector.
However, from what I found on the internet, the only way to make a long running task in Azure Logic Apps is to use Webhooks.
In Webhooks, I could not set a value to the parameter I created "Bool-Approved".. so, How can I check it later in a condition step?
The other possible solution maybe is to use Swagger to have an "Bool-Approved" parameter. However, it does not support long running action!
What's the possible solution for me?
As you mentioned, the way to do it is to use the Webhook action, and for that you need to implement the Subscribe/Unsubscribe pattern described here. The webhook action will allow you to get any payload (via an HTTP Post) from the instance-based webhook you are subscribing to.
The points below are a summary of this blog post:
https://www.mexia.com.au/correlation-identifier-pattern-on-logic-apps/
To implement the Subscribe/Unsubscribe Webhook pattern you need to consider:
Subscription store: A database to store the unique message Id and the
instance-based callback URL provided by the webhook action.
Subscribe and Start Request Processing API: this is a RESTful API that is in charge of starting the processing of the request and storing the
subscription.
Unsubscribe and Stop Request Processing API: this is another RESTful API that is only going to be called if the webhook action on the main workflow times out. This API is in charge of stopping the processing and deleting the subscription from the store.
Instance-based webhook: this webhook is to be triggered by your own custom approval event. Once triggered, your webhook is in charge of getting the instance-based callback URL from the store and invoking it. After making the call back to the main workflow instance, the subscription is to be deleted. This is the webhook that is in charge of sending the payload you require to the waiting webhook action in your Logic App.
The subsequent actions will be able to use that response body, so you can implement your conditions, etc.
You can follow the blog post mentioned above to see a detailed example and get more details on how to implement it.
make you api return HTTP code 200 if the response if "ok" and 400 if the response is "not ok". This way you can force logic app to behave the way you need it to behave..
I am using Stripe and I need to understand how to only process webhooks that are generated by Stripe behind the scenes. When my server sends something to Stripe (new subscription, new individual charge) Stripe will generate events that are sent via the webhooks I provide. Well, I don't need to process those since it will create a mess. I only want to process Stripe generated webhooks in situations like: failed charge at subscription renewal, manual modifications via the Stripe dashboard, refunds generated in the dashboard, etc).
I went through the events generated and I cannot find anything that would make a difference from those my API calls generate or those generated behind the scenes.
Is there something I am missing?
Update
- API call: event has a request id
- Stripe behind the scenes: event has null request_id
- Stripe dashboard: event has a request id (This still remains a problem)
If I discard all webhook events that are not null I will also discard Stripe dashboard events. I need to process Stripe behind the scenes and also Stripe dashboard generated events.
First of all, Stripe currently does not support identifying the incoming webhook event type. Looking in the Dashboard I indeed can see what initiated the event (API, Dashboard or Automatic) but Stripe's people said they don't support it.
However, there is a workaround. For anyone struggling with this I will describe what I did. An automatic Stripe generated event is easy to differentiate. It contains a null request field. Any other type of event will have a request id (ex: re_123h2kj18321hjk3218). The problem remains with differentiating between API and Stripe Dashboard generated requests. Therefore, the solution is to capture the request id for every request generated by the API. Whenever a webhook arrives to your server, you check for the request field NOT to be in the Storage System (DB, etc) OR that the request is null. This means that the event was generated by either the Dashboard or Automatically by Stripe (subscription renewal).
Steps:
Hook into the CurlClient provided by Stripe. Extend that class and
override the request() method. The request method returns the
response generated by Stripe servers. Capture the headers of the
response which would contain a Request-id. Store that in your
Storage (in my case a DB)
In your configuration files you need to specify that Stripe should use your own CurlClient. ApiRequestor::setHttpClient(new CurlClient()); (I've named my CurlClient too but you can name it whatever)
When a webhook arrives, you have three options to identify the type:
Automatic: if the event has a request=null
Dashboard: the request is not null and the request is not in you Storage
API: you're left with one situation. The request is not null but exists in your DB
As you can see, there's quite a lot of work for something really easy. All Stripe needs to do is provide another field in their webhook event name something like request-type with three options (api, automatic, dashboard). They already have this build but they don't allow it to be shown in the webhook event.
On the event object documentation, you'll see the request property documented. This property is set whenever the event came from an API request. Otherwise, if it's null it means there was no API request associated with it and it was what we call an Automatic event in the dashboard.
You need to discard any event where request is not null on your end!