Virtual Service to handle 1 request and multiple responses depending on the incoming request

book

Article ID: 130896

calendar_today

Updated On:

Products

CA Application Test Service Virtualization CA Continuous Application Insight (PathFinder)

Issue/Introduction

 



We have a case of a web service which is stateful and asynchronous.
A request is sent via a request URL and a response is received via a different response URL.

Now we need to have additional responses added to this same VS. Depending on the incoming request, the VS should return additional 2 or 3 responses to a different endpoint.

Cause

N/A

Environment

DevTest on release 10.3.

Resolution

 


Client application sends one request and receives 2 responses. It included 3 steps: 
Steps 7 and 8: contain the VIN Request and the token response - It was accomplished with a standard VSM/VSI.
Step 11: send an additional response to a different endpoint - it was accomplished with a WebService execution step sending the response as a request in the raw xml tab. 

Basically this was the flow 
************************************************* 

Client ---> VSM  


************************************************* 
Client sends WSDL Validation to the VSM ---> 


<---- VSM sends the WSDL Response with updated location pointing to an VSI transaction 


Client sends a SubmitRequest request to the VSM ----> 


<---- The VSM sends the SubmitRequest response with a token ID 




<---- The VSM send the additional Response with data from the SubmitRequest request sent via WebService step to an different endpoint. 




The additional requirement: 
Depending on the transactionLocatorID and IdentificationID (request arguments), the VSM should send 2 or 3 additional responses to the different endpoint (configured in the WebService step). 
If there are more than 1 additional response, it should have a delay of 2 seconds between them.

This is the way we handled to have additional transactions in the VSI that would exact match for the TransactionLocatorID and the IdentificationID. 

Depending on the values of these request arguments, the matching transaction would have the required number of responses. Creating a list of responses. 

The first response on this list, would be returned to the client application sending the request. 

The additional responses on this list would be sent to the additional endpoint thru the WebService step. 

The steps on that: 
1. In the VSI, create additional transactions (copy and paste of SubmitRequest) and provide the correct values for TransactionLocatorID and IdentificationID arguments. 
2. Depending on these values, add the needed additional responses to the transaction. 

3. In the VSM, before the Respond step, verify how many responses the VSI is returning. 

4. The first response should always go to the HTTP Respond step, to be returned to the application sending the request. 

The additional responses should be sent to the additional endpoint using the WebService step.
We will need to loop thru the number of responses and for each additional responses, the webService step will be executed.  
When the list of responses ends, the VSM flow would go back to the HTTPS Listen step. 

Below is a summary of how steps 3 and 4 were accomplished:
step 3. In the VSM, before the Respond step, verify how many responses the VSI is returning.  

step 4. The first response should always go to the HTTP Respond step, to be returned to the application sending the request.  
The additional responses should be sent to the additional endpoint using the WebService step.  
a) In the VS Image Response Selection, we added the an scripted assertion with the following code:

import com.itko.lisa.vse.stateful.model.TransientResponse;  
import com.itko.lisa.vse.stateful.model.Response;  
import java.util.List;  

for (int i = 1; i <= lisa_vse_response.size() ;i++)  
{  
TransientResponse addResponse = lisa_vse_response.get(i);  
String addRespText = testExec.parseInState(addResponse.getBodyText());  
if (i==1)  
{  
testExec.setStateValue("rspSize",2);  
testExec.setStateValue("wsRequest1",addRespText);  
} else if (i==2)  
{  
testExec.setStateValue("rspSize",3);  
testExec.setStateValue("wsRequest2",addRespText);  
}  
}  
return true;  


This code is going through the list of responses for the matched transaction. 
If we have 2 responses:  
wsRequest1 will save the second response.  

If we have 3 responses:  
wsRequest1 will save the second response.  
wsRequest2 will save the third response.  

b) The HTTP/S Respond step will always return the first response from the VSI response list. That is why we are not handling the lisa_vse_response.get(0) in the code above.  

c) The next step after the HTTP/S Respond step will be the WebService step and will send the response saved in wsRequest1 property - second response in this case.  

d) There is an assertion in the WebService step to verify if the response size is 3.  
If yes, it will go to the Do-Nothing step.  
If not, it will go back to HTTP/S Listen step and will wait for a next incoming request to the VSM. 

e) In the Do-Nothing step we have 2 filters to save one property to another.  
The first filter saves the second response from the wsRequest2 property to wsRequest1 property.  
The second filter changes the value of rspSize to 0. We saved rspSize2=0 in the project.config. 
And this step goes back to the WebService step.  

f) In the WebService step we send the value of wsRequest1 property - that now contains the third response.  
The assertion checks again if the rspSize is 3, but now it is 0. In this case, the next step is the HTTP/S Listener step.  

When using these steps, I believe we will not need the filters we used before to add the incoming arguments values in the response sent via the WebService step. These values can be used directly in the VSI responses and you would not need the additional filters we added to the VSM. 

We provided a sample VSI/VSM with the sample responses. 
There are limitations with this virtual service. For right now, this model is able to handle 2 additional VSI responses - 3 in total.
If we need to handle more messages, we need to make some changes in the steps/filters/assertions on the model.

After you applied the changes on your side, the application team was not receiving the responses.
During one WebEx session, we verified the responses were being sent, but for some reason the client application was not receiving them.
Usually what happens is that the VSI response does not contain a specific data or it is not in a structure that your client application needs.
After some testing, we found that we had to edit the response so the client app was able to receive them. 

It looked like the response had to follow a specific structure, otherwise it would act as no response was sent. 
You were able to modify the additional responses accordingly and the application received the responses sent by the VSM/VSI.

There were an additional requirement:
In a specific scenario, you had 1 more additional response, that would make 4 VSI responses for one request.

I modified the virtual service and resent it to you.
The difference on this is that the Scripted Assertion in the VS Image Response Selection has a response size=4 and the 4th response is being saved in wsRequest3.
There is also an additional Do-Nothing Step that saves the responses to different properties. 
In the sample VSI I have, the transaction 11 is the one that contains 4 responses. 

When testing we verified the responses were being sent out of order. The 4th response was being sent before the 3rd response.
For that I added one more filter to the Do-Nothing step that changes how the responses are being saved to the wsRequest1 property. 
I tested it on my side and could verify the responses being sent on the correct order. 

As per your confirmation, the virtual service is now working as expected.

Additional Information

This virtual service is limited to 4 responses - 3 additional responses being sent by WebService Execution step.
There are different ways you can accomplish the same and won't be limited to the number of responses. 
This involve more coding and an engagement with the services organization may be necessary. We can contact your account manager for you if needed.

You can also use our DevTest community - https://communities.ca.com/community/ca-devtest-community, regarding any questions you have on custom process. 
Developers, services people and different customers are always replying questions or giving suggestions on how to accomplish a specific requirement that would require customization.