Troubleshooting a VSE Request Matching
search cancel

Troubleshooting a VSE Request Matching

book

Article ID: 10526

calendar_today

Updated On:

Products

Service Virtualization

Issue/Introduction

This article will provide guidelines on troubleshooting VSE request matching.

When a request comes into VSE , it attempts to match the request against the conversations/stateless transactions in the service image.

If a match is found, the relevant response is returned.

If the request does not match, VS will send a No match response as "The VSE service could not match your request to recorded request". 

This message usually means that the request sent to a virtual service does not match any of the recorded conversations/stateless transactions (operation/signature entries) in the VSI.

Environment

All supported DevTest releases and platforms.

Cause

N/A

Resolution

 Here are some troubleshooting steps to follow when you get a No Match response:

  • Verify the virtual service is using the correct VSI or not. In the Portal, go to Monitor ->VSE-->Select the VS. Rt-Click on the VS --> Inspection View -> select the Matching Tab and will see the Service Image name and the path in the What happened panel. For example, Service Image :  /VirtualServices/Images/WS.vsi.  If the WS.vsi does not have the transaction you are testing, will see a NO MATCH FOUND.

 

  • Verify the Transaction name and arguments. Verify these in the Recent Request panel or in the What happened panel. If request and arguments are not matched then will see NO MATCH FOUND.

 

  • If an ERROR, check the Inspection View - >Request Event Details, which shows the list of inbound requests. Select the request in the Error Request panel and select the steps in the Execution Step Event panel and see which step caused the error. Matching Tab will display NO MATCH FOUND. 

 

  • Also validate the requests in the log files, vse_matches.log and VS_XXXX.log (where XXXX refers to the virtual service name). These log files are located in the lisatmp_v.x (where v.x is the DevTest version number) folder. In the log files, will see information including the operation and the arguments that DevTest parsed when the request hit the VS. Then can compare this information to the transactions, Match style and Request Data Arguments in the VSI. 

 

How to find the inbound Request in the logs: 

 

See the below information in the logs only when the log level for VSE is set to INFO/DEBUG/TRACE. Set the log level in DEVTEST_HOME/logging.properties with the property - log4j.logger.VSE=INFO, VSEAPP.  Do not leave it set to DEBUG or TRACE longer than necessary. Here is a sample Inbound Request that is sent to a Virtual Service:

 

GET /someOperation 

 

{ "argument":{

      "Devtest_Portal":"9.0",

      "Devtest_Workstation":"2.0"

 }

}

 

Matched Request shown in the logs as below:

 

2017-08-03 05:21:47,953Z (00:21)[json [VS_json_Run]/1] INFO  - Response Lookup Completed

2017-08-03 05:22:04,214Z (00:22)[json [VS_json_Run]/1] INFO  - Inbound Request {"id":0,"operation":"GET /someOperation","arguments":{"argument_Devtest_Portal":"9.0","argument_Devtest_Workstation":"2.0"}}

2017-08-03 05:22:04,235Z (00:22)[json [VS_json_Run]/1] DEBUG - Signature match Signatures match

2017-08-03 05:22:04,237Z (00:22)[json [VS_json_Run]/1] INFO  - Stateless Match Transaction: {"id":822,"navigationTolerance":"<stateless>","request":{"id":829,"matchTolerance":"SIGNATURE","operation":"GET /someOperation","arguments":{"argument_Devtest_Portal":"9.0","argument_Devtest_Workstation":"2.0"}}}

2017-08-03 05:22:04,239Z (00:22)[json [VS_json_Run]/1] DEBUG - Operation match Operation names match

2017-08-03 05:22:04,246Z (00:22)[json [VS_json_Run]/1] DEBUG - Exact match Incoming matched source exactly

2017-08-03 05:22:04,255Z (00:22)[json [VS_json_Run]/1] INFO  - Response Lookup Completed

 

No Match Request shown in the logs as below:

 

2017-08-03 05:19:10,694Z (00:19)[json [VS_json_Run]/1] INFO  - Response Lookup Completed

2017-08-03 05:21:41,267Z (00:21)[json [VS_json_Run]/1] INFO  - Inbound Request {"operation":"GET /someOperation/","arguments":{"argument_Devtest_Portal":"9.0","argument_Devtest_Workstation":"2.0","id":"0"}}

2017-08-03 05:21:41,270Z (00:21)[json [VS_json_Run]/1] INFO  - No Session ID No session identified

2017-08-03 05:21:41,281Z (00:21)[json [VS_json_Run]/1] DEBUG - Operation match failure source: 'GET /someOperation', incoming: 'GET /someOperation/'

2017-08-03 05:21:41,283Z (00:21)[json [VS_json_Run]/1] INFO  - No Stateless Match Could not match a stateless transaction

2017-08-03 05:21:41,286Z (00:21)[json [VS_json_Run]/1] WARN  - No Match Request

 

Validating VSI in the Workstation:

 

1. Service Image Tab: Open the VSI and CLICK on the Service Image tab in the upper left.  Review the response in the Body tabs on the right (unknown conversational /Stateless response). The NO MATCH response is coming from here because the VSI could not match any transactions to an incoming request (located under the Transaction tab next to the Service Image tab). When there is no transaction match with the Request, DevTest sends the default no match Response "The LISA VSE service could not match your request to a recorded request".

 

  

 2. Transactions Tab:

Validate the Inbound Request by comparing the Match style, Operation and Arguments in the VSI.  If the request is valid.  The operation name and the arguments in the inbound request matches with the recorded VSI ( Exact Match).

 

If the Match style is Signature, the META response that is specified in the Meta Transaction is used.  

 

A request is invalid when the Operation is empty so it will show NO MATCH.  That will not match the operation name in the VSI.  

 

A request is invalid and will show NO MATCH because no arguments were parsed and the VSI is expecting two arguments.

 

 Note **:  Be aware that CASE sensitivity applies in the transaction match.  

Data Protocol Handlers - DPH

If the request being sent to the VSM matches the transaction in the VSI and you are still facing a no match, verify the Data Protocol Handler (DPH) under Filters in the HTTP Listen Step, especially if it required manual configuration - example Request Data Manager and Generic XML Payload Parser. It can be that a specific value was added twice in the DPH. If that is the case you can remove the additional request argument by using the icons to edit the DPH.

If a VSI was modified after the recording process, verify if the DPH matches the additional transactions in the Service Image. For a REST Virtual Service, make sure the URI rules match the operation names available in the VSI.

 

During VSE recording,  if you get the below message:

Please verify the port used.  Another VS might be running on the same port. 

 

 

 

Additional Information

Refer to these sections in them documentation of the release of DevTest you are running:

Match Tolerance

Inspection View

 

If you still have an issue with your request matching or have more questions, open a ticket with Broadcom Support and share the below:

  • Request you are sending to VS.
  • VSM and VSI.
  • VS_<yourServiceName>.log and vse_matches.log files located in the lisatmp_v.x,x (where v.x,x is the DevTest version number) on your VSE server.
Powered by Wolken Software