HTTP virtual service architecture

A tester uses a web browser to access the console. The console manages the virtual service. The system under test (application under test) connects directly to the virtual service on different ports.
screenshot

Add/Edit HTTP mappings

Usage

First, go to HTTP in the top navigation bar and then click Add/Edit.

Fill in the Request/Response fields and click Save to configure a mapping.

You can also select from the scenario dropdown which will populate the Request/Response fields for that scenario.

After saving the mapping, it will appear in the list of mappings.

Clicking the edit button will allow you to edit an existing mapping.

Configuring scenarios

In order to edit the list of elements on the scenarios dropdown on the Add/Edit page please open and edit file trafficparrot-x.y.z/scenarios.js and using the samples provided in the file add your new entries and remove the existing ones.

Valid values of request-url-matcher:
  1. urlEqualTo
  2. urlMatching
  3. urlPathEqualTo
  4. urlPathMatching
Valid values of request-url: any valid URL.
Valid values of request-method:
  1. ANY
  2. GET
  3. POST
  4. PUT
  5. HEAD
  6. OPTIONS
  7. DELETE
  8. CONNECT
  9. TRACE
Valid values of request-headers: new line separated list of header keys and values, for example 'Accept-Encoding: gzip, deflate, sdch, Upgrade-Insecure-Requests: 1'.
Valid values of request-body-matcher:
  1. any
  2. equalTo
  3. contains
  4. matches
  5. doesNotMatch
  6. equalToJson
  7. matchesJsonPath
  8. equalToXml
  9. matchesXPath
Valid values of request-body: any request body.
Valid values of response-status-code: any valid HTTP status code integer value.
Valid values of response-delay: any positive integer value.
Valid values of response-fault:
  1. CLOSE_CONNECTION_AFTER_HALF_RESPONSE
  2. DRIP_BYTE_EVERY_100ms
  3. DRIP_BYTE_EVERY_1s
  4. DRIP_BYTE_EVERY_10s
Valid values of response-headers: new line separated list of header keys and values, for example 'Content-Type:text/javascript; charset=UTF-8, Etag: "234762534726"'.
Valid values of response-body: any response body.
If you cannot see a video frame below please download it here
 

Recording HTTP

Usage

First, navigate to the recording page by clicking HTTP in the top navigation bar and then click Record.

In order to record traffic to a URL, simply enter the Recording URL and click Start recording.

All traffic received by the Traffic Parrot virtual service will be proxied to the host in the Recording URL and recorded as Mappings.

Clicking the edit button will allow you to edit the recorded mapping.

Filter by URL path

If the Recording URL includes a path, only traffic to this path will be recorded, however all traffic will still be proxied.

For example, if the Recording URL is set to http://example.com/aSampleResource then only traffic to paths staring with /aSampleResource will be recorded and all other traffic will be proxied to http://example.com.

Filter by Content-Type

In order to record only specified content types go to trafficparrot.properties file and change the value of the property:
trafficparrot.virtualservice.recordOnlyContentTypesContaining=TP_RECORD_ALL_CONTENT_TYPES
to include content types you would like to record, for example:
trafficparrot.virtualservice.recordOnlyContentTypesContaining=application/javascript,application/xml

Virtualizing identical URLs

When using Traffic Parrot to virtualize multiple HTTP services at the same time, you may encounter namespace issues if the services have name clashes in the context path.

For example, you may have two services that both have a GET /api/resources endpoint, and one might be hosted at http://service1/api/resources and the other at http://service2/api/resources.

The Traffic Parrot virtual service http://localhost:8081/api/resources would have two mappings associated with it.

There are a number of ways to deal with this situation, one of which is detailed below.

Using custom headers

One solution to having the same name resource URL /api/resources for different services is to make a change the system under tes t and start sending a custom header when communicating with those services. For example, a request to http://service1/api/resources could include a HTTP header Service-Name: service1, and a request to http://service2/api/resources could include a HTTP header Service-Name: service2. That way the HTTP requests are different and Traffic Parrot can map them to different responses.

If you would like to capture those headers during a recording, Traffic Parrot will record the headers that are defined in the property: trafficparrot.virtualservice.recordRequestHeadersForMatching.

For example, if you set the following value of the property, a Service-Name header will be recorded.

trafficparrot.virtualservice.recordRequestHeadersForMatching=Service-Name

Note that trafficparrot.virtualservice.recordRequestHeadersForMatching may contain multiple headers to record, as a comma separated list.

You can also add those headers manually by editing the mapping.

Configuration

See configuration in the user guide.

Typical environments

See typical environments in the user guide.

Proof of concept with on-premises installation at a large enterprise

See proof of concept in the user guide.

Custom extensions

Have a look at available extensions