Working with HTTP stubs without using proxies

When you run the HTTP stubs on Rational® Test Automation Server, the endpoint on which the stub is exposed externally uses a host name that includes a generated ID. If a client application is required to call the stub 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 stub.

Before you begin

You must have completed the following tasks:
  • Been assigned the Tester or Owner role to run the tests.
  • Created a project on Rational® Test Automation Server and added the repository that contains the HTTP stubs.
  • Completed the prerequisite tasks before you start HTTP stubs. See Prerequisites for running HTTP stubs.
  • Selected the branch of the Git repository to view test resources on the Execution page.

About this task

When you have installed Rational® Test Automation 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 have installed Rational® Test Automation 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 Routing 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.

Procedure

  1. Open the project that contains the stubs and click Execution.
  2. Select the branch of the repository that contains the stubs that you want to run.

    All test assets in the selected branch are displayed on the Execution page.

  3. Identify the stubs that you want to run from the assets listed.
    Tip: You can identify the stubs by the Stub icon Image of the icon for stubs. for the test asset under the Type column. Stubs are displayed with the extension .stb in their names under the Name column.
    You can also identify the stubs by completing any of the following steps:
    • Search for the stubs by entering any text contained in the test asset name in the Search field box.
    • Create a filter query by using the New filter option and complete the following steps:
      1. Enter the relevant parameters and apply the filter query.
      2. Save the filter query for retrieving it from the saved filters list.

        For example, you can create a rule, which has the Type attribute equal to API Stub, to display the stubs in the assets in the selected branch.

    • Retrieve a saved filter by using the Open filters icon Image of the icon. by completing the following steps:
      1. Select the saved filter.
      2. Apply the filter.
      Note: To open the filter query, you must have created and saved a filter query.
  4. Click the Execute icon Image of the icon. in the row of the identified stub.

    The Execute test asset dialog box is displayed.

  5. Select the version of the stub that you want to start.
  6. Select the environment that was used to bind the physical and logical resource in the API project, in the ENVIRONMENT tab.
    Important:
    • The results are not captured for the stubs started or run on Rational® Test Automation Server and the stubs are not displayed on the Results page.
    • The configuration that you set for the test run in the Execute test asset dialog box is preserved when you start stubs again. Those changes are not visible when another user logs in to Rational® Test Automation Server.

      For example, if you selected an environment, the same environment is selected when you start stubs again.

  7. Click Advanced, and then enter the following JVM argument in the JVM Arguments field: 
    -Dexecution.ingress.host.identifier=<custom_id>
    Notes:
    • The value of the <custom_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, A-X, 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 Rational® Test Automation 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
  8. Click Execute.

Results

You have started an HTTP stub. The stub exposes the host name that contains a custom ID that you specified.

What to do next

You can perform any of the following tasks from the Progress page:
  • You can stop the running stub at any point after you start the stub.
  • You can view the progress of the stub.
  • You can view the Execution log for the stub.

You can view the routing rules of the stubs. See Viewing routing rules.