Error handling walkthrough

Transcript

The purpose of the next walkthrough exercise is to show you the default error handling capabilities within scenarios, as well as how to add directives to individual modules. The examples we use aren’t necessarily practical, but are meant to teach the principles behind functionality. To be successful at this walkthrough exercise, you’re going to clone your creating different paths using router scenario, and you’ll also want to remember that you can access your execution history by clicking out of the designer and into the history section of that scenario. We’ll be intentionally creating errors in this scenario as you can see, and coming in and viewing the details of an execution with an error.

Let’s start by cloning our create different paths using routers scenario.

We’ll name it create different paths using routers - Error Handling Test.

First thing I want to highlight was from tip number one that every time you run a scenario it’s going to verify that all the connections in all the modules are not broken and are working correctly. What I’m going to do, and I recommend that you do not follow along at this point, is I’m going to go ahead and delete my Workfront connection.

If I go into my connections area I can come in and delete that Workfront account.

It will of course give me a message saying, “Are you sure you want to continue?” But I’m going to ignore that error and go ahead and click okay.

Now, if I go back into my scenario, click run once, we’ll see that my scenario doesn’t even try to execute one time, and in my scenario log down here at the bottom, I can see that the connection was not found. To establish this connection, I need to click into at least one of my Workfront modules and add my connection.

What you’ll notice here is that once your module panel loads, most of your setup remains intact. It remembers how you set up that module, so we just need to reestablish the connection. I’m going to go through and do the same for the other connection here.

Once I fix all of my connections, I can run again just to make sure everything is working correctly and as we can see it is. Now I want to run another situation to test the default error handling. I’m going to come into that bottom Workfront module and I’m going to intentionally mess up the Workfront ID.

I’m going to add three Zs to this project ID here and click okay.

And of course, that’s not a valid Workfront ID so when I click run once, run the scenario again, you can see that once it comes down this third path it catches this error and the scenario is then stopped. I can click into the execution inspector bubble and as you can see, I have what they’ve labeled a RuntimeError. Let’s go ahead and fix this and try creating another error in one of the HTTP modules.

Clicking into my Get Pokemon info module, I’m going to add the same three Zs to the character name in the Pokemon call.

I’ll click okay and run the scenario again and we’ll see what happens.

Here we see a more immediate error and cancellation of the scenario run because it’s involved in the very first path within the scenario. Clicking on the execution inspector, we see a 404 error again, and then down in the URL we can see of course that we’re using a Pokemon name that does not exist within the API. Let’s go ahead and fix this as well.

Although we don’t see it while the scenario is running, if I go down to my scenario settings at the bottom of my panel and click on show advanced settings, I can see that the number of consecutive errors is three, which is the default number.

This is the number of times that Fusion will try to execute on an error before it quits. We’ll click okay and we’ll save our scenario and now we’ll go into the history panel.

We can see the two errors that we simulated on the Workfront module and the HTTP module. If I click into the details of an execution history that’s labeled as an error, I can see in the simple log how the scenario was ticked off and where the error occurred. I can also, in the blueprint of the scenario in the history panel, click into the scenario error message and understand what’s going on.

Let’s return to our scenario designer for creating different paths using routers error handling tests to add error handling to a specific module, like Get Pokemon info. I can right click, and the third option down from the top is add error handler.

You’ll notice that at the top of the panel that appears, we have our five different directives listed. Below that we have different apps already in use in our scenario labeled as favorites. If I choose rollback, commit or ignore, you’ll notice that there’s no additional options or fields that we have to set up to use this type of error handler. If however, I remove this, and let’s say I add an error handler such as resume, you’ll notice that I now need to supply information that will help the Get Pokemon info module run correctly. This panel will have different fields necessary depending on the module that you’re adding the directive to.

You’ll notice that the directives will appear hollow or transparent, the same with a line that connects them to their module. You’ll also notice that we still maintain the path above, where, if an error does occur, we’ll use the resume directive to correct the information passed into the module and then we’ll continue on and execute the next module. If I come down to my Create a task module and add an error handling here, let’s say that we actually want to do something different within Workfront so instead of using one of these set directives up here maybe I want to update a record with a note or some other type of information indicating that an error has occurred when I tried to create a task.

You’ll notice that the module itself is not hollow but the connecting line is. You’ll also notice that if I move this I still have a connection point for another module so I can still create another path for when errors do not occur.

Remember that when you use certain error handling directives, in the execution history, they’ll either be labeled as a success, a warning, or an error. In the next course will learn more about storing incomplete executions and how you can go into the incomplete execution for a scenario and resolve an error manually. -