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 virtualization
  In 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 virtualization
  If 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.
  On the Server page, Server Socket Overrides section, enter a number for the Port field that does not conflict with anything on the host where the stub will run. That host is one of the following servers:
  - 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 stub
  
  Figure 7. Direct connection to stub that is not running

Results

The dependency for the system under test is now virtualized. Traffic that matches the operations that are specified in the stub (or all traffic, in the case of direct connection to the stub) now receives virtualized responses instead of connecting to the live system.

Feedback