Virtualizing HTTP

You can simulate an HTTP connection with a virtual service, also known as a stub.

Procedure

Perform the following steps in the Architecture School perspective:
1. Create a logical HTTP connection resource. See Creating logical HTTP connections.
2. Create a physical web server resource for the logical HTTP connection. See Creating physical web server resources.
3. Create an operation that uses the HTTP connection. See Options for creating test resources.
  
  Note: You do not have to create an operation if you are not creating the stub by using the Recording Studio perspective.
Create virtual services (message-based stubs) to represent these resources in either of the following methods:
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 HCL DevOps Test Integrations and APIs (Test Integrations and APIs), or publish them to HCL DevOps Test Virtualization Control Panel (Test Virtualization Control Panel) and run them there. See Publishing and running stubs.
Use any of the following methods to configure the system under test (SUT) so that the SUT sends messages to the stub.
Note: 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.
- No proxy, no virtualization
  No proxy, no virtualization shows a network with no virtualization.
  Figure 1. No proxy, no virtualization
- HTTP proxy, no virtualization
  The simplest method is to configure the system under test to send its HTTP traffic through the Test Integrations and APIs HTTP proxy server (HTTP proxy, no virtualization-HTTP proxy forwards to other system). 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.
  HTTP proxy, no virtualization 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
- HTTP proxy with virtualization
  In HTTP proxy with virtualization, 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
  When there are multiple instances of the stub for the transport or operation that have the same routing rules that are running, then the HTTP proxy routes the requests to the stub instances by using a round-robin algorithm. See HTTP proxy forwards to a stub when multiple stubs exist.
  Figure 4. HTTP proxy forwards to a stub when multiple stubs exist
- HTTP proxy forwards to other system
  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 HTTP proxy forwards to other system. You can see those rules on the Network Dashboard in Test Virtualization Control Panel. For more information, see Viewing running agents.
  Figure 5. HTTP proxy forwards to other system
- Reverse proxy
  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 hostname 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.
  Reverse proxy shows a reverse proxy.
  Figure 6. Reverse proxy
- Direct connection to stub
  Another alternative is to configure the system under test to connect directly to the stub (see Direct connection to stub). 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 Test Integrations and APIs 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 Test Integrations and APIs is running
  
  If running through Test Virtualization Control Panel, the server where the HCL DevOps Test Integrations and APIs Agent (Test Integrations and APIs 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 Direct connection to stub that is not running).
  
  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 Test Virtualization Control Panel for the correct environment. With this method, if running through Test Virtualization Control Panel, you must configure the system under test to use the exact machine on which the Agent runs the stub.
  Figure 7. Direct connection to stub
  
  Figure 8. 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.