A method and apparatus for representing a progress of a robotic process automation (RPA) execution

Abstract

This application relates to the field of Robotic Process Automation (RPA) technology, and more particularly to a method and apparatus for characterizing the running progress of RPA. The method includes: determining the current running node in the RPA process file; after the current running node completes its execution, obtaining the first workload consumed by the completed nodes in the RPA process file and the first dynamic total workload of the RPA process file; and updating the RPA running progress based on the first workload and the first dynamic total workload. In the above method, when calculating the first dynamic total workload, the static total workload of multiple nodes in the process file, as well as the repeated execution process of any completed node, are considered. Furthermore, the calculation can be refined to each loop node, branch node, and sub-process node, and combined with the overall running progress for comprehensive analysis and updating the RPA running progress, resulting in a more accurate and detailed running progress.

Description

Technical Field

[0001] This application relates to the field of Robotic Process Automation (RPA) technology, and in particular to a method and device for characterizing the running progress of RPA. Background Technology

[0002] In the process of designing and monitoring the automated process of a robot, the designer first designs the automated process, which contains multiple runnable nodes. Then, a process file that can be run automatically is generated and executed by the executor.

[0003] During the execution of a process file, the executor needs to monitor its progress. In existing technologies, the executor software product displays the running status of each process in a list format, showing the process name followed by its running status, primarily including: loading process file, running, and stopped. This method provides relatively coarse-grained monitoring of the process file, failing to monitor the specific execution progress of each process. It cannot promptly detect process timeouts or impending timeouts, thus hindering timely troubleshooting.

[0004] Therefore, there is an urgent need for a method and computing device to represent the progress of Robotic Process Automation (RPA) operations, so as to make the monitoring of robot operation progress more precise. Summary of the Invention

[0005] This application provides a method and device for characterizing the running progress of Robotic Process Automation (RPA), which enables more refined monitoring of robot running progress.

[0006] In a first aspect, embodiments of this application provide a method for characterizing the running progress of Robotic Process Automation (RPA), the method comprising:

[0007] Determine the currently running node in the RPA process file; the RPA process file contains multiple nodes with an execution order; the multiple nodes include the main process node and the calling process node;

[0008] After the current running node completes its operation, the first workload consumed by the completed nodes in the RPA process file and the first dynamic total workload of the RPA process file are obtained. The first workload is determined based on the workload of any completed node in each running process. The first dynamic total workload is determined based on the static total workload of multiple nodes in the RPA process file and the workload of any completed node in each repeated running process.

[0009] Update the RPA running progress based on the first workload and the first dynamic total workload.

[0010] In the above method, the calculation of the first dynamic total workload considers the static total workload of multiple nodes in the process file, as well as the repeated execution of any completed node. The first dynamic total workload changes as any node runs; repeated execution of a node increases the first dynamic total workload. This incorporates loops, branches, and calls within the process file, and combined with the static total workload, makes the determination of the overall execution progress more granular. When determining the real-time execution progress, it can be refined to each loop node, branch node, and sub-process node, and comprehensively analyzed with the overall execution progress to update the RPA execution progress, resulting in a more accurate and detailed execution progress.

[0011] In one possible design, the first workload is determined based on the workload of any completed node in each run, including:

[0012] For any completed node, the total workload of the completed node is determined based on the single run workload q and the number of runs c of the completed node.

[0013] The total workload of each completed node is summarized to obtain the first workload.

[0014] In the above method, when determining the first workload, the workload q of a single run of the completed node and the number of runs c are considered. This forms a dynamic workload statistics process. As the node is run repeatedly, the total workload of the completed node increases, and the first workload also increases, which is consistent with the actual operation process in the process document.

[0015] In one possible design, the workload q of a single run of any node is determined by the conversion factor between the running time of any node and the baseline running time.

[0016] In the above method, the workload of any node in a single run is determined by using a conversion coefficient based on the baseline time, which can improve the accuracy of determining the workload of any node in a single run.

[0017] In one possible design, the static total workload of multiple nodes in the RPA process file is obtained by summing up the single-run workload q of each node in the RPA process file.

[0018] In one possible design, the static total workload is determined according to the following formula:

[0019]

[0020] in, This represents the total static workload of multiple nodes in the RPA process file. Let be the workload of a single run of the i-th node. This refers to the total number of nodes contained in the RPA process file.

[0021] In one possible design, the first dynamic total workload is determined based on the static total workload of multiple nodes in the RPA process file and the workload of any completed node in each repetitive run, including:

[0022] For any completed node, the total workload of the completed node is determined based on the single run workload q and the number of runs c of the completed node.

[0023] The first dynamic total workload is determined based on the static total workload and the total workload of each completed node.

[0024] In one possible design, the first dynamic total workload is determined according to the following formula:

[0025]

[0026] in, This represents the first dynamic total workload. This represents the total static workload of multiple nodes in the RPA process file. Let i be the workload of a single run of the i-th node; This represents the number of times the i-th completed node has been run; This represents the total workload of the nodes that have been completed.

[0027] In the above method, the static total workload of each node in the process document is easy to obtain. However, by incorporating the factor of repeated processes during the actual execution of the process document, a dynamic method for determining the total workload is formed. This means that the total workload used to determine the running progress also changes, making the process for updating the running progress more refined.

[0028] In one possible design, the method further includes:

[0029] If the running time of the current running node exceeds the estimated time of the current running node during the running process, the current running node is determined to be in a running timeout state. The estimated time of the current running node is determined based on the single running workload q, the baseline time, and the timeout threshold of the current running node.

[0030] In one possible design, the baseline time is determined by the time taken by the sample node to run on a robot in a normal operating environment.

[0031] In one possible design, the method further includes:

[0032] The taskbar on the display interface shows the RPA running progress and / or the running status of the currently running node; the running status includes running normally, running timeout, or running error.

[0033] The above method not only allows monitoring of the specific running progress, but also identifies which running node has timed out or encountered an error, improving the accuracy of RPA running progress monitoring and facilitating troubleshooting.

[0034] Secondly, embodiments of this application provide a device for characterizing the running progress of Robotic Process Automation (RPA), comprising:

[0035] The determination module is used to determine the currently running node in the RPA process file; the RPA process file contains multiple nodes with an execution order; the multiple nodes include the main process node and the calling process node;

[0036] The acquisition module is used to acquire, after the current running node has finished running, the first workload consumed by the completed nodes in the RPA process file and the first dynamic total workload of the RPA process file; the first workload is determined based on the workload of any completed node in each running process; the first dynamic total workload is determined based on the static total workload of multiple nodes in the RPA process file and the workload of any completed node in each repeated running process.

[0037] The update module is used to update the RPA running progress based on the first workload and the first dynamic total workload.

[0038] In one possible design, the acquisition module is specifically used to determine the total workload of the completed nodes based on the single run workload q and the number of runs c of the completed nodes; and to summarize the total workload of each completed node to obtain the first workload.

[0039] In one possible design, in the acquisition module, the workload q of any node in a single run is determined according to the conversion factor between the running time of any node and the baseline running time.

[0040] In one possible design, in the acquisition module, the static total workload of multiple nodes in the RPA process file is obtained by summing up the single-run workload q of each node in the RPA process file.

[0041] In one possible design, the acquisition module is specifically used to determine the static total workload according to the following formula:

[0042]

[0043] in, This represents the total static workload of multiple nodes in the RPA process file. Let be the workload of a single run of the i-th node. This refers to the total number of nodes contained in the RPA process file.

[0044] In one possible design, the acquisition module is further configured to, for any completed node, determine the total workload of the completed node based on the single-run workload q and the number of runs c of the completed node.

[0045] The first dynamic total workload is determined based on the static total workload and the total workload of each completed node.

[0046] In one possible design, the acquisition module is specifically used to determine the first dynamic total workload according to the following formula:

[0047]

[0048] in, This represents the first dynamic total workload. This represents the total static workload of multiple nodes in the RPA process file. Let i be the workload of a single run of the i-th node; This represents the number of times the i-th completed node has been run; This represents the total workload of the nodes that have been completed.

[0049] In one possible design, the update module is further configured to determine that the current running node is in a timeout state if the running time of the current running node exceeds the estimated time consumption of the current running node during the running process; the estimated time consumption of the current running node is determined based on the single running workload q, the baseline time consumption, and the timeout threshold of the current running node.

[0050] In one possible design, the baseline time is determined in the acquisition module by the time taken for the sample node to run on a robot in a normal operating environment.

[0051] In one possible design, the update module is further configured to display the RPA running progress and / or the running status of the currently running node in the taskbar of the display interface; the running status includes running normally, running timeout, or running error.

[0052] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when run, executes any of the methods described in the first aspect above.

[0053] Fourthly, embodiments of this application provide an electronic device, including: a memory for storing program instructions; and a processor for calling the program instructions stored in the memory and executing the method in any of the designs in the first aspect above according to the obtained program.

[0054] Fifthly, embodiments of this application provide a computer program product that, when run on a processor, implements the method as described in any of the designs in the first aspect above.

[0055] The beneficial effects of the second to fifth aspects mentioned above can be specifically referred to as the beneficial effects that can be achieved by any of the designs in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0056] Figure 1 An exemplary schematic diagram of a system architecture provided in an embodiment of this application is shown;

[0057] Figure 2 This illustration shows a schematic diagram of the main interface of an actuator software product provided in an embodiment of this application;

[0058] Figure 3 This illustration shows a progress bar diagram in a central control platform provided in an embodiment of this application.

[0059] Figure 4 This illustration shows a flowchart of a method for representing the running progress of Robotic Process Automation (RPA) according to an embodiment of this application.

[0060] Figure 5 This illustration shows a schematic diagram of the summation process of a calculator provided in an embodiment of this application;

[0061] Figure 6 This illustration shows a schematic diagram of a display interface taskbar provided in an embodiment of this application;

[0062] Figure 7 This illustration shows a taskbar diagram of a timeout display interface provided in an embodiment of this application.

[0063] Figure 8 This illustration is a schematic diagram of a robotic process automation (RPA) operation progress characterization device provided in an embodiment of this application. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0065] Robotic Process Automation (RPA) technology can simulate how employees operate computers using keyboards and mice in their daily work. It can replace humans in performing tasks such as logging into systems, operating software, reading and writing data, downloading files, and reading emails. By using automated robots as virtual labor, companies can free employees from repetitive, low-value tasks, allowing them to focus their energy on high-value-added work. This enables companies to reduce costs and increase efficiency while undergoing digital and intelligent transformation.

[0066] RPA (Robotic Process Automation) is a technology that uses software robots to replace manual tasks in business processes. These robots interact with computer front-end systems like humans. Therefore, RPA can be viewed as a software-based program robot running on a personal PC or server. It replaces human repetitive tasks by mimicking user actions on a computer, such as retrieving emails, downloading attachments, logging into systems, and data processing and analysis, offering speed, accuracy, and reliability. While both RPA and traditional physical robots address the speed and accuracy issues in human work through specific rules, traditional physical robots are hardware-software hybrids requiring specific hardware support and software to perform tasks. RPA robots, on the other hand, are purely software-based; once the appropriate software is installed, they can be deployed to any PC or server to complete the assigned tasks.

[0067] In other words, RPA is a method and related technologies that use "digital employees" to perform business operations in place of humans. Essentially, RPA uses software automation technology to simulate human operation of computer systems, software, web pages, and documents, acquiring business information, executing business actions, and ultimately achieving automated process processing, saving labor costs, and improving processing efficiency.

[0068] During RPA operation, it's necessary to monitor the RPA's progress to understand the processing status of RPA tasks. Simultaneously, it's crucial to promptly identify and troubleshoot any issues that arise during RPA execution, such as timeouts or errors, to prevent irreversible damage to the entire RPA task. This significantly improves work efficiency.

[0069] Figure 1This illustration shows a schematic diagram of a system architecture provided in an embodiment of this application. Figure 1 As shown, an RPA product mainly includes a designer, an executor, and a central control platform. The designer is used to design automated processes. Each automated process contains multiple execution nodes, and each execution node can be used to perform an operation on the processor. For example, the execution nodes of an RPA deployed on a personal computer include mouse clicks, reading emails, and inputting text. RPA can also be deployed on terminal devices such as servers or private clouds. The types of execution nodes therein are similar to those of RPA deployed on a personal computer, and will not be elaborated further here. After the designer completes the design of the execution nodes, it can instantiate and store them in a process file according to the execution order. The process file can then be used by the executor to execute the process.

[0070] The executor is primarily used to manage the process files designed by the designer, and to actually schedule and execute these process files, completing the operations of each running node in each process file, and storing the execution results. The execution results can be stored locally or uploaded to a cloud platform for storage. Alternatively, the executor can also send the execution results to a central control platform, where the central control platform centrally stores and analyzes the execution results.

[0071] Furthermore, the central control platform can also be used for unified management of designers and executors. It manages the design of process documents in the designers and the execution of these process documents by each executor. One central control platform can manage multiple designers and executors. It should be noted that the central control platform and the designers and executors can also be deployed on different terminal devices. For example, the central control platform can be deployed on a server, and the designers and executors can be deployed on various computers connected to the server.

[0072] In related technologies, monitoring the execution of process documents is mainly accomplished by designing a monitoring interface. For example, Figure 2 This illustration shows a schematic diagram of the main interface of an actuator software product provided in an embodiment of this application, such as... Figure 2 As shown, the main interface includes sections for process name, start method, status, and operations, displaying the process file's execution in a list format. The start method includes manual and automatic; the running status includes loading (loading process file), running (running), and stopped (stopped). Figure 2 As can be seen, each process file corresponds to one line to display its running status, and the display results are limited to the three types mentioned above. For files that are running, their progress cannot be shown. This results in a rather coarse and granular description of the running files. Various risks and faults that occur during process execution cannot be monitored in a timely manner. For example, if a process file times out, it is difficult to assess the specific timeout point.

[0073] To address the above issues, a progress bar can be used in the central control platform to display the process progress. Figure 3 This illustration shows a progress bar diagram in a central control platform provided in an embodiment of this application. Figure 3 As shown, the central control platform displays a progress bar to show the progress of a workflow file. The workflow file consists of multiple nodes. The progress bar is calculated by estimating the total number of nodes in the workflow and then dividing that number by the current node. For example, if the workflow has 10 nodes and the 3rd node has been completed, the progress bar is at 3 / 10 of the total progress, showing a progress of 30%.

[0074] In the above approach, because the process includes loops, branches, and calls, a node may run multiple times or not at all, causing the progress value to fluctuate wildly and even regress, which does not meet user expectations. Continuing with... Figure 3 For example, suppose nodes 3, 4, and 5 form a loop. After the first execution of node 5, the progress is displayed as 50%. After the second execution of node 5, node 3 is executed, and the progress is displayed as 30%. This results in the execution progress regressing from 50% to 30%. Upon observing this, the user might mistakenly believe that an error has occurred and actively pause the process to investigate, but this is unnecessary.

[0075] In another possible implementation, when a sub-process is called within a workflow, the execution time at a certain node may become excessively long, causing the progress bar to remain unchanged for an extended period, resulting in a "frozen" appearance. For example, at node 3 mentioned above, a sub-process containing 10 nodes is called. During the execution of other sub-processes at node 3, the progress bar will not update, and will update much slower than when running nodes 1 and 2. From the user's perspective, it is impossible to determine whether node 3 is calling a sub-process or whether the entire workflow file has become frozen.

[0076] Furthermore, in cases where the process times out, it is impossible to determine whether the timeout is due to the cumulative timeout of multiple nodes or the timeout of one or more nodes. The granularity of the timeout assessment is too large to achieve fine-grained results.

[0077] Based on this, this application provides a method for characterizing the running progress of Robotic Process Automation (RPA), which enables more refined monitoring of the robot's running progress.

[0078] Figure 4 This illustration shows a flowchart of a method for representing the running progress of Robotic Process Automation (RPA) according to an embodiment of this application. Figure 4As shown, the method includes:

[0079] Step 401: Determine the currently running node in the RPA process file; the RPA process file contains multiple nodes with an execution order; the multiple nodes include the main process node and the calling process node.

[0080] This method automatically updates the progress during the execution of the workflow file. The currently running node refers to the node that is currently running, such as reading emails or clicking the mouse.

[0081] Step 402: After the current running node has finished running, obtain the first workload consumed by the completed nodes in the RPA process file and the first dynamic total workload of the RPA process file; the first workload is determined based on the workload of any completed node in each running process; the first dynamic total workload is determined based on the static total workload of multiple nodes in the RPA process file and the workload of any completed node in each repeated running process.

[0082] Step 403: Update the RPA running progress based on the first workload and the first dynamic total workload.

[0083] In the above method, the calculation of the first dynamic total workload considers the static total workload of multiple nodes in the process file, as well as the repeated execution of any completed node. The first dynamic total workload changes as any node runs; repeated execution of a node increases the first dynamic total workload. This incorporates loops, branches, and calls within the process file, and combined with the static total workload, makes the determination of the overall execution progress more granular. When determining the real-time execution progress, it can be refined to each loop node, branch node, and sub-process node, and comprehensively analyzed with the overall execution progress to update the RPA execution progress, resulting in a more accurate and detailed execution progress.

[0084] Step 402 above includes concepts such as first workload, first dynamic total workload, static total workload, and workload in each repeated run. The meaning and algorithm of each concept will be introduced one by one below.

[0085] The workload is determined based on the execution time of the running nodes. Therefore, it is essential to first clarify the concept of a baseline execution time, which is determined by the execution time of sample nodes on robots in a normal operating environment. A normal operating environment refers to robots or computers with balanced hardware and network conditions. After determining the baseline execution time of the sample nodes, the unit workload (1) is determined based on the baseline execution time. For the running nodes in the current process file, the workload of each node in the process file is determined based on the operating environment of the current process file. For example, some nodes can run without a network, and their execution time will be less than that of the sample nodes. In this case, the workload of this node can be determined as 0.8 times the unit workload. Some process files run on robots with hardware performance lower than normal, so the workload of all running nodes in this process file is at least 1.2 times the unit workload.

[0086] The workload q of a single run of any node is determined by a conversion factor between the node's run time and the baseline run time. The aforementioned 0.8 and 1.2 are these conversion factors, expressed as floating-point numbers. For nodes with shorter run times, the conversion factor ranges from 0.01 to 0.99; for nodes with medium run times, the conversion factor ranges from 1 to 9. For nodes with excessively long run times, the conversion factor can range from 10 to 100.

[0087] In addition, the conversion coefficient can be determined according to the type of node. For ordinary logic unit nodes, the conversion coefficient is 0, that is, the workload of the corresponding logic unit node is 0; for file reading nodes, the conversion coefficient is 1, that is, the workload of the corresponding file reading node is 1; for interface automation nodes, the conversion coefficient is 1, that is, the workload of the corresponding interface automation is 1; for artificial intelligence nodes, the conversion coefficient is 10, that is, the workload of the corresponding artificial intelligence node is 10... The conversion coefficients for other node types can be set according to human experience, which will not be elaborated here.

[0088] Table 1 illustrates some specific node types:

[0089] Table 1

[0090]

[0091] It should be noted that for a process file, the workload corresponding to each node must be set when designing the process in the designer, stored in the process file, and can be parsed and interpreted by the executor engine.

[0092] Based on the single-run workload q of any of the above nodes, the concept of static total workload is introduced. The static total workload of multiple nodes in an RPA process file is obtained by summing the single-run workload q of each node in the RPA process file.

[0093] In one possible implementation, the static total workload can be determined using the following formula:

[0094]

[0095] in, This represents the static total workload of multiple nodes in the RPA process file. Let be the workload of a single run of the i-th node. This represents the total number of nodes contained in the RPA process file.

[0096] The concept of static workload is explained below using the process of calculating 1+1 with a calculator. Figure 5 This illustration shows a schematic diagram of the summation process of a calculator provided in an embodiment of this application, such as... Figure 5 The calculator's summation process shown contains 10 nodes:

[0097] Node 1: A node with actual operation; click the calculator program icon in the taskbar; workload q [1] =1;

[0098] Node 2: Logical node, click multi-digit number: workload q [2] = 0;

[0099] Node 3: Parse the high-order bits of the number and parameterize the value; workload q [3] =0;

[0100] Node 4: Click the numeric key: Workload q [4] = 1;

[0101] Node 5: Click the plus button; Workload q [5] =1;

[0102] Node 6: Logical node, click multi-digit number: workload q [6] = 0;

[0103] Node 7: Parse the high-order bits of the number and parameterize the value; workload q [7] =0;

[0104] Node 8: Click the numeric key: Workload q [8] = 1;

[0105] Node 9: Enter the equals sign key: Workload q [9] =1;

[0106] Node 10: Output results to the console and log; workload q

[10] =0;

[0107] Therefore, the static total workload in the process file for summing 1+1 can be obtained as 5.

[0108] Having clarified the concept of the static total workload, the concept of the first workload will now be explained.

[0109] For any completed node, if the number of times the completed node is run is c, then the total workload of the completed node is determined based on the single run workload q and the number of runs c; the total workload of each completed node is summarized to obtain the first workload.

[0110] Let's take the example of calculating 1+1 as an example again:

[0111] The workload of node 1 is 1, the number of runs is 1, and after running node 1, the initial workload is 1.

[0112] The workload of node 2 is 0, the number of runs is 1, and after running node 2, the first workload is 1.

[0113] The workload of node 3 is 0, the number of runs is 1, and after running node 3, the first workload is 1.

[0114] The workload of node 4 is 1, the number of runs is 1, and after running node 4, the first workload is 2.

[0115] The workload of node 5 is 1, the number of runs is 1, and after running node 5, the first workload is 3;

[0116] ...

[0117] In the 1+1 example above, each node runs once. Below is an example of calculating 10+10 to illustrate the impact of repetition count on the initial workload. The process nodes for calculating 10+10 are the same as those for calculating 1+1, and will follow the same steps. Figure 5 As shown. The difference is that nodes 2, 3, and 4 need to be run repeatedly; that is, after node 4 is run for the first time, nodes 2, 3, and 4 are run again. Similarly, nodes 6, 7, and 8 also need to be run repeatedly; that is, after node 8 is run for the first time, nodes 6, 7, and 8 are run again. Specifically:

[0118] The above process can be represented by the following formula:

[0119]

[0120] in As the primary workload, Let be the number of runs for the i-th completed node. This represents the workload of a single run on the i-th node. The specific execution process is as follows:

[0121] The workload of node 1 is 1. After running node 1, Q(1) = 1.

[0122] The workload of node 2 is 0. After running node 2, Q(2) = 1.

[0123] The workload of node 3 is 0. After running node 3, Q(3) = 1.

[0124] The workload of node 4 is 1. After running node 4, Q(4) = 2.

[0125] Repeat the process:

[0126] After the second run of node 2, Q(5) = 2;

[0127] After the second run of node 3, Q(6) = 2;

[0128] After the second run of node 4, Q(7) = 3;

[0129] The workload of node 5 is 1. After running node 5, Q(8) = 4.

[0130] The workload of node 6 is 0. After running node 6, Q(9) = 4.

[0131] The workload of node 7 is 0. After running node 7, Q(10) = 4.

[0132] The workload of node 8 is 1. After running node 8, Q(11) = 5.

[0133] Repeat the process:

[0134] After the second run of node 6, Q(12) = 5;

[0135] After the second run of node 7, Q(13) = 5;

[0136] After the second run of node 8, Q(14) = 6;

[0137] The workload of node 9 is 1. After running node 9, Q(15) = 7.

[0138] The workload of node 10 is 0. After running node 10, Q(16) = 7.

[0139] Based on the concepts of static total workload and first workload mentioned above, the concept of first dynamic total workload is introduced below:

[0140] The first dynamic total workload is determined based on the static total workload and the total workload of completed nodes.

[0141] In one possible implementation, the first dynamic total workload can be determined according to the following formula:

[0142]

[0143] in, This represents the first dynamic total workload. This represents the number of times the i-th completed node has been run.

[0144] The following example, using the calculation of 10+10, illustrates how the first dynamic total workload is calculated:

[0145] In the example of calculating 10+10, the static total workload S is 5:

[0146] The workload of node 1 is 1. After running node 1, E(1) = 5.

[0147] The workload of node 2 is 0. After running node 2, E(2) = 5.

[0148] The workload of node 3 is 0. After running node 3, E(3) = 5.

[0149] The workload of node 4 is 1. After running node 4, E(4) = 5.

[0150] Repeat the process:

[0151] After the second run of node 2, E(5) = 5;

[0152] After the second run of node 3, E(6) = 5;

[0153] After the second execution of node 4, E(7) = 5 + 1 = 6;

[0154] The workload of node 5 is 1. After running node 5, E(8) = 6.

[0155] The workload of node 6 is 0. After running node 6, E(9) = 6.

[0156] The workload of node 7 is 0. After running node 7, E(10) = 6.

[0157] The workload of node 8 is 1. After running node 8, E(11) = 6.

[0158] Repeat the process:

[0159] After the second run of node 6, E(12) = 6;

[0160] After the second run of node 7, E(13) = 6;

[0161] After the second run of node 8, E(14) = 6 + 1 = 7;

[0162] The workload of node 9 is 1. After running node 9, E(15) = 7.

[0163] The workload of node 10 is 0. After running node 10, E(16) = 7.

[0164] In step 403 above, the RPA running progress is updated based on the first workload and the first dynamic total workload.

[0165] In one possible implementation, the running schedule can be determined based on the ratio of the first workload to the first dynamic total workload. That is, P(J) = Q(J) / E(J). 100%. The specific process is as follows:

[0166] After running node 1, P(1) = 20%;

[0167] After running node 2, P(2) = 20%;

[0168] After running node 3, P(3) = 20%;

[0169] After running node 4, P(4) = 40%;

[0170] Repeat the process:

[0171] After the second run of node 2, P(5) = 40%;

[0172] After the second run of node 3, P(6) = 40%;

[0173] After the second run of node 4, P(7) = 50%;

[0174] After running node 5, P(8) = 66.67%;

[0175] After running node 6, P(9) = 66.67%;

[0176] After running node 7, P(10) = 66.67%;

[0177] After running node 8, P(11) = 83.33%;

[0178] Repeat the process:

[0179] After the second run of node 6, P(12) = 83.33%;

[0180] After the second run of node 7, P(13) = 83.33%;

[0181] After the second run of node 8, P(14) = 85.71%;

[0182] After running node 9, P(15) = 100%;

[0183] After running node 10, P(16) = 100%.

[0184] Optionally, if the running time of the current running node exceeds the estimated time of the current running node during the running process, the current running node is determined to be in a running timeout state.

[0185] The estimated execution time of the current running node is determined based on the single-run workload q, the baseline execution time, and the timeout threshold. For example, if the baseline execution time is 1 second, the single-run workload of the current running node is 10, and the timeout threshold is set to 10%, then the estimated execution time of the current node is 11 seconds. If the execution time of the current running node exceeds 11 seconds, then the current running node is determined to be in a timeout state.

[0186] In another possible implementation, the estimated timeout can be determined first, and then different timeout threshold levels can be set to determine the current running node's different timeout states. For example, if the baseline timeout is 1 second and the workload of a single run of the current running node is 10, then the estimated timeout for the current node is 10 seconds. Setting the timeout threshold to 10% determines the current running node to be in a mild timeout state; setting the timeout threshold to 20% determines the current running node to be in a severe timeout state; and setting the timeout threshold to 50% determines the current running node to be in a very severe timeout state.

[0187] Figure 6 This illustration shows a schematic diagram of a display interface taskbar provided in an embodiment of this application, such as... Figure 6 As shown, the RPA running progress is displayed in the taskbar of the display interface. When the mouse moves over the icon in the taskbar, the running status of the current running node is displayed in the thumbnail; the running status includes running normally, running timeout, or running error. Optionally, different colors can be used in the icon to represent different running statuses, for example, green indicates running normally, yellow indicates running timeout, and red indicates running error.

[0188] Figure 7 This illustration shows a taskbar diagram illustrating a timeout display interface provided in an embodiment of this application. Figure 7 As shown, when running to node 5, a timeout was detected. At this time, the running progress is displayed as 50% of the running progress at node 4.

[0189] By using the above methods, we can not only determine if there is an error in the process file during operation, but also pinpoint the specific node in the process file that is causing the error, thus enabling more precise monitoring of the RPA operation progress.

[0190] Based on the same technical concept, this application also provides a device for characterizing the running progress of Robotic Process Automation (RPA). Figure 8 This illustration shows a schematic diagram of a robotic process automation (RPA) running progress characterization device provided in an embodiment of this application. This device can execute the aforementioned RPA running progress characterization method, such as... Figure 8 As shown, the device includes:

[0191] The determination module is used to determine the currently running node in the RPA process file; the RPA process file contains multiple nodes with an execution order; the multiple nodes include the main process node and the calling process node;

[0192] The acquisition module is used to acquire, after the current running node has finished running, the first workload consumed by the completed nodes in the RPA process file and the first dynamic total workload of the RPA process file; the first workload is determined based on the workload of any completed node in each running process; the first dynamic total workload is determined based on the static total workload of multiple nodes in the RPA process file and the workload of any completed node in each repeated running process.

[0193] The update module is used to update the RPA running progress based on the first workload and the first dynamic total workload.

[0194] In one possible design, the acquisition module is specifically used to determine the total workload of any completed node based on the single-run workload q and the number of runs c of the completed node; and to summarize the total workload of each completed node to obtain the first workload.

[0195] In one possible design, in the acquisition module, the workload q of any node in a single run is determined according to the conversion factor between the running time of any node and the baseline running time.

[0196] In one possible design, in the acquisition module, the static total workload of multiple nodes in the RPA process file is obtained by summing up the single-run workload q of each node in the RPA process file.

[0197] In one possible design, the acquisition module is specifically used to determine the static total workload according to the following formula:

[0198]

[0199] in, This represents the total static workload of multiple nodes in the RPA process file. Let be the workload of a single run of the i-th node. This refers to the total number of nodes contained in the RPA process file.

[0200] In one possible design, the acquisition module is further configured to, for any completed node, determine the total workload of the completed node based on the single-run workload q and the number of runs c of the completed node.

[0201] The first dynamic total workload is determined based on the static total workload and the total workload of each completed node.

[0202] In one possible design, the acquisition module is specifically used to determine the first dynamic total workload according to the following formula:

[0203]

[0204] in, This represents the first dynamic total workload. This represents the total static workload of multiple nodes in the RPA process file. Let i be the workload of a single run of the i-th node; This represents the number of times the i-th completed node has been run; This represents the total workload of the nodes that have been completed.

[0205] In one possible design, the update module is further configured to determine that the current running node is in a timeout state if the running time of the current running node exceeds the estimated time consumption of the current running node during the running process; the estimated time consumption of the current running node is determined based on the single running workload q, the baseline time consumption, and the timeout threshold of the current running node.

[0206] In one possible design, the baseline time is determined in the acquisition module by the time taken for the sample node to run on a robot in a normal operating environment.

[0207] In one possible design, the update module is further configured to display the RPA running progress and / or the running status of the currently running node in the taskbar of the display interface; the running status includes running normally, running timeout, or running error.

[0208] Based on the same technical concept, this embodiment of the invention also provides a computer program product that, when run on a processor, implements the method shown in the above embodiments.

[0209] Based on the same technical concept, embodiments of the present invention also provide an electronic device, including: a memory for storing program instructions;

[0210] The processor is used to call program instructions stored in the memory and execute the methods shown in the above embodiments according to the obtained program.

[0211] Based on the same technical concept, embodiments of the present invention also provide a computer-readable storage medium that implements the method shown in the above embodiments when the computer program product is run on a processor.

[0212] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0213] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0214] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0215] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0216] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for characterizing the running progress of Robotic Process Automation (RPA), characterized in that, The method includes: Determine the currently running node in the RPA process file; the RPA process file contains multiple nodes with an execution order; the multiple nodes include the main process node and the calling process node; After the currently running node completes its operation, the first workload consumed by the completed nodes in the RPA process file and the first dynamic total workload of the RPA process file are obtained; the first workload is determined based on the workload of any completed node in each running process; the first dynamic total workload is determined based on the static total workload of multiple nodes in the RPA process file and the workload of any completed node in each running process; wherein, The static total workload of multiple nodes in the RPA process file is determined using the following formula: in, This represents the total static workload of multiple nodes in the RPA process file. Let be the workload of a single run of the i-th node. The total number of nodes contained in the RPA process file; and The first dynamic total workload is determined according to the following formula: in, This represents the first dynamic total workload. This represents the total static workload of multiple nodes in the RPA process file. Let i be the workload of a single run of the i-th node; This represents the number of times the i-th completed node has been run; This represents the total workload of the completed nodes. Update the RPA running progress based on the first workload and the first dynamic total workload.

2. The method as described in claim 1, characterized in that, The first workload is determined based on the workload of any completed node in each running process, including: For any completed node, the total workload of the completed node is determined based on the single run workload q and the number of runs c of the completed node. The total workload of each completed node is summarized to obtain the first workload.

3. The method as described in claim 2, characterized in that, The workload q of a single run of any node is determined by the conversion factor between the running time of any node and the baseline running time.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: If the running time of the current running node exceeds the estimated time of the current running node during the running process, the current running node is determined to be in a running timeout state. The estimated time of the current running node is determined based on the single running workload q, the baseline time, and the timeout threshold of the current running node.

5. The method as described in claim 4, characterized in that, The baseline time was determined by the time taken for the sample node to run on a robot in a normal operating environment.

6. The method as described in claim 4, characterized in that, The method further includes: The taskbar on the display interface shows the RPA running progress and / or the running status of the currently running node; the running status includes running normally, running timeout, or running error.

7. An electronic device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the method as described in any one of claims 1 to 6 according to the obtained program.

Images