Worker[].Type*

Type of worker instance to be executed:

The All type can be used if three identical instances are to be defined that only differ in type. The program implicitly creates three instances for each worker of the pseudo type All, each of which has the type Input, Process and Output. All other properties of the instances are identical. The .Name property is an exception. To make this property distinguishable for the three types, although the property is only defined once, the variable %Type% can be included in the value. The variable is replaced by the actual type name at runtime.

The value None is used to (temporarily) deactivate a worker. This means that you will not have to delete the entire object from the configuration in order to deactivate the worker.

Worker[].Tenant

Name of the tenant for which the worker instance is executed

Default value: Default

Worker[].Name

Name of the worker instance (optional)

This name is used for display in logging and the Status Monitor. The %Type% variable enables dynamic insertion of the actual worker type. This is relevant when using the worker type All (see Worker[].Type*).

Worker[].Timer

Individual execution times for the worker instance

Syntax: see Miscellaneous

Alternatively, the value specified under Timer.Worker will be used.

Within a run, a worker instance determines one single time which batches or documents are pending for processing for the worker instance at this point in time. The worker instance processes these batches or documents one after another in the order found. All objects that have been added since the determination are not included until the next run.

Worker[].ConfigSource[]*

Reference to the data sources with the specific configurations of the scenarios that the worker instance processes

Syntax: URI syntax (see Data Format and Data Sources)

Assign scenarios to worker instances based on the use case at hand. Within one program instance of xSuite Interface, you can have multiple worker instances of the same type and for the same tenant working on the same scenario in parallel to achieve an increase in throughput. However, this might be counterproductive if the instances running in parallel block each other due to a scarcity of resources (e.g., when accessing the administrative database at the same time). An alternative is to have multiple program instances, even on different computers, working on the same scenarios in parallel as long as they use the same database and storage resources.

A general restriction on parallel executability applies to the input worker. Multiple instances that process the same scenario for the same tenant are not allowed for the input worker. This is meant to avoid possible conflicts when accessing the same input data simultaneously.

As a counterpart to parallel execution, a worker instance can also process data from multiple scenarios. Within a timer run, processing then takes place consecutively in the order in which the scenarios are assigned to the worker.