Virtualizing HTTP
You can simulate an HTTP connection with a virtual service,
also known as a stub.
Procedure
- In the Architecture School perspective, create a logical HTTP connection resource (Creating logical HTTP connections) and a physical web server resource for HTTP (Creating physical web server resources). If you are not creating the stub by using the Recording Studio perspective, also create an operation that uses the HTTP connection. See Options for creating test resources.
- Create virtual services (message-based stubs) to represent these resources. See Creating and modifying message-based stubs.
- To create stubs by using the Recording Studio, see Recording HTTP and HTTPS traffic and Stub creation by using the Recording Studio.
- To virtualize REST APIs that use path parameters (web URL schemas) manually, see Virtualizing a REST API without recording or synchronization.
- You can run stubs directly in Rational Integration Tester, or publish them to Rational Test Control Panel and run them there. See Publishing and running stubs.
- Use one of the following methods to configure the system
under test so that it sends messages to the stub. If you
recorded HTTP messages in the process of creating the stub, notice
that these choices are similar. Differences between recording and
virtualizing include the fact that packet capture does not allow virtualization,
and no direct connection option is available for recording.Figure 1 shows a network with no virtualization.Figure 1. No proxy, no virtualization
- The simplest method is to configure the system under test to send
its HTTP traffic through the Rational Integration Tester HTTP
proxy server (Figure 2-Figure 4).
When the stub is running, the messages are dynamically routed to the
stub. When the stub is not running, the messages are sent to the live
system, if available. Using the proxy also enables sift and pass-through
for HTTP stubs. For more information about configuring systems under
test to use the HTTP proxy, see HTTP/TCP proxy setup.Figure 2 shows the system under test addressing a request to the live system, but the HTTP client is configured to make all its connections to the HTTP proxy. No stub is running, so the request is forwarded to the live system.Figure 2. HTTP proxy, no virtualizationIn Figure 3, the stub is running, so the request is forwarded to the stub. Depending on the configuration of the stub or the configuration of the proxy, the proxy might take one the following steps:
- Forward all traffic for the requested host to the stub
- Filter the traffic based on other parts of the message, such as the path of the URL or the HTTP header values
Figure 3. HTTP proxy with virtualizationIf the system under test specifies a host other than the live system, the traffic does not match the rules that the stub has set up in the proxy. The traffic is, therefore, forwarded to the specified "other" system, as shown in Figure 4. You can see those rules on the Agents page in Rational Test Control Panel. For more information, see Viewing running agents.Figure 4. HTTP proxy forwards to other system - If the system under test cannot be configured to use an HTTP proxy,
then the next alternative is to configure the HTTP proxy as a reverse
proxy. Change the host name and port of the endpoint that is used
by the system under test, such that the system sends traffic to the
host and the port that is specified in the bind attribute of the forwarding
rule for the proxy. The reverse proxy has many of the benefits of
using the standard proxy, including dynamic message routing and sift
and pass-through. However, it does not work if the responses from
the stub contain absolute URLs that the system under test then dereferences.
In those circumstances, the standard proxy is required. See Configuring a HTTP(S) reverse proxy or TCP port forwarding.Figure 5 shows a reverse proxy.Figure 5. Reverse proxy
- Another alternative is to configure the system under test to connect
directly to the stub (see Figure 6). This process
requires assigning a fixed port number to the transport that the stub
uses. To do so, take one of the following actions:
- Go the Logical view of the Rational Integration Tester Architecture School perspective, right-click the HTTP connection resource, and click Open physical resource.
- Go the Physical view of the Architecture School perspective and double-click the web server resource.
- The server where Rational Integration Tester is running
- If running through Rational Test Control Panel, the server where the Rational Integration Tester Agent is running
For more information about socket overrides, see Creating physical web server resources.
Next, configure the system under test to use as its endpoint the host and port number of the server where the stub will run, rather than using the host and port for the live system. Be aware of the following limitations:- As with the reverse proxy, this method does not work if the responses from the stub contain absolute URLs.
- This method does not route messages dynamically. When the stub is not running, connections fail (see Figure 7).
- All traffic for the specified endpoint is routed to the stub. This method does not filter the traffic based on operations.
- If the stub is running, it can perform pass-through to the live system, with the following limitation. If the operation stub settings define that paths, method or headers are filtered, then the path, method, and headers in the request must match the filter. If they do not match, the stub is not invoked, an error response is returned to the client, and pass-through does not occur. If the stub is not running, then connections fail.
- With other methods, you can have multiple Agents and the stub can run on any Agent that is registered with Rational Test Control Panel for the correct environment. With this method, if running through Rational Test Control Panel, you must configure the system under test to use the exact machine on which the Agent runs the stub.
Figure 6. Direct connection to stubFigure 7. Direct connection to stub that is not running
- The simplest method is to configure the system under test to send
its HTTP traffic through the Rational Integration Tester HTTP
proxy server (Figure 2-Figure 4).
When the stub is running, the messages are dynamically routed to the
stub. When the stub is not running, the messages are sent to the live
system, if available. Using the proxy also enables sift and pass-through
for HTTP stubs. For more information about configuring systems under
test to use the HTTP proxy, see HTTP/TCP proxy setup.
Results
Related concepts:
Related reference:
Feedback