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)