- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read-only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read-only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- SmartCard Authentication
- Audit
- Resource Catalog Service
- Folders Context
- Automations
- Processes
- Jobs
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Other Configurations
- Integrations
- Classic Robots
- Host administration
- Organization administration
- Troubleshooting
Orchestrator User Guide
Managing Queues in Studio
The data added in the ItemInformation window in Studio is displayed in the Item Details window, under Specific Data, in Orchestrator. All items added to queues have the status set to New.
SpecificContent()
function. Write the name of the argument that was used to add information to the queue between quotation marks in brackets.
For example, the screenshot above displays the Value field of an Assign activity. It enables you to retrieve the value attributed to a queue item (displayed in the Item Details window, under Specific Data, in Orchestrator) and assign it to a string variable, so that you can process it later.
In the screenshot above:
transItem
- is a QueueItem variable used to store transaction items..SpecificContent
- is the function that retrieves information from transaction items.("transactionID")
- is the name of the argument that was added in the ItemInformation window to populate the queue items with data. The argument name is also displayed in the Item Details window, under Specific Data, in Orchestrator..ToString
- is a function used to convert the ID of the queue, which was initially an integer, to a string.
The remainder of the automation project can be set as explained above.
For example, the following workflow example sets each item status to Successful or Failed automatically, depending on how you design the Transaction Body sequence:
- Do nothing,Break, or Continue- results as Successful
- Throw Exception - results as Failed (Application error)
- Throw BusinessRuleException - results as Failed (business error)
- Set Transaction Status - results as the status you set
- Postpone Transaction Item - results as New
-
Should stop - if you stop the workflow from Orchestrator, the workflow exists the loop after the current transaction completes.
The workflow repeats for every queue item automatically, and sets the corresponding transaction status.
In case of Break or if the queue is empty, the workflow exists the loop.
Download the archived workflow and use it as a reference.