How to iterate over a persistent model map in javascript step?

[venkat raj]

I have a requirement, to find the duplicacy of a particular value in the request. for example, there is a request parameter session ID in my incoming request with values as SessionID = 12345; if one more request with the same Session ID is received by the VSI I have to set an error response. So I have to store the session ID in a persistent model map and whenever a request is coming, the map will hold all the values, to find the duplicate ID i have to iterate over the persistent model map. Can someone help on how to iterate ?

code:

com.itko.lisa.coordinator.TestRegistry tr = com.itko.lisa.test.Environment.getTestRegistry();
    String sessionID="";
    boolean sessionexpired=false;
    try {
        Request req = (Request) testExec.getStateValue("lisa.vse.request");
        ParameterList args = req.getArguments();
        sessionID = args.get("SessionID");
        if (tr.getAllMapValues("ExpiryData").size()>0) {  // new values will be added in the map//
            tr.putMapValue("ExpiryData", "sessionID", sessionID);
            sessionexpired=false;
        } else {
            iterate over the map and check if the value is already present or not.

[Legacy User]

Would something like the following work for you or perhaps you could use an entrySet iterator.  Also, in your example, what is there to loop over if the size is not greater than 0?

// retrieve map from ExpiryData namespace

java.util.Map m = tr.getAllMapValues( "ExpiryData" );

_logger.info( "Going to try to loop over the keys" );

// iterating the keys looks like this

for ( String key : m.keySet() ) {
    _logger.info( " Key value is: {}", key );
}

_logger.info( "Going to try to loop over the values");

// iterating the values looks like this

for ( String val : m.values() ) {
    _logger.info( " Value is: {}", val );
}

 

OR

 

for ( java.util.Map.Entry entry : m.entrySet() ) {
    _logger.info( "key is: {} and value is: {}", entry.getKey(), entry.getValue() );
}

 

UPDATED:

I just noticed your logic.  If you use the method tr.putMapValue("ExpiryData", "sessionID", sessionID);  you will never have more than one entry in your persistent model map.  The key is more likely the variable sessionID.  If a sessionID exists and you fire the "putMapValue" a second time, the value of the existing sessionID will be updated.  PMM will not create a duplicate entry in the map. Perhaps, your put looks more like this:

tr.putMapValue( "ExpiryData", sessionID, "some string value here" ); 

 

Take a look at the differences in the attached test case.  Run in ITR mode and review the Events tab.  The logger displays provide some insight as to what I am saying with regard to the key.

Attachment(s)

Persistent_Map_Loop.tst.zip   1 KB 1 version

[Legacy User]

Replying to the reply....  If you store the sessionID in the key side of the map, you only need to fire the getMapValue method and check it.  

 

If the get method returns NULL, the sessionID is not on the map (or it been deleted from the map by the DevTest cleaner process -- which OOTB is 30 days).  

 

If the value is on the map, you can process your error response.  For example,

 

com.itko.lisa.coordinator.TestRegistry tr = com.itko.lisa.test.Environment.getTestRegistry();
String sessionID="";
boolean sessionexpired=false;
try {
        Request req = (Request) testExec.getStateValue("lisa.vse.request");
        ParameterList args = req.getArguments();
        sessionID = args.get("SessionID");

// you might add some safety logic here in case the incoming request does not have a sessionID argument
        if ( tr.getMapValue( "ExpiryData", sessionID ) == null ) {  // session is not on the map
            tr.putMapValue("ExpiryData", sessionID, "session added" );
            sessionexpired=false;
        } else {
            // A non-NULL response means the session ID is on the map

           sessionexpired = true;  //?????

       }

}

 

Another way I have done this is to save the sessionID as the key and a string date/time stamp in the value.  If the map contains the sessionID, the logic obtains the difference in the current date/time and the date/time from the map.  If the span of time exceeds a certain amount (for example 3 minutes), the session expired response is processed. If the time is within the threshold, the logic updates the map with the current date/time because activity is occurring between the consumer and the service. In this case, the session is 'active'.

[venkat raj]

Great! worked perfectly for my requirement. Thanks!!

[Legacy User]

The only additional comment I would make since I did not see any logic to remove sessionID data is that you consider the frequency on which you clean up the Persistent Model Map in order to prevent large numbers of stale sessionIDs from building up on the map.

 

The properties for setting when the Persistent Model Map cleaner executes are in lisa.properties.

lisa.persistent.map.delete=true            --> specifies whether to expire data at all
lisa.persistent.map.delete.cycle=10m  --> specifies how often the delete process runs
lisa.persistent.map.delete.age=30d     --> specifies the age of the entries to delete

 

Depending on how you use the service, you might create a simple test case that iterates over the map and removes entries.  Or, you could add a 'special' helper operation that accepts a REST call and let the VSM handle cleaning the PMM.

[venkat raj]

I want the session ID's to be deleted after 2 days of time.

Is it enough to just update in the lisa.properties file or should I add any external code to delete the values from map?

[Legacy User]

You should be able to add the override for 2 days so long as no other services need data in the map for longer than that. These properties affect all of the namespaces in the map.

lisa.persistent.map.delete=true       
lisa.persistent.map.delete.cycle=10m  
lisa.persistent.map.delete.age=2d

You can also review the review the example remove method in the test case attached above.  This way you can manually remove data when testing locally.