Service Virtualization

I have two independent virtual servives (two VSMs and VSIs).

I need to capture the value of an incoming argument from one virtual service and be able to use this as a value for one of the tags in the response in another virtual service. 

How can I achieve this?

J_NeSmith

abrsh01

gadpr08

monika_mehta

Deleted User

Hi, 

You can edit the model from the first service adding a step that saves the value to a file. Edit the model from the second service to read this value. 

Regards,

Francis

I tried do this. But it's not working for me. Following is my approach:

I have VSM-1 on some port say 8090 and its corresponding VSI-1 with few specific transactions.

I go into my scenario specific transaction, and in the match script I write the following :

String sourceCity      = incomingRequest.getArguments().get("origin_code");

testExec.setStateValue("SourceCityProp", sourceCity);

Then, in the VSM, in Response Selection step, I added a "Save property value to File" filter. But this is not writing anything to the properties file.

If this writes successfully, then I can add a read property from file step in my VSM2 and use it in my VSI-2 response.

Hi,

    Can you try the following code after listener step in Javascript step.

import com.itko.lisa.vse.stateful.model.Request;
import com.itko.util.ParameterList;

ParameterList args = req.getArguments();
String sourceCity =args.get("origin_code");
testExec.setStateValue("SourceCityProp", sourceCity);

                             Thanks,

Vish

I recommend using the in-memory SharedModelMap in a script:

com.itko.lisa.vse.SharedModelMap

It has the same API as a Java map - methods like put(key,value) and get(key).  However, it also introduces the concept of namespaces like put(namespace,key,value) which helps prevent unrelated services from accidentally using the same key.

Be warned, however, that it has a maximum capacity of 256.  When you try to put() a 257th item, the least recently used value gets dropped.

--Mike

Hi,

To be more elaborate,

VSM1:

Filter out the Argument value and set property (Ex: SourceCityProp)

Put this below script in Execute Script:

import com.itko.lisa.vse.SharedModelMap;
import com.itko.lisa.VSE;

SharedModelMap.clear("Namespace"); 

SharedModelMap.put("Namespace","SourceCityProp", SourceCityProp);

*******************************************************************************************

VSM2:

Put this below script in Execute Script:

import com.itko.lisa.vse.SharedModelMap;
import com.itko.lisa.VSE;

testExec.setStateValue("destination", SharedModelMap.get("Namespace","SourceCityProp"));

Hope it will work!!!

Thanks Venkat,

It works for me now. :-)

Great Mallik!!!

Best Regards,

Venkat Yedida 

To add more meat to the answers that have already been provided, take a look at my blog entry here:

So you want to keep count in a virtual service? 

Hi,

I have similar requirement to be implemented in my process. 

To be more elaborate,

VSM1:

Filter out the Argument value and set property (Ex: SourceCityProp)

 To achieve the above :
I tried keeping the filter on Listener  Step/ Prepare Request step / on the Response selection step. But i wasn't getting the value. 

Could you please let me know how to filter the value and where to add the execute script step in the VSM.

Thanks

  PanditiAvinash

J_NeSmith

VenkatYedidaCG

Can you provide a sample of how and where the VSM is accessing / filtering / storing the argument value?

In addition to Rick.Brown helpful reference link, above, please refer to the scripting guide for additional  examples: DevTest 8.0 - Scripting Guide - V1.1.pdf  

Typically, I implement model map logic in a Listen Step Scriptable DPH since the incoming request is available.  However, I do this more for sanity reasons than because it is a DevTest requirement.

A few points worth noting for those that do not often use Shared Model Maps:

1. Keep in mind that virtual services are threaded; therefore, multiple, concurrent incoming requests can occur. The VSM may need behavior to keep the value of one incoming request separate from the value of another incoming request. This means the key used on the Shared Model / Persistent Model Maps may need to be managed by the Scriptable DPH or JSR step to create uniqueness. 
2. Shared Model Maps are memory based. Either script logic manually cleans the map, the map is "cleared out" when the VSE is stopped/started, or size limit (which can be set higher than 256 by calling a method) mentioned by Mike_Gavaghan is reached. 
3. Shared Model Maps are NOT shareable across VSE memory boundaries. Therefore, a VSM running on VSE1 cannot use the Shared Map to share information with a VSM running on VSE2. Similarly, a VSM running in ITR does not share information with a VSM running in VSE. And, a test case running in the Coordinator/Simulator does not have access to the VSE's Shared Model Map.  All are examples of crossing a JVM memory boundary.
4. Shared Model Maps consume VSE memory. This technique should not be used for 'general storage' or as a work area for models.
5. Make certain you have a precise reason (this thread is a good reason) for using these maps to meet a business requirement and that you understand the consequences of using the technique.