This scenario creates a convenience store app so they can easily determine whether or not a customer is old enough to purchase alcohol. The cashier simply needs to post the name and birthdate of the customer AND a verified client token to a URL that’s been provided. Once entered, that will trigger our scenario to calculate the appropriate response and return it to the requestor.
Workfront recommends watching the exercise walkthrough video before trying to recreate the exercise in your own environment.
The purpose of this next walkthrough exercise is to learn about using webhooks to receive posts as a trigger and then send webhook responses as error messages or success messages, making sure that we’re not processing any type of request sent to the webhook. To have fun with this scenario, we’re going to pretend that we’ve created an app that a customer can use to determine if someone’s old enough to drink or not, very quickly. The information that we receive in our custom webhook trigger is going to be the name, date of birth and a client token. If the client token does match the specific one we’ve established, it will go down a successful path. If not, it will return an error message. Down the successful path, we’ll evaluate the date of birth and send back a response that you’re old enough or not old enough to drink. To be successful in this walkthrough exercise, you’ll of course want your Fusion system pulled up in your browser. And you’ll also want to open Postman. There are instructions below the walkthrough training videos to download Postman and set it up for this walkthrough exercise.
Let’s start by creating a new scenario titled, Using Webhooks. For our trigger, we’re going to use the custom webhook module.
Since I haven’t established a webhook already, I’m going to click the add button to create a new one. For the webhook name, I’m simply going to title this, Drinking Age App. You can see below the webhook name that you can set up a white list of IP addresses, if that’s known. In this scenario, we’re going to address unauthorized posts to this webhook, using routing. Go ahead and click save. And then to create data in our scenario that we can use to send a response, we actually want to copy our generic URL from our webhook that we just created. Click okay and then select Run Once on our scenario. Once we do that, we’ll go into our Postman, which we’ve set up already and you can follow the instructions below the training videos if not and you’ll see that in the body of a post, I already have form data set up for name, birthdate and a client token. For name I chose to put in my own name. I put in an arbitrary birthdate, which I know is older than 21 years. And then I put in 5121933, as the client token. Again, an arbitrary number that you can copy or create your own. For the post that we want to send in to create some form data for our scenario, I’m going to paste that URL that I copied from our trigger module and click send. Once I send, I can come back into my scenario and see that it’s successfully executed or received the post from Postman. If I click into the execution inspector, I can see that name, birthdate and the client token that I posted in Postman, is now available to be used in my scenario.
Now that we have information to utilize within our scenario, we’re going to create two different paths. The first path will send an error response if an unauthorized request is made without the matching client token. The second path will be if the client token matches, we’ll send an appropriate response back, indicating whether someone is old enough or not, to drink. To set up the two different paths, I’m actually going to right click anywhere and add a new module. For the module, I want to use the webhook response.
I’ll ignore the error message for now and clone this module. Connecting both of these to the trigger to set up the routing.
Our top path is going to be when the client token does not match. So we’re going to change the default status to a 401 or an unauthorized request. And then the body, I’m going to paste in a simple error message written in JSON so that on the receiving end it can be parsed if necessary. Go ahead and click okay and then set up the filter.
For the filter on this path, we’ll say the client token does not match.
And for the condition, we can map over the client token and then in the operators, go to numeric operators and choose not equal to and then our client token.
Clicking okay. For our second path, we’ll just do the reverse of the the above and choose client token does match.
Finally, let’s realign our scenario to clean it up and rename our modules. Our trigger we can call it, Receive a Post.
And our two responses can be, Error Message and Success Message.
Now that we have our routing paths set up, we need to create a success message that’s dynamic and will send an appropriate response, whether someone is old enough to drink or not. Clicking into the success message module, I’m going to leave the status as a 200 or okay response. And for the body, I’m going to create a message using the mapping panel and formula editor. For this, I’ll start typing in the words, you are and then I’m going to use an If statement and an Add Years function. I’ll find the If statement under the general functions tab of the mapping panel. And then after the first parentheses for the If statement, I’ll go to the date based section and find Add Years.
What I want to calculate is, if we add 21 years to someone’s birthdate it needs to be less than today for them to be old enough to drink. So I’ll go back to my module item list and choose birthdate.
After the semicolon in my Add Years function I’ll add 21 years. And after the closed parentheses, I’ll use the math function less than and then go back to the dates and choose Now. So someone’s birthdate plus 21 years must be less than now and we’ll send a response back, old enough to drink.
If not, after the semicolon, we’ll say, Out of Luck.
So if old enough, if their birthdate plus 21 years is less than right now, they are old enough to drink and they’ll receive that response. If it’s not less than now, meaning they are not 21 years old, then we’re going to say, you are out of luck.
Let’s go ahead and click Okay. Now that we’ve done that, let’s activate our scenario. So anytime there’s a new post, it will go down either path and return a response. We can now test our scenario by going into Postman. And as you recall, I put in a date of birth that is at least 21 years old and I can send in a post.
I see that the response I received from our scenario is, you are old enough to drink. I can test again by changing the date of birth to something that is not 21 years old, such as 2000 and send that again and I’ll see that I received the opposite response, You are out of luck. -
For step-by-step instructions on completing the walkthrough, go to the Webhooks walkthrough exercise.
To follow along with the walkthrough exercise, you need to download the free Postman application. Follow the steps below to navigate to the right area of Postman for the exercise.
Practice exercises and challenges are optional and are not necessary to complete Fusion training.
This practice exercise builds on what you learned in the walkthrough, but the solution is not provided.
Create a Workfront webhook that is waiting for new updates created and then logs the date, the name of the person who made the update, and what the update says. Email yourself this information.
Hint: Use the Workfront Watch Events trigger module to create your webhook. Also, in Workfront updates are called notes.
Challenge: Can you find and add the URL for where the update was made for easy access?