Running HTTP virtual services without using proxies

When you run HTTP virtual services on HCL OneTest™ Server, the endpoint on which the virtual service is exposed externally uses a host name that includes a generated ID. If a client application is required to call the virtual service directly via its external host name and not via the HTTP proxy, then you might want to determine the host name to configure the client first before you start the virtual service.

Before you begin

You must have completed the following tasks:
  • Been assigned the Tester or Owner role in the project to run the virtual services.
  • Created a project on HCL OneTest™ Server and added the repository that contains the HTTP virtual services.
  • Completed the prerequisite tasks before you start HTTP virtual services. See Prerequisites for running HTTP virtual services.
  • Selected the branch of the Git repository to view test resources on the Execution page.

About this task

When you installed HCL OneTest™ Server on Ubuntu, the default HTTP stub endpoints are of the following form:
in-<unique_id>.<ingress_domain>
For example, with an ingress domain as 10.1.2.3.nip.io, a stub endpoint might be as follows:
in-cd3a755635574c6fa7e264911301821a.10.1.2.3.nip.io
When you installed HCL OneTest™ Server on OpenShift, the default HTTP stub endpoints are of the following form:
<ingress_domain_first_label>-<unique_id>.<remainder_of_ingress_domain>
For example, with an ingress domain as ots.mycluster-123456-0000.region.containers.appdomain.cloud, a stub endpoint might be as follows:
ots-cd3a755635574c6fa7e264911301821a.mycluster-123456-0000.region.containers.appdomain.cloud
The <unique_id> is generated when the stub is started. The full host name can be viewed in the Routing to field of the routing rule created for the stub on the Intercept Rules page. When traffic is routed to the stubs via the HTTP proxy, a client application is unaware of this host name. If the client application is required to call the stubs directly, it must be aware of the stub host name. To allow a host name to be known before you start the stub, you can replace the generated ID with a value that you specify.
Notes:
  • The value of the <unique_id> that you specify is used as the <unique_id> for the stub.
  • The <unique_id> must start and end with an alphanumeric character. The characters supported include a-z, 0-9, and a hyphen. No other characters can be used in the <unique_id>.
  • The <unique_id> must be unique to a stub that is running.
    Restriction: You must not assign the same <unique_id> to another stub that is running simultaneously. Doing so might result in an undefined behavior of the stub.
For example, on Ubuntu, if you specify the value of the <custom_id> for the stub as stub123-test and HCL OneTest™ Server has an ingress domain as 10.1.2.3.nip.io. Then the host name of the stub endpoint is as follows:
in-stub123-test.10.1.2.3.nip.io

Procedure

  1. Log in to HCL OneTest™ Server.
  2. Open the project that contains the virtual service resources in the test assets by clicking Projects > My Projects > project_name.
    The Overview page is displayed.
  3. Click Virtualization > Resources in the navigation pane.

    The Resources page is displayed.

  4. Select the branch of the repository that contains the virtual services that you want to run from the list in the Branch field.

    All virtual services in the selected branch are displayed on the Resources page.

  5. Identify the virtual service that you want to run.
  6. Click the Execute icon Image of the icon. in the row of the identified virtual service.

    The Execute virtual service dialog box is displayed.

  7. Select the version of the virtual service that is in the repository that you want to start by performing any of the following actions:
    • Expand the list in the Version field, find the version of the test resources, and then select the version.
      Use the following details about the version of the test resources that are displayed to identify the version that you want:
      • Commit message.
      • Tags labeled for the version committed.
      • The user who committed the version to the repository.
      • Relative time of the commit. For example, 2 hours ago or 3 days ago.

      The list displays the versions of the test resources committed by all users to the branch in the repository. The versions are arranged with the latest version committed followed by the versions committed previously.

    • Expand the list in the Version field, and then search for the version that you want to select by entering a partial or the complete commit message of that version.

      The version that matches the search criteria is displayed and it is selected for the test run.

  8. Select the environment that was used to bind the physical and logical resource in the API project, in the ENVIRONMENT tab.
    Important: The configuration that you set for the run in the Execute virtual service dialog box is preserved when you run the same virtual service again. The configurations that you set are not available to other members when they want to run the virtual service. For example, if you selected an environment, the same environment is selected when you run the virtual service again.
  9. Enter a label, if required.

    A label that you enter for the test run that helps you to identify the virtual service instance on the Instances page. The label that you entered is displayed for the virtual service under the Labels column on the Instances page. After you have created a label, any member of the project can use that label.

  10. Follow the instructions if you want to modify the configurations for the behavior of the virtual service:
    1. Click the BEHAVIOR tab, if it is not already open.
    2. Configure or change the settings for the following options:
      Note: The settings displayed are the settings that were configured for the virtual service when it was authored in HCL OneTest™ API.
      Option Description
      Performance
      The following settings are available for handling of requests by the virtual service:
      Option Description
      Optimize performance
      If enabled, attempts are made to reduce the amount of processing between the time the virtual service receives a request and the time it sends a response. Specific optimizations depend on the message contents, as in the following examples:
      • When the virtual service receives requests, all validations are disabled, and for all XML payloads, the store and filter actions are converted to use XPath expressions.
      • When the virtualization sends responses, any store actions set on a message are disabled, and any XML content is collapsed when the virtual service is compiled instead of being collapsed every time that a response is sent.
      The optimization is disabled as the default action for this setting and you can enable the performance optimization if you fully understand the implications of optimizing the performance.
      Threads

      The maximum number of threads used in processing requests received by the virtual service. The default number of threads is 10.
      Operation Specifies an operation referenced by the virtual service.
      Response time

      Specifies the response time behavior for responses sent by the virtual service for the selected operation.

      You can modify the value by selecting a value from the following options:
      Option Description

      No delay

      Select this option for a response with no delay.

      Minimum delay

      Select this option for a delay in the response by entering the required delay in milliseconds (ms).

      Uniform distribution

      Select this option for a uniformly distributed response time by specifying the minimum and maximum delay in milliseconds (ms).

      Gaussian distribution

      Select this option for a response time with Gaussian distribution by specifying the minimum and maximum delay in milliseconds (ms).
      Passthrough

      Specifies the pass through behavior for the selected operation when requests are not handled within the virtual service.

      You can modify the value by selecting a value from the following options:
      Discard This option stops the system under test from receiving the intercepted message. This option can disrupt the calling system. For example, the system might time out while it waits for a reply.
      Pass Through This option passes the intercepted message to the system under test, with an optional delay.
      Simulate Error This option returns an error to the calling system. The message is not passed to the system under test.
  11. Click Advanced to make the following advanced configurations:
    1. Enter the following configuration options as parameters and their values in the Additional Configuration Parameters fields.
      Parameter name Value
      execution.ingress.host.identifier <custom_id>
  12. Click Execute.

Results

You have started an HTTP virtual service that does not use a proxy. The virtual service exposes the host name that contains a custom ID that you specified.

What to do next

After you start a run of a virtual service, you can view the status of the virtual service in any of the following ways:
  • On the Resources page, the virtual services are displayed with the state as Running along with the number of instances that are running in the Active instances column.
  • On the Resources page, you must click the Show in instances page icon Image of the icon. in the row of the virtual service to view all the running instances of a particular virtual service on the Instances page.
  • Go to the Instances page by clicking Virtualization > Instances. You can view instances of all the virtual services that are running and are displayed with the state as Running under the State column. You can also view the requests that are received by the virtual service. The number of requests is displayed as number of hits when you hover the cursor over the text in the Activity column.