Service Virtualization

  • 1.  Requirement to create a VS with one Request Response two or more Response

    Posted Mar 23, 2017 12:15 PM

    Hi All,

         I have a requirement to create a virtual service with with one Request Response two or more Response .

    After sending the resp1, I need to wait for 5s and send rsp2 response.workflow like this,

            CRM             OServer                    
          req1 ->       vsm1(listen)
          <- resp1      vsm1(resp)
     
          <- resp2      vsm1(resp) 
    Please share us any sample vsm if you have encountered.
     
     


  • 2.  Re: Requirement to create a VS with one Request Response two or more Response

    Posted Mar 23, 2017 12:20 PM

    Anyone here?



  • 3.  Re: Requirement to create a VS with one Request Response two or more Response

    Posted Mar 24, 2017 10:02 AM

    need help



  • 4.  Re: Requirement to create a VS with one Request Response two or more Response

    Posted Mar 24, 2017 10:51 AM

    What transport protocol are you using (HTTP, JMS, MQ, TCP, etc.)?  

     

    If the protocol is HTTP, which spec (HTTP 1.1, 2.0) are you using? 

    If the protocol is HTTP, you can send the second response via the REST or WS Execution XML steps?  <== This approach means your VSM is technically sending a request as the second response not an unsolicited response to the incoming HTTP request.  The reason is that HTTP 1.1 is synchronous not async.

     

    For HTTP, some scripting is involved because you need to 'grab' the second response out of the lisa_vse_response list and send it as the second 'response'.  DevTest takes care of sending the first response (synchronous) from the response list in the Responder Step.  But, OOTB DevTest discards any remaining responses in the response list. Perhaps, when HTTP 2.0 is implemented, the feature to send unsolicited responses might be added. I do not know the engineering plans related to HTTP 2.0.

     

    If the protocol is message-based (JMS, MQ, etc.), DevTest has a built-in facility to send multiple responses.  You add the second response for a specific or META transaction in the VSI.  See the '+' icon in the VSI, Response tab to add a second response.



  • 5.  Re: Requirement to create a VS with one Request Response two or more Response

    Posted Mar 24, 2017 11:31 AM

    Ths,Joel

       As you reply,impossible to achieve while using HTTP/1.1 to respond to multiple messages,if use HTTP/2 protocol  may be able to success?

    Do you Know how create  HTTP/2 protocol  VS ,And how create JMS MQ with websevice VS.



  • 6.  Re: Requirement to create a VS with one Request Response two or more Response

    Posted Mar 24, 2017 11:55 AM

    To my knowledge, a custom HTTP/2 transport protocol handler has not been developed by CA.  Perhaps, someone in the community has attempted to do this and would be willing to share their JARs.  On the surface, I would guess the level of complexity associated with creating a HTTP 2.0 TPH is reasonably high.  To get an idea of how TPHs are created using the SDK, check here: Sample Transport Protocol Handler Implementation   

     

    The pattern for creating message-based services closely resembles HTTP patterns such as by recording, R/R pairs, etc.

    DocOps might help get you started JMS Messaging Steps - DevTest Solutions - 9.5 - CA Technologies Documentation or for version 10 use JMS Messaging Steps - DevTest Solutions - 10.0 - CA Technologies Documentation.  It is difficult to provide a definitive implementation pattern because we know nothing about your environment or the data structures that would be recorded.

     

    Installation of the correct set of JAR files (if required), having an admin create proxy queues, and defining the DevTest assets are keys to enabling the recording and playback. There may also be other community posts that help you see how recording works.

    Help Understanding JMS Proxy Recording Process 

    How to retrieve JMS headers from Queues & Topics   

    How to capture valid data from JMS?  

     

    Also check out youtube.  CA has some additional demo materials there:

    IBM MQ Native Support - CA Service Virtualization - YouTube

    UPDATE: This diagram provides an example of the HTTP 1.1 pattern.  For the initial invocation, the client is the consumer and SV is the provider.  During the callbacks, SV is the consumer and the client becomes the provider.     

    One implementation might be to save off the subsequent responses (in this case callback HTTP requests). The Response Callback in this example is a RESTful call to an endpoint.  The step is not communicating on the same socket as the original HTTP incoming request. After the first response is sent, the model iterates over the list of callbacks until there are no more to process.  Logic could also be included to time the callbacks according to requirements.  One could go so far as to review the call back response from the provider and make decisions about whether or not to continue sending callbacks for that incoming request transaction.



  • 7.  Re: Requirement to create a VS with one Request Response two or more Response

    Posted Mar 25, 2017 03:17 PM

    J_NeSmith .. If I wanted to try , I would have done as below.. please correct me if this wont work.. 

     

    I will add both the response to single request in VSI using + symbol in response section, then in VSM before we process the response to respond step, extract the array of responses from lisa.vse.response using transient response then dispatch the first response.

     

    responseList = testExec.getStateObject("lisa.vse.response");
    String responseText = "";
    int m=0;
    TransientResponse response = responseList.get(m);

     

    then after 5 seconds dispatch the second response by increasing m=1.. 

     

    Regards

    Jagath



  • 8.  Re: Requirement to create a VS with one Request Response two or more Response
    Best Answer

    Posted Mar 27, 2017 11:23 AM

    You might want to consider the following flow to see if it meets your requirements.  

    The key is that the Responder step is only going to fire one (1) time and then close the original socket.  

    This snippet represents just one approach.  I typed the code pretty quickly so please expect potential syntax errors.

     

    1) VSI Selection Step

        a) Add a scripted Assertion or Add a JSR-223 step between the VSI Selection step and the Responder step.

        b) If assertion, set the Assertion to only fail if the response is 'false'.   If JSR is used, you can change to return string and assert on that.

    Potential logic:

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

    // get the list of responses after the VSI Selection Step occurs
    List lst = testExec.getStateValue("lisa.vse.response");

    // remove the first response from the list because it 
    // will be sent by the Responder step automatically
    lst.remove(0);

    // Save off the remaining responses - they will be checked later during the
    // looping process that sends the subsequent responses
    testExec.setStateObject("fl_responseList", lst);

    // return true so the script does not fail.  If using JSR-223 change to return "true" if you want

    return true;

     

    2) Responder Step - leave in place and let if fire as it normally would

     

    3) Add a JSR-223 step to simulate a thread sleep for 5 seconds

    Thread.sleep(5000);

     

    4) After the sleep step, add a JSR-223 Step to process the callback transaction from the saved list.

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

    // Get the List that was saved off in the VSI Response Selection Step
    List lst = (List)testExec.getStateObject("fl_responseList");

    // Add an Assertion to this step - when "false", go to LISTEN step
    if (lst.size() == 0) {
        return "false"; // List size 0 means no more to send
    }

    // List size > 0 means we need to send a response
    TransientResponse tr = lst.get(0);
    String rsp = tr.getBodyAsString();
    testExec.setStateValue("fl_asyncResponse", rsp);

    // remove the response from the list so it is not sent again
    lst.remove(0);

    // store the LIST -- it will be checked after the loop occurs
    testExec.setStateObject("fl_response_list", lst);

    // return true. Use an Assertion to stop the loop and go to LISTEN
    return "true";

     

    Add an Assertion to step 4).  If the response is "false", branch to LISTEN Step.  Otherwise, keep going.

     

    5) Add a REST or WS Execution XML step.  In the body (content) use DevTest notation to reference the response body from the list

    {{fl_asyncResponse}}

     

    Using the For Next Step, branch the REST or WS Execution XML step to the Thread Sleep step ( i.e., Step 3 ) if you want to wait 5 seconds before sending the next response.  Or, branch to Step 4, to immediately setup for the next response to go on the wire.

     

    You can get more fancy by adding code to access response header meta data if there are certain values that need to go out on the response (REST request) header.

     

    NOTES:

    - The above example does not take into account any knowledge of the behavior of the actual application.

    - The above example shows an HTTP 1.1 callback flow not a 2.0 flow.

    - The async responses are technically requests from the VSM to an application.  They are not unsolicited responses to an earlier request.

    - The VSM's REST or WS Exec step will wait for a response before continuing.  If an ACK or other response is not sent, an HTTP timeout is likely to occur.

    - Because of the callback and thread sleeps, a functional VSE may experience performance issues during periods of heavier load as TPS is throttled.

    - This is just one approach for looping and sending callbacks.  One could implement a delegation model and have a secondary VSM provide the callback workload.  A mechanism to pass the responses (e.g., via the Shared Model Map) to the second VSM would be required.  This approach is more complex and will not be addressed here.

    Hope this helps.