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