Request Parameters

Request parameters can be configured in different ways and types. This page describes how single parameters are defined and composed to create permutations (e.g needed in extensive offline evaluations where wide range of parameters are permutated to use in requests to the target system).

There are two general types of parameters, which are STANDALONE and MAPPING. STANDALONE just stands for a single parameter (with one or more values), while MAPPING allows to specify relationships between different parameters. Every MAPPING specifies a parameter that provides key values and one or more mapped values. These mapped values can either map to the key values or to any mapped value that has been defined before the mapped value of interest (since mapped values are defined as sequence). To define what to map to, key-mapping-assignments are specified. Here the index 0 refers to the key values, while any other index j > 0 refers to the mapped value that can be found at the (j-1)th index of the mapped values sequence.

So what is this actually good for? Using these mappings, we can significantly reduce the number of combinations processed in a grid search. If we know that some parameters are specific for let’s say each query, it does not make sense to do the calculations over the whole parameter set for each query.

Every parameter (whether standalone or key or value in a mapping) is assigned to a value type that clarifies that the effect of the parameter is on the request composition. Note that all types with suffix _REPLACE are actually not values used as parameters themselves, but providing values by which defined placeholders in the actual value type (given by the prefix of parameter value type with suffix _REPLACE) are replaced. So lets say you define a json payload and you’d like to set a single parameter value in the payload to 100 different values, and generate results for all of these variants, you can define the json payload once (BODY type) and place some placeholder at the position where the value shall be set. Then you define a BODY_REPLACE with the name set to the placeholder value you defined in the parameter of type BODY. During generation of request permutations those placeholders will be substituted by the current value generated by the BODY_REPLACE parameter.

In the following we will give an overview of the configuration options for STANDALONE and MAPPING parameter types.

STANDALONE

The value definitions are analogue to the descriptions of FROM_ORDERED_VALUES_TYPE, PARAMETER_VALUES_TYPE and VALUES_FROM_NODE_STORAGE from the resource-directives section in this documentation.

MAPPING

Mappings always consist of a parameter that serves to provide the key values and one or more mapped values, which are mappings of key values to the actual parameter values. The actual mapping value types are described in detail in the section on resource directives, thus please refer to that part of the documentation. Those types are: JSON_VALUES_MAPPING_TYPE, JSON_VALUES_FILES_MAPPING_TYPE, JSON_SINGLE_MAPPINGS_TYPE, JSON_ARRAY_MAPPINGS_TYPE, FILE_PREFIX_TO_FILE_LINES_TYPE, CSV_MAPPING_TYPE, VALUES_FROM_NODE_STORAGE.

Note that the key-mapping assignment is given by a list of 2-element arrays where the first element specifies the index of the values used as keys and the second element gives the index of the mapped parameter. Note that the key values relate to index 0, while the mapped parameters start at index 1. The first element always has to be smaller than the second, yet depending on the needs each mapped parameter can either be mapped to the values of the key value parameter or any mapped parameter (that has a smaller index than the mapped value itself).

Example configuration: