- Organization Modeling in Orchestrator
- Automation Best Practices
- Optimizing Unattended Infrastructure Using Machine Templates
- Organizing Resources With Tags
- Orchestrator Read-only Replica
- Exporting grids in the background
- 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)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read Only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Elastic Robot Orchestration
- Automation Cloud™ Robots - VM
- Automation Cloud™ Robots - Serverless
- Configuring VPN for Cloud Robots
- Bulk Uploading Queue Items Using a CSV File
- Managing Queues in Orchestrator
- Managing Queues in Studio
- Review Requests
- Test Automation
Orchestrator Read-only Replica
Orchestrator maintains a read-only replica of its read-write operational database, with the main purpose of improving performance. Some read-only workloads are directed towards the read-only replica, so as to optimize write-replica consumption. This allows data to be read and loaded faster, which, in turn, ensures the performance of your system.
As a result of this implementation, a slight delay between the write and read actions might occur. This is to be expected, and has no impact on data becoming available.
Retrieving Queue Items
An example of this scenario is retrieving a queue item as soon as it was added: when performed from the interface, the new queue items might not be displayed instantly, as there is a slight asynchronicity between the operational database (where the item is written) and the replica (which is called for reading the item).
The same mechanism applies when retrieving data used to display your monitoring views.