Service Virtualization

Looking for some suggestions here on if I'm doing this the "smart way".

Client to Live-Service Workflow (it's a REST service)

1. Client requests info on a person account.
2. Service responds with account info.
   
   1. The response also contains URLs to other REST calls that the client can hit for additional info.
3. Client takes the response, does what it needs with the data.
   1. Sometimes the client will want to get some additional info and will make a call to one of those URLs that were returned in the previous response.

The problem

During recording, that response that contains the URLs to other service calls is obviously returning URLs that point at the live service.  So when we deploy the virtual service, that initial call is virtualized no problem.  However, the URLs that are returned in the virtual response point at the live  service.  So the client then ends up making the next calls to the live service.

To work around this, I've been modifying the URLs that get returned from the virtual service to point at a DevTest recorder.  That way when the client makes its' initial call to the virtual service, the virtual service responds with a URL that points at a recorder, which in turn passes the call to the live service and captures the data.  After the data is captured from this second call, then I can deploy that service and now we have virtualized 2 calls.

This process works, but is cumbersome because each call returns URLs that the client can go hit for more info.  So if the client ends up wanting to hit one of those URLs that got returned from the previous response, then we have to go through this little dance again.

All of the URLs that get returned, point at the same live service HOST.  I doubt this functionality exists, or if it even makes sense, but it would be awesome if there was some way during the recording to have it dynamically know to replace any occurrence of that HOST, with the host where my recorder lives.

Anybody have any suggestions?

Thanks,

Jeff

This can be one of the approach (explained in diagram below) which can make life easier in situation what you have described. Currently the live recorder doesn't give an option to dynamically update the response during recording. You can have an additional VSM acting as a proxy to the actual Live DevTest recorder that can manipulate the responses before sending it back to the caller. 

Thanks for the response Ashutosh.Satyam !

Question for you.  In that custom VSM, do I just create a .vsm file and have it forward all traffic received to Restful Service (1) ?

Yes, this custom VSM workflow can be broken down into 4 steps.  In the "Update Response" step the model needs to read the incoming response from External service and update it as necessary before responding back.  The Custom VSM is listening to and responding back to the Live DevTest Recorder.

Ashutosh.Satyam are these the steps that you would use in the .vsm file?



If so, I'm trying to understand how you can have the Listener step change the target host value and forward the request onto the live service via the HTTP Get step.

For invoking external service you can use any of the steps grouped under Web/Web Services like Rest Step, Web Service Execution or HTTP/HTML request.  In any of these steps, you can specify the external endpoint, URL parameters, Post parameters as needed. 

Ashutosh.Satyam I'm still confused on how the "invoke external service" step is going to be smart enough to route the request to the proper host and resource.

For example ::

1. Client will invoke the recorder at :: http://myRecorder:9001/user/1
2. The recorder will be configured to pass all traffic to my custom VSM, effectively making the call :: http://myCustomVSM:9001/user/1
3. In the custom VSM, the "HTTP/s Listen" step will see the request, but how can I then make the "invoke external service" step smart enough to know to append the proper context (i.e. /user/1) to the base url?  I know that I can define what URL I want to hit with whatever implementation I choose for the "invoke external service" step, but I need to be able to only specify the base url and then have the step know what context to append to the URL.  Essentially, I need it to be smart enough to take whatever URL context is received in the "HTTP/s Listen" step and append that to the base URL that I define in the "invoke external service" step.

Does that make sense?

Every  step in the model when executed sets multiple properties which can be accessed in the later steps. For instance, when HTTP/S Listen step is executed you will notice a bunch of properties is set as shown below.  In the next step, you need to read the property lisa.vse.http.current.transaction and extract the URI value.

It seems in your case the request to be forwarded has only URL parameters. To make it simple instead of using HTTP/s listen you can instead use Socket-Listen step. When this step gets executed it gives you straight the URI as a property without requiring further extraction.

In your next step which invokes the actual service the Endpoint URL can be set like this:

http://myCustomVSM:9001/{{lisa.Socket-Listen.http.uri}}

Ashutosh.Satyam Awesome!  I will definitely give this a shot and let you know how it goes.  Also, the example URL context that I provided is just an example.  I just wanted to make the example be easy to follow.  Our use-case is a bit more complicated than that, but it seems like I might be able to get it to work with the info you've provided.

Thanks again for the help  

Ashutosh.Satyam
I finally got some cycle time to work on this.

However, I've run into a snag.

I've got the custom VSM to ::
- accept a request

- extract the URI context from the request

- append the URI context to the REST call and invoke the live service

That is where I hit the snag.  I need to be able to return whatever response I get from the live service.  (I will also need to parse through the response and replace all instances of the live service host, with the host for the recorder before returning.  But I need to get past this hurdle first)

How can I get the Virtual HTTPS Responder step to return the response that the live service generates?

I suggest that you setup the virtual recording as above and trigger all the calls for "additional info" and record them into individual Virtual Service Image. After which, you can merge them into 1 Virtual Service.