Workload Management properties configuration description
- Dernière mise à jour2022/11/09
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. |