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.

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 union node to merge branches and collect node to 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.

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