Requests and composition

These boxes run a request / response call and hand control back. For connections that stay open, see Connections and streams.

Each one is bound to a project request: you designate it when you create the box.

HTTP Request

Runs an HTTP request, a GraphQL one, a unary gRPC one or a WebSocket one in a single shot.

Inputs	env (the environment to run in), override (overrides, an object)
Outputs	response — the complete response
Configuration	requestId, label

The response output carries the response object: status, headers, body, time. Put a selector on the link to extract directly what you care about — status, body.data.id.

SOAP Request

Runs a SOAP request.

Inputs	env
Outputs	response
Configuration	requestId, label

A <soap:Fault> response shows up on the response object: test it with an Assert rather than relying on the HTTP status alone.

Redis command

Runs a single Redis command, on a fresh connection.

Inputs	env
Outputs	response

Kafka produce

Publishes a Kafka record.

Inputs	env
Outputs	response — the record’s metadata: topic, partition, offset

Run scenario

Calls another scenario in the project — this is the composition mechanism.

Inputs	one param:<name> port per free parameter of the sub-scenario
Outputs	one output:<name> port per sub-scenario output, plus result
Configuration	scenarioId, label

The ports are derived live from the sub-scenario: add a parameter there and the port appears on the caller.

That is what lets you factor things out: one “get a token” scenario, called by the other five.

Run the scenario "Log in"
  ├─ param:user   ◄── Input
  └─ output:token ──► Set variable "token"

Overriding the request

Four layers, applied in this order:

1. the request as saved in the project;
2. the quick setting designated on the action;
3. the overrides entered on the action;
4. the value received on the override port.

The same call therefore replays with three data sets, without duplicating the request.