Route to Live

Overview

Route to Live controls the runtime behavior of a virtual service by determining whether the response comes from the virtualized operation or a live backend system. When the service receives a request, it checks for a matching virtual operation. If it finds a match, it returns the configured response. If no match exists, the service routes the request to the live backend. If the live system does not respond or times out, the virtual service returns a default response, if one is configured. This routing option supports hybrid testing scenarios and ensures uninterrupted workflows when full virtualization isn't in place.

Configure Route to Live

Note

If you are using Route to Live with a proxy that requires a username and password for authentication, review the following requirements:

From Java 11 onwards, some weaker authentication methods (such as Basic or Digest) are disabled by default.

Route to Live in ReadyAPI uses the HttpClient from java.net for asynchronous operations (via CompletableFuture). To support these authentication schemes, add the following VM option:

-Djdk.http.auth.tunneling.disabledSchemes=""

This allows the proxy credentials to work correctly with Route to Live.

For information on where to add this setting, see Modifying JVM Settings.

If you are deploying the virtual service to VirtServer, also add this VM option to VirtServer’s configuration file. Refere to more details on the JVM Settings page.

  1. Select Route to Live

    RAPI-screenshot-select-route-to-live.png

    Route to Live: The virtual service routes incoming requests for which it has no virtual operations. Virtual operations are processed in accordance with the Routing and Dispatch settings, and when no match is found, the request is routed to the live service.

    For Conditional Match

    Request is received by ReadyAPI or VirtServer.

    • Signature–Match + Data Values–Match

      Response: The specific (exact match) response is returned from the virtual service.

    • Signature–Match + Data Values–No Match

      Response: A meta (signature-level default) response is returned from the virtual service.

    • Signature–No Match (Not Found)

      Request Routed: The request is routed to the live system to fetch the live response.

    • No Response

      If no signature match, no data match, or no response is received from the live system, a generated response is returned.

  2. Routing Configuration

    Route to Live: Manage Connection Settings

    To configure the Route to Live, click Manage Connection Settings. The Connection Settings dialog appears, allowing you to adjust the necessary settings.

    Connection Settings for Route to Live

    RAPI-screenshot-connection-settings.png

    Once the Connection Settings dialog appears, you can adjust the following settings for the Route to Live feature:

    Table 18. Connection Settings

    Setting

    Description

    Example Value

    Name

    A unique identifier for the connection settings.

    MyLiveServerConnection

    Target Server

    The hostname or IP address of the live server.

    live.example.com

    Target Port

    The port of the live server.

    8080

    Keystore Location

    The file path to the keystore containing the certificates.

    /path/to/keystore.jks

    Keystore Password

    The password used to access the keystore.

    password123

    Connection Timeout (ms)

    Maximum time to wait for a connection to be established.

    10000

    Max Retries

    Maximum number of connection retry attempts on failure.

    3

    Socket Timeout (ms)

    Maximum time to wait for data on the socket.

    5000



    Configurable Timeout Behaviors for Route to Live

    Users can configure the timeout settings to control how the virtual service handles live routing:

    • Gateway Socket Timeout

      Sets the overall timeout for attempting to retrieve a response from the live system (for example, 10,000 ms).

    • Per Attempt Timeout

      Specifies the timeout per individual attempt to retrieve a response (for example, 500 ms).

    • Maximum Number of Retries

      Determines the maximum number of retry attempts to fetch a response (for example, 10).

  3. Default Response Configuration

    Route to Live: Manage Responses

    You can configure a default response to be returned when the live system does not respond. This response is used when no match is found or when the live system fails to provide a response within the configured timeout limits.

    1. Click the Manage Responses button under the Default Response dropdown.

    2. In the Manage Route to Live Responses dialog, click Add New Response, then OK.

    3. In the Add New REST Response dialog, enter the response name, then OK.

    4. In the Route to Live Response Editor, select the HTTP status code, content/media type, and other fields as needed. Confirm with OK.

    Logic

    If the maximum number of retries and per-attempt timeout fail to retrieve a response, or if the gateway timeout is reached with no response from the live backend, the virtual service returns a generated response based on the following:

    • No signature match.

    • No data match.

    • No response from the live system.

    Limitations

    • REST-Only Support: The Route to Live setting works for REST virtual services.

    • No Recording Mode: The Route to Live setting does not support a recording mode.

See Also

In this section:
© 2025
Publication date: