Service Virtualization

 View Only
Expand all | Collapse all

Scope of testExec and Result propagation between Steps in VSM

  • 1.  Scope of testExec and Result propagation between Steps in VSM

    Posted Jun 21, 2018 01:16 AM

    Hi, 

    I have few queries about the scope and behaviour of testExec object. The documentation of testExec does not seem to clarify these. 

     

    • What is the scope of testExec object? when we set State values using TestExec and access them in the following Steps, during concurrent hits on the Virtual Service, will the testExec object scope be common to all concurrent hits or scope is seperate to individual hit?
    • If some custom computation results needs to be propagated between Steps in a VSM. I can see see two options to do so ( correct me if I'm wrong)
      • Using the LASTRESPONSE property
      • Setting StateValues to testExec 

          Are there other ways to do the same? Which approach is the best and efficient way to do the same?

     

    Any help is much appreciated.



  • 2.  Re: Scope of testExec and Result propagation between Steps in VSM

    Posted Jun 21, 2018 09:48 AM
      |   view attached

    I am working with Sudarsun on this DevTest Virtual Service, it has become necessary to integrate it with a database that is maintained by our Test Data Management team.  We are most concerned about the scope of properties use in the VSM in BeanShell scripts.  We are looking for how to set the returned values so their scope is limited to the current iteration of the Virtual Service.

     We are also interested in the scope of variables set in other standard steps and how to properly pass variable to and from them.

    1. Virtual Service Execution Router
    2. JDBC
    3. VS Image Response Selection
    4. .VSI (virtual service image)

     We have researched this in the DevTest documentation as well as reviewing community bulletin board responses.

    Attachment(s)



  • 3.  Re: Scope of testExec and Result propagation between Steps in VSM

    Broadcom Employee
    Posted Jun 21, 2018 10:34 AM

     We have researched this in the DevTest documentation as well as reviewing community bulletin board responses.

    You didn't check blog entries

    I created a simple chart of the property scopes I use in virtual services here:

    So you want to keep count in a virtual service? 



  • 4.  Re: Scope of testExec and Result propagation between Steps in VSM

    Posted Jun 21, 2018 11:23 AM

    Rick

     

    Thank you for your attention, three of us reviewed your blog post which has helped us through some hurdles.  We also looked at the scripting guide.  Your post has listed most if not all of the areas we are interested in.  Unfortunately the post seems to be geared towards doing what we are trying to ensure we prevent.  We want to ensure no date is shared between iterations "Contained within a single invocation of a running virtual service". 

     

    This section led us to the scripting guide but it did not spell out some of the variable scope questions. 

    One thing that still has the developers concerned is the passing of variables into the VSI from the previous script step.

     

    There are various places in a virtual service where properties can be defined and manipulated. These include:

    • Datasets applied to steps in service models
    • Script steps in service models
    • Scriptable data protocol handlers in service models
    • Routing steps in service models
    • Match scripts in service images
    • Inline scripts in service image data values


  • 5.  Re: Scope of testExec and Result propagation between Steps in VSM

    Broadcom Employee
    Posted Jun 21, 2018 12:10 PM

    Hi Jay --

     

    I'd need someone to check, as I don't have a chance to check right now, but my assumption is:

    A VSI that sets an in-line property value will have that value discarded after it is parsed.

    Any script that sets a property will have that value discarded when the script completes, unless exported to the VSM by using testExec.setStateValue().

     

    A VSM that sets a property value will be shared amongst all invocations of that VSM, because it runs as a test with a loop in it. A difference is that it's multi-threaded, and I don't know how the threading changes this behaviour, so it's worth exploring. Any property you use in a VSM would presumably be set in the VSM before use, so it shouldn't be a problem. Again, worth exploring.

     

    So, I guess that your first example preserves the property value (incrementing the dataset.rowNum, but you'll need to check as I can't rightly remember), but the rest of them discard it, unless you use testExec.setStateValue().

     

    Rick



  • 6.  Re: Scope of testExec and Result propagation between Steps in VSM

    Posted Jun 21, 2018 01:37 PM

    Hi Rick,

     

    My name is Gabe and I work with Jay and Sudarsun. Thank you for sharing all this information. 

     

    So, the testExec.setStateValue() will place variables at the VSM scope which, if I'm not mistaken, it means that we can't use LASTRESPONSE either since we can obtain this value using testExec.getStateValue("LASTRESPONSE") - I suspect that means it was previously set using testExec.setStateValue().

     

    At this point I'd like to explore the possibility of adding data calculated in various virtualization steps to the request object so it can be used for subsequent steps. Do you feel like about this approach ?

     

    Gabe



  • 7.  Re: Scope of testExec and Result propagation between Steps in VSM

    Broadcom Employee
    Posted Jun 21, 2018 02:23 PM

    Hi Gabe --

     

    OK, let's see if I can completely contradict myself by thinking this through logically (still without trying it).

     

    The way I understand the architecture of a virtual service is that a listener thread receives an incoming message, and it spawns a worker thread to deal with the internal processing of the message and its response. When the worker thread is spawned, it is sent a copy of the request object, and presumably any properties that have been previously set.

     

    The worker thread is destroyed in (just before? Just after? During? I'd need a developer to chime in with the exact details) the response step, so all the properties set or changed during the lifespan of the worker thread are also reset.

     

    Any properties that have been set inside that worker thread are local to that worker thread, to ensure that the virtual service is thread-safe.

     

    Therefore, you should be safe to set any properties you need, and the values won't bleed over other requests to the same virtual service.

     

    Sounds convincing, right? And contradictory! Now I need to try it and see if it's true (see the "worth exploring" sentences in my previous response)!

     

    You can try this out yourselves, and/or I can. Whichever of us comes to a conclusion first should respond to this thread!

     

    Rick



  • 8.  Re: Scope of testExec and Result propagation between Steps in VSM

    Broadcom Employee
    Posted Jun 21, 2018 03:56 PM

    Initial test results.

     

    Virtual Service:

    DEVTEST_HOME/examples/vservices/copyOfWebServices.vsm

     

    Test:

    DEVTEST_HOME/examples/tests/webServices.tst

     

    Script:

    int scriptable = testExec.getStateInt("scriptable", 0);

    scriptable++;
    testExec.setStateValue("scriptable", scriptable);

    return scriptable;

     

    Run test 10 times. Result:

    scriptable=10

     

    Add the same script to VSM

    Add line to script:


    _logger.info("Scriptable:>{}<", scriptable);

    Add a 10 second delay to the VSM response, to make sure there are multiple concurrent requests.

     

    Deploy virtual service

    Create 10 vuser staging document

    Create suite to run the webServices test with the 10 vuser staging document

    Open the vse.log file.

     

    If there is any chance of bleeding property values, the log should show additions to the value of "scriptable" property.

    If it's all thread-safe, the log should show "scriptable" always being >1<

     

    Log snippet:

    2018-06-21 19:37:37,618Z (20:37) [Event Sink Thread Pool Thread 2] INFO com.itko.lisa.vse.stateful.DelayedResponder - Responder queue size: 10
    2018-06-21 19:37:39,618Z (20:37) [Event Sink Thread Pool Thread 2] INFO com.itko.lisa.vse.stateful.DelayedResponder - Responder queue size: 10
    2018-06-21 19:37:41,816Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:41,830Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:41,832Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:41,920Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:41,922Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:42,018Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:42,020Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:42,118Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:42,120Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:42,254Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:42,256Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:42,353Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:42,355Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:42,425Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:42,432Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:42,519Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:42,521Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:42,728Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:43,017Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:43,052Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:43,056Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:43,466Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:43,529Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:43,532Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:43,569Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:43,571Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:43,669Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:43,671Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:43,771Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:43,774Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:43,869Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:43,871Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:43,970Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:43,972Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:44,069Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:44,071Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:44,169Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:44,171Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:44,269Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:44,271Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:44,369Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:44,370Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:44,469Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:44,471Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:44,569Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:44,571Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:44,669Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:44,671Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:44,770Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:44,772Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:44,870Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:44,872Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:45,176Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:45,472Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:47,618Z (20:37) [Event Sink Thread Pool Thread 2] INFO com.itko.lisa.vse.stateful.DelayedResponder - Responder queue size: 10
    2018-06-21 19:37:49,618Z (20:37) [Event Sink Thread Pool Thread 2] INFO com.itko.lisa.vse.stateful.DelayedResponder - Responder queue size: 10
    2018-06-21 19:37:54,645Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:54,832Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:55,193Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:55,266Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:55,269Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:55,307Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:55,309Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:55,556Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:55,566Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:55,569Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] WARN com.itko.lisa.coordinator.VSETransactionLicensingManager - Transaction processing speed is being gated due to licensing restrictions.
    2018-06-21 19:37:55,828Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:55,902Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<
    2018-06-21 19:37:56,116Z (20:37) [CopyOfWebServicesModel [VS_CopyOfWebServicesModel_Run]/1] INFO com.itko.lisa.script.logger - Scriptable:>1<

     

     

    Ok, it's confirmed - the scope of properties saved to testExec (from a scriptable DPH) is "local to the invocation from an incoming message".

    The property is NOT persisted for subsequent calls.

    The property is NOT shared between multiple concurrent invocations of the virtual service.



  • 9.  Re: Scope of testExec and Result propagation between Steps in VSM
    Best Answer

    Broadcom Employee
    Posted Jun 21, 2018 04:12 PM

    I might just be repeating Rick, but:

     

    1) testExec values are not shared across threads.

     

    2) When one iteration of a VSM is completed, testExec is not explicitly reset.  If you set a property in testExec, it will still be there the next time that particular thread services a request.  I think I might be contradicting Rick...more in the next bullet.

     

    3) If you don't want that behavior, you can create a final script to invoke testExec.removeState("propname").  The VSM sometimes gives the illusion that testExec resets everything.  In reality, the response step only removes properties it knows the infrastructure would have created (such as "request_*").  Any user created properties do not get cleaned up automatically.

     

    4) Lastly, on your query about "where properties can be defined and manipulated."  Don't forget about filters!

     

    --Mike



  • 10.  Re: Scope of testExec and Result propagation between Steps in VSM

    Broadcom Employee
    Posted Jun 21, 2018 05:01 PM

    Mike Gavaghan wrote:

    If you set a property in testExec, it will still be there the next time that particular thread services a request.

    Don't forget that each invocation spawns a worker thread, and the thread is destroyed at response time, which leads to

     

    1) testExec values are not shared across threads.

     

    and is therefore why we never see the value of "scriptable" in my DPH incrementing above 1.

     

    So, returning to the original question ...

     

    You can use testExec.setStateValue() to store properties that you want to re-use within a single transaction.

    The LASTRESPONSE property is the output of the previous step executed within that invocation of the virtual service. I would always prefer to use the testExec object to store values, as it is more flexible.

     

    There is a caveat to all this (isn't there always?). If you're in a stateful conversation, I believe the worker thread isn't destroyed until you reach the end of the conversation tree, so I think any testExec properties are persisted, within that thread (still thread-safe, not bleeding to other invocations of the virtual service), until then.



  • 11.  Re: Scope of testExec and Result propagation between Steps in VSM

    Broadcom Employee
    Posted Jun 23, 2018 11:09 AM

    It seems that I owe Mike a beer! This is a very interesting investigation!

     

    If I use testExec to create a property whose name starts with "request", it gets removed after the response.

    If I use testExec to set a property starting with a different name, it gets preserved for subsequent calls inside the virtual service.

    If I have two virtual services with testExec properties of the same name, they don't share values.

     

    Now I need to think of some customer use cases where I can exploit this property sharing behaviour!