We're back with another full bot build tutorial. In this tutorial, we'll take you through our approach to solving the Financial Transaction Validation challenge. As always, use this as a guide to see another perspective on how to build, or as a resource, if you get stuck on your build. One of the best ways to learn is to get hands-on, so try this one out on your own (if you haven't already) and come back here when you're ready to see how we solved this one.
Challenge Page Intro
In this challenge page, FoodMart grocery needs your help to improve the way they capture their books. They have a good amount of detail on the recent financial transactions, however, the supplier’s name for each transaction is missing. For each of the transactions listed on the challenge page, participants are asked to look up the corresponding transaction in Rusty Bank and update the Supplier Name on the challenge page. Beware though - FoodMart uses Rusty Bank - who has one of the least reliable banking applications known to man. Build an automation that's able to validate all of FoodMarts transactions in spite of the fact that Rusty Bank's web interface keeps crashing.
Key Points to Solving This Challenge
Steps
We say this for absolutely every solution tutorial we do - start with just laying out the Steps of what you need to do. Not only does this build a "skeleton" of the logic you'll need to fill in (like a box of your actions/logic), but it's also a helpful way for somewhat forcing commenting logic into your automation. When you think of steps, think of "What are the key moments in this solution that I would want to highlight if I were explaining this to a business user?" - because, in fact, minimizing all of your automation logic down to the clearly named/labeled steps is a great way to explain to a non-technical user what your automation is doing.
Page Navigation Dictionary
We got a little fancy in this tutorial with the way that we navigate the pages of Rusty Bank - mainly to get you to think about different ways that you can handle repeated conditionals outside of using the If package. In the tutorial above, we demonstrated that if we paired the name of the account (key) with the corresponding DOMX path (value) in a dictionary, we could dynamically use the correct DOMX path based on our extracted account name. Will this be replicable in all of your builds? Likely not, but it's good to understand how some of the additional variable types in Automation 360 enable users to create more dynamic solutions.
Using a dictionary enables the dynamic storage and retrieval of DOMX paths based on the corresponding key
When implementing this solution in your own build, you can easily reference the correct DOMX path by providing the corresponding Account Number (key) within the DOMX path Object Property for your Recorder: Capture action.
Error Handling and Retries Left (Looping)
The most important aspect of this challenge to learn (and the key takeaway) is how to appropriately use the Error Handler. Error Handling can enable your automations to be more resilient to errors, can provide a response mechanism for issues as they occur, and can ensure that errors don't leave your Bot Runner in a hung state. There are 3 components to the Error Handler - 2 of which we leverage in the tutorial above.
- The Try block is exactly like it sounds - anything inside of this block with try to execute. If it works, great - whatever logic is next in the automation will be executed after this block as completed. If it fails, however, that's where the Catch block comes into play.
- The Catch block is designed to trap any errors that occur in the Try block. The logic in this block will only execute if an error is detected in the Try block - otherwise, the logic here is skipped.
- The Finally block is designed to execute whether the Try block is successful or not. It likely won't be used in all cases of implementing a Try/Catch, but it provides the capability to execute logic regardless of the success of the Try/Catch.
- Typically, this is used to log the final result of a transaction regardless of success/failure, or to perform cleanup on a machine regardless of success of the automation run (closing all applications, clearing out any temp files, etc)
The only real shortcoming of using Error Handling on its own (especially midway through an automation like we're doing in this tutorial) is that on its own, it doesn't try transactions again. If there's a failure, the Catch block executes, but it’s up to you to determine what to do next - try the transaction again, move on to whatever's next, log the failure, etc.
The video tutorial above walks through the process of implementing a "Retries Left" loop around the Error Handler to attempt to retry the current transaction up to X (3 in our case) number of times before moving on to the next transaction. Line 10 establishes our Loop with a set counter of 3...meaning we would try any transaction a maximum of 3 times. Line 11 is the start of the Try/Catch Lines 12-14 are trying to navigate through Rusty Bank, search for a transaction, and read the corresponding table response. Line 15 is a break for our loop. This line is important to the efficiency of executing a Try/Catch with Retries left. Break will automatically break us out of the current iteration of the loop. So if lines 12-14 all executed without error, Line 14 breaks us out of the Retries Left loop, and would enable us to execute whatever comes after our Try/Catch. IF, however, there is an error on 12-14, the break wouldn't be executed, and instead, we would hit the Catch. Line 17 is the first line inside of our Catch block, and its set up to click the "Take me to the Login" button from the 503 Error Page. Line 18 executes the Login Subtask that we'd used at the beginning of the exercise to log-in to Rusty bank. Because we're in a loop, after line 18 is executed (in the case of an error), the focus of our code jumps back to line 10 where we start the second iteration of our loop (of a total of 3) and attempt the logic from lines 12-14 again.
Conclusion
Obviously, we all got a bit frustrated seeing the 503 train pop-up when trying to navigate Rusty Bank or do our Capture steps to look up a transaction. The purpose of this challenge, though, was not to frustrate you so much as to enable you to practice and built familiarity with important concepts around dealing with automation resiliency. The fun doesn't stop here though! As we mentioned in the video, there are lots of different ways to solve this challenge. Once you've got a build that works, try injecting JavaScript to go through the exercise, or consider reading all of the transactions from the challenge page into a DataTable before trying to look up each transaction in Rusty Bank. Trying out these various approaches makes for a great learning exercise, and will surely help you in future automation builds. Happy building - Go Be Great!