Learning a REST service tutorial
Learning data from live communication is often the easiest way to create data models for your virtual services. Let’s see how to learn data for a REST service using one of Service Virtualization's demo services.
Let’s assume you would like to test a service, which is dependent on another service. The other, 3rd party service is not available from Wednesday to Friday. Today is Tuesday and you know you need to use this 3rd party service by tomorrow to finish all the testing in time, as you are already running late. Fortunately, you can clone the 3rd party service in the form of a virtual service. We’ll demonstrate this using the Claim Processing Demo service.
Tip: Find more details about the concepts presented here or about how to perform any of the steps in this tutorial by searching the Service Virtualization Help.
- Install Service Virtualization Designer.
Start the MemberAccounts REST Demo service:
In the sample projects folder, locate and run
ClaimProcessingRestDemo\run-xml.batto open the Health Insurance demo client.
The sample project folders are located, by default, in <Your Documents folder>\Service Virtualization\Demos.)
- In the Health Insurance demo client, click Enter Claim.
The demo client now looks like this:
Now everything is ready for you to virtualize the Member Accounts service by recording the real service behavior.
Virtualize a REST service
To virtualize the MemberAccounts service, you need to perform the following steps:
- Create a virtual service
- Reconfigure the client application
- Record communication
- Verify that simulation works correctly
In this step you will create an empty REST virtual service, configure it, and switch it into Learning mode. While in Learning mode, the virtual service will record any traffic between the demo client and the Member Accounts service. Recorded data will be saved in a data model when you stop recording.
- Start the Service Virtualization Designer.
- Create a new project. From the main menu, click File > New > Virtualization Project.
- Add a new REST virtual service. From the main menu, click File > New > Virtual Service.
In the Import Real Service Description dialog box, select I don't have a service description.
In the Choose Service Protocol dialog box, select the REST protocol.
In the Service Properties dialog box, specify the endpoint of the "real" service, as follows:
Click Virtualize to complete the process.
In the Virtual Service Editor, click Learn to switch the new virtual service to Learning mode.
Now we need to make a configuration change so that the client will send requests to the virtual service instead of to the real service.
We know that the client application is using the system proxy, so we need to change it, as follows:
- Set your machine's proxy server to the same proxy server that the virtual service is using.
Make sure that the proxy will be used for local addresses as well. In Windows 10, you must clear the Don't use the proxy server for local (intranet) addresses option.
In the demo client, click Enter Claim to send the request again.
The communication flows through the virtual service on its way to the real service, and the real service behavior is recorded.
Notice that there are 8 messages, which means 4 requests and 4 responses. This is what we expected, and what the sequence diagram at the beginning of this tutorial showed us.
To make sure that the recording was successful and that no manual modification of the data model is required, we need to test the virtual service with the client application.
- In the Virtual Service Editor, click Simulate to switch the virtual service to Simulation mode.
Close the console window of the MemberAccountsService that was started together with the demo client. The real service is no longer needed.
Send the request again from the demo client.
The demo client should now show the same message as during recording or as before we reconfigured the proxy.
In this tutorial, we populated a data model for our virtual service with four recorded request-response pairs by recording communication between the client and the real service. To route requests to our virtual service, we reconfigured the system proxy. Finally, we verified that the virtual service is simulating properly.