3rd VSI Selector Sending Meta Response
Document ID :
Last Modified Date :
Show Technical Document Details
CA Service Virtualization
CA Application Test:ITKOTF
We split large VSI's and I added a 3rd response selector to my vsm. I am able to get correct responses ffrom the first 2 response selectors but the 3rd sends meta responses (which I shouldn't be receiving).
The response we are getting for the transaction POST /api/search/ is from the D44_4_2.vsi instead of D44_4_3.vsi.
The reason for getting the response from D44_4_2.vsi is "Ensure Result contains string" assertion is failing.
As you know the lisa.vse.response is in Transient form and when there are more than one lisa.vse.response (in your VS, you have responses from D44_4_2.vsi and D44_4_3.vsi also) is there the Transient response becomes a list and responses shows as below:
<p key="Content-Type">application/json; charset=utf-8</p>
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 D44_4_2.vsi.
We changed the "Ensure Result contains string" assertion to look for "NoMatch" then the assertion returned true and transaction match happened in D44_4_3.vsi.
We sent a request from SoapUI and was able to get this to work.
In the saved the ITR so you can see what we are seeing as well as captured the SOAPUI call.
Transient response is what we call responses from the VSE, they are in a certain format.
When we ran through the IT, we could see the response from the D44_4_2 step coming back in a slightly different format.
It you look 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.
Iif you needed an additional VSI, you would have to change the assertion on D44_4_3 to just look for NoMatch.
Was this information helpful?