OmarR admin


Last Active
Members, Admin, Staff
  • Web Functional Workflow for the latest version of Chrome / Firefox

    Parasoft: Web Functional Workflow for the latest version of Chrome / Firefox


    The latest version of SOAtest 9.10.0 comes prepackaged with Selenium-Version: 2.53.1. Currently, there is no version of Selenium (non-Marionette) Firefox driver that fully supports Firefox48 and higher. This is not a limitation of the Parasoft tool, but a limitation of the Selenium Webdriver. Furthermore, the latest version of Chrome55 contains a core browser issue that can prevent SOAtest from recording with it. Below are a few possible solutions to work around this.


    Download Chrome54 / Firefox47 or below. SOAtest 9.10.0 should record and playback successfully with these versions.

    If when recording with a previous version of Chrome/Firefox, you continue to receive a blank page:

    1)Close the page and "Stop Recording".

    2)After stopping the Recording, expand the Test Suite created and right click the child Scenario in the test suite and select "add new test suite".

    3) Select Web>Record Web Scenario and click Next in the Wizard.

    4)Select "Continue recording from: "Scenario:xxxxxx" and select "Append new test to..."

    5)Select Finish and continue recording with your desired Browser selected.

    6)After you have finished recording, close the browser and "Stop Recording".

    After this, your recording should have been captured and appended to your current Test suite.

    If you are unable to revert back to Chrome54 / Firefox46, you may still be able to use the latest version of Chrome for playback, but not for recording. Interestingly enough, you may be able to use the latest version of Firefox to record, but not playback. In order to continue with your Web Functional testing using the latest version of these browsers, you can do the following:

    1) Record your Web Scenario using Firefox or IE

    2) Once you’ve finished with your Recording, verify that your Web Scenario was captured successfully

    3) Create a New “Test Configuration” to execute Web Scenarios using the Chrome Browser

    4) (Optional) You may also configure the Browser Playback Options in your Test Suite(s) to use the Chrome Browser

    5) Run your .tst and verify that your Web Scenario executes as expected

  • How to Create a .tst Using a Windows Shortcut Key

    How to Create a .tst Using a Windows Shortcut Key


    Inspired by EM/CTP's quick actions feature, I took advantage of SOAVIRT's REST API and Windows Powershell to use an alternative method to create a client for those times when I want to quickly test an idea, demo a feature, or assist someone on the forums. :)


    1) A Server API Enabled (SOAtest) or Service Enabled (Virtualize) license feature
    2) SOAtest/Virtualize server must be running


    1) Download the attached batch file and place it on your Desktop

    2) Run the file and verify that it creates a .tst under the TestAssets folder

    3) To avoid having the command prompt display, create a shortcut of the batch file

    4) Open the Shortcut properties

    • Change the “Run” option to minimized
    • Provide a Shortcut Key (e.g., Ctrl + Alt + Z)
    • (Optional) Under General tab, select Hidden

    5) Use your Shortcut Key and verify that it creates a .tst/client successfully

    -- OmarR

  • Re: How to extract specific node in JSON Databank

    Hey Uday,

    Do you want to capture the name of the node or the entire element? Try the following:

    Xpath: /root
    result: {"Node_12345":{"Key":"XXXXX","value":"YYYYY"}}

    Xpath: /root/Node_12345[1]/name()
    result: Node_12345

  • Re: Redirecting a request to 3 EndPoints


    As @williammccusker recommended, you may chain multiple messaging clients to your Responder. Like this:

    If you wish to redirect the incoming Request Message to different endpoints, your setup would require a databank to capture the request message content so that you may forward the same message to all your endpoints using the messaging clients:

  • Re: Virtual Asset to respond with different responses for the same req param

    Good morning,

    To clarify @keegan_chan 's neat solution, the "gateway" responder will route where the request will be forwarded to by using an extension tool to generate/store a variable in a file (write file tool) and update it every time a request is sent. The gateway will then use the Forward Tool to forward the request to the desired responders. The responder whose responder correlation matches the criteria stored in the file will then be invoked.

    Another approach could be to add the "Gateway" responder to the end of the original PVA to avoid using two different PVAs. Furthermore, you may eliminate the need to write to a file by inserting the test suite variable directly in the forwarded URL and configuring your Responders to correlate using Responder Correlation> URL Paths.

    1. Create a pva and add a test suite variable "x" with an integer value of 1.

    2.Create 3 responders and configure each to correlate to a URL path under the Responder Correlation tab

    3.Chain an Extension tool to each Responder and verify each extension tool is attached as the Output of the ** Incoming Request.**

    4.Add the following Groovy script for each extension tool and update the setValue to be the subsequent test#. For example, the following script will be used for the extensionTool chained to the 1st Responder. Notice the setValue is set to 2. The Extenstion Tool for Responder 2 will have a setValue of 3, and the extension tool for Responder 3 will have a setValue of 1 to reset the cycle again.

        import com.parasoft.api.*;
        public void exampleScript(Object input, context){

    5. Add another responder to the end of your suite. This responder will act as the gateway.

    6. Chain a Message Forward Tool to the Gateway Responder and change the Input mode to "Multiple Responses". Enable Correlation and add a fake correlation to force a correlation failure. This will activate the Message Forwarding tool.

    7. Finally, Add the following syntax to the end of the endpoint: ${x}

    At the end, your PVA should look like the following:

    If you are handy with Virtualize's REST API, there is an even simpler approach to this that will avoid scripting all together. We could chain a messaging Client at the end of each responder to make a call to /v5/tools/disabled to disable itself at the end of each run. The client chained to the last responder would re-enable the previous two responders and the cycle would begin again. This was my initial approach to this scenario. However, there may be performance issues due to redeploying the PVA after each run in order for the changes to successfully take place.

    Let us know if you have any trouble implementing these :#