- The problem
- The example
- Intended audience
- Overview of virtual service variants
- Environments to bind logical to physical
- Create an environment in Rational Integration Tester
- Configure the HTTP proxies
- Configure systems under test to use the different environments
- Create and publish the virtual service variants
- Start the two variants of the virtual service
- Why this works
- Downloadable resources
- Related topics
Virtualize multiple behaviors in parallel with Rational Test Virtualization Server
Use two variants of a virtual service for different systems under test
Why would you want to run two different variants of a virtual service simultaneously? Typically, this function is used when there are two different systems under test (SUTs), or two components of an integrated system, both of which depend on the same service interface definition. It is possible that your situation requires those two components to receive different responses from that service interface, even if they submit identical requests. This can occur in two main situations:
- Multiple test cases are being run in parallel: For example, when the SUT is hosted in a cloud, it is easy to deploy multiple identical instances on which to run the separate test cases. These multiple test cases might require different behaviors of the virtual service for the service interface in question.
- Multiple components in a SUT: These components depend on the same service interface, but, for purposes of the test case, must receive different responses. The virtual service design cannot distinguish between these components based on the requests alone.
This article considers the case of multiple test cases being run on separate SUTs in parallel. However, the same steps and principles apply to separate components; just replace the phrase SUT with component.
This article follows a particular service virtualization example, as shown
in Figure 1. In this example, the system under test is a web application.
This web application has a dependency on the
calculator web service, which is provided by
IBM® Rational® Test Control Panel in IBM® Rational®
Test Virtualization Server.
Figure 1. The test environment without service virtualization
As shown in Figure 2, you set up virtualization of this dependency for use when testing the web application that depends on it.
Figure 2. The test environment with service virtualization
It is possible to deploy multiple instances of this web application, which is especially useful when testing, so that not all tests are waiting to use the same instance. In this example, we will set up virtualization in two test cells so that the testing can be performed concurrently, with two tests being run at any one time – one on each test cell.
calculator dependency is not hosted within the
production environment of the web application being tested, but it is an
external dependency. Therefore, it is also not hosted within the test
cells themselves, but both cells, by default, point to the same external
dependency, as shown in Figure 3.
Figure 3. Multiple instances without service virtualization use the same dependency
As shown in Figure 4, you virtualize the dependency to provide control of the service and its behavior in the scope of an individual test cell.
Figure 4. Multiple instances with service virtualization use separate virtual services
The intended audience of this article are users with some initial experience in using IBM® Rational® Integration Tester and Rational Test Virtualization Server. It is aimed at users who are faced with a problem of running different systems against different virtual service variants, or users who want to learn more about how to use Rational Test Control Panel environments and the Rational Integration Tester HTTP proxy.
Ensure that you have access to the following software:
- Rational Test Control Panel, which is available in the Rational Test Virtualization Server installer.
- A virtual service, already created, in a Rational Integration Tester
project, which must already have an environment defined. In the
examples, this article uses a project into which is imported the
calculatorWSDL file from the Rational Test Control Panel examples, which can be found on a local install at http://localhost:7819/RTCP/examples/.
- An HTTP proxy from the IBM Rational Integration Tester Platform Pack
- IBM Rational Integration Tester Agent running and registered with Rational Test Control Panel.
Overview of virtual service variants
This scenario, as described in the problem statement, includes a virtual service that behaves in two different ways for different callers at any one time. This article refers to these as different variants of the stub. However, this is not a term found in the Rational Integration Tester user interface.
How you use these variants depends on your situation. For example, they might need to return different data, use different test data sets, or one might need to simulate an error and one might need to simulate a success case. You define the variants using one of the following options:
- Create a parameterized stub: The single stub takes an input value into one of its tags in the tag data store. Configure the stub to behave differently based on that input value. For example, if the virtual service returns a number, such as a credit score, and the only difference between the two variants is what number it returns, you can configure it to take the number to return as an input tag. See the documentation for Rational Integration Tester for more information on stub input tags.
- Create a single stub for the first variant and modify for others: You can create a single stub for the first variant, and publish that at one version (for example, version 1.0). Then modify it to behave as the other variant and publish it as a second version (for example, 2.0). This approach is not recommended, unless one of the systems under test really is intended to run against a particular baseline of the virtual service. This approach is not suitable for modeling different versions of the service interface or of the real implementation of the service. In those cases use a parameterized stub.
Environments to bind logical to physical
In Rational Integration Tester, an environment is used to bind the logical model of the system to physical resources, such as web servers or message brokers. The logical model does not contain enough information about the physical resource (for example, the host and port of a web server) to make a request to an operation or to virtualize an operation.
For example, you might have an environment for the bindings used for each of the following: the production environment, the staging environment, and a continuous integration environment. Both the systems under test and the dependencies might have different bindings in each of these environments. These might be different physical test cells, or they might be logical groupings of shared components.
Rational Test Control Panel extends this concept, and can confine its intercepts (including the HTTP proxy) and agents to the scope of a particular environment. It is good practice to use a different HTTP proxy for each of your environments to prevent them from interfering with each other's traffic. For example, you do not want a virtual service in the continuous integration testing environment to route traffic from the staging environment.
Environments are created in Rational Test Control Panel when you publish
the virtual services to it. Environments in the control panel are grouped
into domains. In this article the domain used is called
default, but this can be any name. You can create a domain when you publish virtual services or using the
Administration page in the control panel.
For the scenario in this article, you need two environments: one for each of the systems under test. That is, each of the variants of the virtual service must be run in its own environment.
Create an environment in Rational Integration Tester
This article assumes that you have created an initial environment when you
modeled your system. For example, when importing a WSDL file, it creates
an environment for you with the correct bindings. In this example, the
original environment is named
In your Rational Integration Tester project, create a second environment, as shown in Figure 5:
- Click Project > Edit environments
- Select your existing environment.
- Click Clone the selected environment.
- Give the new environment a name (for example,
Figure 5. Cloning an environment
Configure the HTTP proxies
As stated above, Rational Test Control Panel can scope its HTTP proxies to individual environments. This scope is defined in the HTTP proxy configuration file. It is possible to run two instances – that is, two HTTP proxies – from a single installation of the Rational Integration Tester Platform Pack.
Set up two instances of the platform pack's HTTP proxy -- one for each of your environments:
- If the HTTP proxy is running, stop it.
- Inside the installation directory of the platform pack, duplicate the
httptcp directory, and name the new copy
- Edit the httptcp/registration.xml file: uncomment the
<domains>element at the bottom of the file, and insert the name of your first environment and its domain. This will mean this proxy only picks up rules for that environment. For example, if your domain is called
defaultand your first environment is called
TestCell1, the code looks similar to Listing 1.
Listing 1. Configure the first proxy with the TestCell1 environment
<!-- A proxy does not need to register against a domain or environment. By default it will proxy for all domains/environments. If you want to restrict its use then add <domain> entries based on the example below. Each domain may have 0 or more environments → <domains> <domain name="default"> <environment name="TestCell1" /> </domain> </domains>
Note: If you have not yet created a domain, choose its name now. When the proxy registers, it will create the domain for you.
- Edit the file httptcp2/registration.xml:
- Change the
<http-proxy>element's port attribute to be a different value, e.g. 3130.
- Delete the
<https-proxy>element (or change its port number and plainCommsPort number to different values).
- Comment out or delete the
- Uncomment the
<domains>element at the bottom of the file, and insert the name of your second environment and its domain. For example, if your domain is called
default, and your second environment is called
TestCell2, the code looks similar to Listing 2.
- Change the
Listing 2. Configure the second proxy with the environment TestCell2
<!-- A proxy does not need to register against a domain or environment. By default it will proxy for all domains/environments. If you want to restrict its use then add <domain> entries based on the example below. Each domain may have 0 or more environments → <domains> <domain name="default"> <environment name="TestCell2" /> </domain> </domains>
- Start both of these proxies, by running
- Go to the agents page of the Rational Test Control Panel and select the appropriate domain. Make sure you can see both HTTP proxies registered, each reporting a different environment. You may need to refresh the page if the domain was just created.
Figure 6. The registered proxies
Configure systems under test to use the different environments
For a SUT to use an environment, two pieces of configuration are needed:
- The SUT must be configured with the same bindings that are used in the Rational Integration Tester project's environment. No action is required to make this happen at this stage, because the environment in Rational Integration Tester should have been created using the values that the SUT is using, for example, by importing the WSDL describing the services it uses.
- The SUT must be configured to send its HTTP traffic through the HTTP proxy for the appropriate environment.
Configure each of your systems under test to use the appropriate proxy, which will determine which environment's virtual services are used by that system:
- The systems that are to go to the first variant of the stub should be
configured to use the first proxy (on default port
- The systems that are to go to the second variant of the stub should be
configured to use the second proxy, using the port you configured in
<http-proxy>element of httptcp2/registration.xml (
3130in the previous examples).
Create and publish the virtual service variants
- Create the two variants of your virtual service using one of the strategies described in the overview of virtual service variants. How to create virtual service stubs is outside the scope of this article. For more information, see the Rational Integration Tester information center and the links in the resources section.
- Publish stubs to Rational Test Control Panel under both environments.
This action makes both variants available to Rational Test
- Go to the test factory perspective.
- Right-click on the Logical folder and then click Publish stubs.
- As shown in Figure 7, type a new version number (for example,
- If no domains exist on Rational Test Control Panel, select Create new domain, enter a name, and click OK.
- Select your domain and both environments.
- Click Publish.
Figure 7. Publishing stubs
Start the two variants of the virtual service
Now, whenever one of the variants of the virtual service is required by a test in one of the test cells, that variant can be started in the appropriate environment. It will then only affect traffic for that test cell, and will not interfere with testing in the other test cell.
To demonstrate this, start each variant of the stub in the appropriate environment.
- Go to Rational Test Control Panel, open the VIE page, and select the first environment, as shown in Figure 8.
Figure 8. Selecting an environment
- Start the first variant.
- If you created a single stub to accept an input parameter, in the start stub dialog select Configuration > Input tags, and in the value input field for the appropriate input tag enter the value for the first variant.
- If you created two versions of a single stub, one for each variant, after you select the stub's name, select the first version.
- Return to the VIE page and select the second environment. Start the
- If you created a single stub to accept an input parameter, in the start stub dialog select Configuration > Input tags, then in the value input field for the appropriate input tag, type the value for the second variant.
- If you created two versions of a single stub, one for each variant, select the stub's name and select the second version.
Now the system under test that is configured to use the first proxy will receive responses from the first variant of the stub when it submits a request to the virtualized service interface, and the system that is configured to use the second proxy will receive responses from the second variant of the stub.
Why this works
This method works because each of the variants of the virtual service creates a routing rule for the proxies that are registered against the environment in which that virtual service is running. To see the rules that exist, go to the Agents page of Rational Test Control Panel, select the appropriate domain, and click Show rules.
- The proxy registered against the first environment picks up the routing rule created by the first virtual service, and so directs traffic to that service.
- The proxy registered against the second environment picks up the routing rule created by the second virtual service, and so directs traffic to that service.
Because you configured each system under test to use a different proxy, they each use a different virtual service, even though both are running at the same time and have the same rule condition by which they match requests.
Environments can be used in Rational Integration Tester and Rational Test Control Panel in two main ways, and there is significant overlap between the two:
- Rational Integration Tester can assign different physical transports – that is, different endpoint bindings – to a service in different environments. This article does not use this feature. Both environments use the same binding, because in both cases, the systems under test have the same endpoints configured for the dependency that is being virtualized.
- In Rational Test Control Panel, the different environments can be used to represent different test labs, or different collections of machines being used for testing. In this article, each test lab (whether real physical test labs, or a conceptual separation of testing resources) has its own HTTP proxy, so that the traffic in each case can be controlled separately without interfering with testing that is happening in the test lab represented by the other environment. In the same way, Rational Test Virtualization Server agents can be registered against a single environment, so each test lab can have its own agent or collection of agents, again to avoid interference between environments.
This article begins with two different systems under test that use two different variants of a virtual service simultaneously. To achieve this, the example runs each system under test against a different environment, where each environment has its own HTTP proxy, and each virtual service is run in the appropriate environment. This article offers help for how to use environments in Rational Integration Tester and Rational Test Virtualization Server to achieve more flexible, powerful, parallel testing and virtualization.
- Learn more about Rational Integration
Tester on developerWorks. In particular, check out these additional
- Rational Integration Tester information center includes pointers and helpful tips and installation instructions.
- Stubs made easier with Rational Integration Tester (developerWorks, November 2013) explains how to simplify integration testing even if you don't have all the necessary components.
- Check out the blog post The Rational Integration Tester HTTP Proxy: What is it?, which introduces the HTTP proxy.
- Find out how to Use Rational Integration Tester to test WebSphere MQ test message interactions (developerWorks, February 2013)
- Learn What's new in Rational Integration Tester 8.5.1.
- To learn how to test using virtual services in Rational Test Virtualization Server see Testing with Rational Test Virtualization Server in the Rational Integration Tester information center.
- Learn more about environments in Rational Integration Tester in Getting started with Rational Integration Tester – Environments in the information center.
- Find out more about IBM Rational Test Workbench on developerWorks and learn about its features and benefits on the Rational Test Workbench product page.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, anytime, and many of the Getting Started ones are free.