Broadcom Software Academy Blog

Turbo-Charging Your Virtual Services by Making Them Data Driven

Written by Sankar Natarajan | Oct 19, 2022 6:32:09 PM

Virtual services are crucial to testing practices. (See the recent post, 4 Key Reasons Service Virtualization is a Must for Agile Teams, for a great overview of why.) When it comes to creating a virtual service, one approach teams can use is recording. While this can be a great way to create a virtual service, it has some limitations in terms of the scope of the data set that can be held. This is largely due to the limitations associated with request-response pairs used with this approach.

Service Virtualization offers a feature called “Data-Driven Virtual Service.” This enables teams to turbo-charge their Service Virtualization investments. With this powerful tool, teams can address the data scenarios they need to effectively simulate production systems. This feature enables teams to use the Lookup or Refer command to reference an external data set, such an .xlsx or .csv file, and provide a response based on the values in the request.

In the following example, we’ll show how a country name can be entered as an input, the correct row in the table can be identified, and related details can be returned. Here’s a sample table:

Country Name

Capital

Currency

Official Language

Head of Government

Afghanistan

Kabul

Afghani

Dari Persian; Pashto

President - Ashraf Gani

Albania

Tirane

Lek

Albanian

Prime Minister – Edi Rama

Algeria

Algiers

Dinar

Arabic; Tamazight; French

Prime Minister – Ahmed Ouyahia

Andorra

Andorra la Vella

Euro

Catalan

Antoni Martí

Angola

Luanda

New Kwanza

Portuguese

President – João Lourenço

Assume that your backend service accepts the following request-and-response format.

Request

Response

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://www.webservicex.net/">
<soapenv:Header/>
<soapenv:Body>
<web:GetDetailsByCountry>
<web:Country>India</web:Country>
</web:GetDetailsByCountry>
</soapenv:Body>
</soapenv:Envelope>

 

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<GetDetailsByCountryResponse xmlns="http://www.webservicex.net/">
<Country>India</Country>
<Capital>New Delhi</Capital>
<Currency>Rupee</Currency>
<Language>Hindi</Language>
<HeadOfGovt>Prime Minister – Narendra Modi</HeadOfGovt>
</GetDetailsByCountryResponse>
</soap:Body>
</soap:Envelope>

In order to fully virtualize your backend, you have a few options:

Approach

Pros

Cons

Record with all the possible request parameters.

Easy to set up recording.

Works well for limited set of data.

Doesn't scale for large volumes of varied requests.

Takes very long time to record all possible inputs and responses.

Start with a basic virtual service using a request-response (RR) pair and then deploy the virtual service in learning mode.

Easy to create the virtual service and deploy.

May take a very long time to capture all possible request-response pairs to be recorded and have the virtual service fully ready to replace the live system.

Make your virtual service data driven.

Quick—all the possible request inputs and corresponding responses can be exported from a database to a .xlsx or .csv file and power your virtual service.

Flexible—incremental updates to your request-response data store could be handled very easily, just by adding rows to the data set and re-deploying the virtual service.

Efficient—this is by far the most efficient way to manage large sets of request-response pairs.

More realistic—by having support for large data sets readily available, the virtual service very closely mimics the real service.

This can only be set up only from the portal.

How to Create a Data-Driven Virtual Service: GetDetailsByCountry

Step 1. Create a basic virtual service using request-response pairs.

  1. Login to the Portal.
  2. Create a virtual service using the request-response pair files linked here: country-req.xmlcountry-rsp.xml
  3. Start your virtual service.

Step 2. Test your deployed virtual service (optional).

It is important to be able to test that the virtual service you create is working. Using Workstation, create a test case and add a single step: web service execution (XML). Then hit the end point of the virtual service deployed from step 1. Use the XML request from country-req.xml file. The virtual service would promptly return the recorded response.

Test Case

Step 3. Make your virtual service data-driven

The next step is to make your virtual service data driven so that it is even more powerful. At this point, the virtual service only knows about India. It must be given information about the remaining 202 countries of the world. Let’s see how to add more horsepower to your virtual service with some simple steps.

Prepare your data set as an .xlsx or .csv file, with the column names occupying the first row. For this specific example, I quickly prepared the sheet by taking all the data that is available here

My data sheet looks like the example below. You can also access the file here.

Once the data sheet is ready, it’s time to rewire our virtual service by adding data-driven behavior. You do this by following these simple steps:

  1. Go to the DevTest Portal.
  2. Go to Manage Virtual Services.
  3. Locate the virtual service that we created in step 1.
  4. Edit the virtual service.
  5. Go to the “Signature Definition” tab and turn on “Data Driven Behavior” by sliding to the right.
  6. You can create data-driven services using existing files known to the system or you can upload a new file. I uploaded the countries.csv file and clicked Done. This uploaded the file and read the column headers so that I can map the columns for input and response.
  7. Once the .csv file is uploaded, we define how to map request-and-response arguments. Based on the XML request, the editor shows the argument. We need to identify the right column header from the .csv file. For simplicity, I named the columns the same as that of the XML tag name. You are free to have any column names. There are no restrictions.
  8. The next step is to map the response arguments. You have a choice here: You could either map a specific column as the response or you could fill in a template using values from various columns, as shown below. The first method of mapping a single column as response would make sense if the entire XML response is provided in one column. However, in the countries.csv file, we have separated the details of a country in distinct columns. This page auto saves. Once you are done just close the tab.
  9. We are done with adding more horsepower to our virtual service. Let’s check and make sure that the virtual service is configured correctly. Open the virtual service in edit mode and check the .csv file that it uses. You can also use the gear wheel to change the input file at a later point if needed.
  10. Now let’s test the new data-driven behavior and validate that the newly enhanced service has been augmented to include the data scenarios it needs to replicate production. For this example, let’s pass a different country name to the input using the test created in step 2. I am passing China as input and expecting the following values as a response.

    However, what I got from the running virtual service was bizarre...I got all the details of India with just the country name changed...What went wrong???

  11. The bizarre behavior happened because we haven’t re-deployed the virtual service after data driving it. Let’s go ahead and re-deploy the virtual service. You do this from Manage Virtual Services. (This is the .mar file used in the example)
  12. Once done, check the new behavior. This time, the details of China are correct. Check out a few more countries too.

I hope you find this information useful, and that you are as successful and happy as I was when I got this process working well. Good luck.