Service Virtualization

Hi,

I have requirement where client should call first live (lower) environment and on failure it should fall back to virtual service. I have tried doing this by creating default project and in router step to pick ExecutionMode to be Image Validation. Added additional listener in most efficient mode and Image response step in case of environment error to fallback on virtual service. Have made 2 different servers of LISA to act one as Live and other as LISA since environment was not available. Lisa version 7.5.2 is what I have at my end and the problem I am seeing is if Live server is not available the fall back option isin't working very well, out of 10 calls 2 calls works, looks like some retry is happening when environment is down and I am not sure where these settings are.

Please suggest if there is better way to implement this or how can I make my solution to respond appropriately.

You can manage this with single virtual service by doing assertion on the live invocation step response and redirect to image response selection step if assertion pass/Fail. 

Thanks Anna ..what kind of assertion do you recommend me to use and where. What should be the ExecutionMode and how do I override the retry to live system?

Out of curiosity is it possible to upgrade to the latest version of DevTest which has some Live / Failover capabilities built-in?  

If unable to upgrade, please recognize that you are trying to manually configure a 7.5.2 VSM to implement some rather unique behavior. I believe you will find that implementing this type of logic is going to require some coding and a lot of testing against different scenarios.

Also, please consider the remainder of this post as commentary - not a proven approach or suggestion. It is best to play with various options to understand their behavior and the impact on your service.

- Your concept of using Image Validation mode is intriguing, however, this is the least efficient mode for a VSM to operate under. You may also find this is the cause of some of the transactions working and others not in cases where the requests don't exactly match up.  This mode also puts strain on other DevTest components and is typically not recommended as an 'always-on' option. 

- I suppose in the Live Invocation step, rather than end the test case on errors & exceptions, you could branch the logic to the VSI Selection Step. At least you could potentially get a virtual response if an exception occurs while making the Live Invocation request. What happens though if the exception is legitimate, and you really need the VSM to throw an error and shut down?  You lose that ability with this type of modification.

- Perhaps, you could add Scripted Assertions in the Live Invocation step to deal with live responses. You might evaluate scenarios such as connection refused, various HTTP Response Codes (4xx, 5xx), etc., then branch to the VSI Selection step. Assertion logic may also need to evaluate the live response payload content to distinguish if the values are correct and whether or not the VSI selection step should be invoked. 

- I suspect that trapping HTTP Timeouts will be more difficult as the Live Invocation step will sit and wait until the HTTP connection times out (which could last 90 - 180 secs depending on settings).  I do not recall if timeouts manifest as an exception or a response with an error message inside. And, there is no step-specific HTTP timeout setting available - the property that controls connection timeouts is global. 

Keep us posted.  Interesting to say the least.

Thanks Joe, your reply gives me various options to think. We are upgrading to 9.5 but its not going to happen soon. I agree that standard vsm modification is not right way to do it but haven't played around much with Scripted Assertions. Would it be possible to share sample project or script to handle one http response code that calls virtual service please. 

I do not have a sample project that I can upload.  I created a sample VS model without all the tracking, learning & failover steps.  In this model, the Live Invocation Step either branches to Responder or VS Image Selection.  

Disregard the "if failover" assertion because this picture is taken from DevTest v10.

- Change the If environment Error to branch to VS Image Response Selection step.  A connection refused exception to your Live Endpoint will be considered an environment error.  This assertion fires before your Scripted Assertion.  You might also see a 'red' dot next to the service in the Console view if this assertion fires - not sure.

- Then, add a Scripted Assertion to check for things that are important to you.  For example, consider the Assertion logic below.  

If the Assertion returns TRUE, the logic should branch to the VS Image Response Selection step.  

If the Assertion returns FALSE, the Live System response is sent to the client.

I used 'false' in the logic below because when DevTest encounters an error in the script at runtime, DevTest will assume the response from the assertion is 'false'.  If a scripting error occurs, the code will attempt to send the Live Response.  

Switch the the true/false around and change the Assertion branching according to what makes sense to you.

import com.itko.lisa.vse.stateful.model.TransientResponse;
import com.itko.util.ParameterList;
import java.util.List;

// Get the response from the Live System
List lst = (List)testExec.getStateObject("lisa.vse.live.response");
if ( lst.size() < 1 )
    return true; // noting in the response to process so go virtual

TransientResponse tr = lst.get(0);
// this is an HTTP service so the list should only have one entry

// if response is null, go virtual
if ( tr == null) {
    _logger.info(" hum, response from live is NULL");
    return true;
}

// Check the HTTP Return Codes
ParameterList pl = tr.getMetaData();
if ( pl.containsKey( "HTTP-Response-Code" ) ) {
    if ( "200".equals( pl.get( "HTTP-Response-Code" ) ) ) {
        _logger.info(" HTTP response is 200 ");
        // 200 is a good response but maybe we need to check the body

        // for something so do not return out of this logic
    } else {
        _logger.info(" HTTP response is: {} branching virtual", pl.get( "HTTP-Response-Code" ) );
        return true; // all other HTTP response codes go virtual
    }

} else {

    // likely there is an issue if no HTTP response code is returned from Live

    // so go virtual

    return true;
} 

// get the body and determine what to do
String theBody = tr.getBodyAsString();

// for example
int i = 0;
i = theBody.indexOf( "<head><title>404" );
if ( i > 0 )

    return true;

// all checks passed must mean you want to send Live response

// Assertion is set to branch to RESPONDER Step if the return is false
return false;

I am not sure how an HTTP Timeout is trapped or what it looks like in the Live Invocation step. So that is some additional testing you will need to take care of. 

Thanks Joe. vsm looks neat now and includes 5 steps only and works well even with http not found without retrial issue. I wanted to add additional error from live to handle list of error codes like 400,503,500, these are rest calls. Kindly suggest where to add them in the script. Sorry this my first trail with scripts.

You can change around the section that gets MetaData according to your requirements.  The earlier code fragment sent all non-HTTP 200 responses to the virtual service.  You could add if...else... as appropriate or do something like this:

ParameterList pl = tr.getMetaData();

String rspCode = null;

if ( pl.containsKey( "HTTP-Response-Code" ) ) {

      rspCode = pl.get( "HTTP-Response-Code" );

}

if ( rspCode == null ) {

    return true;  // No response so you must go virtual

}    

// log a message or remove to prevent excessive amounts of data in log files

_logger.info(" HTTP response from Live Invocation is: {}", rspCode );

// Implement code for each response code

switch ( rspCode ) {

   case "200": break;           // 200 response OK, but check response body

   case "401": return false;    // Unauthorized send Live response rather than virtual

   case "403": return false;    // Forbidden send Live response rather than virtual

   case "404": return true;     // Not found try to return the virtual

   case "500": return true;     // Internal server error return virtual

   default: return true;        // default for any other response code is virtual

}

// code to check the body when the response is HTTP 200 follows

Hi J_NeSmith, there is small change in the requirement and since its related to same post I am replying here. I need to capture incoming REST request arguments,headers and part of the url and verify if it is equal to virtual service data. Please can you help?

I am not exactly sure what you mean by "verify if it is equal to virtual service data" -- that is the main purpose of the VS Image Selection step in determining a virtual response (specific, META, or Service Image Not Found responses).  

With the exception of the incoming request headers, the operation and arguments are validated in the VSI.  If some header arguments need validation, I suppose you could use RDM DPH to copy them from MetaData into the Arg List so they too could be checked by the VS Image Selection Step.

If you are interested in checking things using code:

The lisa_vse_request.getOperation() method will return the incoming request operation.

The lisa_vse_request.getArguments() method returns a com.itko.util.ParameterList that exposes accessor methods such as containsKey( ) and get( ) methods.

And, lisa_vse_request.getMetaData() returns a ParameterList with the incoming request header information.

In your DevTest installation directory (LISA_HOME), look for the directory LISA_HOME\doc. The member SDKJavaDoc.zip provides some insight.

Thanks Joe..I did the changes as you mentioned but I am not sure if Assertion step is getting executed correclty. Do we have any pre-requisite to run assertion step? However for HTTP not found it rightly calls virtual service and I am assuming its because of environment error we have looped back to call virtual.

This is what I got from Test Event:

Assert evaluated Virtual HTTPS Live Invocation 8031 [Scripted Assertion] The assertion of type Assert by Script Execution had outcome:
Script,

/*code*/

execution error so we assume false: Sourced file: inline evaluation of: ``import com.itko.lisa.vse.stateful.model.TransientResponse;  import com.itko.util . . . '' : Attempt to resolve method: info() on undefined variable or class name: _logger : at Line: 26 : in file: inline evaluation of: ``import com.itko.lisa.vse.stateful.model.TransientResponse;  import com.itko.util . . . '' : _logger .info ( " HTTP response from Live Invocation is: {}" , rspCode ).

There appears to be a syntax error at line 26 in the Assertion. I am not sure what is at line 26 in your code.  If the line is the _logger.info( "..." ), you can comment it out.

Also, if you copy/pasted the code, a quote (") or some other value may not have converted to a proper ASCII quote.

Because of the syntax error, DevTest generated a "false" response which likely sent the Live Response in the Responder step. 

Update, it looks like there may be a <space> between _logger and ".info(" at Line 26.  If so, remove the space _logger.info(.... .