WEB AUTOMATION - Lesson 3: Data-driven web automation

  • How to work with the different approaches to data-driven automation, including using databases, web services, and command line scripts.
  • How to use Excel as a data source for an automation flow. 
  • How to parameterize a sub-flow, making it even more reusable.
  • How to use the Strategy Editor for modifying the selector strategy for capturing web elements.
Go to next video.

You will learn:

  • How to work with the different approaches to data-driven automation, including using databases, web services, and command line scripts.
  • How to use Excel as a data source for an automation flow. 
  • How to parameterize a sub-flow, making it even more reusable.
  • How to use the Strategy Editor for modifying the selector strategy for capturing web elements.
Go to next video.

TRANSCRIPT

Welcome to the third lesson in web automation with LEAPWORK

In the previous lessons we have looked at how to create a basic flow
and how we could turn part of the flow into a reusable, parameterized sub flow.

In this lesson we will drive the flow with data from external data sources.
This means remove any hard coded values from the flow and get the data from one of the sources
supported by LEAPWORK.

If we look at the flow we built in lesson 2, we have 2 Set Text blocks containing
hard coded values for email and password. On top of this we have a Find Web Element
block that looks for a specific name to verify that the login was successful.

We can expect that if we change the email and password,
the trivial name of the logged in user will change as well.

So, if the email and password is coming from an external data source, so should the trivial name.

In this lesson we will use Microsoft Excel as the external data source,
but LEAPWORK has building blocks to handle more or less all types of external data,
including databases, web services, powershell scripts, bat files etc.
You can find more about this in the advanced section in our Learning Center.

To read the data from an Excel sheet,
we add a Read Excel block before the login block

In the Excel building block we can choose to either upload an excel file
or point to an Excel sheet on the local computer or on a network path.

I have prepared a file in advance and when the path is specified
I click on "Define" to specify the data range we will use to drive the flow.
We have 3 columns in the sheet - "email", "password" and "display name" and 3 data rows.
I'll select all of them and check the "Use first row as header".

When we click Save, we can see that the building block understands what fields or columns
are available for the individual data rows. All the headers in the Excel sheet
is now exposed as individual properties on the building block,
allowing us to easily use them as input in the flow.

We can now connect the email property on the Excel block
to the email property on the sub flow,
and do the same with the password field.

When the flow is running, the Excel block will read the data,
and when the login block is about to execute it will get the data from the Excel sheet field by field.
Very easy to configure and very easy to understand just looking at the flow.

One thing more thing we can configure on the Excel block is the way the rows are provided.
The default method is to just read the first row in the selected data range.

The second option is to read a specific row, by specifying the row number.
This mean you can keep all the available credentials in one excel sheet,
and then just specify a row number to use a specific set of credentials to login.

The third option is Iterate, which runs through all the data rows in the selected data range
and triggers the top connector for each data row.

The flow attached to the top connector will be executed for each data row in the data range,
and once all data rows have been processed, the Completed connector is triggered,
allowing the flow to continue.

An example of using Iterate is to keep a list of item ids that need to go into a basket in an Excel sheet.
The attached flow will read the ItemID, search for the product and add the item to the basket.
After all items are added to the basket, the flow continues from the Completed trigger
to checkout, payment etc.

The last thing to do in this flow,
is to make the verification that the login went well,
dynamic as credentials provided.

This brings us to the concept of locator strategies.
When we capture a web element,
LEAPWORK generates a so-called strategy to find the captured element.
The strategy is based on one or more properties that will uniquely identify the element,
when the flow runs.

Examples are the ID of a field, the text inside in a text box, the destination of a link
or maybe a combination of these properties.

We can get access to the strategies and also modify the strategies by clicking on the captured element
and select "Edit element". This will open the strategy editor.

On the left we have a list of strategies.
When we capture an element, LEAPWORK creates a number of different strategies that all return the same element,
but is doing it in different ways.

On the right we can see the actual element and the details for selecting the element.

The first strategy is based on selecting the SPAN tag on this simple demo web page.
The second strategy is also based on the SPAN,
but in this strategy the conditions states that the SPAN should contain a specific text.

We can use this strategy for the dynamic verification of the login.
Instead of looking for a hard coded text inside the span, we can add a dynamic field
allowing us to inject the text that we want as part of the strategy.

Clicking on Save means that the selected locator strategy will be used
and that the dynamic field is added as a property to the building block holding the element.

With the dynamic property available it's easy to wire up the last field from the excel sheet,
to make the automation flow entirely data driven.

Let's try to run it using row 2
I'll select "Row index" as the method,
and use a Set Number block to specify that we want to use row number 2.

Let's run the flow.

$$$ Run the flow

As we can see in the activity log, row number 2 was used and the flow ended successfully.

In the lesson we looked at different data driven approaches including using databases, web services and command line scripts.
We saw a demo of how to use Excel as a data source for a flow
and how to parameterize a custom building block, making it even more reusable.
We ended by having a look at the strategy editor, which is used for selecting and modifying the
selector strategies for captured web elements.