Try Step
This video will demonstrate how to use try steps when building robots in Design Studio. Applications of the try step are crucial for building robust robots acting on a dynamic web environment where changes in structure are commonplace. Use cases include trying multiple different strategies for interacting with or extracting from a website, and setting up conditional statements in a robot. We will go through two examples in this video, demonstrating the two use cases, starting with the latter.
As a first example we will be using ExtractFromTable.robot, which is a basic robot that extracts data from a table on the News Magazine website. It can be found under Robots in the Examples folder. I open the robot and hide the projects view.
Once open, you will notice that the robot has only one path to follow in the robot view until it reaches this diamond shaped step called a try step. What a try step does is set up multiple alternatives for the robot to try. A try step can have any number of alternatives which are shown as dashed arrows emerging from the right side of the try step. If an alternative succeeds the robot continues as usual, ignoring any other alternatives from that try step. If an alternative does not succeed, however, the robot goes back to the try step and tries the next alternative.
To use try steps, it is important to understand what it means for an alternative to "succeed" or "not succeed"? Let me try to demonstrate with this example robot.
ExtractFromTable is a simple robot that extracts person information from a table by using a loop. Clicking the "for each tag" step reveals the table which the robot extracts from. Inside the loop, which loops through the rows in the table, the four pieces of information from each person are assigned to different attributes of the person variable. The try step is used to assign either true or false to the isMale attribute, based on the value of the last column in the table, called sex. The column can have either of the two values, "Male" or "Female," and we want to assign true or false to the isMale attribute respectively.
To test the value in the sex column, a Test Tag step has been inserted in the first alternative. Test Tag is a step which can conduct an action based on whether the found tag matches a specified pattern. Clicking the Test Tag step we see that the found tag is the cell in the sex column of the row from which we are extracting in the current iteration, and the pattern to match is simply set to "male" and only matches against text, ignoring case. If the pattern matches, the step then does what is specified in the Error Handling Tab. Under Error Handling, the step is set to "Try Next Alternative", which is also indicated by the small icon in the upper left corner of the step. This means that if the sex is male, and the pattern is thereby matched, the Test Tag step will do what is specified under Error Handling and try the next alternative. The second alternative therefore, has a step that assigns "true" to the isMale attribute. If the pattern is however not matched, the Test Tag step does nothing and execution proceeds normally to the next step, which assigns false to the isMale attribute.
In other words, an alternative can be said to succeed if no errors which specify to try next alternative are encountered, and can be said to not succeed if such an error is encountered. As soon as one alternative succeeds, all other alternatives are skipped.
In the example I just went through, the error was generated by the Test Tag step, but usually errors are caused by steps which are unable to perform their actions. This is most often because steps cannot find a certain tag or loading of certain content times out, but it could be anything that stops a step from performing its action.
Executing the example robot in debug mode, you will see that the correct values are assigned to the isMale attribute. True values are indicated by check marks and false values are indicated by the absence thereof.
To give you an even better understanding of how the try step works, let me show a more complex, yet common, use case. In Design Studio, I have this robot which needs to log into a site and extract some data, which is only available upon login. The page used by the robot is of course the familiar News Magazine page. The robot is called Login and is available from the examples folder. If you have closed the Projects View, it can be reopened from the Window menu.
Look at the robot view to get an overview: In the login process, the robot uses save and restore session in such a manner that the robot logs into the site and saves the session on the first run. Consecutive runs will then load the saved session instead of performing the login sequence again. At some point the session expires and the robot will have to log in and save a new session. Most robot executions will thus be able to restore a session and be able to skip the entire login procedure.
So… we have three different scenarios to test for: either it is the first time the robot executes and there is no saved session, or there is a saved session which is already logged in, or there is a saved session but it has expired.
Looking at the robot view, there are two alternative paths for the robot to take, depending on whether it is able to use the stored session or not. To show each case, let's try simulating them by clicking through the robot.
The first time the robot is executed there is no saved session. The robot will first try the topmost alternative from the try step, but if I try executing the Restore Session step it will fail, since there is no session to restore. When this step fails, it will cause an error, triggering error handling which is set to "Try Next Alternative". The robot will therefore have to execute the second alternative, which follows this lowermost branch, loading News Magazine, clicking to get to the login page, entering username and password, clicking to login, saving the session for future executions of the robot, clicking again to get to the data we want to extract, and finally extracting the specific text. We have now simulated the first run of the robot.
Going back to the first step in the robot, let's simulate the second run. In all executions following the first, the session should be restored successfully, so following the topmost alternative the session is restored, the robot clicks to open the page that we want to extract data from, and finally the data is extracted - simple.
We now want to replicate what happens if the robot is executed after the login session has expired. To do this, open Logout.robot from the examples folder. The logout robot restores the saved session and clicks logout on the News Magazine page. In this way, we are emulating expiration of the login session, rather than actually waiting the 10 minutes it takes for the session to timeout and expire on this specific page. Click the end step of the logout robot to execute all steps.
Going back to the login robot, click the step named "Click site data" to make it the active step and click Refresh in the toolbar to re-execute all the steps up until the active step. After all the steps have been executed again, notice that the page shown in the browser view looks as though we are still logged into News Magazine. This is because the saved session also contains the entire robot state, including the html of the page we were on when the session was saved. Restoring the session therefore does not properly refresh the page to show its current state. Clicking on the extract step to execute the click step will however refresh the browser to show us that it is no longer logged in. The extract step therefore fails to extract the data we want, causes an error and tries the next alternative from the try step, which logs in and saves a new session for future use.
Thus, the login robot handles all three cases and thereby ensures that the robot always logs in before extracting the data which is otherwise not available.
To summarize on what we have looked at in this video, from a try step spring multiple alternative routes for the robot to take. An alternative succeeds unless it has a step that causes an error and specifies to "Try Next Alternative" in the Error Handling Tab. Only the first alternative that succeeds is executed; the others are completely ignored. If an alternative does not succeed, the robot goes back and tries the next alternative.
Here are a couple of tips when using try steps:
As we saw in the first example, any condition steps, meaning steps with "Test" in their names, work well with the try step.
If no alternatives of a try step succeed then the try step itself generates an error. Specify what action to take in the error handling tab of the try step itself.
You can give a try step a name by double clicking below it in the robot view.
When specifying to "try next alternative" under error handling for any step, you can also choose which try step to go back to based on their names. This means you can have nested try steps allowing for complex robot structures.
That concludes this video on the topic of try steps.