ExtractFromTable is a simple robot that extracts person information from a table by using a loop. Clicking
the “for each tag” step and scrolling down reveals the table which the robot extracts from. Inside the loop,
which loops through the rows in the table, the four pieces of information for 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 one of
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 has been 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
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 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