A method and system for collaborative management of RPA robot swarms

Abstract

This application provides a collaborative management method and system for RPA robot clusters, relating to the technical field of RPA robot management. The method includes: if a task execution request exists, parsing and generating a target task and performing task judgment; if not, re-judging after a preset interval; if the target task contains multiple subtasks, adding tags to the subtasks and matching them with the target RPA robot cluster; otherwise, adding tags to the task and matching it; selecting a target robot using a weighted round-robin algorithm based on the running data of each RPA robot in the target RPA robot cluster, and sending the task or subtask to the target robot. This application enables more refined task division and matching, improving the efficiency and accuracy of task execution, while fully utilizing the resources of the RPA robot cluster.

Description

Technical Field

[0001] This application relates to the technical field of RPA robot management, and in particular to a method and system for collaborative management of RPA robot clusters. Background Technology

[0002] With the development of Robotic Process Automation (RPA) technology, RPA robot clusters of over 100 units have become standard for digital transformation in large organizations. In scenarios with massive concurrent tasks, robot clusters need to dynamically coordinate computing resources with task requirements. However, traditional centralized task scheduling systems, due to their rigid architecture, are unable to adapt to complex needs such as fragmented business processes and fluctuating task priorities, leading to increasingly prominent scalability bottlenecks in RPA systems.

[0003] Chinese invention patent application CN113467383A provides a task management method, device and storage medium for RPA robots. The RPA controller in this patent matches the most suitable RPA robot or RPA robot group in an idle state to perform RPA tasks according to a preset matching rule. The preset matching rule defines the matching degree calculation method between RPA task characteristics and different robot characteristics.

[0004] However, the aforementioned patent allocates the entire task as a whole without taking into account the multiple subtasks that may exist within the task. This coarse-grained task division method may result in some subtasks being executed by RPA robots that are not the most suitable, thereby affecting the overall execution efficiency and accuracy of the task. Summary of the Invention

[0005] In order to achieve more refined task division and matching, improve the efficiency and accuracy of task execution, and make full use of the resources of RPA robot clusters, this application provides an RPA robot cluster collaborative management method and system.

[0006] Firstly, this application provides an RPA robot cluster collaborative management method, which adopts the following technical solution:

[0007] A method for collaborative management of RPA robot clusters includes the following steps:

[0008] Request determination: Determine if a task execution request exists. If yes, parse the task information in the task execution request, generate the target task based on the task information, and execute the task determination steps. If no, repeat this step after a preset interval.

[0009] Task Judgment: Determine whether the target task contains multiple subtasks. If so, add a subtask tag to each subtask and match the target RPA robot cluster based on each subtask tag. If not, add a task tag to the target task and match the target RPA robot cluster based on the task tag.

[0010] Task assignment: Sequentially obtain the running data of each RPA robot in the target RPA robot cluster, select the target robot in the target RPA robot cluster based on the running data using a weighted round-robin algorithm, and send the target task or subtask to the target robot.

[0011] This application first determines whether a task execution request exists. If a request exists, it proceeds to the next processing step; otherwise, it re-determines after a preset interval. This approach not only responds to task requests promptly but also reduces resource consumption caused by frequent determinations. Subsequently, this application adopts different processing methods (adding subtask tags or task tags) depending on whether the task contains multiple subtasks. It then matches the target RPA robot cluster based on the subtask tags or task tags. This categorized processing allows for more accurate task allocation to appropriate RPA robot clusters, improving the targeting and efficiency of task processing and facilitating better resource utilization.

[0012] Subsequently, this application sequentially acquires the operational data of each RPA robot in the target RPA robot cluster and employs a weighted round-robin algorithm to select the target robot. This comprehensively considers the operational status of the RPA robots to achieve a more reasonable task allocation. The weighted round-robin algorithm can weight the RPA robots based on factors such as performance and load, ensuring that RPA robots with better performance and lower load have a higher probability of being selected. This improves the overall task execution efficiency and quality, reduces the problem of load imbalance in the RPA robot cluster, and sends the target task or subtask to the target robot, ensuring that the target task is accurately communicated and executed.

[0013] Optionally, the step of issuing the task further includes:

[0014] Set the priority of each subtask tag and send the subtasks to the corresponding target robot in descending order of priority.

[0015] This application, by setting subtask priorities, prioritizes important subtasks that have a significant impact on the overall task and sends them to the target robot for execution. Sending subtasks in priority order ensures that critical business processes are completed first, minimizing delays caused by low-priority tasks consuming resources and improving the timeliness and accuracy of business processing. Some tasks have strict sequential logical relationships, with subsequent subtasks depending on the results of preceding subtasks. Setting priorities ensures that this logical order is followed, allowing tasks to proceed step-by-step according to the correct process and reducing errors and repetitive work caused by disordered sequencing.

[0016] The performance and load of individual RPA robots in a target RPA robot cluster may vary. Sending high-priority subtasks to high-performance, low-load RPA robots can fully leverage their strengths, quickly complete critical tasks, and improve overall resource utilization efficiency. Sending subtasks in priority order can prevent low-priority tasks from occupying RPA robot resources for extended periods, thus preventing high-priority tasks from executing in a timely manner.

[0017] Optionally, subtasks are sent to the corresponding target robots in descending order of priority, including:

[0018] Send the i-th priority subtask to the target robot corresponding to the i-th priority subtask, obtain the processing result of the target robot, and store the processing result in the database;

[0019] Before sending the (i+1)th priority subtask to the target robot corresponding to the (i+1)th priority subtask, the processing result is extracted from the database, the processing result is injected into the task information to obtain new task information, and a new (i+1)th priority subtask is generated based on the new task information. The new (i+1)th priority subtask is then sent to the target robot corresponding to the (i+1)th priority subtask.

[0020] This application stores the processing result of the i-th priority subtask in the database and extracts and injects it into the new task information before sending the (i+1)-th priority subtask, enabling data transfer between subtasks of different priorities. In many business scenarios, the execution of subsequent subtasks depends on the results of previous subtasks. This application strictly follows the business logic order, ensuring that each subtask can be performed on the basis of the correct completion of the preceding task, thus maximizing the coherence and correctness of the entire task flow.

[0021] Optionally, after obtaining the processing result of the target robot, the method further includes:

[0022] The processing results are reviewed according to the preset review rules and expected results. If the review fails, the execution log and screen recording file data of the i-th priority subtask are obtained, the execution log and screen recording file data are analyzed, and the analysis results are obtained and fed back.

[0023] Based on the analysis results, a correction workflow is set up, a correction robot is designed and correction tasks are generated based on the correction workflow, the correction tasks are assigned to the correction robot, and the correction results are obtained. The correction results are used as new processing results and stored in the database.

[0024] This application reviews the processing results based on preset review rules and expected outcomes, enabling timely detection of errors, deviations, or non-compliance with requirements. When a review fails, execution logs and screen recordings are retrieved and analyzed to pinpoint the exact steps and causes of the problem. Execution logs record detailed steps and time information of task execution, while screen recordings visually demonstrate the operations during task execution. By comprehensively analyzing these two types of data, errors can be quickly located. Subsequently, this application sets up a correction workflow based on the analysis results, and designs a correction robot and generates correction tasks based on this workflow, achieving automatic problem correction. This allows for rapid response to failed reviews in subsequent review processes, reducing the time and cost of manual intervention and improving the system's fault tolerance and repair efficiency.

[0025] Optionally, in the step of issuing the task, the method further includes:

[0026] The historical approval count and total approval count of each RPA robot are obtained through a heartbeat mechanism. The historical approval rate is calculated based on the historical approval count and total approval count. The historical approval rate corresponding to each RPA robot is used as an approval factor. The approval factor is introduced into the weighted round-robin algorithm to obtain a dynamic weighted round-robin algorithm. The dynamic weighted round-robin algorithm is used as the new weighted round-robin algorithm.

[0027] This application uses a heartbeat mechanism to obtain the historical approval count and total approval count for each RPA robot, and calculates the historical approval rate, which can intuitively reflect the accuracy and reliability of each RPA robot in past task processing. Subsequently, this application sets an approval factor based on the historical approval rate and introduces the approval factor into the weighted round-robin algorithm. This allows RPA robots with high approval rates to receive greater weight in task allocation, enabling more rational utilization of RPA robot capabilities and assigning tasks to RPA robots more likely to complete tasks with high quality. Different types of tasks may have different requirements for RPA robots. Some complex and critical tasks need to be handled by RPA robots with high approval rates and strong stability to improve task accuracy and reliability; while some simple and routine tasks can be assigned to RPA robots with relatively lower approval rates but still capable of completing the task. The dynamic weighted round-robin algorithm can flexibly adjust the task allocation strategy according to the characteristics of the task and the historical performance of the RPA robot, better adapting to the needs of different tasks.

[0028] Optionally, the calculation of the historical approval rate based on the number of historical approvals and the total number of approvals includes:

[0029] Obtain the timestamps of the historical number of approved reviews and the total number of reviews. Based on the timestamps of the historical number of approved reviews and / or the total number of reviews, divide the historical number of approved reviews and / or the total number of reviews into multiple sub-approval numbers and / or sub-approval numbers according to a preset time window. Calculate the sub-approval rate for each preset time window based on the sub-approval numbers and sub-approval numbers.

[0030] The timestamp of the number of times a sub-approval is passed is used as the timestamp of the sub-approval pass rate. A time decay function is set based on the difference between the timestamp of the sub-approval pass rate and the current timestamp. The sum of the product of the sub-approval pass rate and the function value of the time decay function is normalized and used as the historical approval rate.

[0031] This application divides the historical approval count and total approval count into multiple sub-approval counts and sub-approval counts according to preset time windows, and calculates the sub-approval approval rate for each time window. This allows for a more detailed observation of the RPA robot's task processing capabilities changing over different time periods. For example, during the day, the RPA robot may perform well in the morning when network conditions are good and system load is low, resulting in a high approval rate; while in the afternoon, due to network congestion or limited system resources, the approval rate may decrease. By dividing the time windows, this trend can be clearly seen, thus providing a more accurate understanding of the RPA robot's recent performance.

[0032] Subsequently, this application sets a time decay function based on the difference between the timestamp of the sub-approval pass rate and the current timestamp, and normalizes the sum of the product of the sub-approval pass rate and the function value of the time decay function to obtain the historical approval pass rate. This makes the recent sub-approval pass rate have a greater impact on the final historical approval pass rate, while the impact of earlier sub-approval pass rates gradually decreases.

[0033] Using historical approval rates that take into account time factors as a reference during task allocation allows for a greater allocation of tasks to RPA robots that have recently performed well and are in good standing. Compared to traditional task allocation methods based on overall historical approval rates, this application better adapts to the dynamic changes of RPA robots, improving the accuracy and rationality of task allocation.

[0034] After upgrading, maintaining, or optimizing an RPA robot, the effectiveness of the improvements can be evaluated by observing changes in the sub-approval pass rate across different time windows. If the improvements are effective, the recent sub-approval pass rate should show a significant increase, and the historical pass rate should also increase accordingly. This provides decision-makers with quantifiable evaluation metrics, helping them make more informed decisions.

[0035] Optionally, before calculating the sub-approval pass rate for each preset time window based on the number of sub-approvals and the number of sub-approvals, the method further includes: if the total number of approvals within a preset time window is zero, then setting the sub-approval pass rate corresponding to the total number of approvals within the preset time window to zero.

[0036] If the total number of reviews within a preset time window is zero, a division-by-zero error would occur using conventional calculation methods, leading to program crashes or infinity-based results. This application pre-sets the sub-review pass rate to zero at this time, avoiding calculation errors, ensuring smooth calculation, and improving the stability of the results.

[0037] A total of zero reviews can be considered a special case of missing data. Setting the corresponding sub-review pass rate to zero is a reasonable and logical approach. Since no review operations were performed within this time window, there were naturally no approved reviews. Therefore, setting the sub-review pass rate to zero accurately reflects the review status of the RPA robot during that period, rather than providing incorrect or inexplicable calculation results.

[0038] The calculation of the historical approval rate involves data from multiple preset time windows. If the case where the total number of reviews is zero is not handled, the final historical approval rate calculation will be inaccurate and unreliable due to inconsistencies in data format and meaning across different time windows (some time windows have normal approval rate calculations, while others have division-by-zero errors or outliers). Setting the sub-approval rate to zero when the total number of reviews is zero ensures that the data from all time windows has a consistent calculation logic and format, guaranteeing data consistency and continuity.

[0039] In complex real-world operating environments, various anomalies are inevitable, such as system failures and network interruptions, which may cause RPA robots to be unable to receive or process audit tasks for certain periods, resulting in a total audit count of zero. This application enhances the fault tolerance for such anomalies by pre-setting processing rules, enabling the robot to continue operating normally when problems occur, rather than crashing or producing incorrect results due to calculation errors.

[0040] Optionally, before performing the task distribution step, the method further includes:

[0041] Determine if there are any idle RPA robots in the target RPA robot cluster. If so, remove the busy RPA robots and execute the task distribution step. If not, repeat this step after a preset interval.

[0042] This application determines whether there are idle RPA robots in the target RPA robot cluster, and assigns tasks to RPA robots with processing capacity. If idle RPA robots exist, it means they can immediately start processing tasks. Issuing tasks at this time ensures that tasks start executing promptly, minimizing the risk of assigning tasks to busy RPA robots and causing task queuing, thus improving the accuracy and rationality of task allocation.

[0043] When there are no idle RPA robots in the target RPA robot cluster, this application will re-execute the judgment step after a preset interval. This dynamic detection mechanism allows this application to flexibly adjust the task allocation strategy according to the real-time status changes of the RPA robots. As time goes by, previously busy RPA robots may complete their tasks and become idle. At this time, re-judging can promptly allocate tasks to these newly idle RPA robots, thereby improving the utilization rate of the entire system resources.

[0044] By continuously judging and adjusting task allocation, the load of each RPA robot in the cluster can be more balanced, avoiding situations where some RPA robots run at high load for a long time while others are at low load or idle. Balanced load helps improve overall stability and reliability.

[0045] Optionally, when there are no idle RPA robots in the target RPA robot cluster, the method further includes: constructing a task queue and placing the target task at the tail of the task queue.

[0046] When no idle RPA robots are available, target tasks will not pile up or be lost in an disordered manner, but will wait for processing in a queue according to a certain order. The above scheme helps to clearly grasp the execution order and status of tasks, facilitating subsequent task tracking and management. This application, by placing tasks in a pending task queue instead of simply discarding them or waiting for the RPA robot to become idle and re-initiate the task request, can make full use of the system's computing and storage resources. The queue can store task-related information and process it only when an RPA robot becomes available, reducing resource waste caused by tasks not being processed in a timely manner due to busy RPA robots.

[0047] The pending task queue can rationally allocate tasks based on the processing capacity and current load of the RPA robots. When an idle RPA robot becomes available, a task can be retrieved from the queue and assigned to it, thus ensuring a relatively balanced load across the RPA robots. This reduces situations where some RPA robots are overworked while others are idle, improving the resource utilization efficiency of the entire RPA robot cluster.

[0048] Secondly, this application provides an RPA robot cluster collaborative management system, which adopts the following technical solution:

[0049] An RPA robot swarm collaborative management system includes: a memory and a processor.

[0050] The memory contains a computer-readable storage medium;

[0051] When the processor processes a computer program stored on the computer-readable storage medium, it implements the method as described in the first aspect.

[0052] In summary, this application includes at least one of the following beneficial technical effects:

[0053] 1. This application first determines whether a task execution request exists. If a request exists, it proceeds to the next processing step; otherwise, it re-determines after a preset interval. This approach not only responds to task requests promptly but also reduces resource consumption caused by frequent determinations. Subsequently, this application adopts different processing methods (adding subtask tags or task tags) depending on whether the task contains multiple subtasks. It then matches the target RPA robot cluster based on the subtask tags or task tags. This categorized processing allows for more accurate allocation of tasks to appropriate RPA robot clusters, improving the targeting and efficiency of task processing and facilitating better resource utilization.

[0054] 2. This application sequentially acquires the operational data of each RPA robot in the target RPA robot cluster and employs a weighted round-robin algorithm to select the target robot. This comprehensively considers the operational status of the RPA robots to achieve a more reasonable task allocation. The weighted round-robin algorithm can weight the RPA robots based on factors such as performance and load, ensuring that robots with better performance and lower load have a higher probability of being selected. This improves the overall task execution efficiency and quality, reduces the problem of load imbalance in the RPA robot cluster, and ensures that the target task or sub-task is accurately communicated and executed when sent to the target robot. Attached Figure Description

[0055] Figure 1 This is a flowchart of Embodiment 1 of this application;

[0056] Figure 2 This is a flowchart of the process from S21 obtaining the processing result to S23 sending the task in Embodiment 2 of this application. Detailed Implementation

[0057] The following combination Figure 1 and Figure 2 This application will be described in further detail.

[0058] The following are definitions of terms used in this application:

[0059] RPA executor: also known as RPA robot, is an executable program installed on the worker's computer. RPA robot is software used to replace humans in performing target tasks. The tasks that each RPA executor can perform are pre-configured through permissions.

[0060] RPA Controller: This is a B / S system deployed on a server. All RPA robots installed on staff computers need to be registered on the RPA Controller. All target tasks are distributed and scheduled through the RPA Controller. The RPA Controller's interface is mainly for maintenance personnel to log in and use via a browser.

[0061] RPA Designer: Deployed on a standalone computer by operations and maintenance personnel, it is used to configure automated processes in a drag-and-drop and low-code manner, and then publish the automated processes to the RPA controller after configuration.

[0062] The Social Insurance Digital Employee Platform is a browser-based system deployed on a server. It is accessible to employees via a browser and serves as a platform for managing their automated tasks, allowing them to view the progress of their assigned tasks.

[0063] Example 1: This example discloses an RPA robot cluster collaborative management method, referring to... Figure 1 This embodiment includes: S11 request determination, S12 task determination, and S13 task issuance. The request determination checks whether a task execution request exists. If it exists, the target task is parsed, generated, and the task determination steps are executed. If it does not exist, the determination is repeated after a preset interval. If the target task contains multiple subtasks, tags are added to the subtasks and matched against the target RPA robot cluster; otherwise, tags are added to the task and matched. A weighted round-robin algorithm is used to select the target robot based on the running data of each robot in the target RPA robot cluster, and the task or subtask is sent to the target robot. The process is as follows:

[0064] S11 Request Decision: Staff log in to the social insurance digital employee platform, select the target automation process configured by the RPA designer, and trigger the execution instruction. Based on the execution instruction, a task execution request is generated. The background automatically calls the RPA controller to schedule tasks according to the task execution request. During this process, the RPA controller continuously listens to the task request queue (such as Kafka, RabbitMQ) using a polling strategy. If the task request queue is not empty, it means that there is a task execution request; if the queue is empty, it means that there is no task execution request.

[0065] After receiving a task execution request from the Social Insurance Digital Employee Platform, the RPA controller enters the task parsing process, which is as follows:

[0066] Extract task information (such as JSON / XML format) from the task execution request. The task information includes task type (such as data cleaning, report generation), priority (marked according to execution order), deadline, input parameters (such as database connection string, file path), etc. After extracting the task information, perform task validity verification (such as required fields, parameter range).

[0067] The parsed task information is encapsulated into a target task (such as a Task class), which includes the RPA robot's unique ID, status (to be executed), sub tasks field, and the dependency relationship between sub tasks fields.

[0068] This embodiment uses an asynchronous framework (such as Celery in Python or Quartz in Java) to manage the queue containing the target task.

[0069] When there are no task execution requests, the thread sleeps for a preset time (e.g., 500ms) and then listens again to minimize CPU idling.

[0070] S12 Task Decision: Determines whether the subtasks field in the task information of the target task is not empty.

[0071] If so, it means that the target task contains multiple subtasks. Then, add a subtask label to each subtask (such as {"type": "data_processing", "priority": "high"}).

[0072] If not, it means that the target task does not contain subtasks. In this case, simply add a task tag to the target task (such as {"type": "report_generation"}).

[0073] The subtask tag / task tag refers to the same tag as the skill tag of the RPA robot. For example, if an RPA robot is used to perform the preliminary review of the calculation of residents' pension benefits, then the skill tag of the RPA robot is set to the preliminary review of the calculation of residents' pension benefits, and the subtask tag / task tag can be the preliminary review of the calculation of residents' pension benefits.

[0074] Use Redis to store the skill tags and status of RPA robots, and maintain the skill tag library of RPA robots regularly (e.g., robot A → ["data_processing", "ETL"]).

[0075] Inverted index algorithms are used to quickly find target RPA robot clusters whose skill tags and statuses match subtask tags or task tags. For example, you can query the target RPA robot cluster corresponding to the data_processing task tag.

[0076] S13 issues a task to sequentially obtain the running data of each RPA robot in the target RPA robot cluster. The running data includes: CPU utilization, memory utilization, and current task queue length.

[0077] Based on operational data, a weighted round-robin algorithm is used to select target robots from the target RPA robot cluster. The process is as follows:

[0078] Each RPA robot has a base score based on its hardware configuration (number of CPU cores, memory capacity). The base score is calculated as f(number of CPU cores, memory capacity). For example, if an RPA robot has 8 cores and 32GB of memory...

[0079] CPU core count: 1 point per core (e.g., 8 cores → 8 points)

[0080] Memory capacity: 0.5 cents per GB (e.g., 32GB → 16 cents)

[0081] The base score for this RPA robot is 24 points.

[0082] The dynamic score for each RPA robot is configured based on the operational data. First, the load index is calculated based on the operational data. The load index is calculated as follows:

[0083] Load index = CPU utilization weight × CPU utilization + memory utilization weight × memory utilization + task queue length weight × (task queue length / number of tasks the queue can hold).

[0084] Among them, the weight of CPU utilization rate + the weight of memory utilization rate + the weight of task queue length = 1.

[0085] To reduce the base score of RPA robots with high load indices, in this embodiment, a dynamic score is obtained after reducing the base score of high-load RPA robots. The dynamic score is calculated as follows:

[0086] Dynamic score = base score × (1 - load index).

[0087] The dynamic score of a faulty RPA robot is set to 0. After the fault is recovered, the dynamic score of the RPA robot is recalculated.

[0088] Calculate the dynamic score of each RPA robot in the target RPA robot cluster, sort them by dynamic score, and select the RPA robot with the highest dynamic score as the target robot. If the dynamic scores are the same, randomly select any RPA robot as the target robot.

[0089] Subtasks are issued sequentially or in parallel. If the dependency relationship between subtasks is shown in the subtasks field, the subtasks are issued in the order of dependency. If the dependency relationship between subtasks is empty, that is, there is no dependency relationship between the subtasks, the subtasks are issued in parallel.

[0090] If the RPA robot does not respond, trigger the retry mechanism (up to 3 times) or switch to a backup RPA robot.

[0091] By adopting the above scheme, this embodiment comprehensively considers the hardware conditions of RPA robots (such as the number of CPU cores and memory capacity) and operating data (such as CPU utilization, memory utilization, and current task queue length), calculates the dynamic score of each RPA robot, and selects the RPA robot with the highest dynamic score as the target robot. This embodiment can reasonably allocate tasks according to the actual load of RPA robots, try to avoid assigning tasks to RPA robots with excessive load, and improve the overall utilization of cluster resources.

[0092] Example 2: This example differs from Example 1 in that, in step S13, the task issuance also includes:

[0093] The priority of each subtask tag is generated based on the dependency relationship between the subtasks fields, and priority is added to each subtask tag. For example, the process of processing compensation calculation requires four subtasks: acceptance, preliminary review, secondary review, and final review. These need to be executed in sequence by RPA robots with different permissions. Therefore, the process of processing compensation calculation includes four subtask tags: acceptance, preliminary review, secondary review, and final review. The priority of these four subtask tags from high to low is: acceptance, preliminary review, secondary review, and final review.

[0094] This embodiment uses a multilevel feedback queue (MFQ), with each priority level corresponding to an independent queue. High-priority queues use a first-in, first-out (FIFO) strategy, while low-priority queues use a round-robin (RR) strategy. Subtasks are then sent to the corresponding target robots in descending order of priority.

[0095] Reference Figure 2 In this embodiment, subtasks are sent to the corresponding target robots in descending order of priority, including:

[0096] S21 obtains the processing result, retrieves the i-th priority subtask from the head of the i-th priority queue, sends the i-th priority subtask to the target robot selected by the dynamic weighted polling algorithm in the task issued in S13, and obtains the processing result of the target robot.

[0097] The S22 review process involves reviewing the results based on pre-defined review rules and expected outcomes. The process is as follows:

[0098] Compare the processing result with the expected result. If they are the same, the review is considered approved; otherwise, the review is considered unapproved (e.g., if the processing result shows that the person's age is 49, but the expected result requires an age of 65, the processing result is different from the expected result, and the review is considered unapproved; if the household registration in the processing result is different from the household registration in the expected result, the review is considered unapproved).

[0099] If the review is approved, the processing results of the target robot will be stored in the database.

[0100] If the review fails, the execution log of the i-th priority subtask and the screen recording file containing the RPA robot operation interface are obtained. The execution log and screen recording file data are analyzed to locate the specific reason for the execution failure (e.g., interface element not found, network timeout, data processing logic error, etc.), and the analysis results are obtained and fed back.

[0101] Based on the analysis results, a correction workflow is set up. The correction workflow includes steps to resolve issues that cause the review to fail. A correction robot is designed based on the correction workflow. At the same time, correction tasks are generated according to the correction workflow, assigned to the correction robot for execution, correction results are obtained, and the correction results are used as new processing results and stored in the database.

[0102] S23 Sending Task: Before sending the (i+1)th priority subtask to the target robot corresponding to the (i+1)th priority subtask, extract the processing result of the previous priority subtask from the database, inject the processing result into the task information to obtain new task information, generate a new (i+1)th priority subtask based on the new task information, and send the new (i+1)th priority subtask to the target robot corresponding to the (i+1)th priority subtask.

[0103] This embodiment generates priorities based on the dependencies between subtask tags, enabling tasks to be executed in a reasonable order. This reduces inefficiencies caused by disordered task execution, allows critical tasks to be completed first, and shortens the overall business processing cycle.

[0104] Example 3: This example differs from Example 1 in that the task issuance in S13 further includes:

[0105] The historical approval count and total approval count of each RPA robot are obtained through a heartbeat mechanism. The historical approval rate is calculated based on the historical approval count and the total approval count. The formula for calculating the historical approval rate is as follows:

[0106] Historical approval rate = Number of historical approvals / Total number of approvals.

[0107] The historical approval rate of each RPA robot is used as the approval factor. The approval factor is introduced into the weighted round-robin algorithm to obtain the dynamic weighted round-robin algorithm. The dynamic weighted round-robin algorithm is used as the new weighted round-robin algorithm. The remaining part of the process, excluding the calculation process of the dynamic score, is the same as the calculation method in Example 1. It will not be repeated here. Only the calculation method of the dynamic score part is described.

[0108] The dynamic score is calculated in the new weighted round-robin algorithm as follows:

[0109] Dynamic score = base score × (1 - load index weight × load index + audit factor weight × audit factor);

[0110] Among them, the weight of the load index plus the weight of the audit factor = 1.

[0111] In another embodiment, calculating the historical approval rate based on the number of historical approvals and the total number of approvals includes:

[0112] Obtain the timestamps of the historical number of approved reviews and the total number of reviews. Based on the timestamps of the historical number of approved reviews and / or the total number of reviews, divide the historical number of approved reviews and / or the total number of reviews into multiple sub-approval numbers and / or sub-approval numbers according to a preset time window.

[0113] If the total number of reviews within a preset time window is zero, then the sub-review pass rate corresponding to the total number of reviews within the preset time window is set to zero.

[0114] If the total number of reviews within a preset time window is not zero, the sub-review approval rate for each preset time window is calculated based on the number of sub-reviews approved and the number of sub-reviews approved. The calculation formula is as follows:

[0115] Sub-approval pass rate = Number of sub-approvals / Number of sub-approvals.

[0116] The timestamps of the number of sub-approvals passed are used as the timestamps of the sub-approval pass rate. A time decay function is set based on the difference between the timestamps of the sub-approval pass rate and the current timestamp. The calculation model is as follows:

[0117] ;

[0118] in, This is the difference between the current timestamp and the timestamp of the sub-approval pass rate, i.e., the absolute value of the difference between the timestamp of the sub-approval pass rate and the current timestamp; This is the attenuation coefficient, with a value ranging from 0 to 1. The closer to 1, the higher the weight of the data that is closer to the current timestamp.

[0119] In other embodiments, the calculation model for the time decay function may also be:

[0120] ;

[0121] in, This is a preset time window.

[0122] The historical approval rate is calculated by normalizing the sum of the product of the sub-approval rate and the function value of the time decay function. The calculation model is as follows:

[0123] ;

[0124] in, Let the approval rate of the j-th sub-approval be denoted as . G represents the function value of the time decay function corresponding to the j-th sub-approval pass rate; G represents the historical approval pass rate.

[0125] This embodiment introduces an audit factor on the basis of the traditional weighted round-robin algorithm, and calculates a dynamic score by combining the load index weight and the audit factor weight, thereby comprehensively considering the load of the RPA robot and its historical audit performance, so that task allocation no longer depends solely on a single factor.

[0126] Example 4: This example differs from Example 1 in that, before executing S13 to issue the task, it also includes:

[0127] Periodically (e.g., every 5 seconds), obtain the status of all RPA robots in the cluster through a heartbeat mechanism or API polling, and determine whether there are any idle RPA robots in the target RPA robot cluster. If so, remove the busy RPA robots and execute the task distribution step; if not, build a task queue, place the target task at the end of the task queue, and re-execute this step after a preset interval.

[0128] Example 5: This example discloses an RPA robot swarm collaborative management system, the system including: a memory and a processor.

[0129] The memory contains a computer-readable storage medium;

[0130] When the processor processes the computer program stored on the computer-readable storage medium, it implements the RPA robot cluster collaborative management method.

[0131] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A method for collaborative management of RPA robot clusters, characterized in that, include: Request determination: Determine if a task execution request exists. If yes, parse the task information in the task execution request, generate the target task based on the task information, and execute the task determination steps. If no, repeat this step after a preset interval. Task Judgment: Determine whether the target task contains multiple subtasks. If so, add a subtask tag to each subtask and match the target RPA robot cluster based on each subtask tag. If not, add a task tag to the target task and match the target RPA robot cluster based on the task tag. Task assignment: Sequentially obtain the running data of each RPA robot in the target RPA robot cluster, select the target robot in the target RPA robot cluster based on the running data using a weighted round-robin algorithm, and send the target task or subtask to the target robot; In the step of executing the task distribution, the method further includes: obtaining the historical number of approvals and the total number of approvals for each RPA robot through a heartbeat mechanism, calculating the historical approval rate based on the historical number of approvals and the total number of approvals, using the historical approval rate corresponding to each RPA robot as an approval factor, introducing the approval factor into the weighted round-robin algorithm to obtain a dynamic weighted round-robin algorithm, and using the dynamic weighted round-robin algorithm as a new weighted round-robin algorithm; The dynamic score is calculated in the new weighted round-robin algorithm as follows: Dynamic score = base score × (1 - load index weight × load index + audit factor weight × audit factor); Among them, the load index weight + audit factor weight = 1; the basic score of each RPA robot is configured according to the hardware conditions of each RPA robot; The load index is calculated as follows: Load index = CPU utilization weight × CPU utilization + memory utilization weight × memory utilization + task queue length weight × (current task queue length / number of tasks the queue can hold). Among them, CPU utilization weight + memory utilization weight + task queue length weight = 1; The target robot is selected based on the ranking of dynamic scores in the new weighted round-robin algorithm. The calculation of the historical approval rate based on the number of historical approvals and the total number of approvals includes: Obtain the timestamps of the historical number of approved reviews and the total number of reviews. Based on the timestamps of the historical number of approved reviews and / or the total number of reviews, divide the historical number of approved reviews and / or the total number of reviews into multiple sub-approval numbers and / or sub-approval numbers according to a preset time window. Calculate the sub-approval rate for each preset time window based on the sub-approval numbers and sub-approval numbers. The timestamp of the number of times the sub-approval is passed is used as the timestamp of the sub-approval pass rate. A time decay function is set based on the difference between the timestamp of the sub-approval pass rate and the current timestamp. The sum of the product of the sub-approval pass rate and the function value of the time decay function is normalized and used as the historical approval pass rate. Before calculating the sub-approval pass rate for each preset time window based on the number of sub-approvals and the number of sub-approvals, the method further includes: if the total number of approvals within a preset time window is zero, then setting the sub-approval pass rate corresponding to the total number of approvals within the preset time window to zero.

2. The RPA robot cluster collaborative management method according to claim 1, characterized in that, The step of issuing the task also includes: Set the priority of each subtask tag and send the subtasks to the corresponding target robot in descending order of priority.

3. The RPA robot cluster collaborative management method according to claim 2, characterized in that, Subtasks are sent to the corresponding target robots in descending order of priority, including: Send the i-th priority subtask to the target robot corresponding to the i-th priority subtask, obtain the processing result of the target robot, and store the processing result in the database; Before sending the (i+1)th priority subtask to the target robot corresponding to the (i+1)th priority subtask, the processing result is extracted from the database, the processing result is injected into the task information to obtain new task information, and a new (i+1)th priority subtask is generated based on the new task information. The new (i+1)th priority subtask is then sent to the target robot corresponding to the (i+1)th priority subtask.

4. The RPA robot cluster collaborative management method according to claim 3, characterized in that, After obtaining the processing results of the target robot, the method further includes: The processing results are reviewed according to the preset review rules and expected results. If the review fails, the execution log and screen recording file data of the i-th priority subtask are obtained, the execution log and screen recording file data are analyzed, and the analysis results are obtained and fed back. Based on the analysis results, a correction workflow is set up, a correction robot is designed and correction tasks are generated based on the correction workflow, the correction tasks are assigned to the correction robot, and the correction results are obtained. The correction results are used as new processing results and stored in the database.

5. The RPA robot cluster collaborative management method according to any one of claims 1-4, characterized in that, Before executing the task distribution step, the method further includes: Determine if there are any idle RPA robots in the target RPA robot cluster. If so, remove the busy RPA robots and execute the task distribution step. If not, repeat this step after a preset interval.

6. The RPA robot cluster collaborative management method according to claim 5, characterized in that, When there are no idle RPA robots in the target RPA robot cluster, the method further includes: constructing a task queue and placing the target task at the tail of the task queue.

7. An RPA robot swarm collaborative management system, characterized in that, include: Memory and processor The memory contains a computer-readable storage medium; When the processor processes a computer program stored on the computer-readable storage medium, it implements the method as described in any one of claims 1-6.

Images