Dynamic cloud deployment of Robotic Process Automation (RPA) robots

Abstract

To provide a robotic process automation (RPA) execution method for facilitating programming and deployment on cloud, a computer system, and a computer-readable medium.SOLUTION: A method comprises determining whether a provisioning condition is satisfied according to a queue of RPA jobs and further according to a pool of RPA robots currently instantiated on a selected RPA host platform. The method further comprises, when the provisioning condition is satisfied, initiating an automatic provisioning of a virtual machine (VM) on the selected RPA host platform according to a VM template selected from a template repository according to an RPA job of the queue. Executing the VM template causes the VM to instantiate and start an RPA robot for executing the RPA job. The method further comprises determining whether a machine termination condition is satisfied and performing an automatic termination of the VM.SELECTED DRAWING: Figure 1

Description

Background Art

[0001] The present invention relates to robotic process automation (RPA), and more particularly to executing RPA activities on a cloud computing platform.

[0002] RPA is an emerging field of information technology aimed at improving productivity by automating repetitive computing tasks, thus enabling human operators to perform more intellectually sophisticated and / or creative activities. Notable tasks for automation include, among other things, extracting structured data from documents, generating invoices and other business documents, and interacting with user interfaces, for example to fill out forms.

[0003] One particular area of interest, accelerated by the rapid development of cloud computing, involves executing RPA activities on a cloud, i.e., a remotely accessible computing platform implementing an infrastructure-as-a-service (IaaS) and / or software-as-a-service (SaaS) business model. However, such development faces certain technical hurdles. For example, successfully executing RPA on the cloud typically requires, among other things, concurrent knowledge of RPA tools, cloud management, and virtualization, which is expected to exceed the capabilities of the average RPA developer. Accordingly, there is a strong interest in facilitating the programming and deployment of software robots designed to operate on the cloud, with the ultimate goal of expanding the reach of RPA technology to users lacking advanced programming skills or training.

Summary of the Invention

[0004] In one embodiment, a robotic process automation (RPA) method includes using at least one hardware processor of a computer system to determine whether provisioning conditions are met according to a queue of RPA jobs and, further, according to a pool of RPA robots currently instantiated on a selected RPA host platform. In response, the method, when the provisioning conditions are met, initiates the automatic provisioning of a virtual machine (VM) on a selected RPA host platform according to a VM template selected from a template repository according to the queue of RPA jobs, and further includes initiating the execution of the VM template, causing the VM to instantiate RPA robots for executing RPA jobs. In response to the provisioning of the VM, the method further includes connecting the RPA robots to an RPA orchestrator configured to assign queues of RPA jobs to a pool of RPA robots. The method further includes determining whether machine termination conditions are met and, if so, initiating the automatic termination of the VM. [Brief explanation of the drawing]

[0005] The aforementioned aspects and advantages of the present invention will be better understood by reading the following detailed description and referring to the drawings.

[0006] [Figure 1] This document illustrates an exemplary robotic process automation (RPA) environment according to several embodiments of the present invention.

[0007] [Figure 2] This document illustrates exemplary components and operations of RPA robots and orchestrators according to several embodiments of the present invention.

[0008] [Figure 3]This document illustrates various RPA host systems according to several embodiments of the present invention.

[0009] [Figure 4-A] This shows exemplary RPA components that run on an RPA host according to some embodiments of the present invention.

[0010] [Figure 4-B] This shows exemplary RPA components performed on an RPA host in an embodiment that uses hardware virtualization.

[0011] [Figure 5] This document illustrates an exemplary RPA orchestrator for deploying robots across multiple RPA host platforms, according to several embodiments of the present invention.

[0012] [Figure 6] This illustrates the operation of an exemplary automated optimizer according to several embodiments of the present invention.

[0013] [Figure 7-A] This shows an exemplary series of steps performed by an automated optimizer according to some embodiments of the present invention.

[0014] [Figure 7-B] This shows another exemplary set of steps performed by an automated optimizer according to some embodiments of the present invention.

[0015] [Figure 8] This specification shows an exemplary hardware configuration of a computing device programmed to perform some of the methods described herein. [Modes for carrying out the invention]

[0016] In the following description, it is understood that all enumerated connections between structures can be direct operational connections or indirect operational connections via intermediate structures. A set of elements contains one or more elements. An enumeration of elements is understood to refer to at least one element. Multiple elements contain at least two elements. Any use of "or" means non-exclusive or. Unless otherwise requested, the method steps described do not necessarily have to be performed in a specific illustrated order. A first element derived from a second element (e.g., data) includes a first element equal to the second element, as well as a first element produced by processing the second element and optionally other data. Making a determination or decision according to a parameter includes making a determination or decision according to a parameter and optionally other data. Unless otherwise specified, indicators of some quantity / data may be the quantity / data itself or indicators different from the quantity / data itself. A computer program is a set of processor instructions that perform a task. The computer programs described in some embodiments of the present invention may be standalone software entities or sub-entities of other computer programs (e.g., subroutines, libraries). The term “database” is used herein to refer to an organized collection of searchable data. Computer-readable media include non-temporary media such as magnetic, optical, and semiconductor storage media (e.g., hard drives, optical disks, flash memory, DRAM), as well as communication links such as conductive cables and optical fiber links. According to some embodiments, the present invention provides, among other things, a computer system comprising hardware (e.g., one or more processors) programmed to perform the methods described herein, and computer-readable media encoding instructions for performing the methods described herein.

[0017] The following description illustrates embodiments of the present invention and is not necessarily limiting.

[0018] Figure 1 shows an exemplary robotic process automation (RPA) environment 10 according to several embodiments of the present invention. Environment 10 comprises various software components that work together to achieve the automation of a particular task. In an exemplary RPA scenario, a company employee performs repetitive tasks using business applications (e.g., a word processor, a spreadsheet editor, a browser, and an email application) to issue invoices to various clients, for example. To actually perform each task, the employee performs a series of operations / actions, which are considered a process in this specification. Exemplary operations that form part of the invoice issuance process may include opening a Microsoft Excel® spreadsheet, retrieving the client's company details, copying each detail into an invoice template, filling in invoice fields indicating the purchased goods, switching to an email application, composing an email message to each client, attaching the newly created invoice to each email message, and clicking the “Send” button. Various elements of the RPA environment 10 can automate their respective processes by mimicking the set of operations performed by their respective human operators in the course of performing their respective tasks.

[0019] Mimicking human operation / action is understood herein to include reproducing the sequence of computing events that occur when a human operator performs each operation / action on a computer, as well as reproducing the results of the human operator performing each operation on the computer. For example, mimicking the action of clicking a button on a graphical user interface may include having the operating system move the mouse pointer to each button and generate a mouse click event, or it may include switching each GUI button itself to a clicked state.

[0020] Processes typically targeted for such automation include, among others, payment processing, invoicing, communication with business clients (e.g., distribution of newspapers and / or product offerings), internal communication (e.g., memos, meetings and / or task scheduling), auditing, and payroll processing. In some embodiments, a dedicated RPA design application 30 (Figure 2) enables a human developer to design software robots that implement workflows to effectively automate target processes. Workflows typically include a series of custom automation steps, herein considered activities. Each activity can include actions to be performed by the robot, such as clicking a button, reading a file, writing to a spreadsheet cell, etc. Activities can be nested and / or embedded. In some embodiments, the RPA design application 30 exposes a set of user interfaces and tools that give the developer control over the execution order and the relationships between the activities of the workflow. One commercial example of an embodiment of the RPA design application 30 is UiPath StudioX (trademark).

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

[0022] Once a workflow is developed, it can be encoded in a computer-readable format as a set of RPA scripts 40 (Figure 2). The RPA scripts 40 may be formulated in accordance with any data specification known in the art, for example, in Extensible Markup Language (XML), Javascript Object Notation (JSON), or in a version of a programming language such as C#, Visual Basic, Java. Alternatively, the RPA scripts 40 may be formulated as a sequence of instructions in a bytecode RPA-specific version or in a natural language such as English, Spanish, Japanese. In some embodiments, the script 40 is pre-compiled into a set of native processor instructions (e.g., machine code).

[0023] One skilled in the art will understand that the RPA design application 30 can comprise multiple components / modules that can be executed on separate physical machines. In one such example showing an embodiment of cloud computing of the present invention, the RPA design application 30 can be executed in a client-server configuration, where one component of the application 30 can expose a robot design interface to the user of the client computer, and another component of the application 30 executed on the server computer can assemble a robot workflow and formulate / output the RPA scripts 40. For example, a developer can access the robot design interface via a web browser executed on the client computer while software that processes user input received on the client computer is actually being executed on the server computer.

[0024] Once formulated, the script 40 can be executed by a set of robots 12a-c (Figure 1) which can be further controlled and coordinated by the orchestrator 14. Each of the robots 12a-c and the orchestrator 14 may contain multiple computer programs, which may or may not run on the same physical machine. Exemplary commercial embodiments of the robots 12a-c and the orchestrator 14 include UiPath Robot® and UiPath Orchestrator®, respectively. The types of robots 12a-c include, but are not limited to, attended robots, unattended robots, development robots (similar to unattended robots but used for development and testing purposes), and non-production robots (similar to attended robots but used for development and testing purposes).

[0025] Attended robots are triggered by user events and / or commands and operate alongside human operators on the same computing system. In some embodiments, attended robots can only be started from a robot tray or command prompt and therefore cannot be controlled from, for example, an orchestrator 14 or run under a locked screen. Unattended robots can run unattended in a remote virtual environment and can be responsible for remote execution, monitoring, scheduling, and providing support for work queues.

[0026] The orchestrator 14 can have a variety of functions, including provisioning, deployment, configuration, queuing, monitoring, logging, and / or providing interconnection to robots 12a-c. Provisioning may include forming and maintaining connections between robots 12a-c and the orchestrator 14. Deployment may include ensuring that software (e.g., RPA scripts 40) is correctly delivered to robots 12a-c for execution. Configuration may include maintaining and delivering robot environments and workflow configurations. Queuing may include providing job queues and queue item management. Monitoring may include maintaining a track of robot status and maintaining user permissions. Logging may include storing and indexing logs to a database and / or another storage mechanism (e.g., SQL, Elasticsearch®, Redis®). The orchestrator 14 can further function as a central point of communication for third-party solutions and / or applications.

[0027] Figure 2 shows exemplary components of a robot 12 and an orchestrator 14 according to several embodiments of the present invention. The exemplary RPA robot is built using the Windows® Workflow Foundation Application Programming Interface from Microsoft, Inc. The robot 12 may comprise a set of executors 22 and an RPA agent 24. The robot executors 22 are configured to receive an RPA script 40 that outlines a set of activities that mimic the actions of a human operator performing a business process, and to actually execute each set of activities on their respective client machines. In some embodiments, the robot executors 22 comprise an interpreter (e.g., a just-in-time interpreter or compiler) configured to translate the RPA script 40 into a runtime package containing processor instructions for performing the operations described in each script. Thus, executing the script 40 may include the executors 22 translating the RPA script 40 and instructing the processors of their respective host machines to load the resulting runtime package into memory and to start the runtime package being executed.

[0028] The RPA agent 24 can manage the operation of the robot executor 22. For example, the RPA agent 24 can select tasks / scripts for execution by the robot executor 22 according to input from a human operator and / or according to a schedule. The agent 24 can start and stop jobs and configure various operational parameters of the executor 22. If the robot 12 includes multiple executors 22, the agent 24 can coordinate their activities and / or inter-process communication. The RPA agent 24 can further manage communication between the RPA robot 12 and the orchestrator 14 and / or other entities.

[0029] In some embodiments performed in a Windows® environment, robot 12 installs the Microsoft Windows® Service Control Manager (SCM) management service by default. As a result, such robots can open interactive Windows® sessions under the local system account and have processor privileges for Windows® services. For example, a console application may be launched by the SCM management robot. In some embodiments, robot 12 can be installed at the user level with processor privileges (user mode, ring 3). Such robots have the same rights as the user on which each robot is installed. For example, such robots can launch any application that each user can. In a computing system that supports multiple interactive sessions running concurrently (e.g., Windows® Server 2012), multiple robots may run concurrently in separate Windows® sessions, each using a different username.

[0030] In some embodiments, the robot 12 and orchestrator 14 can be run in a client-server configuration. It should be noted that the client side, the server side, or both can include any desired number of computing systems (e.g., physical or virtual machines) without departing from the scope of the invention. In such a configuration, the robot 12, including the executor 22 and the RPA agent 24, can be run on the client side. The robot 12 can execute several jobs / workflows simultaneously. The RPA agent 24 (e.g., Windows® Services) can act as a single client-side contact for the executor 22. The agent 24 can further manage communication between the robot 12 and the orchestrator 14. In some embodiments, communication is initiated by the agent 24, which can open a WebSocket channel to the orchestrator 14. The agent 24 can then use the channel to send notifications about the status of each executor 22 to the orchestrator 14, for example, as heart rate signals. Next, the orchestrator 14 can use the channel to send approvals, job requests, and other data such as RPA scripts 40 to the robot 12.

[0031] The orchestrator 14 may, in some cases, run on a server side distributed across multiple physical and / or virtual machines. In one such embodiment, the orchestrator 14 may include an orchestrator user interface (UI) 17, which may be a web application, and a set of service modules 19. The service modules 19 may further include a set of Open Data Protocol (OData) Representative State Transfer (REST) ​​Application Programming Interface (API) endpoints and a set of service APIs / business logic. Users can interact with the orchestrator 14 via the orchestrator UI 17 (for example, by opening a dedicated orchestrator interface in a browser) to instruct the orchestrator 14 to perform various actions, such as starting a job on a robot 12, creating a robot group / pool, assigning robots, adding / deleting data to / from a queue, scheduling jobs to run unattended, and analyzing logs per robot or workflow. The orchestrator UI 17 may use Hypertext Markup Language (HTML), JavaScript (JS), or other data formats known in the art.

[0032] The orchestrator 14 can perform actions requested by the user by selectively calling service APIs / business logic. Furthermore, the orchestrator 14 can communicate with the robot 12 using REST API endpoints. The REST APIs can include configuration, logging, monitoring, and queuing functions. Configuration endpoints can be used to define and configure application users, permissions, robots, assets, releases, etc. Logging REST endpoints can be used to log various information, such as errors, explicit messages sent by robots, and other environment-specific information. Deployment REST endpoints can be used by robots to query the version of the RPA script 40 to be executed. Queuing REST endpoints can be responsible for queue and queue item management, such as adding data to the queue, retrieving transactions from the queue, and setting the transaction status. Monitoring REST endpoints can monitor the web application components of the orchestrator 14 and the RPA agent 24.

[0033] In some embodiments, the RPA environment 10 (Figure 1) further comprises a database server 16 connected to the RPA database 18. In embodiments where the server 16 is provisioned on a cloud computing platform, the server 16 may be embodied as a database service, for example, as a client having a set of database connectors. The database server 16 is configured to selectively store and / or retrieve data related to the RPA environment 10 in and from the database 18. Such data may include configuration parameters of various robots 12a-c, robot pools, and data characterizing workflows performed by various robots, as well as data characterizing users, roles, schedules, queues, etc. Another exemplary category of data stored and / or retrieved by the database server 16 includes data characterizing the current state of each robot in execution. Yet another exemplary category of data includes messages recorded by various robots during execution. The database server 16 and the database 18 may use any data storage protocol and format known in the art, such as, among other things, Structured Query Language (SQL), ElasticSearch®, and Redis®. In some embodiments, data is collected and managed by the orchestrator 14, for example, via logging of a REST endpoint. The orchestrator 14 can then issue structured queries to the database server 16.

[0034] In some embodiments, the RPA environment 10 (Figure 1) further comprises communication channels / links 15a-e interconnecting various members of the environment 10. Such links can be implemented according to any method known in the art, for example, as virtual network links, virtual private networks (VPNs), or end-to-end tunnels. In some embodiments, data circulating through some or all of the links 15a-e is further encrypted.

[0035] Those skilled in the art will understand that various components of the RPA environment 10 can be implemented and / or run on separate host computer systems (physical devices and / or virtual machines). Figure 3 shows various such RPA host systems 20a-e according to some embodiments of the present invention. Each host system 20a-e represents a computing system (e.g., individual computing devices or a set of interconnected computers) having at least a hardware processor, a memory unit, and a network adapter that enables each RPA host to connect to a computer network 13 and / or other computing devices. Exemplary RPA hosts 20a-c include, among other things, personal computers, laptops and tablet computers, mobile communication devices (e.g., smartphones), and enterprise mainframe computers. Other exemplary hosts shown as hosts 20d-e include cloud computing platforms such as server farms operated by Amazon® AWS and Microsoft® Azure®. A cloud computing platform comprises multiple interconnected server computer systems centrally managed according to platform-specific protocols. Clients can interact with such cloud computing platforms using platform-specific interfaces / software layers / libraries (e.g., software development kits - SDKs, plugins, etc.) and / or platform-specific command syntax. Exemplary platform-specific interfaces include, among other things, the Azure® SDK and the AWS® SDK.

[0036] Another exemplary RPA host includes on-premises computers (e.g., servers). The term “on-premises” is used herein to refer to hardware owned by the individual / organization that owns the RPA jobs being performed using and / or on the respective hardware, as opposed to a cloud platform owned by a different entity, for example, the individual / organization.

[0037] Figures 4-A and 4-B show exemplary software running on an RPA host platform 20 in various configurations. The illustrated RPA host platform 20 can represent any of the RPA hosts 20a-e in Figure 3, for example, a standalone personal computer, an on-premise server, a cloud computing platform, etc. In one such embodiment shown in Figure 4-A, the platform 20 runs an operating system (OS) 30 and an instance of an RPA target application 32, i.e., a software application targeted for automation by a robot 12, such as an instance of Microsoft Excel® or a web browser. The OS 30 comprises a software layer that interfaces between the application 32 and the hardware of the host platform 20, and can be any widely available operating system such as Microsoft Windows®, MacOS®, Linux®, iOS®, or Android®. The RPA target application 32 generally represents any computer program used by a human operator to perform a task. Exemplary applications 32 include, among others, word processors, spreadsheet applications, graphics applications, browsers, social media applications, and electronic communication applications.

[0038] In some embodiments employing hardware virtualization technologies, particularly cloud computing, several components of the RPA environment 10 can be run within virtual machines (VMs), as shown in Figure 4-B. Virtual machines are known in the art as software emulations of actual physical machines / computer systems that can run operating systems and other applications. Some cloud computing platforms expose a set of VMs 28a-b using a hypervisor 26. The hypervisor 26 typically has a software layer that runs with the highest level of processor privileges (i.e., the most privileged level, sometimes known as root or ring-1). Exposing VMs as herein involves creating or enabling multiple virtualization devices, such as virtual processors and virtual controllers, and presenting such virtualization devices to software in place of actual physical devices on the host platform 20. Each virtualization device (e.g., processor, input, output, storage, etc.) emulates at least some of the functionality of the respective physical devices on the host platform 20. For example, software running on a virtualized processor can send and / or receive network traffic through a virtualized network adapter. The hypervisor 26 can further enable the multiplexing (sharing) of hardware resources on the RPA host 20 by multiple VMs 28a-b. In some embodiments, such sharing is configured so that each VM 28a-b operates independently and is unaware of other VMs running simultaneously on the host platform 20.

[0039] In some embodiments, the RPA host platform 20 may further implement a usage measurement module 29 configured to determine various metrics of the current workload of each RPA host, such as the number of VMs currently instantiated on each host platform, the number of instances of RPA robots 12 that are currently running and / or idle, and the amount of hardware resources (e.g., processor cycles, memory, data traffic) currently consumed by each host platform. The measurement module 29 may form part of the hypervisor 26 as shown in the figure, but this configuration is not intended to be limiting. The measurement module 29 may use any method known in the art of hardware virtualization to determine workload metrics, for example, via memory introspection or by working with a set of measurement agents inserted into individual VMs 28a-b.

[0040] Figure 5 shows an exemplary orchestrator 14 that manages RPA activities across multiple RPA host platforms according to several embodiments of the present invention. Although Figure 5 shows only three RPA host platforms, those skilled in the art will understand that this description extends similarly to substantially any number of RPA hosts. Each illustrated RPA host platform 20f-gh can represent a separate computing system, e.g., an individual computer, an on-premises server, and / or a cloud computing platform. Each host platform can represent a cloud computing platform that operates according to a separate protocol and / or is owned by a separate entity. For example, platform 20f may include an Amazon AWST server, and platform 20g may represent a Microsoft Azure® server. Some or all components of the orchestrator 14 may then run on yet another RPA host 20h (e.g., a Google® cloud platform server from Google, Inc.). The orchestrator 14 can communicate with the RPA hosts 20f-g via a communication network 13, which may include the Internet.

[0041] Each RPA host platform 20f-g can run multiple virtual machines (exemplary virtual machines are shown as VM28c-de in Figure 5). Each VM can be identified by a unique identifier, such as a VM ID, so that it can be selectively started, stopped, inspected, configured, etc. In some embodiments, VMs currently published / instantiated on a host can be grouped into pools, such as machine pool 38 shown in Figure 5. Such grouping can reflect common ownership, common hardware or software configuration, and / or assignment to common tasks. For example, machines belonging to one machine pool may be owned and / or operated by customer A, and machines belonging to another machine pool may be owned and / or operated by customer B. In another example, VMs belonging to one machine pool may be reserved / assigned to one type of RPA job, and VMs belonging to another machine pool may be reserved / assigned to another type of RPA job.

[0042] Each RPA host platform 20f-g can run multiple RPA robots, some of which can run within virtual machines. Each RPA robot can be identified by a unique robot ID, allowing for selective startup, shutdown, inspection, configuration, job assignment, etc. Some RPA robots can also be grouped into pools (see, for example, robot pools 48a-b shown in Figure 5). Such groupings can reflect common ownership, common robot types, assignment to common tasks, etc. Robots running on the same RPA host or within the same VM are not necessarily part of the same robot pool. In the example in Figure 5, RPA robots 12d-ef belong to robot pool 48a, but robot 12g does not.

[0043] In some embodiments, the orchestrator 14 maintains a mapping between currently running RPA jobs and the RPA hosts, VMs, and / or RPA robots that perform each job. The orchestrator 14 may further map robots to the VMs they are running on, individual VMs to their respective machine pools, and / or individual RPA robots to their respective robot pools. Such mappings can be encoded and stored as part of the RPA database 18.

[0044] In some embodiments, the automation optimizer 50 is configured to dynamically scale RPA activities on RPA host platforms 20f-g on behalf of multiple customers, as detailed below. Figure 5 shows the optimizer 50 as part of the orchestrator 14, but this configuration is not intended to be limiting. In alternative embodiments, the automation optimizer 50 may be performed as a separate entity from the orchestrator 14 and may run on a separate RPA host platform. In such embodiments, the optimizer 50 may communicate with the orchestrator 14 via a dedicated application programming interface (API).

[0045] The automation optimizer 50 can interface with a customer database 52 and a VM template repository 54. Such interfaces can be embodied as database servers. In some embodiments, the customer database 52 may include a set of customer records indicating various parameter values ​​that characterize each of several different RPA customers. Exemplary customer records may specify various aspects of a service level agreement (SLA) between each RPA customer and the operator of the automation optimizer 50, such as the type, duration, and / or time window for providing RPA services to each customer. Customer records may further indicate the RPA host platform (e.g., a cloud computing platform such as Amazon AWS®) that each customer uses for RPA purposes. For example, each customer record may include a location indicator (e.g., URL, network address) for each customer's on-premises server, which is used for RPA activities. Customer records may further include a set of customer credentials (e.g., username, password, etc.) for accessing the respective RPA host platform or the configuration interface of the respective RPA host platform.

[0046] The customer records stored in the customer database 52 may further include an indicator of whether the automation optimizer 50 is permitted to instantiate and / or terminate virtual machines on behalf of each customer. Other information encoded in the customer records may include identifiers of virtual machines and / or pools of VMs currently assigned by each customer for RPA activities. In such embodiments, the orchestrator 14 may assign RPA jobs exclusively to each indicated target VM or exclusively to VMs selected from the indicated machine pool. Similarly, the customer records may include identifiers of RPA robots and / or robot pools. In such embodiments, the orchestrator 14 may assign jobs only to members of the indicated robot or robot pool.

[0047] The customer record may further include various RPA workload parameter values, such as the maximum and / or minimum number of selected types of virtual machines and / or RPA robots that can be simultaneously instantiated on the selected RPA host platform on behalf of each customer, and preferred time slots for executing RPA activities on the selected RPA host platform.

[0048] A customer record may further contain identifiers or VM templates stored in the template repository 54, each template being used to instantiate a VM on behalf of the respective customer. The customer record may further indicate the type of RPA job to be executed for each customer.

[0049] In some embodiments, dynamically scaling RPA activity up and / or down includes the optimizer 50 instantiating new VMs and / or terminating existing VM instances on a selected RPA host platform. Alternatively, dynamically scaling RPA activity may include starting and / or stopping VMs on a selected RPA host platform. Instantiating a VM may include exposing a set of virtual hardware devices that make up each VM (e.g., virtual processors, virtual network devices, etc.) and / or creating new instances of software components (e.g., RPA robots) that run within each VM. Software that runs on the virtual processors of a VM is referred to herein as running within each VM. In the example shown in Figure 4-B, the OS 30 and robot 12 run within VM 28a, while the hypervisor 26 runs outside of VMs 28a-b.

[0050] A VM instantiated for RPA purposes may contain RPA-specific software such as a set of RPA robots 12 and / or an instance of an RPA target application 32. The robots 12 and / or target application 32 may vary depending on the type of RPA job. For example, a VM instantiated to perform robotic operations on spreadsheet data may include an instance of Microsoft Excel™, but may not include another VM instantiated for robotic scraping of web data.

[0051] In some embodiments, a VM template is used to characterize each type of VM currently available for instantiation for RPA purposes. An exemplary VM template includes a set of parameter values ​​that collectively characterize each VM. For example, a VM template may include, among other things, a set of hardware parameter values ​​such as the processor type, the amount of virtual memory reserved for each VM, or the reserved bandwidth / maximum communication throughput for each VM. A VM template may further include values ​​for specific software parameters, such as the type and version of the operating system to be instantiated on each VM. A VM template may further include memory images (e.g., snapshots) of the software components to be instantiated on each VM, such as the RPA robot 12 and / or the RPA target application 32. Images of software entities as used herein represent data structures that, when loaded into the memory of a computer system, cause the computer system to perform the respective software entity.

[0052] Some VM templates may include an indicator (e.g., a URL or network address) of the target RPA host platform on which each VM will be instantiated. A template may further include a set of commands and / or scripts for instantiating each VM on the target host platform. Such VM templates may be host-specific; that is, each template may be formulated and configured for use in instantiating each VM on a particular type of RPA host. For example, separate VM templates may exist for provisioning web scraping robots on a local (on-premises) machine and on a cloud computing platform such as Microsoft Azure. Templates may be developed, tested, and maintained by a team of engineers according to customer specifications and / or requests, or they may be provided by the customer themselves. Templates may be indexed, stored, and selectively retrieved in a template repository 54, which may include a database using any protocol and data format known in the art (e.g., a relational database, a Redis store, etc.). The template repository 54 may further store indicators of the association between each VM template and the type of RPA job that requires instantiation of each VM template.

[0053] Figure 6 shows exemplary operation of an automated optimizer 50 according to several embodiments of the present invention. The optimizer 56 receives or retrieves the contents of an RPA job queue 56 maintained by the orchestrator 14. In some embodiments, the queue 56 includes a set of job indicators that show RPA jobs currently waiting to be executed. The term “job” as used herein means an instance that executes an RPA workflow. Each workflow can be encoded in a computer-readable format as an RPA script (see, for example, script 40 in Figure 2). Jobs may be added directly to the queue 56 by a user, for example, via the orchestrator UI 17 (Figure 2), or they may be added automatically by the orchestrator 14 as part of scheduling. Jobs may be removed from the queue 56 upon completion.

[0054] In some embodiments, each job in queue 56 is represented by a job indicator that may include an indicator of the customer on which the job is being performed and an identifier of the target machine (e.g., VM28c in Figure 5) on which the job must be performed. Alternatively, the job indicator may include an identifier of a machine pool (e.g., machine pool 38 in Figure 5) containing machines capable of running the job or reserved for running the job, and / or an identifier of a robot pool (e.g., robot pool 48b in Figure 5) containing RPA robots for running the job. In some embodiments, the job indicator may further indicate a VM template (e.g., via a pointer to template repository 54) representing a machine pre-configured to run the RPA job. The job indicator may further indicate, among other things, a desired time window for running the RPA job and the priority of the job.

[0055] The automation optimizer 50 may further receive or access the current RPA ledger 58, which characterizes RPA jobs that are currently running or have already been assigned for execution on various robots / machines. An exemplary ledger 58 may contain multiple job entries, each job entry indicating the current status of the respective job (e.g., running, completed, paused, hung, expired, error code characterizing the type of error that occurred during execution) and the machine and / or instance identifier of the RPA robot 12 to which the respective job is currently assigned.

[0056] In some embodiments, the optimizer 50 may receive a workload indicator 64 from the RPA host platform 20j (Figure 6), which indicates the current status and / or workload of selected machines and / or robots instantiated on each RPA host platform. An exemplary workload indicator 64 may include the number of VMs currently running on behalf of a selected customer, the count or robot instances being performed on behalf of a selected customer, the number of VMs currently belonging to a selected machine pool, and the number of RPA robots currently belonging to a selected robot pool (e.g., robot pool 48c in Figure 6). Another exemplary workload indicator 64 may indicate the current amount of hardware resources (e.g., memory, processor cycles, data traffic) consumed by RPA activity on behalf of a selected customer. The workload indicator 64 may be generated on demand or automatically, for example, using a heart rate model. If the RPA robots are hosted on a cloud computing platform, the workload indicator 64 may be generated by the cloud management interface in response to queries sent by the automation optimizer 50. In some embodiments, the workload indicator 64 may be generated by a software module running on each RPA host, for example, the usage measurement module 29 in Figure 4-B.

[0057] As part of the dynamic scaling of RPA activity, optimizer 50 can initiate a provisioning procedure via a provisioning request 62 sent to a selected RPA host platform, such as platform 20j in Figure 6. The request 62 may include a set of commands and / or scripts formulated in a programming / scripting language. An exemplary provisioning request 62 may include an authentication exchange followed by commands to instantiate a VM on the RPA host platform 20j. Another exemplary request 62 may include an image of the virtual machine to be instantiated and / or an RPA script 40 indicating the workflow to be performed. Yet another exemplary provisioning request 62 may include a set of commands to establish a virtual network connection (e.g., a VPN link) between the recently provisioned RPA robot and orchestrator 14. Yet another exemplary provisioning request 62 may include a set of commands to terminate a selected VM currently exposed on the RPA host 20j.

[0058] In response to receiving request 62, the RPA host platform 20j may send a provisioning response 63 to the automation optimizer 50, which may include, for example, an acknowledgment that the provisioning request has been received, the status of the received request indicating whether the request was successfully performed or whether the execution of the operations specified in each request failed, and a set of error codes indicating why the execution of the steps specified in the received request failed. The provisioning response 63 may further include a set of credentials for accessing the provisioned resources (e.g., VMs, robots) and / or the addresses of each provisioned resource (e.g., network addresses, uniform resource locators - URLs, fully qualified domain names - FQDNs).

[0059] For example, in some embodiments where the RPA host 20j is a cloud computing platform, the optimizer 50 can replace items 62-63 with a cloud management server / interface that can subsequently select and configure each physical machine to receive and / or run the respective VMs / robots, rather than the actual physical machines that host the selected VMs or robots.

[0060] Figure 7-AB shows an exemplary sequence of steps performed by an automated optimizer 50 according to several embodiments of the present invention. The sequence of steps 202-204 can wait until the RPA job queue 56 contains pending jobs. If so, step 206 can select a job from the queue 56. In step 208, the optimizer 208 can identify the customer associated with the selected job and retrieve the customer record for each customer in the database 52. In some embodiments, the queue entry for the selected job may indicate the respective customer. Next, step 210 can identify the RPA host platform for performing each job and obtain a set of credentials (e.g., username, password) to access each host platform according to the job indicator and / or the customer record. Thus, the optimizer 50 can determine whether each RPA host platform is a standalone machine, an on-premise server, a cloud computing platform, etc., and further determine the location (e.g., network address) of each RPA host. In some embodiments, the customer record and / or queue entry / job indicator for the selected job further includes identifiers for the target machine / machine pool or target RPA robot / robot pool to perform the respective job. Once the machine or robot pool is indicated, the automation optimizer 50 can select the target machine and / or robot from the respective pool, as further shown below.

[0061] In some embodiments, it may then be determined whether to assign the current job to an existing machine / robot or provision a new machine / robot for the task. To make this determination, step 212 may determine whether the provisioning conditions are met. In some embodiments, step 212 includes determining whether the optimizer 50 is permitted to instantiate new machines and / or robots on behalf of each customer or owner of the current job, according to customer records stored in the customer database 52. In one use case scenario, a customer may manage a pool of machines on a cloud computing platform (e.g., Amazon AWS®), and the VMs in the pool are reserved and / or assigned RPA activities according to a daily schedule. However, the customer hosts, manages, and maintains each machine themselves and does not allow the optimizer 50 to instantiate new machines / robots or terminate existing machines / robots in each pool. In such a situation, the optimizer 50 only needs to assign the current job to an existing machine / robot in each machine / robot pool, as will be described in more detail below.

[0062] In another use case scenario, the RPA customer / owner of the current job allows the optimizer 50 to dynamically scale computing resources as needed, as indicated in the customer record associated with each customer. In such a situation, determining whether the provisioning conditions are met (step 212 in Figure 7A) may include determining whether the computing resources already instantiated on the identified RPA host platform are sufficient to handle the current job. This determination can be carried out according to the contents of the RPA ledger 58 and / or workload indicator 64 received from each RPA host platform. In some embodiments, the workload indicator 64 may indicate, for example, the number of VMs and / or RPA robots currently running the RPA job on each RPA host platform. The RPA ledger 58, on the other hand, may indicate the current status of each RPA job (e.g., running, hung, completed, etc.). In some embodiments, it may be possible to further determine whether the provisioning conditions are met according to the maximum allowable number of machines and / or robot instances, as indicated in the license or service level agreement (SLA) with each customer and / or as indicated in the customer record associated with each customer and stored in the customer database 52. In one such example, the optimizer 50 may determine that the provisioning conditions are met if all RPA robots in the selected pool are currently busy and the current count of RPA robots in the selected pool is less than the maximum allowable robot count.

[0063] In some embodiments, the determination of whether the provisioning conditions are met can be further advanced according to the current contents of the RPA job queue 56. For example, in some embodiments, the determination of whether the provisioning conditions are met can be made according to the length of the current queue 56 (e.g., the number of pending jobs, the number of jobs of various types), according to the estimated execution duration of the current job and / or other pending jobs in the RPA queue 56, and / or according to the priority of the current job or other jobs in the queue. Another criterion for determining whether the provisioning conditions are met includes job wait times, e.g., the average time spent by selected jobs (or jobs of selected job types) in the job queue 56. Further criteria for determining whether the provisioning conditions are met may include whether the target machine pool currently contains machines that have the appropriate hardware and / or software configuration to run the current job. For example, the optimizer 50 may determine whether any machine in the target machine pool has been instantiated according to a particular VM template, and / or whether any machine has a particular type and / or version of the RPA target application 32, and so on. In one such example, optimizer 50 may determine that the provisioning condition is met if there are currently no machines in the target pool that are capable of running the current RPA job and / or configured to run the current RPA job.

[0064] Further criteria for determining whether provisioning conditions are met may include the current time and / or calendar date. In one such example, optimizer 50 could be allowed to dynamically scale the computing resources of the RPA host platform only within specific time windows (e.g., nighttime), specific calendar days (e.g., the first day of the month, the last business day of each month), and / or specific weekdays (e.g., during weekends). Such time preferences and restrictions can be used for cost control and can be specified in customer database records associated with each customer and / or RPA queue entries associated with the current job.

[0065] If the provisioning conditions are not met (step 214 returns no), several embodiments may proceed to a sequence of steps shown in Figure 7-B and detailed below. Meanwhile, optimizer 14 may assign the current job to an existing VM and / or RPA robot instance. Each VM and / or robot can be selected from a machine / robot pool selected according to various criteria, such as the hardware and / or software configuration of each machine, the current workload of each machine, and the number of robot instances running on each machine. For example, orchestrator 14 may select the VM and / or robot that is currently the least loaded. The tasks of starting, stopping, monitoring, and communicating with each VM / robot can be performed according to any method known in the field of robotic process automation and are outside the scope of this specification.

[0066] Once the provisioning conditions are met (step 214 returns yes), several embodiments may provision a new machine on their respective RPA host platform, which then involves instantiating a set of RPA robot instances. Step 216 may select a VM template from the template repository 54 according to the current job and / or according to other criteria such as current availability, customer preference, etc. In a further step 218, the optimizer 50 may initiate the VM provisioning procedure according to the selected template and additional job parameters. Step 218 may include sending a provisioning request 62 to the selected RPA host platform and receiving a response 63 from the selected RPA host platform (or from the cloud configuration interface of their respective RPA host platform). The provisioning request 62 may include a set of commands / instructions to cause their respective RPA host platform to instantiate a new VM with specified parameters and / or using a specified VM template. The set of commands / instructions may be platform-specific in the sense that they conform to platform-specific protocols and may be formulated according to platform-specific APIs (e.g., Azure® SDK vs AWS® SDK).

[0067] In response to receiving a provisioning response 63 indicating the successful provisioning of a new VM, step 220 may connect / register the newly instantiated robot instance with the RPA orchestrator 14. Connecting each robot with the orchestrator 14 may include generating a unique identifier for each RPA robot and providing each robot with a location indicator of the orchestrator 14 (e.g., URL, network address, etc.). In some embodiments, connecting may further include setting up a virtual network (e.g., VPN) or peer-to-peer connection between each robot and the orchestrator 14. Such operations effectively prepare each robot to receive job assignments from the orchestrator 14.

[0068] Step 222 allows newly instantiated VM and / or robot instances to be added to an existing machine / robot pool, for example, by updating database entries that associate individual machines with machine pools and / or customers. If such pools are not currently defined on the respective RPA host platform, step 222 can initialize a new pool to include the newly instantiated VM and / or RPA robot. In a further step 224, some embodiments update the RPA ledger 58 to reflect the addition of the new VM and / or robot instances. The RPA ledger 58 may be further updated by the orchestrator 14 to reflect the assignment of new RPA jobs to the newly instantiated RPA robot.

[0069] Figure 7-B shows another set of steps performed by several embodiments of the automated optimizer 50, which demonstrates scaling down computing resources by, for example, terminating idle VMs. A series of steps 232-234 can search the RPA ledger 58 to determine if the termination conditions are met, and if so, the optimizer 50 can terminate at least one VM and remove it from its respective machine pool.

[0070] In some embodiments, the termination condition is determined according to the current contents of ledger 58, the current workload of the machine / robot running the RPA job on behalf of the customer, and possibly further, the customer's preferences. In one example, step 234 may use the information from the RPA ledger 58 and the contents of at least one workload indicator 64 to identify machine and / or robot instances that are currently idle, i.e., not currently assigned to any RPA job. The optimizer 50 may then identify customers according to each machine / robot or according to the machine / robot pool to which each machine / robot belongs, and search the customer database 52 to determine a set of preferences associated with each customer. An exemplary optimizer may determine that the termination condition is met if the selected machine or robot instance has been idle for a period exceeding a predetermined threshold.

[0071] In some embodiments, it may be possible to further determine whether the termination condition has been met depending on whether the selected VM or RPA robot is currently hanging or experiencing technical problems such as failures (e.g., hardware or software exceptions, bugs in the RPA script 40, etc.) or communication failures. One example of such an exemplary optimizer 50 may determine that the termination condition has been met if the selected machine or robot instance has not communicated with the orchestrator 14 for a period exceeding a predetermined threshold (e.g., if the orchestrator 14 has not received a predetermined number of consecutive heartbeat signals from each VM / robot).

[0072] Other criteria for determining whether termination conditions are met include the current contents of RPA job queue 56, the average job wait time, the current number of VMs and / or RPA robots instantiated on each RPA host platform, and / or the current number of VMs and / or robots in machine or robot pools associated with each customer. An exemplary optimizer 50 may decide not to terminate currently idle machine or robot instances if queue 56 contains RPA jobs that are likely to belong to the same customer or be assigned to machines or robots from the same pool.

[0073] Other exemplary criteria for determining whether the termination conditions are met for a selected machine include, among other things, whether the optimizer 50 is permitted to scale computing resources on behalf of each customer, and the current time and / or calendar date.

[0074] If the termination conditions are met for the selected machines, step 238 may initiate the termination of each machine by, for example, sending a provisioning request 62 to each RPA host platform, which identifies the selected machines and formulates the request 62 to terminate each host platform. In response to receiving a provisioning response 63 indicating successful termination, step 240 may disconnect any RPA robots previously running on the terminated VMs from the orchestrator 14.

[0075] Next, a series of steps 242-244 can remove the terminated VMs and / or robots from their respective pools and update the RPA ledger 58 to reflect the termination of each machine and / or robot instance. Then, execution can proceed to step 202 described above in relation to Figure 7-A.

[0076] Figure 8 shows an exemplary hardware configuration of a computer system 70 programmed to perform some of the methods described herein. The computer system 70 can represent, for example, one of the RPA host platforms 20a-e in Figure 3, as well as the automation optimizer 50 in operation. The illustrated device is a personal computer. Other devices such as servers, mobile phones, tablet computers, and wearables may have slightly different configurations. The processor 72 comprises a physical device (e.g., a microprocessor, a multicore integrated circuit formed on a semiconductor substrate) configured to perform computational and / or logical operations using a set of signals and / or data. Such signals or data can be encoded and delivered to the processor 72 in the form of processor instructions, such as machine code. The processor 72 may include a central processing unit (CPU) and / or an array of graphics processing units (GPUs).

[0077] The memory unit 73 may include a volatile computer-readable medium (e.g., dynamic random access memory DRAM) for storing data / signal / instruction coding accessed or generated by the processor 72 in the process of performing an operation. The input device 74 may include, among other things, a computer keyboard, mouse, and microphone, including their respective hardware interfaces and / or adapters that enable a user to introduce data and / or instructions into the computer system 70. The output device 75 may include, among other things, display devices such as monitors and speakers, and hardware interfaces / adapters such as graphics cards that enable their respective computing systems to communicate data to the user. In some embodiments, the input device 74 and the output device 75 share common hardware (e.g., a touchscreen). The storage device 76 includes a computer-readable medium that enables non-volatile storage, reading, and writing of software instructions and / or data. Exemplary storage devices include magnetic and optical disks and flash memory devices, as well as removable media such as CDs and / or DVD disks and drives. The network adapter 77 enables the computing system 70 to connect to electronic communications networks (e.g., network 13 in Figure 3) and / or other devices / computer systems.

[0078] The controller hub 78 generally represents multiple system buses, peripheral buses, and / or chipset buses, and / or all other circuits that enable communication between the processor 72 and the remaining hardware components of the computer system 70. For example, the controller hub 78 may include a memory controller, an input / output (I / O) controller, and an interrupt controller. Depending on the hardware manufacturer, some such controllers may be incorporated into a single integrated circuit and / or integrated with the processor 72. In another example, the controller hub 78 may include a northbridge connecting the processor 72 to memory 73, and / or a southbridge connecting the processor 72 to devices 74, 75, 76, and 77.

[0079] The exemplary systems and methods described above enable user-friendly management of complex RPA operations, such as running multiple RPA jobs on behalf of multiple RPA customers and on a multi-tenant computing platform (e.g., in the cloud or in a hybrid configuration combining the cloud with on-premises computing).

[0080] Successfully running RPA in such a complex computing environment relies on at least two distinct categories of activities. The first category of activities includes configuring diverse fleets or software robots to meet the specific needs and preferences of each RPA customer and deploying them to various computing environments. The second category of activities includes efficiently assigning RPA jobs to all robots (sometimes according to complex scheduling and / or cost-saving strategies), monitoring the execution of multiple robots, and potentially coordinating them. The first activities may require expertise in cloud computing and hardware virtualization, among other things. The second activities, on the other hand, may require solid knowledge or RPA technology and software. Due to the very broad expertise required to bridge both categories, in traditional RPA, activities in the first category are usually separated from those in the second category. For example, activities in the first and second categories are typically performed by separate members of a team or by separate service providers / contractors.

[0081] In contrast to such conventional RPA implementations, some embodiments of the present invention automate robot provisioning and maintenance activities, seamlessly integrating them with RPA job management activities, emphasizing efficiency and cost reduction while being easily scalable. In some embodiments, the automation optimizer is configured to automatically increase or decrease the number of robots in response to fluctuations in demand for RPA jobs. The automation optimizer can further interface with an RPA orchestrator that assigns RPA jobs to individual robots and manages the execution of each robot.

[0082] In contrast to traditional RPA systems where the fleet or robots are static, i.e., do not automatically evolve to respond to fluctuations in demand, in some embodiments, the number of robots available for an RPA task can be dynamically adjusted by automatically provisioning additional virtual machines that can run additional robot instances when demand is high and deleting VMs when demand is low. Some embodiments determine whether provisioning conditions are met according to various criteria, including, among others, the current count of pending jobs (job queue length), the current load determined according to the current count of VMs running RPA jobs for a particular customer, the license or service level agreement (SLA) of the particular customer with jobs in the queue, and the current time. If the provisioning conditions are met, some embodiments automatically provision new VMs preloaded with sets or robot instances onto a selected RPA host platform. Some embodiments further automatically connect the newly provisioned robots to an orchestrator configured to distribute jobs to all robots and monitor and coordinate RPA activity across multiple robots. The type of provisioned VM can be changed according to the customer and / or according to the type of job currently in the job queue by selectively deploying a VM template with the required characteristics from a library of available pre-configured templates.

[0083] Several embodiments of the automation optimizer can provision VMs on a variety of RPA hosting platforms, including commercial cloud computing platforms (e.g., Amazon AWS®, Microsoft Azure®, etc.), on-premises servers, standalone computers, and hybrid configurations that mix cloud and on-premises resources. Each customer can specify their choice of hosting platform and provide the automation optimizer with credentials to access each hosting platform. Some embodiments further allow customers to set up dedicated machines and / or robot pools for various RPA activities.

[0084] The described system and methods further enable the seamless and user-friendly upgrading of robot fleets. Older versions of robots are automatically discarded in response to VM termination by the automation optimizer. Newly provisioned machines can be preloaded with upgraded versions of RPA robots, thus updating the fleet. Such updates / upgrades can be carried out gradually or in bulk (e.g., upgrading the entire robot pool), according to a schedule, according to current demand for jobs, on demand, etc.

[0085] Some embodiments simplify RPA operations by removing the burden of robot deployment and maintenance from the shoulders of RPA developers. Highly technical tasks such as instantiating virtual machines on diverse computing platforms, deploying robots on each platform, connecting robots to the RPA orchestrator, and ensuring communication between various RPA components may be taken over by an automation optimizer. Thus, some embodiments can make RPA technology more accessible to users who lack advanced programming skills or expertise in cloud computing and virtualization.

[0086] It will be apparent to those skilled in the art that the above embodiments can be modified in many ways without departing from the scope of the present invention. Accordingly, the scope of the present invention should be determined by the following claims and their legal equivalents.

Claims

1. A robotic process automation (RPA) method comprising using at least one hardware processor of a computer system to optimize robotic process automation (RPA) operations on a host platform having a plurality of RPA robots instantiated to execute RPA jobs, wherein the plurality of RPA robots are organized into a plurality of robot pools, Optimizing the aforementioned RPA operation This includes determining whether provisioning conditions are met according to the queue of RPA jobs, wherein the selected RPA job in the queue includes a first identifier of the selected robot pool among the plurality of robot pools. In response, the system further includes, when the provisioning conditions are met, initiating the automatic instantiation of a new RPA robot on the host platform, wherein the automatic instantiation of the new RPA robot includes provisioning a virtual machine (VM) by loading a VM template selected from the template repository according to the selected job onto the host platform, wherein the VM template includes a memory image of the VM preloaded onto the new RPA robot and an instance of the target software application. The process further includes adding the new RPA robot to the selected robot pool in response to the instantiation of the new RPA robot, The process further includes assigning the selected job to the new RPA robot and executing it. The multiple RPA robots running on the host platform are divided into multiple VMs, and the multiple VMs are further organized into multiple VM pools. At least one robot pool spans multiple VMs, and at least one VM includes at least one robot that is assigned to the at least one robot pool and at least one robot that is not assigned to the at least one robot pool. The selected job further includes a second identifier of the selected VM pool from among the plurality of VM pools, The method further includes using the at least one hardware processor to add the VM to the selected VM pool in response to the provisioning of the VM.

2. The method according to claim 1, further comprising using the at least one hardware processor to retrieve a customer record of the owner of the selected job and to determine whether the provisioning conditions are met depending on whether the customer record allows the instantiation of the new RPA robot.

3. The method according to claim 1, comprising using the at least one hardware processor to determine whether the provisioning condition is met according to the number of RPA robots in the selected robot pool.

4. The method according to claim 3, further comprising using the at least one hardware processor to determine whether the provisioning condition is met, according to the maximum allowable number of RPA robots in the selected robot pool.

5. The method according to claim 1, further comprising using the at least one hardware processor to determine whether the provisioning conditions are met according to the current time.

6. A computer system comprising at least one hardware processor configured to optimize robotic process automation (RPA) operations on a host platform having a plurality of RPA robots instantiated to execute RPA jobs, wherein the plurality of RPA robots are organized into a plurality of robot pools, and the optimization of the RPA operations is This includes determining whether provisioning conditions are met according to the queue of RPA jobs, wherein the selected job in the queue includes a first identifier of the selected robot pool among the plurality of robot pools. In response, the system further includes, when the provisioning conditions are met, initiating the automatic instantiation of a new RPA robot on the host platform, wherein the automatic instantiation of the new RPA robot includes provisioning a virtual machine (VM) by loading a VM template selected from the template repository according to the selected job onto the host platform, wherein the VM template includes a memory image of the VM preloaded onto the new RPA robot and an instance of the target software application. The process further includes assigning the selected job to the new RPA robot and executing it. The multiple RPA robots running on the host platform are divided into multiple VMs, and the multiple VMs are further organized into multiple VM pools. At least one robot pool spans multiple VMs, and at least one VM includes at least one robot that is assigned to the at least one robot pool and at least one robot that is not assigned to the at least one robot pool. The selected job further includes a second identifier of the selected VM pool from among the plurality of VM pools, The method further includes a computer system that uses at least one hardware processor to add the VM to the selected VM pool in response to the provisioning of the VM.

7. The computer system according to claim 6, configured according to any one of claims 2 to 5.

8. A non-temporary computer-readable medium that stores instructions for optimizing robotic process automation (RPA) operations on a host platform having multiple robotic process automation (RPA) robots that are instantiated to execute RPA jobs when executed by at least one hardware processor of a computer system, wherein the multiple RPA robots are organized into multiple robot pools, Optimizing the aforementioned RPA operation This includes determining whether provisioning conditions are met according to the queue of RPA jobs, wherein the selected job in the queue includes a first identifier of the selected robot pool among the plurality of robot pools. In response, when the provisioning conditions are met, the system includes initiating the automatic instantiation of a new RPA robot on the host platform, wherein the automatic instantiation of the new RPA robot includes provisioning a virtual machine (VM) by loading a VM template selected from the template repository according to the selected job onto the host platform, wherein the VM template includes a memory image of the VM preloaded onto the new RPA robot and an instance of the target software application. In response to the instantiation of the new RPA robot, the new RPA robot is added to the selected robot pool. This includes assigning the selected job to the new RPA robot and executing it. The multiple RPA robots running on the host platform are divided into multiple VMs, and the multiple VMs are further organized into multiple VM pools. At least one robot pool spans multiple VMs, and at least one VM includes at least one robot that is assigned to the at least one robot pool and at least one robot that is not assigned to the at least one robot pool. The selected job further includes a second identifier of the selected VM pool from among the plurality of VM pools, This method further includes using the at least one hardware processor to add the VM to the selected VM pool in response to the provisioning of the VM, Non-temporary computer-readable media, including the above.

9. A non-temporary computer-readable medium according to claim 8, configured according to any one of claims 2 to 5.

Images