Service Virtualization

  • 1.  Forwarding request

    Posted Apr 11, 2017 12:33 PM

    Hi,
    I am working on a project, in which VS replaces another system. The project is divided into 2 parts. Part1 has been completed successfully, and I need some help/suggestions so that I can complete part2.


    Below is a rough architecture diagram of communication pattern and the order of communication.

     

     

    As mentioned earlier, steps 1 and 2 are completed, and I am sure I can do Step5. Step 4 is associated with an Amazon WS endpoint, which works fine (I tested this communication through REST step). I am stuck in step 3, which is forwarding Req1 to the Amazon WS endpoint; how/what step should I plug (and where) into my VSM so that it will forward Req1 over to Amazon WS endpoint? Is this achievable in the same VSM or should I create 2 VSMs - VSM1 for steps 1 and 2, and VSM2 for steps 1 (if system1 is ok with resending Req1, which is not the actual working process), 3, 4 and 5?
    Any thoughts/ideas/suggestions?
    Thanks in advance.
    FYI, DevTest woversion version: 9.1.0.399.



  • 2.  Re: Forwarding request
    Best Answer

    Posted Apr 11, 2017 02:20 PM

    It is possible to do this in a single VSM, but there are a few caveats so please review the assumptions below. 

     

    One approach is to save off the incoming request and send it to AWS.  Filter the AWS Response and forward it back to the consumer. The single VSM approach means you  extend your existing model and add steps to accomplish the AWS call and consumer callback. A potential example VSM graphic follows:

    The Listen step receives and processes the call from the consumer.

     

    After the LISTEN is a step that saves the incoming request into a property. This could be done in a Scriptable DPH. It also assumes that all you care about is the request body. More script logic may be necessary if the AWS call needs information contained in the request's URI, operation, and/or HTTP headers.

    An example of saving the request into a property is:

    testExec.setStateValue("fl_step1_request", lisa_vse_request.getBodyAsString() );

     

    The VSI Response Selection and Responder steps fire according to plan -- this closes the loop on the Req / Resp (Steps 1 & 2). Under HTTP 1.1 specification, the responder closes the HTTP connection with the consumer once the the response is sent.

     

    After the responder sends the response to the consumer, add a step (WS or REST) that makes the call to AWS. In the content tab of this step, use the property fl_step1_request so the body content is sent to AWS. When the AWS call completes, filter the response into a property (i.e., fl_response).

     

    Add another step to send the AWS response to the consumer's endpoint.  Use "fl_response" property from the AWS response as the content in the callback. Wait for System1 to provide an acknowledgement and loop to Listen for the next incoming request.

     

    A few assumptions:

    - HTTP/2 request (multiplexing) and response (server push) is not required. DevTest does not yet support some of the HTTP/2 features.

    - The callback (Step 5) response is technically a request (REST or WS) step that is initiated with System1. In this step, DevTest is the consumer and a System1 endpoint acts as the server.

    - Step 5, in the original diagram, does not depict System1 providing a response. Because DevTest is operating as the client in the above example, DevTest will hold the socket open, by design, until some type of response is received or an HTTP timeout exception occurs. DevTest can ignore the response.

    - Logic to process information from the incoming request URL is not addressed

    - Logic to process information from the incoming request HTTP meta data is not addressed

    - Transaction volumes are such that timeouts will not occur in the consumer application due to the added amount of time to complete the additional processing

    - Tracking and learning modes are not required (e.g., very little chance of learning the AWS information as it is essentially async and done outside the scope of what DevTest could record in a single recorder)



  • 3.  Re: Forwarding request

    Posted Apr 13, 2017 03:39 PM

    Thanks for the detailed reply and workflow diagram Joel. I did try this out on my end, (and my only focus has been on part 2), it has been working good so far (pending some more testing and data updates).

    I will update once everything has been thoroughly tested and successful.



  • 4.  Re: Forwarding request

    Broadcom Employee
    Posted Apr 12, 2017 11:29 AM

    Good example Joel. 

     

    From the architecture diagram, I see the AWS response becomes the request to VSM. Isn't the VS in loop with the same request again and again?



  • 5.  Re: Forwarding request

    Posted Apr 12, 2017 11:35 AM

    Actually, the AWS response in the Send AWS Response (Step 5) step is assumed to be a REST or WS call to an endpoint on SYSTEM1. It is not a callback to the VSM's endpoint. The loop back to LISTEN after the callback simply closes off the VSM and lets the LISTEN step wait for the next incoming request from SYSTEM1.

     

    This is subtly different from HTTP/2 behavior which might expect an unsolicited send of the AWS response to SYSTEM1. In this context, which we do not support, the service is sending a response to System 1 but there is no 1-to-1 incoming request relationship.