A system for optimizing the processing of automated processes.

Abstract

This invention relates to a system for automating processes, and more particularly to a system for optimizing the allocation of work items among available processing resources in such a system. The system includes an activity queue controller executing on an application server, which manages the creation and deletion of virtual machines on available resources when querying a data repository for work items and instructions for executing the automated process.

Description

[0001] This application is a divisional application of Chinese invention application No. 201810150764.7, filed on February 13, 2018, entitled "System for Optimizing the Allocation of Automated Processes", the contents of which are incorporated herein by reference. Technical Field

[0002] This invention relates to a system and method for automating processes. More specifically, it relates to a system and method for managing the execution of automated processes across one or more virtual workers. Background Technology

[0003] Circumstances are often either anticipated or unexpected, and changes require altering how businesses operate. For example, launching a new product requires integrating existing systems, new rules need to record process steps, or a company acquisition requires merging two production lines and processing flows. Traditional enterprise system planning and rollout can address these issues; however, these planning cycles are designed for large projects, not to support changes in day-to-day operations. As a result, changes are implemented at enormous costs and sometimes take years because a new system must be developed to replace the existing system's functionality and provide the required new features. Extensive testing and quality assurance are also required to ensure reliable implementation. These systems must also be designed and configured by personnel with specialized skills in computer programming and application development. This further increases development time, as the number of people with the required skills (if any) within the organization is often limited, and once such a system is implemented, it can take a long time for existing system users to familiarize themselves with the new system, a process that is often inefficient and inaccurate.

[0004] The problem stems from the fact that back-office processes often involve multiple independent and incompatible applications. Some of these applications have Application Programming Interfaces (APIs) that facilitate information flow in and out of the application by providing predefined interfaces through which another application can interact; however, this is not always the case. For example, some applications used in these back-office processes are legacy applications that are not designed with the aforementioned features necessary for easy access by other applications. In other cases of custom internal software solutions developed for specific purposes, the need to provide interfaces through which other applications can interact is unforeseen. Traditionally, the gaps between these applications have been bridged by using operators. This is an expensive solution because it requires employing a large number of operators to provide the necessary processing power. Because these gaps between incompatible applications or systems are bridged manually, the process is often slow, as operators only work for a portion of the day, are limited by the speed at which they can input information or commands using a keyboard, mouse, or other interfaces, and are limited by the speed at which they can read information from a screen or other output device. Furthermore, humans are prone to errors when inputting data or commands into a system and reading information from other systems, while computers are not. There is also the possibility that using operators in this way could lead to malicious interference with processes, systems, and data.

[0005] For example, a telecommunications provider might release a new handheld mobile phone that requires the use of incompatible existing applications and a new system. This gap is typically filled by operators, but generally, the demand for such a newly released product cannot be predicted. Therefore, there is a problem of training too many or too few personnel to use the software system. Consequently, a solution is needed that can be quickly scaled to meet this demand and does not require prior detailed knowledge of the demand to bridge the gap between incompatible software systems.

[0006] Such systems typically process large amounts of information, which may be sensitive personal information. This information needs to be handled in a consistent manner that minimizes the number of errors that could arise from humans simply copying information into another system, and it also needs to be handled in a private and secure manner that access is only permitted when absolutely necessary.

[0007] These issues, requiring operators to fill in the gaps in existing software applications lacking the functionality needed to implement new processes, are not limited to back-office departments. For example, the front desk of a hospital or doctor's office is typically a busy environment with many patients making appointments. Receptionists spend a significant amount of time handling routine tasks, such as obtaining detailed information about patients making appointments and entering that information into the application used to register appointments. This process is often slow and prone to inaccuracies due to misreading patient details, and it also consumes time that receptionists would otherwise spend performing other duties.

[0008] Ideally, a self-service terminal would be installed at the front desk of a hospital or doctor's office, allowing patients to input their detailed information into the system for self-registration. This would minimize errors, free up receptionists for other tasks, and reduce wait times. However, providing patients with the same interface as the receptionist might not be appropriate. The application used by the receptionist may have more advanced features that don't confuse patients, or it might have administrative controls and access permissions for information unsuitable for patients using the self-registration terminal. Unless existing receptionist applications can provide access to certain functions and features for new applications running on the self-service terminal, the same problems of long planning cycles, costs, inefficiencies, and inaccuracies caused by changes in back-office processes will persist when developing new applications and software systems to provide the necessary functionality for the aforementioned system. This often results in such projects never even starting. The reader will see many other examples.

[0009] Existing solutions involve using virtual machines as virtual workers, configured to automate these processes by interacting with legacy software. PCT application WO 2015 / 001360 A1 describes such a system; however, these systems require users to decide how work items should be allocated among virtual workers, which is often an inefficient way to determine this. Therefore, a suitable system and method are needed to optimize the allocation of work items among virtual workers. Summary of the Invention

[0010] This invention relates to a system for running automated processes. The system includes a data storage device configured to store instructions for executing automated processes, one or more work queues, and an association between each work queue and one of the automated processes; one or more virtual machines configured to execute the one or more automated processes, wherein the automated processes are defined by instructions stored in a database; and an application server configured to deploy the one or more work queues to the one or more virtual machines. Each virtual machine is configured to, when a work queue is deployed by the application server, retrieve instructions from the database for executing the automated process associated with the deployed work queue, and execute the automated process according to the instructions retrieved from the database.

[0011] Each work queue typically includes one or more work items, and each virtual machine is configured to execute one or more automated processes by processing the work items of the deployed work queues, based on instructions stored in a database. Each work item may include one or more information data objects, and each work queue is typically a logical group of work items.

[0012] The instructions stored in the database can define workflows for executing automated processes on each work item.

[0013] Preferably, the data storage is further configured to store link data that defines links between one or more virtual machines and one or more work queues.

[0014] Each virtual machine can be further configured to communicate with one or more other virtual machines. The virtual machine can be configured to communicate directly with one or more other virtual machines. Alternatively, the virtual machine can be configured to communicate by passing messages to one of an application server or a data storage device, which can be configured to store received messages in a message repository, and each virtual machine can be configured to poll the application server or data storage device to find messages in the message repository. Further alternatively, the virtual machine can be configured to communicate by passing messages to one of an application server or a data storage device, which can be configured to transmit received messages to one or more virtual machines.

[0015] The application server can be configured to deploy a single work queue across multiple virtual machines. The data store is therefore configured to prevent multiple virtual machines from simultaneously accessing a given data object when a virtual machine accesses it, by locking that given data object. Preferably, the lock on the given data object persists throughout the failover event, and the data store is configured to release the lock by confirming that none of the multiple virtual machines are able to process the data object.

[0016] The application server can be configured to calculate the time required to process a work item based on localized environment or performance issues, network connectivity, and the responsiveness of the target virtual machine before the work item is processed. The application server can also be configured to provide an estimated time to process the work queue based on the calculated processing time and the number of virtual machines deployed in the work queue.

[0017] The application server can be configured to monitor the progress of work queues processed by virtual machines. The application server can communicate with one or more virtual machines using a message passing protocol, and each virtual machine can respond to the application server with status information during process execution.

[0018] Application servers can be configured to provide recommendations on allocating work queues to additional virtual machines and / or improving performance and throughput.

[0019] Preferably, the application server is configured to deploy work queues based on the resources available for each virtual machine.

[0020] The application server can be further configured to analyze the execution of automated processes to identify an optimal allocation model based on the speed, efficiency, and / or responsiveness of each virtual machine, and deploy work queues to virtual machines based on the identified optimal allocation model. The application server can also instruct at least one virtual machine to stop processing the current work queue and begin processing a new work queue based on the optimal allocation model.

[0021] Application servers can be configured to use machine learning algorithms to analyze the execution of automated processes in order to improve the allocation of work queues to virtual machines.

[0022] The application server can be configured to deploy work queues to virtual machines based on work item and / or work queue attributes. One or more work items may have a maximum queue time attribute, which defines the maximum duration the work item spends in the work queue before being processed. One or more work queues may have a maximum queue length attribute, which defines the maximum number of work items in the work queue. At least one of the one or more work queues may have a queue completion time attribute, which defines the maximum time required to process the work items used in the work queue.

[0023] The application server can be configured to instruct at least one of one or more virtual machines to stop processing the current work queue and start processing a new work queue based on the attributes of work items and / or work queues.

[0024] The system may further include output devices configured to output information about the current state and / or configuration of the system. Attached Figure Description

[0025] Figure 1 This is a schematic diagram illustrating the implementation of the system according to the present invention;

[0026] Figure 2 Examples of work queues and work items according to the present invention are shown;

[0027] Figure 3 This is a logic diagram of the system of the present invention. Detailed Implementation

[0028] The systems and methods described herein operate within an automated process system that uses virtual machines as digital labor to interact and cooperate with software applications in order to efficiently execute the processes. Such systems are described in more detail in WO 2015 / 001360A1, the disclosure of which is incorporated herein by reference.

[0029] Figure 1 A typical system 100 is depicted according to the present invention. System 100 includes a data storage 101, an application server 102, and one or more virtual machines 103. The data storage 101 stores data related to automation processes, such as work items to be processed and instructions defining the automation processes. The application server 102 coordinates communication between the virtual machines 103 and the data storage 101 and manages the creation, destruction, and operation of the virtual machines 103. The virtual machines 103 are configured to execute automation processes according to instructions received from the application server 102.

[0030] Virtual machine 103 can be organized into one or more resource groups 104a-c. Resource groups 104a-c can be logical groups of virtual machines implemented across one or more hardware devices such as servers, representing available computing power that can be used by a given process or work queue to run virtual machines and thus run an automation process. A particular automation process may have access to a single resource group, or multiple resource groups may be available. Data storage 101 and application server 102 are typically located on dedicated hardware resources such as dedicated servers; however, it will be understood that it is possible to run data storage 101, application server 102, and virtual machine 103 on the same physical hardware.

[0031] Virtual machine 103 is a persistent virtualization instance of a standard client operating system, preferably Microsoft. However, any suitable operating system, such as macOS or Linux distributions, can also be used. Preferably, the virtual machine 103 resides on one or more secure servers that cannot be physically or remotely accessed without proper security permission or authentication. The server or resource hosting the virtual machine preferably runs software such as VMware. Type 1 hypervisors are used; however, it is understood that any suitable arrangement of hardware and software that allows the creation and operation of virtual machines can be used. Virtual machine 103 is generally "headless" in that it does not have a connected monitor or similar output device for displaying graphical output. By running multiple virtual machines 103, multiple automated processes can be executed simultaneously to improve productivity or to serve multiple external users at the same time.

[0032] Automated processes executed by virtual machine 103 typically involve interaction with legacy software applications via a user interface using methods such as screen capture or by using any available API or accessibility interface. The workflow defining the automated process is typically designed by the user on a separate computer and saved and stored on application server 102 or data storage 101.

[0033] exist Figure 1 In the depicted embodiment, data storage 101 communicates bidirectionally with application server 102, and application server 102 communicates bidirectionally with virtual machine 103. Thus, the application server acts as an intermediary device managing the connection between virtual machine 103 and data storage 101. Application server 102 holds a security certificate for the data storage, such as Windows operating system authentication or SQL (Structured Query Language) authentication, and acts as a secure connection proxy for data storage 101, enabling all virtual machines 103 to communicate with application server 102 and allowing application server 102 to securely communicate with data storage 101 on behalf of virtual machines 103. This configuration makes application server 102 the only entity in system 100 that needs to store the data storage security certificate with the correct authentication to access and modify data stored on data storage 101. Because the database server security certificate is stored in only one place in system 200, security is improved compared to the case where the security certificate is stored on each virtual machine 103, and it also provides improved security for multi-user, multi-password systems. Of course, it will be understood that the systems and methods described herein may alternatively include direct communication between virtual machine 103 and data storage 101, or indirect communication via a mechanism different from application processor 102. Furthermore, system 100 may include more than one application processor 102. For example, system 100 may include dedicated application processors for one or more resource groups 104a-c.

[0034] Data storage 101 is preferably an SQL database. Data storage 101 has one or more SQL databases that hold a repository of processes and objects related to automation processes, user certificates, audit information, process logs, and workflow configuration and scheduling information for automation processes. Multiple SQL schemas can be represented on a single data storage 101, allowing different virtual machines 103 to execute different automation processes by referencing different sets of information stored in the databases of data storage 101.

[0035] Data storage 101 can be configured to prevent multiple virtual machines 103 from simultaneously accessing a given data object in the data storage by locking the data object when it is accessed by a virtual machine. When a virtual machine 103 accesses a data object in data storage 101, it also issues a lock request. Alternatively, data storage 101 can automatically lock the data object when it is accessed. Record locks in data storage 101 persist throughout a failover event such as a power failure. Data storage 101 releases record locks by confirming that none of the multiple virtual machines 103 can process data in the database without re-requesting a lock. A virtual machine 103 can notify data storage 101 that locking the data object is no longer necessary, and data storage 101 subsequently removes the lock from the data object, allowing it to be accessed again by other virtual machines 103.

[0036] System 100 optimizes the execution of automated processes across multiple virtual machines 103 by utilizing work queues. In existing systems, virtual machines 103 poll the work queues to process work items. In the system of this invention, the work queues are deployed to the virtual machines 103 by an application server 102, which uses target parameters and queue configuration information to determine how to achieve the target. This will refer to... Figure 2 To describe in more detail.

[0037] Figure 2 A typical work queue 201 is illustrated, which is an ordered list of one or more work items 202a-c provided for processing by virtual machine 103. Each work item 202a-c includes one or more information data objects such as a unique identifier for the work item, a case (CASE) ID, and other contextual information. The specific type of information data objects for each work item 202a-c depends on their associated context and automation process. For example, in the process of activating a SIM card for a mobile phone network, work item 202a-c may include the customer name, phone number, ICCID, IMSI, and authentication key.

[0038] Work queues are typically stored in data storage 101, but it is understood that work queue 201 can be stored in any suitable location that communicates with application server 102. The information data object possessed by each work item 202a-c can be stored in plain text form on data storage 101, or work queue 201 can be configured to be automatically encrypted when the information data object is saved to the queue and automatically decrypted when it is retrieved from the queue.

[0039] Work items 202a-c can be filled into work queue 201 manually or via feeder process 205. Feeder process 205 can obtain data from any suitable source such as email 206 or spreadsheet 207, output work item 202a in an appropriate format, and add work item 202a to work queue 201. Work queue 201 can operate on a first-in, first-out (FIFO) basis, allowing work item 202c to be assigned to virtual machine 208 for processing.

[0040] In addition to having informational data objects used as part of an automation process, work item 202a-c may have metadata used to manage the automation process (see [reference]). Figure 3 (For more detailed explanation). For example, work item 202a-c may have a maximum queue time attribute that defines a maximum duration, which is the time work item 202a-c spends in work queue 201 before being processed. Work queue 201 itself may have a maximum queue length attribute that defines the maximum number of work items 202a-c in work queue 201.

[0041] Reference Figure 3 The method by which the system of the present invention processes work queues is described in more detail. System 300 includes a work queue 301, typically located in data storage 101, and includes work items 302. System 300 also includes an activity queue controller 303 located in and executed by application server 102. Activity queue controller 303 is associated with work queue 301. Activity queue controller 303 manages resources 308, such as resource group 306, by creating and destroying virtual machines 307 on resources 308 and deploying resources 308 and virtual machines 307 to their associated work queue 301. Activity queue controller 303 also monitors resources 308 and virtual machines 307 and queries database storage 101 to obtain statistics related to work queue 301.

[0042] Work queue 301 can be associated with additional parameter 304, which determines how the activity queue controller 303 manages the resources of resource group 306. Figure 3In the illustrated example, the "target resource" parameter 304 defines the target number of resources 308 for which the activity queue controller should deploy work queue 301. This parameter 304 can be changed by the system user to add or remove resources for queue work, i.e., to create or remove virtual machines 307 on resource 308, in order to, for example, speed up processes or make time-insensitive processes use resources more efficiently.

[0043] The Activity Queue Manager 303 can provide feedback 305 to system users. For example, "Active Resources" indicates the number of virtual machines 307 currently processing work queue 301. "Available Resources" indicates the amount of resources 308 available to run other virtual machines. "Remaining Time" provides a total estimate of the remaining time to execute all items 302 in work queue 301. The estimated time required to process a single work item can be calculated based on localized environment or performance issues, network connectivity, and the responsiveness of the target virtual machine. The total estimated remaining time can be calculated by multiplying the average execution time of work items 302 in work queue 301 by the number of remaining items 302 in queue 302. "Completion Time" indicates the expected time when work queue 301 will be completed, which is the current time plus "Remaining Time". Additional or alternative indications of the status and progress of work queue 301 can be provided, such as whether queue 301 is running or paused, elapsed time, the number of completed work items 302 in work queue 301, the number of pending work items 302, and / or the total number of cases.

[0044] The activity queue manager 303 is also responsible for creating and destroying virtual machines in resource group 306. In order to execute a given automated process, the activity queue controller 306 searches for available resource 308 in resource group 306 and creates virtual machines on resource 308.

[0045] When the activity queue controller 303 determines that a new virtual machine needs to be created, for example, upon reaching a new "target resource," the activity queue controller creates and starts the new virtual machine on an available resource 308 in the resource group 306 of the queue 301 to which it is deployed. The activity queue controller 303 first creates the virtual machine on the least busy resource 308. For example, if there are four available resources 308 in group 306 and two of them are already running virtual machines, the activity queue controller 303 will create the virtual machine on one of the resources that is not currently running any virtual machines. If any virtual machine fails to be created or started for any reason, it will be retried on another resource.

[0046] If the active queue controller 303 needs to destroy the virtual machine currently processing the work queue 301, the active queue controller 303 can send a stop request to the virtual machine 307, so that the virtual machine 307 stops processing items in the work queue as soon as it finishes processing the current work item.

[0047] Virtual machine 307 retrieves work items 302 from work queue 101 stored on data storage 101 via application server 102. When virtual machine 307 finishes processing each work item 302, it retrieves a new work item 302 from work queue 301 stored on data storage 101 via application server 102, until work queue 101 is complete or until the active queue controller 303 instructs virtual machine 307 to stop processing work queue 301. Once virtual machine 307 is instructed to stop processing a queue 301, it can be instructed to start processing another work queue, and virtual machine 307 itself pulls work items from the new work queue through communication between application server 102 and data storage 101.

[0048] Running resources 308 and virtual machines 307 are configured to communicate with other resources 308 and other virtual machines 307. Multiple virtual machines 307 can communicate directly with each other by sending and receiving direct messages. Alternatively, virtual machines and resources can send and receive messages to each other via application server 102. Application server 102 can simply redirect its received messages to the appropriate destination virtual machine 307, or application server 102 can store the received messages in a repository that can be polled by virtual machines 307.

[0049] Communication between virtual machines is particularly useful in two scenarios. First, one of virtual machines 307 can be used as a management console, allowing the control terminal to display the status and availability (or unavailability) of resource 308. The control terminal can be accessed by system users to manually control the configuration of work queues to resources, receive suggestions from the activity queue controller 303 (described in more detail below), and / or view the current status of virtual machines 307, resource 308, and work queue 301.

[0050] The second approach, as described above, is that, as an alternative to resource groups directly managed by application server 102, one of the virtual machines 307 can act as the "head" of resource group 306 and communicate with other virtual machines 307 and resources 308 in the resource group to determine which virtual machines 307 and resources 308 are available for processing, and pass instructions to other members of the resource group to start and stop processing received from application server 102.

[0051] The activity queue controller 303 is configured to communicate asynchronously or synchronously with the virtual machine 307 during the processing of work item 302 in order to monitor the progress of the automation process. Therefore, in addition to providing statistics 305 to the user, the activity queue controller 303 can offer suggestions to the user regarding deploying work queue 301 to additional resources, i.e., creating a new virtual machine 307 on resource 308, and other performance improvements.

[0052] To provide these recommendations, the Activity Queue Controller 303 can analyze the completion time and performance metrics of virtual machines 307 in the infrastructure using completed work items that store the resource ID of virtual machine 307, the ID of the executing process, the date and time of execution, and the duration of the execution process. Different virtual machines 307 can operate at different rates due to the capabilities of the underlying hardware, the applications installed on the machines (including other virtual machines), and the distance between these applications and the machines themselves and their respective application servers. The Activity Queue Controller 303 uses this data to calculate the time of day for a given process, the overall composition of the work queue processing to be completed, and which resource 308 or virtual machine 307 is optimally placed to execute work at the optimal time.

[0053] As part of the monitoring of virtual machines 307 and resources 308, the activity queue controller 303 analyzes the execution of automated processes to identify the optimal allocation model based on speed, effectiveness, and / or the responsiveness of each virtual machine 307 and resource 308.

[0054] Each work queue maintains historical data on work items 302 that have been processed, providing a high-level view. Each executed work item 302 also maintains a comprehensive log in data storage 101 detailing the processing steps taken to process the work item; this can vary depending on the scenario (CASE). As described above, the activity queue controller 303 can use machine learning techniques to compose the work queue 301 and the resource information collected by the activity queue controller 303, combining the data of work items 302 with detailed log files to build a model that correlates work queue data and log stages to determine which work items require what specific time period to process. For example, a work item related to a current account with three account holders might take twice as long to process as a savings account with one account holder. As the system processes the work queues according to the current optimal allocation model, the optimal allocation model is iteratively improved based on new data generated by the system to refine the recommendations provided by the model. In addition to process and resource information, this information can only be collected over time using the depth of data accumulated in data storage 101 to learn patterns in the data and processes reflected in completion times. The results of this analysis can then be used to generate an optimal allocation model that describes the most efficient way that work items 302 in work queue 301 should be allocated between available resources 308 and virtual machines 307.

[0055] The activity queue controller 303, based on an optimal allocation model, can subsequently provide one or more suggestions to the user regarding how to allocate work item 302, or can automatically deploy work queue 301 and work item 302 to the optimal resource 308. When allocating work item 302 to individual virtual machines 307, the activity queue controller can consider the maximum queue time of a single work item 302 and the maximum queue length attribute of work queue 301.

[0056] It should be recognized that this description is merely illustrative; substitutions and modifications may be made to the described embodiments without departing from the scope of the invention as defined by the claims.

Claims

1. A system for running automated processes, comprising: -Configured to store instructions for executing the automation process, one or more work queues, and a data storage device associated with each work queue and one of the automation processes; – One or more virtual machines configured to execute one or more automated processes, wherein the automated processes are defined by instructions stored in a database; and - Configure to deploy one or more work queues to an application server that runs one or more virtual machines. Each virtual machine is configured such that when a work queue is deployed by the application server... – Retrieve instructions from the database for executing the automation process associated with the deployed work queue, and – Execute the automated process according to instructions retrieved from the database. The application server is configured to analyze the execution of automated processes to identify the optimal distribution model based on the speed, success, and / or responsiveness of each virtual machine. The application server is configured to use machine learning algorithms to analyze the execution of automated processes in order to improve the distribution of virtual machine work queues.

2. The system of claim 1, wherein each work queue includes one or more work items, and each virtual machine is configured to execute one or more automated processes by processing the work items of the deployed work queue according to instructions stored in a database.

3. The system according to claim 2, wherein each work item includes one or more information data objects.

4. The system according to any one of claims 1-3, wherein each work queue is a logically grouped set of work items.

5. The system of claim 1, wherein the instructions stored in the database define a workflow for executing the automation process on each work item.

6. The system of claim 1, wherein the data storage is further configured to store link data defining links between one or more virtual machines and one or more work queues.

7. The system of claim 1, wherein each virtual machine is further configured to communicate with one or more other virtual machines.

8. The system of claim 7, wherein the virtual machine is configured to communicate directly with one or more other virtual machines.

9. The system of claim 7, wherein the virtual machine is configured to communicate by passing messages to one of an application server or a data storage, wherein the application server or data storage is configured to store received messages in a message repository, and wherein each virtual machine is configured to poll the application server or data storage to look up messages in the message repository.

10. The system of claim 7, wherein the virtual machine is configured to communicate by passing messages to one of the application server or data storage, and wherein the application server or data storage is configured to transmit received messages to one or more of the virtual machines.

11. The system of claim 1, wherein the application server is configured to deploy a single work queue to multiple virtual machines.

12. The system of claim 10, wherein the data storage is configured to prevent multiple virtual machines from simultaneously accessing a given data object in the data storage by locking the given data object when the virtual machine accesses it.

13. The system of claim 12, wherein the lock on a given data object persists throughout the entire failover event.

14. The system of claim 13, wherein the data storage is configured to unlock the lock by confirming that none of the plurality of virtual machines is capable of processing the data object.

15. The system of claim 1, wherein the application server is configured to calculate the time required to process a work item before the work item is processed.

16. The system of claim 15, wherein the application server is configured to calculate the time required to process a work item based on localized environment or performance issues, network connectivity, and the responsiveness of the target virtual machine.

17. The system of claim 15 or 16, wherein the application server is configured to provide an estimated time for processing the work queue based on the calculated duration of processing work items and the number of virtual machines on which the work queue is deployed.

18. The system of claim 15 or 16, wherein the application server is configured to monitor the progress of the work queues processed by the virtual machine.

19. The system of claim 18, wherein the application server is configured to communicate with one or more virtual machines using a message protocol, wherein each virtual machine is configured to respond to the application server with status information during process execution.

20. The system of claim 15 or 16, wherein the application server is configured to provide recommendations on allocating work queues to additional virtual machines and / or on improving performance and throughput.

21. The system of claim 1, wherein the application server is configured to allocate work queues based on the resources available to each virtual machine.

22. The system of claim 1, wherein the application server is configured to allocate work queues to virtual machines based on the identified optimal distribution model.

23. The system of claim 1 or 22, wherein the application server is configured to instruct at least one virtual machine to stop processing the current work queue and begin processing a new work queue based on an optimal distribution model.

24. The system of claim 2, wherein the application server is configured to assign work queues to virtual machines based on the attributes of work items and / or work queues.

25. The system of claim 24, wherein at least one of one or more work items has a maximum queue time attribute that defines a maximum duration, the maximum duration being the time the work item is in the work queue before being processed.

26. The system of claim 24 or 25, wherein at least one of the one or more work queues has a maximum queue length attribute that defines the maximum number of work items in the work queue.

27. The system of claim 24 or 25, wherein at least one of one or more work queues has a queue completion time attribute, the completion time attribute defining the maximum time for processing work items used in the work queue.

28. The system of claim 24 or 25, wherein the application server is configured to instruct at least one of one or more virtual machines to stop processing the current work queue and begin processing a new work queue based on the attributes of the work items and / or the work queue.

29. The system of claim 1, wherein the system further comprises an output device configured to output information about the current state and / or configuration of the system.

Images