Virtual Asset to respond with different responses for the same req param (stateful)

SaranyaSaranya Posts: 3
edited June 9 in Virtualize


Can someone throw light on the following situation please?

I have a Virtual Asset which is invoked by ColumnID. When the ColumnID "XYZ" invokes the VirtualAsset for the first time, the VA should respond with a particular xml and for the second time if the Virtual Asset is invoked with the same ColumnID "XYZ", then the response should be different and third time if the same ColumnID is invoked then a different response should be sent.
In bottomline we need different responses for the same ColumnID if it is invoked at different times.
Is there a way that this scenario could be handled?

Thanks in advance.


  • Ireneusz SzmigielIreneusz Szmigiel Posts: 217 ✭✭✭
    edited September 2017

    Hi Saranya,

    As I see it, you need to get every time a different response, however..
    A) Do you need the same format of response with different values?
    B) Do you need a random behavior?

    If you are looking for A then check Parasoft Marketplace and find Custom String Tool and Random Number Generator.
    You can use them to generate values in response which will be correlated by ColumnID

    If you are looking for B then maybe check Responder Randomizer from Marketplace.
    You may need to download Custom Extension Utility Package as some of the tools from Marketplace need it.

  • SaranyaSaranya Posts: 3

    Hi Ireneusz,

    Thanks for your update.

    In my scenario, I would need a same format but with added values each time. For example, for the first time it gives 10 lines of xml response and for the second time it will be 12 lines with added values to the previous response and so on.

  • keegan_chankeegan_chan Posts: 59 ✭✭

    Hi Saranya, here is one way to do it:
    1. Create a pva with responders that do Responder Correlation based on a HTTP header
    2. Create a file that contains the initial value
    3. Create another pva with a responder that would act as a gateway; attach an Extension Tool to the responder's Incoming Transport Header that reads the value from the file, sets it to a variable, and writes the incremented value to the file; attach a Message Forward tool that forwards the request to the pva set up in step 1, using the variable as the HTTP header
    4. The client application would invoke the gateway pva

    For more information on Extension Tool and Message Forward, you can consult the Help documentation.

  • OmarROmarR Posts: 229 admin

    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 :#

  • meghana1meghana1 Posts: 29

    "in our case, the request would be triggered only once and not again and again. When a request is triggered it would send 3 responses, we are unable to configure the same"

  • keegan_chankeegan_chan Posts: 59 ✭✭

    Hi meghana1, your case is different from the issue of this thread. You have started a thread on your issue, right?

Sign In or Register to comment.