Workload Management properties configuration description

Use the list of Workload Management properties as a reference to view the configurations in the wlm.properties file.

Configuration description with default values

Configuration Default value Description Remarks

wlm.db.staging.size

 100 Determines the number of Work Items that can be moved from new to draft state for staging to the messaging queue cache in a single instance. The state is marked internally. These are staged in order.

For example, if you use 5 devices, the staging will start from 500 (100 x 5) Work Items.

Note that Work Item refers to a row or line in a CSV file being processed.

 This is an internal parameter and hence not to be changed.

wlm.db.staging.low.water.mark

70 Determines the minimum number of staged Work Items that can be pushed to the messaging queue cache. When the number of staged Work Items are less than this value, the next batch of Work Items are moved to staging.

For example, if you use 5 devices, the queue will include 350 (70 x 5) Work Items as the low water mark.

This is an internal parameter and hence not to be changed.

wlm.staging.upper.water.mark

 50 Determines the maximum number of staged Work Items that can be pushed to the Apache Ignite queue cache. For example, if you use 5 devices, 250 (50 x 5) work items can be queued. This is an internal parameter and hence not to be changed.

wlm.staging.low.water.mark

 35 Determines the number of Work Items that can be pushed from staging to queue to the Apache Ignite queue cache when the Work Items are less than the number given in this property.

Note that the queue processing is continuous and this count keeps decreasing. Use this to maintain the level of Work Items that can be pushed from staging to queuing stage.

For example, if you use 5 devices the Work Items are to be queued when the number is below 175 (35 x 5).

 This is an internal parameter and hence not to be changed.

wlm.ignite.low.water.mark

 5 Not Applicable from Version 11.3.3. For users on versions less than 11.3.3 - This is an internal parameter and hence not to be changed.

wlm.file.upload.encrypt.lines.count

 100 Determines the number of Work Items that can be encrypted. This is an internal parameter and hence not to be changed.

wlm.file.upload.batch.size

 100 Not Applicable from Version 11.3.3 For users on versions less than 11.3.3 - This is an internal parameter and hence not to be changed.

workOrder.concurrent.execution.count

 5 Determines the maximum number of work orders that can be processed at a time.

For example, you can concurrently process a maximum of 5 work orders when the property value is set to 5.

Note that a work order is a background job that ingests set of Work Items for processing. For example, a work order can contain 100 Work Items.

 This is an internal parameter and hence not to be changed.
workOrder.max.execute.lines 1000 Determines the maximum number of Work Items in a work order that can be processed at a time. This is useful when data with large volumes are uploaded. This is an internal parameter and hence not to be changed.
workOrder.execution.job.interval.seconds 30 Determines the default time interval between the processing of pending work orders. This is an internal parameter and hence not to be changed.

allowed.workItem.processing.deviation

 2 Not Applicable Not applicable
wlm.minimum.seconds.between.deploy 10 Determines the minimum time between two concurrent Work Item deployments.

This is not applicable from Version 11.3.3

For users on versions less than 11.3.3 - If you upload two Work Items in a Queue and there are two Devices then the first item will be processed in 30 seconds and the second one will be processed 10 seconds after that.
wlm.priority.pool.redeploy.minutes 30 Determines the time interval specified in priority mode after which the Work Items are to be redeployed to all Bot Runner devices. This parameter is deprecated from Version 11.3.3

For users on versions less than 11.3.3 - If a Device is stuck for any Work Item, then workload management will wait for 30 minutes and then redeploy the next Work Item to all other Devices.
wlm.automation.trigger.interval.millis 900000 Determines the time interval (in milliseconds) for processing staged or queued Work Items. For example, when you create a new automation at 10:00, it will process the work item for queuing at 10:10. This parameter is used in the backend to refresh the Devices. If the 1st workload management automation fails, it takes 15 minutes to redeploy. You can change this to a lower value - for example, 60000, which is 1 minute. After setting this value, restart the Automation Anywhere Control Room Service.
wlm.workitems.columns.subcrub False Determines whether to truncate the characters of a data in a column when processing the Work Items. It is recommended that you keep this turned off as it runs on each field and affects data ingestion. This is an internal parameter and hence not to be changed.