3rd VSI Selector Sending Meta Response
Article ID: 123498
Updated On:
Products
Issue/Introduction
Split a large VSI's and added a 3rd response selector to the VSM.
Able to get correct responses from the first 2 response selectors but the 3rd sends meta responses (which shouldn't be receiving).
Environment
All supported DevTest releases.
Resolution
The response getting back for the transaction POST /api/search123/ is from the Dxx_2.vsi instead of Dyy_3.vsi.
The reason for getting the response from Dxx_2.vsi is "Ensure Result contains string" assertion is failing.
The lisa.vse.response is in Transient form and when there are more than one lisa.vse.response (in the VS, there are responses from Dxx_2.vsi and Dyy_3.vsi also) in there the Transient response becomes a list and responses shows as below:
<list>
<TransientResponse xmlns="{{server}}/com/itko/lisa/vse/stateful/model/v1.0">
<id>0</id>
<binary>false</binary>
<charset>UTF-8</charset>
<metaData>
<p key="HTTP-Version">HTTP/1.1</p>
<p key="HTTP-Response-Code">200</p>
<p key="HTTP-Response-Code-Text">OK</p>
<p key="Content-Type">application/json; charset=utf-8</p>
<p key="Content-Length">536</p>
<p key="Connection">keep-alive</p>
<p key="X-Powered-By">Express</p>
<p key="Access-Control-Allow-Origin">*</p>
<p key="ETag">W/"218-hWS0/MhWZjquIodc3HC5FwmX7j0"</p>
<p key="Vary">Accept-Encoding</p>
<p key="Date">{{=httpNow()}}</p>
<p key="NoMatch">True</p>
</metaData>
<body>
<bodyAsString>[{"id":"e29b0d57-09c3-4548-86b5-d755d5d91fc2","confCode":"e29b0d57","applicationType":"ID","name_first":"social","name_middle":"fifth","name_last":"required","name_suffix":"","idNumber":"{{=request_idNumber;/*I9600970*/}}","dateOfBirth":"{{=doDateDeltaFromCurrent(&quot;yyyy-MM-dd&quot;,&quot;-17729D&quot;);/*1970-02-15*/}}","addresses_currentResidence_city":"sacramento"}]</bodyAsString>
</body>
<unknown>false</unknown>
<thinkTimeSpec>375</thinkTimeSpec>
</TransientResponse>
</list>
From the above, meta data shows <p key="NoMatch">True</p> instead of "NoMatch=True" in the response and assertion is failing which causes the response sent from Dxx_2.vsi.
Changed the "Ensure Result contains string" assertion to look for "NoMatch" then the assertion returned true and transaction match happened in Dyy_3.vsi.
Sent a request from SoapUI and was able to get this to work.
Transient response is what is called for responses from the VSE and are in a certain format.
When running through the ITR, could see the response from the Dxx_2 step coming back in a slightly different format.
Looking in the ITR, the response from that step was showing, <p key="NoMatch">True</p>, instead of "NoMatch=True" in the response, so the assertion is failing.
If an additional VSI is needed, will have to change the assertion on Dyy_3 to just look for NoMatch.
Feedback
