What are the Best Practices to Automate vSphere Web Client 6.0 & Plugins

Thameemul Ansari Sep 09 - 6 min read

Audio : Listen to This Blog.

This blog walks you through the different phases involved, in order to automate Flex vSphere Web Client & Web Client Plugins. Also this blog provides developers with the ability to create applications that use the customized selenium Flex Automation APIs.

Constraints in automating Flex Application compare to any standard Web Applications

In order to interface with the Flex GUI Widgets, Adobe provided an external API, which enables interaction between action scripts and the Flash Player Container – for example, an HTML page with JavaScript. Adobe recommends using ExternalInterface for all JavaScript to ActionScript interaction.
For Example: Function call b/w ActionScript function in Flash Player, JavaScript function from the HTML page is possible through the use of ExternalInterface.

Flex Automation Tools

Following are the set of tools that support the Web Based Flex GUI Automation. Let’s take a look at each one about their nature and pros & cons.

Tools Pros & Cons
Open Source
Selenium Flex API Automates Flex mx components, but need to extend APIs for supporting spark and other custom made components.
MSYS FLEX Automation Tool Automates most of the Flex Components including mx and spark, but has a problem in automating VMware pop-up and dialogs
Open Script Automation based on mouse coordinates
Genie Observed that it has a support for Flex components which needs to be extended and compiled.
Proprietary
Ranorex($$) Automates vSphere Web Client with trial build. But it has language support only for VB Script and C#.
RIA($) Test Complete($$) Silk Test($$$$) Involves statically compiling Test Agent and automation libraries with source code of application under test.

Automation Approaches

Incase if we are moving forward with the open source tool choice, then there are numerous challenges, which have to be mitigated for automating the web based Flex GUI application.
Let’s take a look at a couple of different approach to mitigate the challenges:

1. Dynamic Loader

  • It is a wrapper with dynamic loading capability to load the Flex application’s SWF file.
  • This loads the entire Flex Application, which was instrumented to enable the record and playback capabilities.

Identified issues in using Dynamic Loader (VMWare specific):

  • Able to automate most of the VMWare components.
  • Encountered a hard problem while automating dialog and pop-up windows, which involves scenarios like create, edit datastore etc, of VMWare components.

Analyzed and found that “usage of FlexGlobals.TopLevelApplication()” function by VMWare Dialog, Popup Widget ends up in making a call to its parent application(VMWare). Since we are loading the entire vSphere Web client page into the dedicated custom loader [which is the parent application]. The above mentioned case fails always and cease the loading of Web based Flex GUI.

Static Compiling:

  • Requires access to the source code of the Flex Application under test.
  • Compile the application with the automation SWC files by using the compiler’s include-libraries option.

Problem encountered in dynamic loader approach is not applicable here. This is because, there is no loader involved in this approach, as we are compiling the automation libraries inside the source code of the application under test.

Pros & Cons of above mentioned approaches:

Dynamic Loader Static Loader
Able to automate Flex mx and spark components Open source tool has support only for mx components. Can be extended to support spark components
Able to automate most of the Flex Components but having problem in automating VMware pop-up and wizards Easily automate pop up and wizards, since there is no loader concept in this case
Need to load the entire application into a loader, which in turn has necessary automation libraries for record and playback Loader concept is not involved here, thereby we can test the functionality by launching the web client in browser
No need to have source code, as the application will be tested inside a loader Need to have access for the source code of the application under test, in order to compile the same automation libraries

Automation Approach Selection:

VMware suggest to choose the static loader approach to mitigate the problem with dynamic loader approach and added capability from SFAPI [Open Source]. VMware supports by extending Selenium Flex API to support Spark and VMWare custom components.

Short Note about Selenium Flex API:

An open source tool, which has the capability to automate vSphere Web client, as it requires their automation API (sfapi.swc) to be compiled with VMware/VC Plugin source codes. This tool has been extended by VMware, in order to support Spark and VMWare custom components.
This tool can also be expanded with required automation libraries, compiled and deployed to generate a custom build, to support automation of VMWare and other required components.
Also to automate components, properties of flex components to be identified, which can be achieved by Flash Inspection Tools whose library file(swc) were also needed to be compiled along with the above mentioned custom build.

Reference:
SFAPI Source Code: https://github.com/hirsivaja/sfapi

vSphere 6.0 – Requesting Custom Build from VMWare with extended support to add third party Automation Libraries

VMWare provided a custom build, which have extended support to include third party Automation Libraries like SFAPI. This custom build does not have support for automating Spark and custom components.
Hence there is a need to extend SFAPI framework to support automation of Spark and Custom VMWare Components. This involves the below mentioned work to be performed in order to enable automation support for vSphere 6.0

  1. Extending SFAPI:
    a. Need to extend existing SFAPI Framework with libraries for automating components which doesn’t have support in the existing SFAPI. This includes spark and other custom components.
  2. Inspection Tool Library: Monster Debugger(.swc)
    a. Respected swc were also need to be compiled along with custom SFAPI.
  3. Enable Automation Support in vCenter Server:

Reference:
vSphere 6.0 Build Steps from VMWare:https://communities.vmware.com/thread/520914

Web Client Not Ready for Automation:

Web Client Ready for Automation:

Vsphere Web Client

Sample Automation Script:

@BeforeClass
   public static void setupClass() throws Exception {
      // Initializing Selenium Server
      remoteControlConfiguration = new RemoteControlConfiguration();
      remoteControlConfiguration.setTrustAllSSLCertificates(true);
      seleniumServer = new SeleniumServer(
            remoteControlConfiguration);
      // Selenium Server Start
      Seleniumserver.boot();
      Seleniumserver.start();
      // Selenium Start
      selenium = new DefaultSelenium(SERVER_HOST,
            Integer.parseInt(SELENIUM_PORT),
            FIREFOX_LOCATION, VC_URL);
      selenium.start();
      selenium.setTimeout("30000");
   }
@Test
   public void sampleTest(){
	// Enter UserName
      enterText(VC_USERNAME_TEXT_BOX, VC_USERNAME);
      // Enter Password
      enterText(VC_PASSWORD_TEXT_BOX, VC_PASSWORD);
      // Click Login Button
      clickButton(VC_LOGIN_BUTTON);
   }
@AfterClass
   public static void tearDownClass() throws Exception {
      if (primarySeleniumserver != null) {
            // getContext().shutDownSeleniumServer();
            primarySeleniumserver.stop();
            primarySeleniumserver = null;
      }
    }
   public void enterText(String textField, String text) {
      call("doFlexType", textField, text);
    }
   public String click(String objectId, String optionalButtonLabel) {
      return call("doFlexClick", objectId, optionalButtonLabel);
    }

Leave a Reply

Learn how you can strategize Software Quality Assurance while Ensuring Success of a Software Product from our whitepaper