Running HTTP virtual services without using proxies
When you run HTTP virtual services on Rational® Test Automation 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
- Ensured that you are assigned a role as a Member or Project Creator in the team space. See Managing members and their roles in a team space.
- Ensured that you are assigned a role as a Project Owner or Tester in the project. See Managing access to server projects.
- Created a project in a team space on Rational® Test Automation 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
in-<unique_id>.<ingress_domain>For example, with an ingress domain as 10.1.2.3.nip.io, a virtual service endpoint might be as follows:
in-cd3a755635574c6fa7e264911301821a.10.1.2.3.nip.io
<ingress_domain_first_label>-<unique_id>.<remainder_of_ingress_domain>For example, with an ingress domain as rtas.mycluster-123456-0000.region.containers.appdomain.cloud, a virtual service endpoint might be as follows:
rtas-cd3a755635574c6fa7e264911301821a.mycluster-123456-0000.region.containers.appdomain.cloud
The <unique_id> is generated when the virtual service is started. The full host name can be viewed in the Routing to field of the routing rule created for the virtual service on the Intercept Rules page. When traffic is routed to the virtual service via the HTTP proxy, a client application is unaware of this host name. If the client application is required to call the virtual services directly, it must be aware of the host name of the virtual service.
- The value of the <custom_id> that you specify is used as the <unique_id> for the virtual service.
- The <custom_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 <custom_id>. The <custom_id> must not be longer than 32 characters.
in-stub123-test.10.1.2.3.nip.io
Procedure
-
Log in to Rational® Test Automation
Server.
The team space that contains your project is displayed.
-
Open the project that contains the virtual service resources in the
test assets by clicking
.
The Overview page is displayed.
-
Click
in the navigation pane.
The Resources page is displayed.
-
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.
- Identify the virtual service that you want to run.
-
Click the Open action menu icon
in the row of the identified virtual service, and then click Execute icon
.
The Execute virtual service dialog is displayed.
-
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.
- Expand the list in the Version field, find
the version of the test resources, and then select the
version.
-
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 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.
-
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.
-
Follow the instructions if you want to modify the configurations for the
behavior of the virtual service:
-
Click Advanced to make the
following advanced configurations:
-
Click Execute.
The run is initiated.
Results
What to do next
- 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
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 . 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.