Best practice for passing browser variables

[Alistair_Bangera]

Hi, I was using browser variables to work on a browser window across multiple invoked workflows. For this, I need to pass the browser variables as input or output parameters wherever applicable to the invoked workflows.

When I am using the RE framework, I might have to modify the various predefined workflows in the framework just to add browser variables as in\out arguments. Is this a preferred method, or should I just attach browsers in the called workflows using selectors.

Knowing the preferred\better method will be helpful. Thanks in advance!

[Lahiru.Fernando]

HI @Alistair_Bangera

This is what I do in my REFramework solutions.

I do not use the browser variable approach anywhere in my solutions. In all the projects that I have done, I have used the attach browser activity and using the selectors I have given the command to attach the browser. But I have made sure that the selector is use there is dynamic and will not fail at any point. So basically, whatever the page it is in, it will attach the browser without any issue. I believe this is the easiest and the best option than passing the browser variable.

but that’s just my idea…

[ClaytonM]

There’s nothing wrong with that approach @Lahiru.Fernando, but I believe the idea of Attach browser or Attach window is that it allows you make an update in only one location if a drastic change to the window occurs, such as the Title completely changes in order to identify the correct scope.

(I must say I prefer Window over Browser, because there are more useful activities for Windows)
@Alistair_Bangera
My idea is that each task that you want to perform should be a workflow that you invoke. And, in each of those workflows, they should be invoking the login workflow for that particular application or portal which is built in a way that returns the application’s window variable or selector string (it doesn’t matter which one), and the login script will be able to attach to existing windows or open a new window and login if it doesn’t exist; it can also throw a business rule exception if the login info was invalid. So, therefore, you don’t need extra logic when you decide to use the workflow for various projects, because each task/invoked workflow will be able to handle the login part.

Here’s an example of what I mean…
Let’s say you have a login script for a portal. The logic might look something like this:

Element Exists 'look for the existing window already logged in'

If Not elementExists
'Login if no exists'
    Get Credentials
    Retry Scope to close all instances of application 'so can be run standalone'
    Open Browser
    Login 
    Element Exists 'wait for successful login'
    If Not elementExists, Then Throw BusinessRuleException
    Navigate to main page, if needed
Else
    ElementExists 'check if on correct main page
    If Not elementExists, Then Navigate to main page
Attach Window to return main page in variable

The above is just some rough quick ideas for Login script. I might also suggest in the Login workflow that the selectors are stored in string variables.

So, with a really good Login script, then you don’t need any added logic, and will only need to invoke this.

Let’s assume you need to download an invoice…
You can call your workflow, PortalName_DownloadInvoice.xaml
The logic might look like this:

Invoke Login workflow
Attach Window
    Search for Invoice 'search criteria and invoice number is from an IN arguments'
    Element Exists 'Check for Not Found'
    If Not elementExists
       Download latest invoice
       Wait for file to exist and Log success
    Else
       Log Not Found

Hopefully, I described this well enough for you to understand. This is kind of how I have been approaching invoked application automation, and allows my projects to only need to invoke one thing and simplify things a bit. While at the same time, if a change to the application’s container selector occurs, an update only to the Login workflow is needed.

Regards.

[Lahiru.Fernando]

Wow @ClaytonM

Thank you so much for the explanation. I learnt something new today!!!

You are the best!!
Thanks again bro for all that great info…

[Alistair_Bangera]

Thanks for the inputs Lahiru.

[Alistair_Bangera]

Thanks for the detailed response Clayton, this certainly helps.