Service Virtualization

Hi All,

I've a requirement like below. Please guide me to achieve this.

Transport Protocol : HTTP/S

Data Protocol: XML

Request ------------ Response

A    ------------------> B

C    ------------------> D

A is the Request Message and Respective Response Message is B.

C is the Request Message and Respective Response Message is D.

• First, request A will trigger and then request C.
• So the response B has to wait until the request C comes.
• Finally, then response D has to send first and then response B. 

Hi Suryateja,

    Do you have any known time gap between Request A and Request C ?, If you know this wait time, you can introduce think time for Response B. So that, this response B will be in wait state for your given time.

   From this, I mean to say that this can be managed by introducing think time in response.

Thanks & Regards

Srikanth Gajawada 

Hi Srikanth,

Using the think time will fail my requirement in few scenarios. Like, for example request C is not triggered. In that case response B will send after some time even without response D. The response B should send, only after sending the response D successfully.

This is an unique requirement and some customization of the virtual service model file is most likely required to handle the asynchronous call to operation "A" followed by returning two responses for operation "C".

Here's how I see this being implemented and keep in mind that this customization specifically addresses the scenario you have provided. Some tweaks may be needed depending on additional requirements, if any.

In your VSI you will have two operations for requests "A" and "C"

For operation "A" add a match script like the following:

For operation "B" configure it to have two responses. Do this by going to Responses tab and click the + icon. See below

After adding your second response and populating it the VSI should look like below, notice it says Response 1 of 2 for Request C. This means Request C will return two responses, in this case the first response (Response 1 of 2) should be populated to have Response B payload, and the second response (Response 2 of 2) should be populated with Response D payload.

Next you need to customize the VSM. You need to add an Assertion that checks if Request A was matched, if so, loop back to the Listen step, otherwise proceed to the Respond step. We can check this condition by looking at the property "Request_A_Called" to see if it's true or false/null, which we set in the match script for Request/Operation A in the VSI.

The easiest way is to add a Scripted Assertion to the "VS Image Response Selection" step and some code to handle this scenario and loop back to Listen step:

1. Select VS Image Response Selection and select Add Assertion > Other > Scripted Assertion

2. Add the following code:

And also configure so that if it returns true then go to Listener step, see below

Hi William,

Using above logic we could see both the Responses D & B are sent to Request C. Is their any way where we can send back the Response D to Request C first  and then Response B to Request A.

Hi William,

Thank you so much for your detailed explanation for this. I've implemented same as like above, but currently it is working as Responses D & B are sending to Request C. Is there any way, we can achieve Response D to Request C first  and then Response B to Request A ?

Surya/Kiran,

I misunderstood the flow of your scenario but I think I get what you're trying to do now. I need to provide a different solution altogether. I will use a "global" hashmap called com.itko.lisa.vse.SharedModelMap. We can use this data structure to pass "data" between the two operations. Here's what I would do...

=============

1. Remove the Scripted Assertion from the VS Image Response Selection step, this is no longer needed based on my new understanding...

2. Remove the second response from Request_C, and make sure the second response (Response B) is the response for Request_A

2. For Request_A's match script, change it to the following code:

boolean operationsMatch = incomingRequest.getOperation().equals(sourceRequest.getOperation());

if (operationsMatch) {

   long currentTime = System.currentTimeMillis();

   while ((System.currentTimeMillis() - currentTime) < 60000) {

      String value = com.itko.lisa.vse.SharedModelMap.get("Request_C_Triggered");

      if ("true".equals(value)) {

         com.itko.lisa.vse.SharedModelMap.put("Request_C_Triggered","false");

         return true;

      }

   }

}

return false;

3. Add the following match script code to Request_C:

boolean operationsMatch = incomingRequest.getOperation().equals(sourceRequest.getOperation());

if (operationsMatch) {

   com.itko.lisa.vse.SharedModelMap.put("Request_C_Triggered", "true");

   return true;

}

return false;

===================

I haven't had a chance to test out this code but let me explain what I'm trying to accomplish and I think you will be able to take it from here...

In the first script I have a loop for a max of 60,000 ms or 60 sec (this is the assumed time out value for the HTTP connection, if it's higher, then simply bump up this value to that same value). Inside the loop I check if the key "Request_C_Triggered" has been set to true (from Request_C transaction/match script), if it is then I return true in this match script and I can respond with Response B, else I keep looping until I meet the time out value.

In the second script I simply put the key value pair Request_C_Triggered=true into the global map, which will be read in Request_A (granted the timeout value hasn't reached yet). It then returns true immediately and returns Response D before Response B is returned for Request_A...

Hope my understanding is correct and it works out this time 

Hi William,

We've updated the model and image as per your updated comment, but now model is accepting only one request. As per our requirement it should accept both requests A & C. First response D should be sent to request C after that response B should sent to request A. Please help to use achieve this.

Please note currently, we're triggering the requests A & C from SoapUI and later we want to see the responses D and B in SoapUI.

I have attempted to try out the implementation on my side and I realized there could be two potential reasons why you're running into issue still.

1. The first possible reason is that you may have a syntax error in your first script (for Request_A). I made an edit to my post last night through my phone device where I added the following line:

com.itko.lisa.vse.SharedModelMap.put(“Request_C_Triggered”,”false”);

The problem above is that my phone used ” for double quotes, instead of ". This will cause a syntax error in the match script editor. Here's the match script again with the proper double quotes:

boolean operationsMatch = incomingRequest.getOperation().equals(sourceRequest.getOperation());
if (operationsMatch) {
  long currentTime = System.currentTimeMillis();
  while ((System.currentTimeMillis() - currentTime) < 60000) {
    String value = com.itko.lisa.vse.SharedModelMap.get("Request_C_Triggered");
    if ("true".equals(value)) {
      com.itko.lisa.vse.SharedModelMap.put("Request_C_Triggered","false");
      return true;
    }
  }
}
return false;

2. The second possible problem is that your VSE must be able to service multiple requests at the same time. This means you need to be able to increase your concurrent capacity. Unfortunately, I currently have a developers VSE license and cannot service more than one request at a time. Therefore when I try to test this out in my machine I'm only able to send a request to Request_A while the Request to C is being queued I think.

So can you confirm the following two things:

1. Your match scripts are working fine and there are no syntax errors (if there is one or more syntax errors then you will see a red dot in the margin of the match script editor along with code underlined in red)

2. When you deploy the virtual service you are able to configure the "Concurrent capacity" to 2 or higher

FYI, a colleague of mine helped me enable performance VSE so that it can service multiple requests. I have tested out the implementation and it works. So the key here is to fix the match script and set the Concurrent capacity to 2 or higher.

I'm including the sample project I created to test this out. You can find the Request_A and Request_C payloads in /Data/rrpair. I used Google Postman to send the requests (first A, then C, and I receive D for C, and B for A, in this order).

Hi William,

I increased the concurrent capacity to 2 and it's working as expected. Thank you so much for your support to achieve this.