Request-Response Processing Mode

This document covers topics which are specific to Request-Response processing mode. Please read the introduction to scenario authoring to understand .

Defining input and output from the Request - Response scenario

Unlike in the Streaming processing mode, there is no Schema Registry which would store data schemas - request and response schemas in our case. Still, the schema of the request and response ("input" and "output") need to be declared to Nussknacker; they are defined alongside the scenario (as the scenario property). The "language" used to define schemas is called JSON Schema. Nussknacker uses those schemas to understand how the request and response should look, assist you with hints and validate expressions you write.

Click kebab menu icon (three vertically aligned dots next to the scenario name) on the right panel and access the properties of the scenario to view or edit the input and output schemas of the scenario.

The output schema is a map from HTTP status code to that code's JSON Schema, with a required default entry used for any status code without its own schema:

{
  "default": { "type": "object", "properties": { "name": { "type": "string" } } },
  "404": { "type": "object", "properties": { "message": { "type": "string" } } }
}

A response sink is validated against - and its response is encoded with - the schema of its selected HTTP status code, falling back to default. The keys must be status codes supported by the HTTP status code sink parameter. The generated OpenAPI definition describes each status code with its own schema.

Integrating scenario into the automation workflows

Click kebabmenu icon and access the properties of the scenario to view the integration details of the scenario:

• the example curl based invocation
• OpenAPI interface definition
• Swagger UI.
• Basic Auth credentials

Note that on the first attempt to call Nussknacker scenario from Swagger UI you will be prompted to enter Basic Authentication credentials for your request - response scenarios. You can find them in the scenario Properties - these are not your Nussknacker cloud credentials.

Scenario response in scenarios with split and for-each nodes

It may happen that the scenario contains parallel branches, following split node. This ifs common in situations when testing multiple 'hypothesis' is important and these 'hypothesis' are independent of each other. Performing this 'hypotheses testing' sequentially yields much higher response times than when the hypothesis are processed in parallel.

If parallel branches end with response nodes and more than one response is generated (e.g there is no filtering after split), the only response which is returned is the one which is generated first chronologically. There is no way to determine which one will be generated first. If all responses are important to you, you need to take additional measures - use the collect node to merge the branches and collect data records coming from individual branches into a list.

If you use for-each node and need to collect all the results into a list of values, use collect node.

Finally, if no response is generated (e.g. after filtering), an error is returned (in the future this behavior may change).

Request - Response specific components

Source

The request source does not take any parameters - just drag it onto the scenario authoring canvas.

Sink

The response sink configuration form will contain an entry field for each "top level" item defined in the scenario output schema.

If, instead of filling separate autogenerated fields, you prefer to define the whole response as one expression containing value of the scenario response, you can do that by switching Raw editor to true.

When using the Raw editor, you can choose the validation mode. If you prefer to define the whole scenario response as one expression instead of filling individual fields, you can do that by setting Raw editor to true.

The HTTP status code advanced parameter selects the HTTP status code returned by the scenario when this sink produces the response (200 OK by default). Besides success codes, common client error codes and some server error codes can be selected, so a negative business branch (e.g. "customer not found") can end with a sink returning 404 Not Found together with a response body. All status codes declared by the scenario's response sinks are listed in the generated OpenAPI definition of the scenario. If several sinks producing a response are reached within a single request and they declare different status codes, the default 200 OK is used.

The response body of a sink is validated against the response schema of its status code (see output schema), so different status codes can return differently-shaped responses.

Kafka service

Request-Response scenarios can also write messages to Kafka with the kafka service. It becomes available when the liteRequestResponseKafka.jar component set is on the model classpath and the model configuration contains the kafka section (bootstrap servers, schema registry) - the same configuration as for the streaming Kafka components. The parameters (Topic, Schema version, Key, Value) work exactly like in the streaming Kafka sink.

The record is sent to Kafka as part of handling the HTTP request and the service returns the metadata of the written record (a record with the topic, partition, offset and timestamp fields), so the scenario can continue after the write - e.g. respond with the offset. When the write fails, the whole request fails. Delivery is at-least-once: a client retrying the HTTP request may produce duplicate records. During scenario testing in Designer no records are sent to Kafka - the service only collects the value that would be written and returns stubbed metadata (partition, offset and timestamp set to -1).

Collect component

See here for description of the Collect component.

Scenario properties

Click kebabmenu icon (three vertically aligned dots next to the scenario name) on the right panel and access the properties of the scenario.

Scenario properties explained

Property name	Description
Name	Scenario name
Input schema	See Defining input and output from the Request - Response scenario for explanation
Output schema	See Defining input and output from the Request - Response scenario for explanation
Slug	Change slug to modify the url of your scenario and of its interface definition
Integration	See here