I'd like to know if I can make 2 webhook calls at the same time.
I have two cloud functions: 1) Inserting a user 2) Capture user inputs
How can I go about that using webhooks on watson assistant?
(I've already posted this question on the IBM developer forum but didn't get an answer.https://developer.ibm.com/answers/questions/520504/is-it-possible-to-make-two-webhook-calls-at-the-sa.html)
Right now, there is only a form to add a single webhook to the dialog node. The reason is that each call returns values which then need to be processed by the node. Thus, you cannot make them in parallel.
If you want to make two calls for the same input data, you could do one of:
make a master webhook that then calls the other webhooks
define a sequence of actions to be processed and which is called from Watson Assistant
first call one webhook, then have a dependent node which is processed without user input, from that node perform the second webhook call
There are probably even more options, it depends on the call semantics and whether your webhooks are dependent on results / inputs or not.
One of my code samples uses a dispatch semantic to call other functions. It can be done within the same action as shown for simplicity, calling into other functions (using composer) or using REST calls into other webhooks.
Related
I am not sure I understand the difference? The way I understand it so far is that CHECKOUT.ORDER.APPROVED comes first and once the payment has been processed properly, it moves onto PAYMENT.CAPTURE.COMPLETED (based on this answer and this). So there could be an approved checkout without a completed payment capture, which means, that I should wait for PAYMENT.CAPTURE.COMPLETED before giving users access to content behind paywalls etc.
If this is true, can I generally rely on them coming in this order (e.g. for my webhooks)?
For example: Say I create a new order in my database, when the webhook for CHECKOUT.ORDER.APPROVED is triggered. Now in the webhook for PAYMENT.CAPTURE.COMPLETED I want to continue working with this data. Can I be confident, that this order will exist in the database at this point?
CHECKOUT.ORDER.APPROVED means a payer approved an order. It does not mean it has been captured, and any number of things could interrupt the capture. In general this event is best ignored / not subscribed to -- there is nothing useful to be done with it. Storing orders in your database before successfully capturing them is largely pointless.
PAYMENT.CAPTURE.COMPLETED indicates a transaction has been created. This is more useful. However, since it's an asynchronous notification it's generally only useful for payments that will take place in the future, such as Subscriptions.
For one-time payments, there's no need for webhooks. Just use the v2/checkout/orders API and make two routes (url paths) on your server, one for 'Create Order' and one for 'Capture Order'. You could use one of the (recently deprecated) Checkout-*-SDKs for the routes' API calls to PayPal, or your own HTTPS implementation of first getting an access token and then doing the call. Both of these routes should return/output only JSON data (no HTML or text). Inside the 2nd route, when the capture API is successful you should verify the amount was correct and store its resulting payment details in your database (particularly purchase_units[0].payments.captures[0].id, which is the PayPal transaction ID) and perform any necessary business logic (such as reserving product or sending an email) immediately before forwarding return JSON to the frontend caller. In the event of an error forward the JSON details of it as well, since the frontend must handle such cases.
Pair those 2 routes with this frontend approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server . (If you need to send any additional data from the client to the server, such as an items array or selected options, add a body parameter to the fetch with a value that is a JSON string or object)
I want to make a simple post request in google actions to a self hosted web server and I cant seem to figure out how to do that. I cant find much in the documentation and I dont have access to inline cloud functions either.
What you're looking for is sometimes known as a webhook or a handler or handling fulfillment in the documentation.
You'll configure the overall Action with a single webhook URL. For specific Intents (in Dialogflow) or as part of a Handler when in a scene in Action Builder, you can specify when the webhook should be called. It will be called with a JSON body that is specific to Actions on Google (and differs if you're using Action Builder or Dialogflow) and expects a JSON response in a specific format.
For details about all of this, consult the documentation for webhooks in either Action Builder or Dialogflow.
I want to know about webhook (what is webhook). What is the application of webhook (a real world scenario). Besides, what are the differences between webhook & API?
An API is a standardised way of communicating with a service. You've tagged REST in your question so I'll focus on RESTful APIs using HTTP but it is important to know that API is a very generic term.
In the REST world everything is a resource and you use the HTTP methods to define what action you want to take on or apply to that resource. For example, to list all the users on GitHub you would send a GET request to https://api.github.com/users. The URL (specifically the /users part) defines what resource you are interested in. Here the resource is a collection of all the users. There's other methods you can use; such as PUT to create or update a resource. To learn more about the different methods you can read the HTTP specification.
Webhooks are often used in conjunction with APIs but they are focused on events. They allow a service to send out 'notifications' when an event happens or some condition is met.
GitHub is again a good example of what webhooks are used for. Say I'm building a service which sends out an email every time someone leaves a comment on an issue in GitHub. I could use the GitHub API (like above) to list all of the comments on an issue and then check if there have been any new comments since the last time I checked. I can then just repeat this request every few seconds. This is known as polling. The issue here is that most of the time I'm checking the result is not going to change. This is going to be a waste of resources.
Webooks allow for Event-Driven Programming. Instead of randomly checking I can instruct GitHub to send my service a HTTP request every time a comment is added: aka a webhook. In this architecture I only have to send a request to GitHub's API when I know for sure that a new comment has been left.
Overall, you cannot really compare APIs and webhooks. The link between them is simply that webhooks send requests to APIs.
I want to use Dialogflow fulfillment to connect to an external webservice / API. One way of doing that is to use the custom webhook feature (not the inline web hook). However, when using the custom web hook it seems that you are limited to creating just one even though you may have many intents and you may want to call many endpoints. Is there a way to link to more custom webhooks (API endpoints)?
If you can only set up one web hook then your webserivce will always receive a Post request from Dialogflow and will then need to interpret the body of the request i.e. based on the intent parameter. Just wondering is there a better way to work with REST webservices with Dialogflow.
The other potential option is to use the inline web hook and then put logic in there to call specific endpoints, however, that might get a bit messy.
You can only setup one fulfillment that will handle the processing for all the Intents you've enabled. This can be either the built-in one through the fulfillment editor or at a webhook URL you specify.
That webhook is expected to delegate the actual processing to an Intent Handler of some sort. The Dialogflow node.js fulfillment library has a way to register what handler you want for each Intent name, or you can switch on the Intent name, the Action name, or any other field provided to you in your code.
In the library, you'll typically make the REST calls from an appropriate Intent handler which will take the parameters provided and craft the call. If you are using Javascript, make sure you are handling the call asynchronously and return a Promise.
I recommend a webhook because it gives you more control than the inline editor does. The inline editor is really just a webhook under the covers using Firebase Cloud Functions. Even putting it yourself in a Cloud Function gives you better control over it.
There may be costs depending where you host it, however Firebase has a free tier that is sufficient for testing and light operation. Once your Action is published, you are also eligible for a monthly cloud credit from Google.
I have been pondering about this for a while now and been unsuccessful in finding any information on the topic of subsequent api (ajax) requests.
Let's say we have list of users and one of them is updated. After updating the user, I would like to retrieve the entire, updated list of users.
My question regards two actions:
Update user
Retrieve all users
It is clear to me, that the React component initiates the view action to update the user resulting in an API request via the dispatcher. What isn't clear to me is where the second request to retrieve the users happens.
Looking at Facebook's Chat example...
Does it happen in the web API utils?
Does the store do this after it has been notified of the update?
Does the component do this after it has been notified of the change?
Currently I would do this in the API but I would like to know if there are any tested pattern for solving this problem.
You don't need two actions doing two XHR calls. You actually want just one action that results in two XHR calls. Beware of the tendency to think that you should cause a cascade of actions -- this is exactly the anti-pattern that Flux was created to avoid.
The side effect of updating the entire list of users should be something the UserStore is doing in response to the USER_UPDATED action.
The UserStore will update the user record. This can happen either optimistically or after the server call completes. The XHR call to update the user server-side can happen either within the updateUser() action creator or within the store. However, you will need to create actions for the success/error of that call, so that the store can respond appropriately.
The next step, again, can happen either optimistically or after you get the data back from the server. The store, in this case, would make a XHR call to retrieve the list of users to update all the relevant records it holds.
But like the last XHR, you will want to create two new actions based on success or error of this second XHR.
Creating new actions keeps your application very flexible and resilient. So that if any other store ever needs to know about the result of these XHRs, it will already be receiving that data.
I'd be remiss if I didn't mention that, if you have control over the server-side code, you should simply build an end point to update the user and return the new list of users -- this would make the client side code much simpler and the entire thing would be more efficient.