How to troubleshoot VSE request Matching.

Document ID : KB000010526
Last Modified Date : 14/05/2018
Show Technical Document Details
Introduction:

This article will provide guidelines on troubleshooting VSE request matching.

Background:

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 back. 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.
Instructions:

 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 you 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. You can verify these in the Recent Request panel or in the What happened panel. if request and arguments are not matched then you will see NO MATCH FOUND.
  • If you get 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. 
  • You can 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, you will see information including the operation and the arguments that DevTest parsed when the request hit the VS. You 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: 

We see the below information in the logs only when the log level for VSE is set to INFO/DEBUG/TRACE. You can 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 your 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".

   

Image1.png

 

 2. Transactions Tab:

Validate the Inbound Request by comparing the Match style, Operation and Arguments in the VSI.  For example: In the below image, ONLY the first 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.  

The second request will show NO MATCH because the operation is ""(empty).  That will not match the operation name in the VSI.  

The third request will show NO MATCH because the request is missing the argument   “DevTest_Workstation”  and the VSI is expecting it.

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

 

 Image2.png

 

 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.

Additional Information:

Documentation on Match tolerance is available at: https://docops.ca.com/devtest-solutions/9-5/en/using/using-ca-service-virtualization/ca-service-virtualization-concepts/match-tolerance

Documentation on VS Inspection view is available at:https://docops.ca.com/devtest-solutions/9-5/en/using/using-ca-service-virtualization/using-devtest-portal-with-ca-service-virtualization/monitor-virtual-services/inspection-view

 

If you still have an issue with your request matching or have more questions, open a ticket with CA 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 (where v.x is the DevTest version number) on your VSE server.