<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=1110556&amp;fmt=gif">
Skip to content
    October 19, 2022

    Turbo-Charging Your Virtual Services by Making Them Data Driven

    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.

    ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 1

    ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 2

    ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 3

    ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 4

    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

    ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 5

    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.

    ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 6

    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.ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 7
    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.ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 8
    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.ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 9
    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.ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 10
    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.ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 11
    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.ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 12

      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???ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 13
      ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 14
    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)
      ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 15
    12. Once done, check the new behavior. This time, the details of China are correct. Check out a few more countries too.
      ESD_FY22_Academy-Blog.Turbo-Charging Your Virtual Services by Making them Data Driven.Figure 16

    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.

     

    Other posts you might be interested in

    Explore the Catalog