The Robots Auto Scaling solution is implemented with the help of the official UiPath IT Automation activities - they empower us to automate use cases from all areas of our IT Ecosystem, in both on-premises datacenters and public clouds.
As part of the auto-scaling process, the robot machines are started / stopped automatically as a function of:
1. Defined Scaling Strategy
2. Client’s Current State:
Jobs (pending, running, completed, stopped, faulted)
Robots (available, disconnected, busy)
1. Client Tenants – Orchestrator Webhooks
The managed clients need to have configured in the Webhooks area the url associated with the Webhook Receiver’s endpoint for the events job. created / completed / faulted / stopped. These events act as triggers for the autoscaling process and they are processed in bulk, to minimize concurrency risk for servers start / stop operations.
The SQL Server database with the client Orchestrator acces data + AutoScaling Strategy robot counters can be deployed anywhere and it only contains the Tenants table (sql create script provided). The connection to the DB is done with the UiPath.Database activities – the connection string is retrieved from the TenantsDbConnectionString text Orchestrator asset (from the Management Orchestrator).
3. Webhook Receiver. Webservice / Function
This component consists of minimal code that is designed to receive events, parse their data and forward them to the Management Orchestrator as new queue items.
4. Management Orchestrator
Most of the RAS solution items are to be configured in an Orchestrator tenant, in a dedicated folder: Processes (ProcessQueueItems, ..), Assets (for DB connection, infrastructure access), Queue + Job Trigger (on new item added). The RAS solution can be deployed in the same Orchestrator tenant as one of the managed clients, as long as it is configured in a folder that is not associeted with a client from the DB.
Process Flow. Event Driven
One deployment of the RAS solution can perform autoscaling for multiple clients at the same time – this is possible by leveraging the Orchestrator’s capability to emit job events via webhooks. The job events that are incoming from the managed clients are received by a small web-service / function and forwarded to a Queue in the Management Orchestrator for processing.
As part of the processing step, a ProcessClient job connects to the Database and tries to identity the client of an event in the Tenants table - if found, the information from the selected row has the client Orchestrator API acces data + the scaling strategy for the client’s folder or folder+environment.
The processing job connects to the client’s Orchestrator and retrieves its current state (jobs running/pending, robots available/disconnected/busy). With all the data available, the job will evaluate the state + scaling strategy robot counters, selects the impacted robot machines and proceeds to apply the neccesary actions (start / stop server).
Process Flow. Scheduled (pooling)
This mode doesn’t require any of the job events related RAS components (webhooks, events receiver service, queue): the autoscaling process is triggered periodically (scheduled start at each 5+ min), according to a specified scheduled processing job (1 for each client DB entry).
The current version works with classic folders and can allocate/deallocate robot machines from Azure, AWS, VMware, Citrix
Next releases will work with modern folders too and will add support for Hyper-V and Google Cloud