Additional configuration parameters for virtual services

You can find information about the additional configuration parameters that you can set when you want to run virtual services on HCL OneTest™ Server.

When you use the server UI to start the virtual service, some of the parameters are handled by fields in the Execute virtual service dialog box.

You can enter the other parameters as a name-value pair in the Additional configuration parameters field that is displayed in the Advanced settings panel of the Execute virtual service dialog box.

The following additional configuration parameters are supported when you configure a run for a virtual service.


Requirement	Configuration parameter name	Supported values	An example value	Result of using the example value
To specify a unique identifier for use in the generated host name	`stub.ingress.host.identifier`	Any <custom_id> that you specify.	`mystub`	See Running HTTP virtual services without using proxies, to know how the identifier you specified is used.
To specify whether a virtual service instance should be run in a dedicated container.	`stub.dedicated.container`	`true` `false` Note: The default value is `false`.	`true`	A dedicated container is used to run a single virtual service instance.
To specify whether performance optimization is enabled for the virtual service instance. The value set overrides the setting from the stub definition. This option can be set in the Behavior tab from the UI.	`stub.performance.optimize`	`true` `false` Note: The default value is `false`.	`true`	The performance optimization is enabled for the virtual service.
To specify the number of threads to be used for processing requests for the virtual service instance. The value set overrides the setting from the stub definition. This option can be set in the Behavior tab from the UI.	`stub.worker.thread.count`	Any number that you specify as number of threads to use.	`15`	15 threads are used for processing requests for the virtual service instance.
To specify the stub logging level for the virtual service instance. The value set overrides the setting from the stub definition. This option can be set in the Advanced settings from the UI.	`stub.logging.level`	`none` `normal` `debug`	`debug`	The virtual service writes informational and debugging messages to the container log.
To specify the pass-through behaviour type of the virtual service instance. The value set overrides the setting from the stub definition. This option can be set in the Behavior tab from the UI.	`stub.pass.through.behavior`	Valid values depend on the stub operation transport type but can be as follows: `simulate_error` `discard` `pass_through`	`simulate_error`	This option returns an error to the calling system. The message is not passed to the system under test.
To specify the delay in passing through from the virtual service instance. The value set overrides the setting from the stub definition.	`stub.pass.through.delay.period`	Any number of seconds in milliseconds.	`10000`	A delay of 10 seconds in passing through from the virtual service instance.
To specify the status code to use in the virtual service instance response when simulating an error. The value set overrides the setting from the stub definition. Note: Applies to HTTP stubs. This option can be set in the Behavior tab from the UI.	`stub.pass.through.status.code`	You must specify a valid HTTP status code as the value. For example, `503`.	`500`	The HTTP error code of `500` is sent in the response if the virtual service simulates an error when passing through.
To specify the reason phrase to use in the virtual service instance response when simulating an error. The value set overrides the setting from the stub definition. Note: Applies to HTTP stubs. This option can be set in the Behavior tab from the UI.	`stub.pass.through.reason.phrase`	You must specify the text of the status message as the value.	`my custom error msg`	The text that you specify is set as the HTTP reason phrase in the response if the virtual service simulates an error when passing through.
To specify the type of response-time behavior that is required for the virtual service instance. The value set overrides the setting from the stub definition. This option can be set in the Behavior tab from the UI.	`stub.response.time.type`	`no_delay` `minimum_delay` `gaussian` `uniform` `performance_profile` Note: `performance_profile` is only valid if the stub operation in the stub definition is defined to use a performance profile.	`no_delay`	The virtual service sends a response without any delay.
To specify the minimum time for the response time behaviour required for the virtual service instance. The value set overrides the setting from the stub definition. This option can be set in the Behavior tab from the UI.	`stub.response.time.minimum`	Any number of seconds in milliseconds.	`5000`	The virtual service sends a response after a minimum delay of 5 seconds.
To specify the maximum time for the response time behaviour required for the virtual service instance. The value set overrides the setting from the stub definition. This option can be set in the Behavior tab from the UI.	`stub.response.time.maximum`	Any number of seconds in milliseconds.	`20000`	The virtual service must send a response after a maximum delay of 20 seconds.

Virtual services where the stub definition refers to multiple operations

When a stub definition has two or more events that refer to different operations and each operation has a different behavior, you must specify the <operation_id> suffixed to the configuration parameter name in the Additional configuration parameters field.

Note: The <operation_id> is the internal ID of the operation that is found in the Documentation tab when you open the operation in HCL OneTest™ API.

When the stub definition refers to multiple operations and you want to start a run of a virtual service, you must append the <operation_id> to the <parameter_name> in the Additional configuration parameters field.

The configuration parameter names that you must use for the virtual service, which is associated with a particular operation are as follows:

stub.pass.through.behavior.<operation_id>
stub.pass.through.delay.period.<operation_id>
stub.pass.through.status.code.<operation_id>
stub.pass.through.reason.phrase.<operation_id>
stub.response.time.type.<operation_id>
stub.response.time.<operation_id>
stub.response.time.maximum.<operation_id>

For example, if the <operation_id> is 7281b750:162483a09f1:-7e68, the parameter name for the stub.response.time.type option that you must specify is stub.response.time.type.7281b750:162483a09f1:-7e68.