Auto-scaling strategies for robotic process automation

Abstract

A system and method are provided for allocating computing environments to complete a robotic process automation (RPA) workload. A request to complete the RPA workload is received. A number of computing environments to allocate to complete the RPA workload is calculated based on a selected one of a plurality of RPA auto-scaling strategies. The calculated number of computing environments is allocated to allocate one or more RPA robots to complete the RPA workload. The computing environments may be virtual machines.

Description

[Technical Field]

[0001] The present invention relates generally to robotic process automation (RPA), and more particularly to an RPA autoscaling strategy for allocating virtual machines or other computing environments to run one or more RPA robots. [Background technology]

[0002] In robotic process automation (RPA), jobs are completed by one or more RPA robots that automatically execute RPA workflows. Often, such jobs need to be completed with speed or cost as the priority. Traditionally, machines for implementing RPA robots are manually assigned by a user. However, manual machine assignment is tedious and requires the user to know various contextual information related to the RPA implementation to prioritize speed or cost. In other traditional approaches, machines for implementing RPA robots are assigned based on computing resources, such as central processing unit (CPU) usage and memory usage. However, such traditional approaches do not consider the robot's workload, such as pending jobs. Summary of the Invention

[0003] Embodiments of the present invention provide an RPA (Robotic Process Automation) auto-scaling strategy for allocating virtual machines or other computing environments to balance speed and cost to complete a job.

[0004] According to one or more embodiments, a system and method are provided for allocating computing environments to complete an RPA workload. A request to complete the RPA workload is received. A number of computing environments to allocate to complete the RPA workload is calculated based on a selected one of a plurality of RPA auto-scaling strategies. The calculated number of computing environments is allocated for allocating one or more RPA robots to complete the RPA workload.

[0005] In one embodiment, the computing environment includes a virtual machine.

[0006] In one embodiment, the multiple RPA autoscaling strategies include a speed over cost strategy, a balanced strategy, and a cost over speed strategy. The number of computing environments to allocate is calculated based on the number of computing environments that will complete the RPA workload, the maximum number of computing environments that can be created in the pool, and the number of RPA robots allowed by the license.

[0007] In one embodiment, the plurality of RPA autoscaling strategies includes a custom strategy in which a user configures one or more control variables, while in another embodiment, the plurality of RPA autoscaling strategies includes a dynamic strategy in which one or more control variables are automatically adjusted based on workload type.

[0008] In one embodiment, a selection of the selected RPA autoscaling strategy is received from a user, while in other embodiments, the selected RPA autoscaling strategy is selected automatically according to a schedule and / or based on the source of the RPA workload.

[0009] These and other advantages of the present invention will become apparent to those skilled in the art upon review of the following detailed description and accompanying drawings. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is an architectural diagram illustrating an RPA (Robotic Process Automation) system according to one embodiment of the present invention.

[0011] [Figure 2] FIG. 1 is an architectural diagram illustrating an example of a deployed RPA system according to an embodiment of the present invention.

[0012] [Figure 3] FIG. 1 is an architectural diagram illustrating a simplified example deployment of an RPA system according to an embodiment of the present invention.

[0013] [Figure 4] FIG. 1 is an architectural diagram illustrating a cloud RPA system for implementing cloud-based management of robotic process automation robots, according to an embodiment of the present invention.

[0014] [Figure 5] 1 illustrates a method for allocating computing environments for running RPA robots, according to one embodiment of the present invention.

[0015] [Figure 6] FIG. 1 is a block diagram of a computing system that may be used to implement embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0016] Robotic Process Automation (RPA) is used to automate workflows and processes. FIG. 1 is an architectural diagram of an RPA system 100 according to one or more embodiments. As shown in FIG. 1, the RPA system 100 includes a designer 102 to enable developers to design automated processes. More specifically, the designer 102 facilitates the development and deployment of RPA processes and robots to perform activities in the processes. The designer 102 can provide solutions for application integration and business process automation for third-party applications, management information technology (IT) tasks, and contact center operations. One commercially available example of an embodiment of the designer 102 is UiPath Studio™.

[0017] When designing rule-based process automation, developers control the order of execution and relationships between a custom set of steps developed in the process, defined herein as "activities." Each activity can include actions such as clicking a button, reading a file, writing to a log panel, etc. In some embodiments, processes may be nested or embedded.

[0018] Some types of processes may include, but are not limited to, sequences, flowcharts, finite state machines (FSMs), and / or global exception handlers. Sequences may be particularly well-suited for linear processes, allowing flow from one activity to another without cluttering the process. Flowcharts may be particularly well-suited for more complex business logic, allowing for the integration of decisions and the connection of activities in more diverse ways through multiple branching logical operators. FSMs may be particularly well-suited for large workflows. FSMs may use a finite number of states in their execution, triggered by conditions (i.e., transitions) or activities. Global exception handlers may be particularly well-suited for determining workflow behavior when an execution error is encountered and for debugging the process.

[0019] Once a process is developed in Designer 102, the execution of the business process is orchestrated by Conductor 104, which orchestrates one or more Robots 106 that execute the process developed in Designer 102. One commercially available example of an embodiment of Conductor 104 is UiPath Orchestrator™. Conductor 220 facilitates the creation, monitoring, and deployment management of resources in an RPA environment. In one example, Conductor 104 is a web application. Conductor 104 can also serve as an integration point with third-party solutions and applications.

[0020] The conductor 104 can manage a fleet of RPA robots 106 by connecting and executing the robots 106 from a centralized point. The conductor 104 can have a variety of functions, including, but not limited to, provisioning, deployment, configuration, queuing, monitoring, logging, and / or providing interconnectivity. Provisioning can include creating and maintaining connections between the robots 106 and the conductor 104 (e.g., web applications). Deployment can include ensuring the correct delivery of package versions to the robots 106 assigned for execution. Configuration can include maintaining and delivering robot environment and process configurations. Queuing can include managing queues and queue items. Monitoring can include tracking robot identification data and maintaining user permissions. Logging can include storing and indexing logs in a database (e.g., an SQL database) and / or other storage mechanism (e.g., ElasticSearch®, which provides the ability to store and quickly query large data sets). The conductor 104 can provide interconnectivity by acting as a centralized point of communication for third-party solutions and / or applications.

[0021] The robot 106 is an execution agent that executes the process built in the designer 102. One commercially available example of some embodiments of the robot 106 is UiPath Robots™. Types of robots 106 may include, but are not limited to, attended robots 108 and unattended robots 110. Attended robots 108 are triggered by a user or user events and operate alongside a human user on the same computing system. Attended robots 108 can assist human users in accomplishing various tasks and may be triggered directly by the human user and / or by user events. For attended robots, the conductor 104 may provide a centralized process deployment and logging medium. In certain embodiments, attended robots 108 can only be launched from a “robot tray” or from a command prompt in a web application. Unattended robots 110 operate in an unattended mode in a virtual environment and may be used to automate many processes, such as for high-volume back-end processes. Unattended robots 110 can be involved in providing support for remote execution, monitoring, scheduling, and work queues. Both attended and unattended robots can automate a variety of systems and applications, including, but not limited to, mainframes, web applications, VMs, enterprise applications (e.g., those manufactured by SAP®, Salesforce®, Oracle®, etc.), and computing system applications (e.g., desktop and laptop applications, mobile device applications, wearable computer applications, etc.).

[0022] In some embodiments, a robot 106 installs the Microsoft Windows Service Control Manager (SCM) management service by default. As a result, such a robot 106 can open an interactive Windows session under the local system account and have the rights of a Windows service. In some embodiments, a robot 106 can be installed in user mode, with the same rights as a user, and a given robot 106 has been installed under user mode.

[0023] In some embodiments, the robot 106 is divided into several components, each dedicated to a specific task. In some embodiments, the robot components include, but are not limited to, an SCM-managed robot service, a user-mode robot service, an executor, an agent, and a command line. The SCM-managed robot service manages and monitors the Windows session and acts as a proxy between the conductor 104 and the execution host (i.e., the computing system on which the robot 106 executes). These services are trusted with and manage credentials for the robot 106. The console application is launched by the SCM under local system. In some embodiments, the user-mode robot service manages and monitors the Windows session and acts as a proxy between the conductor 104 and the execution host. The user-mode robot service can be trusted with and manage credentials for the robot 106. If the SCM-managed robot service is not installed, the Windows application can be launched automatically. An Executor can run a given job under a Windows session (e.g., an Executor can execute a workflow) and can be aware of per-monitor dots per inch (DPI) settings. An Agent can be a Windows Presentation Foundation (WPF) application that displays available jobs in a system tray window. An Agent can be a client of a Service. An Agent can request to start or stop jobs and change settings. A Command Line is a console application that is a client of a Service and can request to start jobs and wait for job output.The division of robot components may aid developers, support users, and enable a computing system to more easily implement, identify, and track what each robot component is performing. For example, special behaviors can be configured for each robot component, such as setting different firewall rules for executors and services. As a further example, executors can be aware of per-monitor DPI settings in some embodiments, so that workflows can be executed at any DPI regardless of the configuration of the computing system on which they were created.

[0024] 2 illustrates an RPA system 200 according to one or more embodiments. RPA system 200 may be or may be part of RPA system 100 of FIG. 1. It should be noted that the "client side," "server side," or both may include any desired number of computing systems without departing from the scope of the present invention.

[0025] As shown on the client side in this embodiment, computing system 202 includes one or more executors 204, agents 206, and designers 208. In other embodiments, designers 208 may not be running on the same computing system 202. Executors 204 (which may be robotic components as described above) execute processes, and in some embodiments, multiple business processes may be running simultaneously. In this example, agent 206 (e.g., a Windows service) is a single point of contact for managing executors 204.

[0026] In some embodiments, a robot represents an association between a machine name and a user name. A robot can manage multiple executors simultaneously. In computing systems that support multiple interactive sessions running simultaneously (e.g., Windows Server 2012), multiple robots may run simultaneously in separate Windows sessions (e.g., in a high density (HD) environment), each using a unique user name.

[0027] Agent 206 is also responsible for transmitting the robot's status (e.g., periodically sending "heartbeat" messages indicating that the robot is still functioning) and downloading any necessary versions of packages to be fulfilled. Communication between agent 206 and conductor 212 is initiated by agent 206 in some embodiments. In an example notification scenario, agent 206 may open a WebSocket channel that is later used by conductor 212 to send commands (e.g., start, stop, etc.) to the robot.

[0028] As shown on the server side in this embodiment, the presentation layer includes a web application 214, an Open Data Protocol (OData) Representational State Transfer (REST) ​​Application Programming Interface (API) endpoint 216, and a notification monitoring API 218. The server-side service layer includes an API implementation / business logic 220. The server-side persistence layer includes a database server 222 and an indexer server 224. The conductor 212 includes the web application 214, the OData REST API endpoint 216, the notification monitoring API 218, and the API implementation / business logic 220.

[0029] In various embodiments, most actions performed by a user in the conductor 212 interface (e.g., via browser 210) are performed by calling various APIs. Such actions may include, but are not limited to, starting a job on a robot, adding / removing data from a queue, scheduling a job to run unattended, etc. Web application 214 is the visual layer of the server platform. In this embodiment, web application 214 uses Hypertext Markup Language (HTML) and JavaScript® (JS). However, any desired markup language, scripting language, or any other format may be used without departing from the scope of the present invention. A user interacts with web pages from web application 214 via browser 210 in this embodiment to perform various actions to control conductor 212. For example, a user can create robot groups, assign packages to robots, analyze logs per robot and / or per process, start and stop robots, etc.

[0030] In addition to web application 214, conductor 212 also includes a services layer that exposes OData REST API endpoints 216 (although other endpoints may be implemented without departing from the scope of the present invention). The REST API is consumed by both web application 214 and agent 206, which in this exemplary configuration is a supervisor of one or more robots on a client computer.

[0031] The REST API in this embodiment covers configuration, logging, monitoring, and queuing functions. In some embodiments, a configuration REST endpoint can be used to define and configure application users, permissions, robots, assets, releases, and environments. Logging REST endpoints can be useful for logging different information, such as errors, explicit messages sent by robots, and other environment-specific information. A deployment REST endpoint can be used by a robot to query the package version that should be executed when a start job command is used in the conductor 212. Queuing REST endpoints can involve managing queues and queue items, such as adding data to a queue, retrieving transactions from a queue, and setting the state of a transaction. Monitoring REST endpoints monitor the web application 214 and the agent 206. A notification monitoring API 218 can be a REST endpoint used to register agents 206, distribute configuration settings to agents 206, and send / receive notifications from the server and agent 206. In some embodiments, the notification monitoring API 218 can also use WebSocket communication.

[0032] The server-side persistence layer includes a pair of servers in this exemplary embodiment: a database server 222 (e.g., SQL Server) and an indexer server 224. The database server 222 in this embodiment stores configurations for robots, robot groups, associated processes, users, roles, schedules, etc. This information is managed in some embodiments via web application 214. The database server 222 can also manage queues and queue items. In some embodiments, the database server 222 can store messages logged by robots (in addition to or instead of the indexer server 224). The indexer server 224 is optional in some embodiments and stores and indexes information logged by robots. In certain embodiments, the indexer server 224 may be disabled through a configuration setting. In some embodiments, the indexer server 224 uses ElasticSearch®, a full-text search engine from an open-source project. Messages logged by the robot (e.g., using activities such as log messages or line writes) may be sent via a logging REST endpoint to the indexer server 224, where they are indexed for future use.

[0033] FIG. 3 is an architectural diagram illustrating a simplified example deployment of an RPA system 300 according to one or more embodiments. In some embodiments, the RPA system 300 may be or include the RPA systems 100 and / or 200 of FIGS. 1 and 2, respectively. The RPA system 300 includes multiple client computing systems 302 that execute robots. The computing systems 302 can communicate with a conductor computing system 304 via web applications running thereon. The conductor computing system 304 further communicates with a database server 306 and an optional indexer server 308. With respect to FIGS. 2 and 3, it should be noted that although web applications are used in these embodiments, any suitable client / server software can be used without departing from the scope of the present invention. For example, the conductor can execute a server-side application that communicates with a non-web-based client software application on the client computing systems.

[0034] In one embodiment, RPA system 100 of FIG. 1 , RPA system 200 of FIG. 2 , and / or RPA system 300 of FIG. 3 may be implemented for cloud-based management of RPA robots. Such cloud-based management of RPA robots enables RPA to be provided as software as a service (SaaS). Accordingly, conductor 104 of FIG. 1 , conductor 212 of FIG. 2 , and / or conductor 304 of FIG. 3 are implemented in the cloud for cloud-based management of RPA robots, for example, to create RPA robots, provision RPA robots, schedule tasks for RPA robots, stop RPA robots, or perform any other orchestration tasks for managing RPA robots.

[0035] FIG. 4 illustrates an architecture diagram of a cloud RPA system 400 for implementing cloud-based management of RPA robots, according to one or more embodiments. The cloud RPA system 400 includes a cloud computing environment 402 and a local computing environment 404. The local computing environment 404 represents the local network architecture of a user, such as a company or enterprise, or any other entity or entities. The local computing environment 404 includes a local network 406. The cloud computing environment 402 represents a cloud computing network architecture that provides workload services or processing remote from the user in the local computing environment 404. The cloud computing environment 402 includes various cloud networks, including the Internet 414, a user cloud network 418 that represents a cloud network managed (or controlled) by a user and hosted by a cloud platform provider, and a cloud service provider cloud network 420 that represents a cloud network managed by a cloud service provider and hosted by a cloud platform provider. A cloud service provider is an entity that provides services (e.g., RPA) via the cloud. A cloud platform provider is an entity that maintains the cloud computing infrastructure. The local network 406 of the local computing environment 404 is communicatively coupled to the Internet 414 of the cloud computing environment 402 to facilitate communication between the local computing environment 404 and the cloud computing environment 402 .

[0036] 4, cloud orchestrator 430 is implemented in cloud computing environment 402 to enable cloud-based management of RPA robots. In particular, cloud orchestrator 430 is managed by a cloud service provider and hosted within a cloud service provider cloud network 420 within cloud computing environment 402. In one embodiment, the cloud service provider offers RPA to users within local computing environment 404.

[0037] Cloud orchestrator 430 manages RPA robots in cloud computing environment 402. In particular, a user interacts with computing device 412 in local computing environment 404 to send instructions to cloud orchestrator 430 in cloud computing environment 402 to manage the RPA robot. Alternatively, a user interacts with computing device 412 in local computing environment 404 to set up a schedule on cloud orchestrator 430 to automatically send instructions on the user's behalf to manage the RPA robot. Typical instructions for managing RPA robots include instructions for creating an RPA robot, instructions for provisioning an RPA robot, instructions for scheduling tasks on an RPA robot (e.g., scheduling a time to perform a task and a type of robot to perform the task), instructions for decommissioning an RPA robot, or any other orchestration instructions for an RPA robot. In response to receiving an instruction, cloud orchestrator 430 executes the instruction, for example, by creating an RPA robot, provisioning an RPA robot, scheduling tasks for an RPA robot, decommissioning an RPA robot, etc. In one embodiment, cloud orchestrator 430 may be similar to conductor 104 of FIG. 1, conductor 212 of FIG. 2, or conductor 304 of FIG. 3, but may be implemented in cloud service provider cloud network 420 within cloud computing environment 402.

[0038] The RPA robots managed by cloud orchestrator 430 may include a pool of cloud robots deployed and maintained within cloud computing environment 402. Such cloud robots may include one or more cloud service robots 428-A, ..., 428-X (collectively referred to herein as cloud service robots 428) from a cloud service robot pool 426 and one or more cloud managed robots 424-A, ..., 424-Y (collectively referred to herein as cloud managed robots 424) from a cloud managed robot pool 422. Such cloud robots perform tasks (i.e., processes) in the cloud computing environment 402 and transmit the results of the tasks to a user in the local computing environment 404. Additionally or alternatively, the RPA robots managed by cloud orchestrator 430 may include one or more local robots 410-A, ..., 410-Z (collectively referred to herein as local robots 410) from a local robot pool 408.

[0039] Cloud service robots 428 are maintained by the cloud service provider in the cloud service provider's cloud network 420 to perform RPA tasks within the cloud computing environment 402 for users in the local network environment 404. Cloud service robots 428 are created on demand by users sending instructions from their computing devices 412 to the cloud orchestrator 430. Once created, the cloud service robot 428 enters a standby mode while waiting to perform a task (or workflow). While in standby mode, the cost of operating the cloud service robot 428 is minimized or otherwise reduced. Tasks are scheduled on the cloud service robot 428 by users sending instructions from their computing devices 412 to the cloud orchestrator 430. The instructions for scheduling a task define the time to perform the task and the type of robot to perform the task. The cloud service robot 428 wakes up from standby mode to perform the task and returns to standby mode when the task is complete. Thus, the cloud service robot 428 performs tasks on the cloud service provider cloud network 420 for the user in the local computing environment 404 .

[0040] The cloud management robot 424 is maintained by a user in the user cloud network 418 to perform RPA tasks in the cloud computing environment 402 for a user in the local network environment 404. The cloud management robot 424 is similar in function to the cloud service robot 428 and is also hosted in the cloud computing environment 402. However, the user cloud network 418 on which the cloud management robot 424 is hosted is managed by the user, while the cloud service provider cloud network 420 on which the cloud service robot 428 is hosted is managed by the cloud service provider and hosted by a cloud platform provider. The cloud orchestrator 430 manages the cloud management robot 424 by establishing a connection between the cloud service provider cloud network 420 and the user cloud network 418. The user cloud network 418 may be established by the user using cloud provider technology to tunnel back to the local network 406. The user can establish a dedicated network connection from the local network 406 to the cloud service provider cloud network 420. The connections typically take the form of, for example, any-to-any (e.g., Internet Protocol Virtual Private Network) networks, point-to-point Ethernet networks, or virtual cross-connects through a connectivity provider at a colocation facility. These connections do not traverse the public Internet, which offers higher reliability, faster speeds, consistent latency, and greater security than typical connections over the Internet. The user cloud network 418 remains completely controlled and managed by the user, thereby providing the user with tight control over their data.

[0041] Once a connection between cloud service provider cloud network 420 and user cloud network 418 is established, cloud management robots 424 are created upon request by users interacting with cloud orchestrator 430 via computing devices 412. Cloud management robots 424 are created on user cloud network 418. Thus, cloud management robots 424 perform tasks on user cloud network 418 for users in local computing environments 404. Algorithms can be applied to maximize utilization of robots in cloud management robot pool 422 and reduce operational costs for users.

[0042] A local robot 410 is maintained by a user in a local network 406 to perform RPA tasks for a user in the local network environment 404. The local network 406 is controlled or managed by the user. A cloud orchestrator 430 maintains a connection to the local robot 410 via a standard HTTPS connection.

[0043] During operation, an RPA system, such as RPA system 100 of FIG. 1 , RPA system 200 of FIG. 2 , RPA system 300 of FIG. 3 , and / or cloud RPA system 400 of FIG. 4 , is configured to complete a job. Such a job is completed by one or more RPA robots running or executing on a virtual machine (or any other computing environment) to perform one or more RPA workflows. A virtual machine is a virtualization or emulation of a computer system that runs on another computer system. Sometimes, it may be desirable to complete an RPA job by prioritizing time, cost, or a balance between time and cost. Embodiments described herein provide an RPA autoscaling strategy for prioritizing time, cost, or a balance between time. Preferably, a computing environment is allocated to run one or more RPA robots to complete the job based on a selected RPA autoscaling strategy, thereby completing the job according to the prioritized time, cost, or balance with minimal manual user configuration.

[0044] FIG. 5 illustrates a method 500 for allocating computing environments to execute RPA robots, according to one or more embodiments. The steps of method 500 may be performed by one or more suitable computing devices, such as, for example, computing system 600 of FIG. 6. In one embodiment, the steps of method 500 are performed by an orchestrator or conductor of an RPA system, such as, for example, conductor 104 of RPA system 100 of FIG. 1, conductor 212 of RPA system 200 of FIG. 2, conductor 304 of RPA system 300 of FIG. 3, or cloud orchestrator 430 of cloud RPA system 400 of FIG. 4.

[0045] In step 502, a request to complete an RPA workload is received. The RPA workload may be, for example, a set of RPA jobs.

[0046] In step 504, the number of computing environments to allocate to complete the RPA workload is calculated based on a selected one of a plurality of RPA autoscaling strategies. In one embodiment, the computing environments are virtual machines. However, the computing environments may be any other suitable computing environments for running RPA robots, such as a virtualized desktop environment, a container, etc. The RPA autoscaling strategy may be defined or implemented in a number of ways, such as, for example, as an RPA autoscaling profile.

[0047] The multiple RPA autoscaling strategies balance the time to complete the RPA workload and the cost. In one embodiment, the multiple RPA autoscaling strategies include a speed over cost strategy, a balanced strategy, and a cost over speed strategy. The speed over cost strategy has the fastest time to complete the RPA workload but the highest infrastructure cost. The balanced strategy has a medium time to complete the RPA workload and a medium infrastructure cost. The cost over speed strategy has the slowest time to complete the RPA workload but the lowest infrastructure cost. In one embodiment, the cost over speed strategy is the default strategy.

[0048] The number of computing environments to allocate is determined according to various control variables or parameters based on the selected auto-scaling strategy. In one embodiment, the number of computing environments to allocate is determined according to the selected auto-scaling strategy based on 1) MAX_MACHINES_FOR_WORKLOAD, which represents the number of computing environments that will complete the RPA workload, 2) MAX_MACHINES, which represents the maximum number of computing environments in the pool, and 3) LICENSED_ROBOTS, which represents the number of active RPA robots allowed by the license.

[0049] For the speed over cost strategy, the number of computing environments to allocate ALLOCATION_MACHINE_COUNT is calculated as follows: ALLOCATION_MACHINE_COUNT= min(MAX_MACHINES_FOR_WORKLOAD,MAX_MACHINES) / X where control variable X is any positive integer (e.g., 2), MAX_MACHINES is defined to be the maximum number of computing environments in the pool, MIN_MACHINES is defined to be 1, MACHINE_IDLE is defined to be 30 minutes, and MACHINE_DELETE is defined to be Z minutes. For a balanced strategy, the number of computing environments to allocate, ALLOCATION_MACHINE_COUNT, is calculated as follows: ALLOCATION_MACHINE_COUNT= min(MAX_MACHINES_FOR_WORKLOAD,MAX_MACHINES) / Y where the control variable Y is any positive integer greater than X (e.g., 4), MAX_MACHINES is defined to be the maximum number of computing environments in the pool, MIN_MACHINES is defined to be 0, MACHINE_IDLE is defined to be 10 minutes, and MACHINE_DELETE is defined to be Z minutes. For the cost over speed strategy, the number of computing environments to allocate, ALLOCATION_MACHINE_COUNT, is defined as follows: ALLOCATION_MACHINE_COUNT=1 Here, the control variables MAX_MACHINES is defined to be the maximum number of computing environments in the pool, MIN_MACHINES is defined to be 0, MACHINE_IDLE is defined to be 3 minutes, and MACHINE_DELETE is defined to be Z minutes.

[0050] The number of computing environments to allocate is calculated by calculating ALLOCATION_MACHINE_COUNT according to a formula associated with the selected RPA autoscaling strategy, where the calculated result is rounded up to the next integer. In the above calculation, the control variable ALLOCATION_MACHINE_COUNT is the number of computing environments to allocate, the control variable MAX_MACHINES_FOR_WORKLOAD is the number of computing environments that will complete the RPA workload (taking into account state information such as pending jobs, running jobs, and licensed RPA robot run time), the control variable MAX_MACHINES is the maximum number of computing environments that may be created in the pool, the control variable MIN_MACHINES is the minimum number of computing environments that should remain available at all times (even if there are no pending jobs), the control variable MACHINE_IDLE is the amount of time a computing environment will wait after becoming idle before being put into a waiting state, and the control variable MACHINE_DELETE is the amount of time a computing environment will wait after being deallocated before being deleted.

[0051] It should be understood that other types of strategies may also be included in the RPA autoscaling strategies. In one example, the RPA autoscaling strategies may include one or more custom strategies in which a user configures one or more control variables to manually balance the time and cost to complete an RPA workload. For example, the custom strategy may allocate computing environments based on a formula associated with the speed-over-cost or balanced strategies described above according to user-defined values ​​of X or Y. In another example, the RPA autoscaling strategies may include a dynamic strategy in which one or more control variables are automatically adjusted to balance the time and cost to complete an RPA workload based on, for example, workload type (e.g., average execution time for a set of RPA jobs), internal constraints (e.g., time to deploy computing environments, average time to complete a job, number of available RPA licenses), etc. For example, a scheduler may monitor pending jobs, computing resources, etc., and automatically adjust one or more control variables of the dynamic strategy. In some embodiments, one or more control variables in the dynamic strategy are automatically adjusted using a machine learning-based model.

[0052] In one embodiment, the selection of the selected RPA autoscaling strategy is received from a user interacting with, for example, a user interface of an orchestrator of the RPA system. In another embodiment, the selected RPA autoscaling strategy is selected automatically. In one example, the selected RPA autoscaling strategy may be automatically selected according to a schedule defining a start time and an end time for applying the selected RPA autoscaling strategy. For example, for an accounting firm that handles tax returns and document processing, the RPA workload increases at the end of each month and each quarter. A speed-over-cost strategy may be scheduled at the end of each month and each quarter, and a cost-over-speed strategy may be scheduled for the remaining period. As another example, for a university that handles student enrollment and graduation, the RPA workload increases when students undergo onboarding at the beginning of the academic year for enrollment and when students dismiss at the end of the academic year for graduation. A speed-over-cost strategy may be scheduled at the beginning and end of the academic year, and a cost-over-speed strategy may be scheduled for the remaining period. In another example, the selected RPA autoscaling strategy may be automatically selected based on the source of the RPA workload. This allows a user to prioritize workload received from a particular source so that workload can be processed more quickly by selecting a speed over cost strategy, while workload received from other sources can be processed cost-effectively using a cost over speed strategy. As an example, in the case of an IT (information technology) help desk, a speed over cost strategy may be selected for requests according to an SLA (service level agreement) associated with the source or a business critical flag associated with the source, and a balanced strategy may be selected for all other requests.

[0053] In step 506, the calculated number of computing environments is allocated for assigning one or more RPA robots to complete the RPA workload.

[0054] FIG. 6 is a block diagram illustrating a computing system 600 configured to perform the methods, workflows, and processes described herein, including method 500 of FIG. 5, according to one embodiment of the present invention. In some embodiments, computing system 600 may be one or more of the computing systems illustrated and / or described herein. Computing system 600 includes a bus 602 or other communication mechanism for communicating information and a processor 604 coupled to bus 602 for processing information. Processor 604 may be any type of general-purpose or special-purpose processor, including a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a graphics processing unit (GPU), multiple instances thereof, and / or any combination thereof. Processor 604 may also have multiple processing cores, and at least some of the cores may be configured to perform specific functions. In some embodiments, multiple parallel processing may be used.

[0055] Computing system 600 further includes memory 606 for storing information and instructions executed by processor 604. Memory 606 may be comprised of any combination of random access memory (RAM), read-only memory (ROM), flash memory, cache, static storage such as a magnetic or optical disk, or any other type of non-transitory computer-readable medium, or a combination thereof. Non-transitory computer-readable media may be any available media that can be accessed by processor 604 and may include volatile media, non-volatile media, or both. Also, media may be removable, non-removable, or both.

[0056] Additionally, computing system 600 includes a communication device 608, such as a transceiver, for providing access to a communication network via wireless and / or wired connections according to any currently existing or future implemented communication standards and / or protocols.

[0057] Processor 604 is further coupled via bus 602 to a display 610 suitable for displaying information to a user. Display 610 may also be configured as a touch display and / or any suitable tactile I / O device.

[0058] A keyboard 612 and cursor control device 614, such as a computer mouse, touchpad, or the like, are further coupled to bus 602 to allow a user to interface with the computing system. However, in certain embodiments, a physical keyboard and mouse may not be present, and the user may interact with the device solely through the display 610 and / or touchpad (not shown). Any type and combination of input devices may be used as a matter of design choice. In certain embodiments, no physical input devices and / or display are present. For example, a user may interact with computing system 600 remotely via another computing system that communicates with it, or computing system 600 may operate autonomously.

[0059] The memory 606 stores software modules that provide functionality when executed by the processor 604. The modules include an operating system 616 for the computing system 600 and one or more additional functional modules 618 configured to perform all or part of the processes described herein or derivatives thereof.

[0060] As will be appreciated by those skilled in the art, a "system" may be embodied as a server, an embedded computing system, a personal computer, a console, a personal digital assistant (PDA), a mobile phone, a tablet computing device, a quantum computing system, or any other suitable computing device or combination of devices without departing from the scope of the present invention. Presenting the above functions as being performed by a "system" is not intended to limit the scope of the present invention in any way, but rather to provide one example of many embodiments of the present invention. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed fashions consistent with computing technologies, including cloud computing systems.

[0061] It should be noted that some of the system features described herein have been presented as modules to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising off-the-shelf semi-conductors such as custom very large scale integrated (VLSI) circuits or gate arrays, logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc. A module may also be implemented at least partially in software for execution by various types of processors. An identified unit of executable code may comprise one or more physical or logical blocks of computer instructions, which may be organized as, for example, an object, a procedure, or a function. Nevertheless, the executable files of an identified module need not be physically located together but may comprise different instructions stored in different locations that, when logically combined together, comprise the module and achieve the stated purpose of the module. Furthermore, modules may be stored on a computer-readable medium, which may be, for example, a hard disk drive, a flash device, RAM, tape, and / or any other such non-transitory computer-readable medium used to store data without departing from the scope of the present invention. Indeed, a module of executable code may be a single instruction, or many instructions, and may be distributed across several different code segments, different programs, and several memory devices. Similarly, operational data may be identified and illustrated herein within modules and may be embodied in any suitable form and organized within any suitable type of data structure. Operational data may be collected as a single data set or may be distributed in different locations, including different storage devices, or may exist, at least in part, solely as electronic signals on a system or network.

[0062] The foregoing merely illustrates the principles of the present disclosure. Thus, it will be appreciated that those skilled in the art will be able to devise various configurations that embody the principles of the present disclosure and are within the spirit and scope of the present disclosure, although not explicitly described or shown herein. Furthermore, all examples and conditional language recited herein are primarily for educational purposes to aid the reader in understanding the principles of the present disclosure and the concepts contributed by the inventors to advance the technology, and should be construed as not being limited to such specifically recited examples and conditions. Furthermore, all statements herein reciting principles, aspects, and embodiments of the present disclosure, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Furthermore, such equivalents are intended to include both currently known equivalents and equivalents developed in the future.

Claims

1. receiving a request to complete an RPA (Robotic Process Automation) workload; calculating a number of computing environments to allocate to complete the RPA workload based on a selected one of a plurality of RPA auto-scaling strategies; allocating the calculated number of computing environments to assign one or more RPA robots to complete the RPA workload; 10. A computer-implemented method comprising:

2. The computer-implemented method of claim 1 , wherein the computing environment comprises a virtual machine.

3. 2. The computer-implemented method of claim 1, wherein the plurality of RPA autoscaling strategies include a speed over cost strategy, a balanced strategy, and a cost over speed strategy.

4. 2. The computer-implemented method of claim 1, wherein the number of computing environments to allocate is calculated based on a number of computing environments that will complete the RPA workload, a maximum number of computing environments that may be created in a pool, and a number of RPA robots allowed by a license.

5. 10. The computer-implemented method of claim 1, wherein the plurality of RPA autoscaling strategies includes a custom strategy in which a user configures one or more control variables.

6. 10. The computer-implemented method of claim 1, wherein the plurality of RPA autoscaling strategies includes a dynamic strategy in which one or more control variables are automatically adjusted based on workload type.

7. The computer-implemented method of claim 1 , further comprising receiving a selection of the selected RPA autoscaling strategy from a user.

8. The computer-implemented method of claim 1 , further comprising automatically selecting the selected RPA auto-scaling strategy according to a schedule.

9. The computer-implemented method of claim 1 , further comprising automatically selecting the selected RPA auto-scaling strategy based on a source of the RPA workload.

10. a memory for storing computer instructions; at least one processor configured to execute the computer instructions, the computer instructions causing the at least one processor to: receiving a request to complete a robotic process automation (RPA) workload; calculating a number of computing environments to allocate to complete the RPA workload based on a selected one of a plurality of RPA auto-scaling strategies; allocating the calculated number of computing environments to assign one or more RPA robots to complete the RPA workload; at least one processor configured to execute An apparatus comprising:

11. The apparatus of claim 10 , wherein the computing environment comprises a virtual machine.

12. 11. The apparatus of claim 10, wherein the plurality of RPA autoscaling strategies include a speed over cost strategy, a balanced strategy, and a cost over speed strategy.

13. 11. The apparatus of claim 10, wherein the number of computing environments to allocate is calculated based on the number of computing environments that will complete the RPA workload, the maximum number of computing environments that may be created in a pool, and the number of RPA robots allowed by a license.

14. 11. The apparatus of claim 10, wherein the plurality of RPA autoscaling strategies includes a custom strategy in which a user configures one or more control variables.

15. A non-transitory computer-readable medium storing computer program instructions that, when executed on at least one processor, cause the at least one processor to: receiving a request to complete a robotic process automation (RPA) workload; calculating a number of computing environments to allocate to complete the RPA workload based on a selected one of a plurality of RPA auto-scaling strategies; allocating the calculated number of computing environments to assign one or more RPA robots to complete the RPA workload; A non-transitory computer-readable medium for causing operations to be performed, including:

16. The non-transitory computer-readable medium of claim 15 , wherein the computing environment comprises a virtual machine.

17. 16. The non-transitory computer-readable medium of claim 15, wherein the plurality of RPA auto-scaling strategies include a dynamic strategy in which one or more control variables are automatically adjusted based on workload type.

18. The operation is 16. The non-transitory computer-readable medium of claim 15, further comprising receiving a selection of the selected RPA autoscaling strategy from a user.

19. The operation is 16. The non-transitory computer-readable medium of claim 15, further comprising an operation of automatically selecting the selected RPA auto-scaling strategy according to a schedule.

20. The operation is 16. The non-transitory computer-readable medium of claim 15, further comprising an operation of automatically selecting the selected RPA auto-scaling strategy based on a source of the RPA workload.

Images