Service Virtualization

  • 1.  Matched Response ID from VSI

    Posted Oct 11, 2017 05:57 AM

    Hi SupportListeners,

     

    I enabled log level to info to capture the logs in the virtual service specific log file but for some reason, the Stateless Match Transaction: line gives the meta response ID instead of the specific transaction id of the matched transaction for all the calls. I tried implementing the below logic which I got from an other post to pull the matched transaction id

     

    import com.itko.lisa.vse.stateful.model.Transaction;

    Transaction txn = new Transaction();
    txn = (Transaction) testExec.getStateObject("lisa.vse.matched.transaction");

    long id = 0;
    if( txn != null ) {
    id = txn.getResponses().get(0).getId();
    } else {
    //In this case, the response you got is one of the responses for unknown requests,
    // so you'll need some logic that knows how to deal with that situation. I'll just call it an ID of -1 for demonstration purposes.
    id = -1;
    }
    VSE.info(testExec,"ResponseID","RspID: " + id);

     

    But is it not logging anything. I added it in a scriptable DPH and tried in both listen step as well as in the respond step in the VSM. (Process Response selected)

     

    I tried running in ITR and what I observed in the events is , below properties are removed. Is there anything I'm missing. BTW I'm using CA DevTest 10.

     

     

    Any help is much appreciated.

     

    Regards,

    Shivakumar.



  • 2.  Re: Matched Response ID from VSI
    Best Answer

    Posted Oct 11, 2017 10:03 AM

    If the response is a META response, then your specific transaction(s) is/are not matching for some reason. Let's recap where transaction matching output can be found when logging.properties is set to INFO mode.

     

    When executing in ITR mode, log file output goes into the Workstation.log file. For most folks, this is file is located in: c:/users/yourLoggedInUserId/lisatmp_10.0.1.

     

    When executing in VSE, the output goes into the server's lisatmp_x.x.x directory in the vse_matches.log. The location of this directory is usually LISA_HOME, but SysAdmins can override and direct the output to other locations, so refer to your specific installation. When executing in VSE, the Portal application can display the matching algorithm in Inspection View.

     

    The highlighted fields below are indicators of the ID in the VSI from which the response is selected. Additionally, the "matchTolerance" is an indicator of whether or not the match was specific or META. Consider the following:

     

    Workstation Output From ITR Mode:

    2017-10-11 12:56:50,440Z (07:56) [...] INFO  root - Transaction Navigator Respond from: {"id":53,"request":{"id":54,"matchTolerance":"EXACT",

     

    Portal & vse_matches.log Output 

    2017-10-11 13:04:42,752Z (08:04)[...]/1] INFO  - Transaction Navigator Respond from: {"id":53,"request":{"id":54,"matchTolerance":"EXACT",

     

    2017-10-11 13:04:44,603Z (08:04)[...]/1] INFO  - Transaction Navigator Respond from: {"id":43,"request":{"id":56,"matchTolerance":"EXACT","operation"

     

    The two above responses are specific transactions.

    The response below is a META. 

    2017-10-11 13:04:55,103Z (08:04)[...]/1] INFO  - Transaction Navigator Respond from: {"id":42,"navigationTolerance":"<stateless>","request":{"id":58,"matchTolerance":"SIGNATURE",

     

    If you are seeing your META response and you believe that the service should respond with a specific transaction, carefully review the incoming request arguments found in VS_yourServiceName.log and look for the Inbound request.

     

    2017-10-09 15:20:28,363Z (10:20)[Joel_4_5_6_LineItems [VS_yourServiceName_Run]/1] INFO - Inbound Request {"id":0,"operation":"POST /test","arguments":{}}

     

    Additionally when Meta Matches occur, the VS_yourServiceName.log will display the incoming request and the arguments generated to help debug why a mismatch occurred.

    2017-10-09 15:50:12,387Z (10:50)[...]/1] INFO - No Stateless Match Could not match a stateless transaction
    2017-10-09 15:50:12,391Z (10:50)[...]/1] WARN - No Match Request <?xml version="1.0" ?>

    <request operation="<operation>" matchTolerance="EXACT">
    <arguments>
    <parameter name="ArgName">argValue</parameter>
    <parameter...

     

     

    If you need even more information, you could add a Scriptable DPH to the Listen Step and print the Argument List into the VSE.LOG file.  The DPH Code looks something like this:

     

    %beanshell%
    _logger.info("<<< lisa vse request arguments are:\r\n{}", 

        lisa_vse_request.getArguments().toString() );

     

    The key/value output generated by the snippet above goes into the vse.log file looks something like this:

    2017-10-11 13:53:54,180Z (08:53) [...]/1] INFO com.itko.lisa.script.logger - <<< lisa vse request arguments are:
    ArgName1=argVal1&ArgName2=argVal2...

     

    A few debugging steps are:

    1. Ensure the request arguments (number of and names) match the VSI.
    2. Check for upper/lower Argument Name case mismatches.
    3. Ensure that you understand what DPHs may or may not have done to the incoming request.
    4. Review your VSI comparison criteria against the incoming request values.
    5. Check for Matches Scripts and review that code.
    6. Use Portal to compare the incoming request information to the VSI.
    7. Apply additional debugging such as the Scriptable DPH as necessary


  • 3.  Re: Matched Response ID from VSI

    Posted Oct 12, 2017 07:27 AM

    Hi Joel,

     

    Thanks for the quick response. The actual issue is we have virtualized a good number of mainframe calls and the VSE_Matches.log sometimes becomes so bulky that I cannot rely on it nor the inspection view for debugging. Hence , I tried logging in the matched transaction ID in the service specific log file along with the incoming req and send response details. 

     

    What I observed is the VSE_Matches.log is showing the correct matched transaction id from the VSI but the service specific log file is always showing the meta response  even I get the response from a specific transaction in the VSI. This is where I tried to put the above mentioned custom logic to write the matched transaction ID in the service specific log file which is not working as expected.

     

    Virtual service specific log file:

    The stateless Match Transaction in the above request is the ID of the meta response in the VSI

     

    VSE_Matches.log:

    The ID in the above screenshot is the actual response I'm getting from the VSI

     

    Could you please correct me if I'm missing any.

     

    Regards,

    Shivakumar.



  • 4.  Re: Matched Response ID from VSI

    Posted Oct 12, 2017 10:43 AM

    Hi Shivakumar, these different outputs can be confusing, I know.

    NOTE: I believe the getId()method returns an object ID not the internal VSI response transaction ID. Perhaps, someone else can chime in if they know of a method to return the matched transaction ID.

     

    Here is some background as to how the IDs are formed and printed into the log files:

    - Each VSI file is stored as XML.

    - Internally, DevTest assigns each logical transaction, META, specific transaction, request, response, unknown stateless, and unknown conversation, etc. with an ID attribute to distinguish one element or node from another. There is no magic associated with the value of the ID. It is there to help make the entries unique to the internal engine.

    - The order and value of these attributes is controlled and assigned by DevTest.

     

    An example of the attribute IDs inside a VSI XML file looks something like this. The four (4) IDs we want to look at in this example are: 42 & 58, and 53 & 54.

     

    DevTest prints these IDs in the log files to help developers follow the trail of the matching logic at run-time.

    Consider the high level matching process on the incoming request.

    1. DevTest determines if the request is Stateless or Conversational
    2. DevTest locates a candidate Logical Transaction (ID = 42, 41, etc.) in the Service Image
    3. Once the Logical Transaction is selected, DevTest locates the META Transaction (ID = 58)
    4. DevTest can then examine each Specific Transaction (ID = 53 & 43) for a match. If no match, the META (ID=58) is used.
    5. If a Specific Transaction (ID=53) is selected, the request ID (ID = 54) for the matching transaction can be displayed. 

     

    Some confusion can occur because vse_matches and VS_theService logs can print different sets of values based on the steps the engine goes through when selecting a response.

     

    The VS_theService.log file prints some displays showing the matching logic for locating a Logical Transaction and its corresponding META transaction. For example (excerpted data displayed below):

    Date/Time [.../1] INFO - Inbound Request {"id":0,"operation":"POST /test","arguments":{}}
    Date/Time [.../1] INFO - No Session ID No session identified

     

    The next line shows that a Stateless Logical Transaction (ID=42) was matched and its corresponding META transaction (ID=58) having a tolerance of argument 'signature'. 
    Date/Time [.../1] INFO - Stateless Match Transaction: {"id":42,"navigationTolerance":"<stateless>","request":{"id":58,"matchTolerance":"SIGNATURE", 

     

    This narrows the service selection criteria to the Logical Transaction that is evaluated in order to determine if a specific transaction response can / will be sent. From here, the engine looks at each of the specific transactions.

     

    The most important printout is seen in the vse_matches.log file in the Transaction Navigator Respond From entry.  (I believe this is the ID value you are trying to print out using a code snippet in your service.)

    Date/Time [...]/1] INFO  - Transaction Navigator Respond from: {"id":53,"request": {"id":54,"matchTolerance":"EXACT","operation":"Operation1","arguments":{

    Date/Time [.../1] INFO - Response on the Wire HTTP/1.1 200 OK <followed by the actual response>

     

    The "Response on the Wire" output contains the actual data that is sent to the service consumer.

     

    I played with the idea of using ElasticStack to consume the log files in an effort to align all the various outputs into a dashboard to make research easier. Presently, I do not have any prototypes.

     

    As gadpr08 pointed out, abrsh01 document on matching Tech Tips: Guidelines on troubleshooting VSE request matching is also a helpful resource.



  • 5.  Re: Matched Response ID from VSI

    Broadcom Employee
    Posted Oct 11, 2017 10:24 AM


  • 6.  Re: Matched Response ID from VSI

    Posted Nov 06, 2017 06:21 AM

    Hi Joel,

     

    I tried something like this and it worked.

     

    import com.itko.lisa.vse.stateful.model.Transaction;


    Transaction txn = new Transaction();
    txn = (Transaction) testExec.getStateObject("lisa.vse.matched.transaction");
    MatchedID = 0;
    if( txn != null ) {
    //MatchedID = txn.getResponses().get(0).getId();  //This gives the id of the response which has matched in the VSI
    MatchedID = txn.getId();  // This is the toggle display ID which we see in the VSI. 
    } else {
    id = -1; // for any unmatched requests.
    }
    testExec.log("transactionID:" + MatchedID);

     

    This gives the matched ID from the VSI which I could able to log along with the req and res in my custom log for debugging.

     

    Thanks again Joel for the insight!!

     

    Regards,

    Shivakumar.