A batch job log inspection method and device based on RPA collaboration

Abstract

The present invention discloses a batch job log inspection method and device based on RPA collaboration. The method is that after obtaining job information through the job inspection engine, the RPA robot extracts the log and calls the script to push the inspection results to the job inspection engine for keyword analysis. If an abnormality is found, an alarm is generated and pushed to the alarm monitoring platform. For the allocation of job nodes for dynamic scheduling of RPA in the inspection process, an optimized RPA resource scheduling model is proposed. This model is a single-cycle job inspection task allocation optimization model based on the collaboration of multiple RPA resources. It can realize a balanced scheduling plan that considers multiple goals at the same time, improves the efficiency of job inspection and RPA resource utilization, and provides support and guarantee for the normal operation of batch jobs.

Description

Technical Field

[0001] The present invention relates to the field of automated operation and maintenance technology, and in particular to a batch job log inspection method and device based on RPA collaboration. Background Art

[0002] In data center batch job execution scenarios, the job scheduling platform is responsible for the unified scheduling and execution of various job types. Based on past experience, even if the job script execution status is normal, some incorrect keywords may appear in the execution log. These errors are often not discovered promptly, often only being identified when a business transaction occurs or a system resource alarm is triggered. This significantly impacts business transactions and system stability. Therefore, log verification and confirmation of completed jobs are essential. To ensure efficient scheduling, the job scheduling platform only stores job execution information and does not provide job result storage or automated analysis capabilities. This is to reduce system burden and maintain the scheduling platform's lightweight and high performance. Therefore, batch job log verification still relies on manual operations, such as searching for incorrect log keywords and comparing log history lengths. With the continuous development of business and information systems, tens of thousands of batch jobs have been put online. The traditional manual method has exposed many problems: 1) Frontline inspectors are overburdened. The time spent on checking job logs has occupied the vast majority of their daily work, and the number of inspections far exceeds the daily inspection limit; 2) Human and machine resources are intensively utilized. Although the job inspection process is generally simple and repetitive, human and equipment terminal resources are still required to support the inspection; 3) Manual inspection of log error keywords and length is prone to omissions. Inspectors often ignore quality in pursuit of quantity, resulting in the failure to effectively reduce the risk of job operation.

[0003] Robotic Process Automation (RPA) is a technology that uses software to execute business processes. It mimics and replicates manual operations on a computer graphical interface, automatically executing business processes by driving the mouse and keyboard. To address the issue of job log checking, RPA can be used to simulate manual log checking operations and obtain log results. However, in reality, with tens of thousands of running batch jobs, RPA resources are limited. Without a clear strategy to dynamically schedule multiple RPA resources for job checking, it is difficult to ensure the completion rate of job checks, the timeliness of anomaly detection, and efficient resource utilization. However, no mature solution has yet been found in the relevant technologies to address these issues. Summary of the Invention

[0004] In order to address the needs and problems in the background technology, the present invention proposes a batch job log inspection method and device based on RPA collaboration, which provides a reliable reference basis for subsequent job log inspection.

[0005] The objectives of the present invention are achieved through the following technical solutions: In a first aspect, the present invention provides a batch job log inspection method based on RPA collaboration, comprising the following steps:

[0006] Step 1: Collect the data and information required for the current cycle log inspection task allocation decision, including the set of unassigned inspection jobs, the set of RPAs, and the completion status of a particular inspection task.

[0007] Step 2: Establish a job check task allocation optimization model: Taking into account the job allocation priority and the maximum number of job checks performed by the RPA within a cycle, the job check task allocation optimization model is established with the objective function minimizing the RPA resource usage cost, the penalty cost for not assigning jobs according to the continuity rule, and the penalty cost for not assigning jobs to checks.

[0008] Step 3: Find the cost-optimal solution: Use a two-stage hybrid metaheuristic algorithm to solve the task inspection task allocation optimization model;

[0009] Step 4: Perform job checks: After the start of scheduling cycle K, the RPA robot performs job checks in sequence according to the assigned task priority and inspection plan, following the optimal allocation solution obtained in steps 2 and 3. When the job check succeeds, the RPA robot feeds the results back to the job check engine. The job check engine analyzes the text content based on pre-set alarm keywords and ignore keywords. If any abnormal logs are found, an alarm is generated and pushed to the alarm monitoring platform.

[0010] Furthermore, the information to be collected in step 1 also includes: the time window width T of each inspection cycle N , the unit cost of the RPA resource pool, whether each RPA resource has executed a check task in the previous cycle, a 0-1 matrix is generated. If the RPA has executed the task in the previous cycle, the matrix element is 1, otherwise the matrix element is 0, as well as the probability A of whether the RPA successfully executes a certain check task in the historical data and the time when the RPA checks a single job log.

[0011] Furthermore, in step 2, the assumptions for establishing the operation inspection task allocation optimization model are as follows:

[0012] 1) The maximum number of jobs that each RPA robot can check in each cycle is fixed;

[0013] 2) The inspection time for each job depends on the complexity of the job, which is obtained from historical data;

[0014] 3) RPA robots can process multiple jobs in parallel, but they are subject to resource limitations.

[0015] 4) Jobs that are not checked in time can be accumulated to the next cycle;

[0016] 5) The time it takes for the RPA robot to log in and out of the log server at the beginning and end of each inspection cycle is negligible;

[0017] 6) At the beginning of each cycle, the robot has completed the inspection task in the previous inspection cycle.

[0018] Furthermore, in step 2, the constraints for establishing the operation inspection task allocation optimization model are as follows:

[0019] 1) When the RPA robot is not fully loaded, a robot is assigned to each job for inspection within the cycle:

[0020]

[0021] Where m is the number of RPA robots, r is the currently available RPA, and x rj Generates the elements of a 0-1 matrix for the inspection task, if RPAr is assigned to inspection job j, then x rj is 1, otherwise x rj is 0, U K R is the set of jobs that were not assigned for inspection in time due to RPA resource limitations in the previous cycle. K The RPA set currently available for job inspection;

[0022] 2) The number of tasks assigned to each robot during an inspection cycle must not exceed its maximum number of inspections:

[0023]

[0024] Among them, t rj Time for RPAr to check job j, T N The time window width for each inspection cycle;

[0025] 3) Tasks that cannot be assigned for inspection in time during the K-1 cycle should be assigned with a higher priority than the tasks to be assigned in this cycle during the K inspection cycle:

[0026]

[0027] Furthermore, in step 2, the objective function modeling process of establishing the operation inspection task allocation optimization model is as follows:

[0028] The objective function aims to minimize the total cost Z, including the RPA resource usage cost C r , the penalty cost C for not allocating tasks according to the rules p and the penalty cost C for not checking the job u :

[0029]

[0030] Among them, p j is the penalty cost of the jth job not being checked according to the continuity rule, a rj is the probability that RPAi checks whether job j is successful in the historical data, and q is the unit penalty cost of a job not being checked.

[0031] Furthermore, in step 3, the two-stage hybrid metaheuristic algorithm for solving the model is further processed as follows:

[0032] 3.1) Initial solution generation

[0033] This stage quickly generates a feasible solution to provide a starting point for neighborhood search and uses a greedy strategy to generate an initial solution. The optimization goals are as follows:

[0034]

[0035] 3.2) Neighborhood search;

[0036] Based on the initial solution, a better solution is found by locally modifying the solution; the details are as follows:

[0037] From the solution x rj Randomly select k tasks to be assigned and reset; for each selected task j, reallocate it to the RPA with the lowest cost, and get the updated solution

[0038] Redistribution formula:

[0039]

[0040] Use the acceptance criterion of simulated annealing to decide whether to accept the new solution; that is, if the total cost of the new solution Cost(x (new) )<Cost(x (current) )or Then receive the new solution x obtained after the optimization operation (new) ; where x (current) represents the solution before optimization, ΔCost is the change in cost, T P is the probability of controlling the reception of a poor solution;

[0041] After each iteration, the algorithm decides whether to accept the new solution based on the cost change ΔCost and the simulated annealing criterion. If the cost of the new solution is lower, it is accepted directly; if the cost increases, it is accepted with a certain probability.

[0042] 3.3) Perturbation of the solution

[0043] In order to escape from the local optimum, the current solution is disturbed regularly; k tasks are randomly selected and redistributed; after the disturbance, the task is redistributed:

[0044]

[0045] 3.4) Solution

[0046] After each iteration, the termination condition is checked: 1) the set maximum number of iterations is reached; 2) the change in the current solution is less than the predetermined error range; if the termination condition is met, the algorithm ends; otherwise, it returns to the iterative loop, and the final solution is the optimal solution.

[0047] In a second aspect, the present invention also provides a batch job log checking device based on RPA collaboration, comprising a memory and one or more processors, wherein the memory stores executable code, and when the processor executes the executable code, the batch job log checking method based on RPA collaboration is implemented.

[0048] In a third aspect, the present invention further provides a computer-readable storage medium having a program stored thereon. When the program is executed by a processor, the method for checking batch job logs based on RPA collaboration is implemented.

[0049] In a fourth aspect, the present invention further provides a computer program product, comprising a computer program, which, when executed by a processor, implements the aforementioned method for checking batch job logs based on RPA collaboration.

[0050] Compared with the prior art, the present invention has the following beneficial effects:

[0051] The present invention proposes a batch job log inspection method and device based on RPA collaboration. The process is that after obtaining job information through the job inspection engine, the RPA robot extracts the log and calls the script to push the job log inspection information to the job inspection engine for keyword analysis. If an abnormality is found, an alarm is generated and pushed to the alarm monitoring platform. For the allocation of job nodes for dynamic scheduling of RPA in the inspection process, an optimized RPA resource scheduling model is proposed. This model is a single-cycle job inspection task allocation optimization model based on the collaboration of multiple RPA resources. It can realize a balanced scheduling plan that considers multiple goals at the same time, improves the efficiency of job inspection and RPA resource utilization, and provides support and guarantee for the normal operation of batch jobs. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0053] Figure 1 This is a flow chart of a batch job log checking method based on RPA collaboration of the present invention.

[0054] Figure 2 This is a technical architecture diagram of batch job log inspection based on RPA collaboration in the present invention.

[0055] Figure 3 This is a flow chart of the two-stage hybrid metaheuristic algorithm of the present invention.

[0056] Figure 4 This is a structural diagram of a batch job log checking device based on RPA collaboration of the present invention. DETAILED DESCRIPTION

[0057] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described below with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are only used to explain the present invention and are not intended to limit the present invention.

[0058] like Figure 1 As shown, the present invention includes the following steps:

[0059] Step 1: Collect logs to check the data information required for task allocation decisions;

[0060] Specifically, before the start time of scheduling cycle K, the job inspection engine collects data information required for log inspection task allocation decision in cycle K from the job scheduling platform. The information to be collected includes:

[0061] 1. The set of jobs U that were not assigned for inspection in time due to RPA resource limitations in the previous cycle K :

[0062] U K ={j}

[0063] Task j is not assigned in period K-1 due to RPA resource constraints;

[0064] 2. The RPA set R currently available for job checking in the RPA resource pool K :

[0065] R K ={r|r∈{1, 2, ..., m}} where r is the currently available RPA;

[0066] 3. The time window width T of each inspection cycle N , is a preset fixed value, executed every 10 minutes:

[0067] 4. Unit cost C of the RPA resource pool:

[0068] C={C r |r∈{1, 2, …, m}}

[0069] 5. Generate a 0-1 matrix X based on whether each RPA resource has performed a check task in the previous cycle: X = {x rj |r∈{1, 2,…,m}, j∈{1, 2,…,n}}

[0070] If RPAr executed task j in the previous cycle, then x rj The value is 1, otherwise the value is 0.

[0071] 6. The probability A of whether RPA successfully performs a certain inspection task in historical data:

[0072] A={a rj |r∈{1, 2, ..., m}, j∈{1, 2, ..., n}}

[0073] Among them, a rj is the probability that RPAr will successfully perform task j.

[0074] 7. Time T when RPA checks a single job log:

[0075] T={t rj |r∈{1, 2,…,m}, j∈{1, 2,…,n}}

[0076] Where m is the number of RPA robots, n is the number of inspection tasks, and t rj is the execution time of RPAr checking task j.

[0077] Figure 2 is a detailed technical architecture diagram of the operation inspection according to an embodiment of the present invention, such as Figure 2 This architecture diagram illustrates the interactions and workflows of various components in the job inspection process, enabling automated allocation and processing of job log inspection tasks. This technical architecture diagram includes RPA robots, a job scheduling platform, a job inspection engine, and an alarm monitoring platform. The following are some examples:

[0078] RPA robots: Each RPA robot is responsible for determining the job tasks that need to be checked in each cycle from the job inspection engine. It then obtains the log data of the jobs to be checked from the job scheduling platform based on the tasks to be checked. Finally, it calls the local task script and feeds the job log inspection information back to the job inspection engine.

[0079] Job scheduling platform: This platform is responsible for storing the information of completed jobs in each cycle.

[0080] Job Check Engine: The job check engine is the core of traditional RPA (Robotic Process Automation) and automated log check processes. As a program component that can be embedded in large-scale management information systems, it obtains information about completed jobs per cycle from the job scheduling platform and dynamically schedules multiple RPA resources for resource checks based on the optimal allocation plan. It receives the RPA robot's check results, determines whether the check was successful, and determines subsequent actions. If the check is successful, the job is marked as no longer necessary to schedule within the current cycle. If the check fails, RPA reports the reason for the failure, and the job check engine decides, based on the specific circumstances, whether to immediately retry the job or schedule it for the next cycle. It also parses log content and performs anomaly detection based on pre-set keywords.

[0081] Alarm Monitoring Platform: When the job inspection engine detects abnormal logs, the alarm monitoring platform receives abnormal alerts. This platform is used to monitor and track all potential abnormal events in real time, ensuring timely response and handling.

[0082] During each scheduling cycle, the job check engine retrieves completed job information from the job scheduling platform and dynamically assigns RPA robots to perform task checks. The RPA robots invoke local task scripts to retrieve log data, perform checks, and feed the results back to the job check engine. Based on this feedback, the job check engine determines whether to reschedule unfinished tasks and detects anomalies in the logs. Any anomalies are reported to the alarm monitoring platform to ensure timely resolution.

[0083] Step 2: Establish an optimization model for job inspection task allocation:

[0084] Specifically, considering the job allocation priority and the maximum number of job checks performed by RPA within a cycle, a job check task allocation optimization model is established with the objective function minimizing the resource usage cost of RPA, the penalty cost of not allocating jobs according to the continuity rule, and the penalty cost of not assigning jobs to checks:

[0085] 2.1 Model assumptions are as follows:

[0086] 1. The maximum number of jobs that each RPA robot can inspect per cycle is fixed;

[0087] 2. The inspection time for each job depends on the complexity of the job, which can be obtained from historical data;

[0088] 3. RPA robots can process multiple jobs in parallel, but there are certain resource limitations.

[0089] 4. Jobs that are not checked in time can be accumulated to the next cycle;

[0090] 5. The time it takes for the RPA robot to log in and out of the log server at the beginning and end of each inspection cycle is negligible.

[0091] 6. At the beginning of each cycle, the robot has completed the inspection task of the previous inspection cycle.

[0092] 2.2 The symbols of known variables and decision variables in the model are explained as follows:

[0093] Known variables:

[0094] c r : the unit time cost of the rth RPA resource;

[0095] pj: penalty cost of the jth job not being checked according to the continuity rule;

[0096] q: the unit penalty cost of not checking the job;

[0097] t rj : RPAr checks the time of job j;

[0098] a rj : the probability of RPAr checking whether job j is successful in historical data;

[0099] T N : The time window width of each inspection cycle.

[0100] Decision variables:

[0101] x rj : 1 if RPAr is assigned to check job j, 0 otherwise.

[0102] 2.3 The model constraints required in the model are as follows:

[0103] 1. When the RPA robot is not fully loaded, a robot is assigned to each job for inspection within the cycle:

[0104]

[0105] 2. The number of tasks assigned to each robot during an inspection cycle must not exceed its maximum number of inspections:

[0106]

[0107] 3. Tasks that cannot be assigned for inspection in time during the K-1 cycle should be assigned with a higher priority during the K inspection cycle than tasks to be assigned in this cycle:

[0108]

[0109] 2.4 The objective function modeling process is as follows:

[0110] The objective function aims to minimize the total cost Z, including the RPA resource usage cost C r , the penalty cost C for not allocating tasks according to the rules p and the penalty cost C for not checking the job u :

[0111]

[0112] Step 3: Find the most cost-optimized solution:

[0113] Specifically, after the start time of the scheduling cycle K, a two-stage hybrid metaheuristic algorithm is used to solve the problem based on the established job inspection task allocation optimization model. This algorithm combines strategies such as initial solution generation, neighborhood search, solution perturbation, and solution acceptance to find the most cost-optimal solution under three dimensions: resource constraints, job continuity rules, and penalty costs for unassigned inspections. The two-stage hybrid metaheuristic algorithm for solving the model is as follows: Figure 3 As shown, the solution process is as follows:

[0114] 3.1 Initial solution generation:

[0115] This stage quickly generates a feasible solution to provide a starting point for neighborhood search. The present invention uses a greedy strategy to generate this initial solution. The optimization goals are as follows:

[0116]

[0117] satisfy:

[0118]

[0119] The generation of the initial solution is based on a greedy strategy, which tries to select the RPA with the lowest cost to perform the task and quickly generate a feasible solution, as shown in Table 1;

[0120] Table 1 Initial solution generation stage

[0121]

[0122]

[0123] 3.2 Neighborhood Search;

[0124] Based on the initial solution, a better solution is found by modifying the solution locally. This stage includes large-scale search, solution acceptance criteria, and solution perturbation strategies.

[0125] 3.2.1 Large Neighborhood Search

[0126] In each iteration, a certain percentage of RPA tasks are selected for reset and re-optimization. The steps are as follows:

[0127] 1. From the current solution x rj Randomly select k tasks to be assigned for reset;

[0128] 2. For each selected task j, reallocate it to the RPA with the lowest cost.

[0129] Redistribution formula:

[0130]

[0131] Neighborhood search uses local modifications to find optimal solutions, as shown in Table 2. In each iteration, a certain percentage of tasks are reassigned to the RPA with the lowest cost. During this phase of task reassignment and reallocation, some tasks (Task2 and Task4) were reassigned to different RPAs in an effort to reduce the overall cost. Although the cost of some tasks increased, the overall cost was reduced through reallocation.

[0132] Table 2: The first iteration of the neighborhood search phase

[0133]

[0134] 3.2.2 Acceptance criteria for updated solutions

[0135] Use the acceptance criterion of simulated annealing to decide whether to accept the new solution. That is, if the total cost of the new solution Cost(x (new) ) <Cost(x (current) )or Then receive the new solution x obtained after the optimization operation (new) Among them, x (current) represents the solution before optimization, ΔCost is the change in cost, T P Refers to the temperature, which is used to control the probability of receiving a poor solution.

[0136] After each iteration, the algorithm decides whether to accept the new solution based on the cost change ΔCost and the simulated annealing criterion. If the cost of the new solution is lower, it is accepted directly; if the cost increases, it is accepted with a certain probability P.

[0137] The probability P of accepting a poor solution is controlled by the simulated annealing criterion, which is as follows:

[0138]

[0139] Table 3 Solution acceptance criteria stage

[0140] Task Currently assigned RPA Initial cost accept Task1 RPA1 10 Yes Task2 RPA1 12 Yes Task3 RPA3 8 Yes Task4 RPA2 14 No Task5 RPA2 14 Yes

[0141] The decision of whether to accept a worse solution is made by calculating the cost change and the random number. From the results in Table 3, we can see that the new solution of Task 4 is not accepted because it increases the total cost.

[0142] 3.3 Perturbation of the solution

[0143] In order to escape from the local optimum, the current solution is regularly Make a disturbance, denoted as Randomly select k tasks and redistribute them. The results of redistribution after perturbation are shown in Table 4:

[0144]

[0145] Table 4 Perturbation phase of the solution

[0146]

[0147]

[0148] 3.4 Solution

[0149] After each iteration, the algorithm checks the following termination criteria: 1. The maximum number of iterations has been reached; 2. The change in the current solution is less than a predetermined error range. If the termination criteria are met, the algorithm terminates; otherwise, it returns to the iterative loop. The final solution is considered the optimal solution.

[0150] Table 5 Final solution and convergence

[0151] Task Final assigned RPA Final cost Final time Task1 RPA1 10 5 Task2 RPA1 12 6 Task3 RPA3 8 4 Task4 RPA2 14 5 Task5 RPA2 14 7

[0152] Step 4: Conduct work inspection:

[0153] Specifically, after the start of scheduling cycle K, according to the optimal allocation solution obtained in steps 2 and 3, RPA robots will sequentially perform job checks based on the assigned task priorities and inspection plans. Each RPA robot will call a local task acquisition script to obtain information about the inspection job to be executed by the local RPA from the job scheduling platform. After obtaining this information, the job check begins. After logging in to obtain log results, the RPA robot proactively calls the script on the RPA inspection machine to push the job check results to the job check engine. If the job check succeeds, the RPA will feedback the results to the job check engine. If the check succeeds, the job will be marked as not requiring rescheduling in the current cycle. If the check fails, the RPA will report the reason for the failure, and the job check engine will decide whether to retry the job immediately or reschedule it in the next cycle. In addition, if any problems occur while retrieving job information or logs, the system will retain the failure record for subsequent scheduling adjustments and manual intervention. The job check engine analyzes the text content based on pre-set alarm keywords and ignore keywords. If any abnormal logs are found, an alarm is generated and pushed to the alarm monitoring platform.

[0154] Corresponding to the aforementioned embodiment of a batch job log checking method based on RPA collaboration, the present invention also provides an embodiment of a batch job log checking device based on RPA collaboration.

[0155] See also Figure 4 An embodiment of the present invention provides a batch job log checking device based on RPA collaboration, including a memory and one or more processors. The memory stores executable code. When the processor executes the executable code, it is used to implement a batch job log checking method based on RPA collaboration in the above embodiment.

[0156] The embodiment of the batch job log inspection device based on RPA collaboration provided by the present invention can be applied to any device with data processing capabilities, and the device with data processing capabilities can be a device or apparatus such as a computer. The device embodiment can be implemented through software, or through hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of any device with data processing capabilities in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory for execution. From the hardware level, if Figure 4 As shown in the figure, it is a hardware structure diagram of any device with data processing capability where the batch job log inspection device based on RPA collaboration provided by the present invention is located. Figure 4In addition to the processor, memory, network interface, and non-volatile memory shown, any device with data processing capabilities in which the apparatus in the embodiment is located may also include other hardware, generally based on the actual functions of the device with data processing capabilities, which will not be described in detail.

[0157] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0158] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present invention. A person of ordinary skill in the art can understand and implement the present invention without inventive work.

[0159] An embodiment of the present invention further provides a computer-readable storage medium having a program stored thereon. When the program is executed by a processor, a batch job log checking method based on RPA collaboration in the above embodiment is implemented.

[0160] The computer-readable storage medium may be an internal storage unit of any device with data processing capabilities described in any of the aforementioned embodiments, such as a hard disk or memory. The computer-readable storage medium may also be an external storage device of any device with data processing capabilities, such as a plug-in hard disk, a smart media card (SMC), an SD card, a flash card, etc. equipped on the device. Furthermore, the computer-readable storage medium may also include both an internal storage unit and an external storage device of any device with data processing capabilities. The computer-readable storage medium is used to store the computer program and other programs and data required by any device with data processing capabilities, and may also be used to temporarily store data that has been output or is to be output.

[0161] The present invention also provides a computer program product, including a computer program. When the computer program is executed by a processor, it implements the batch job log checking method based on RPA collaboration.

[0162] The above embodiments are used to illustrate the present invention rather than to limit the present invention. Any modifications and changes made to the present invention within the spirit of the present invention and the protection scope of the claims shall fall within the protection scope of the present invention.

Claims

1. A batch job log inspection method based on RPA collaboration, characterized in that: The steps include: Step 1: Collect the data and information required for the current cycle log inspection task allocation decision, including the set of unassigned inspection jobs, the set of RPAs, and the completion status of a particular inspection task. Step 2: Establish a job check task allocation optimization model: Taking into account the job allocation priority and the maximum number of job checks performed by the RPA within a cycle, the job check task allocation optimization model is established with the objective function minimizing the RPA resource usage cost, the penalty cost for not assigning jobs according to the continuity rule, and the penalty cost for not assigning jobs to checks. The constraints for establishing the optimization model for job inspection task allocation are as follows: 1) When the RPA robot is not fully loaded, a robot is assigned to each job for inspection within the cycle: Where m is the number of RPA robots, r is the currently available RPA, and x rj Generates the elements of a 0-1 matrix for the inspection task, if RPAr is assigned to inspection job j, then x rj is 1, otherwise x rj is 0, U K R is the set of jobs that were not assigned for inspection in time due to RPA resource limitations in the previous cycle. K The RPA set currently available for job inspection; 2) The number of tasks assigned to each robot during an inspection cycle must not exceed its maximum number of inspections: Among them, t rj Time for checking job j for RPAr, T N The time window width for each inspection cycle; 3) Tasks that cannot be assigned for inspection in time during the K-1 cycle should be assigned with a higher priority than the tasks to be assigned in this cycle during the K inspection cycle: The objective function modeling process of establishing the job inspection task allocation optimization model is as follows: The objective function aims to minimize the total cost Z, including the RPA resource usage cost C r , the penalty cost C for not allocating tasks according to the rules p and the penalty cost C for not checking the job u : Where n is the number of inspection tasks, p j is the penalty cost of the jth job not being checked according to the continuity rule, a rj is the probability of RPAi checking whether job j is successful in historical data, and q is the unit penalty cost of the job not being checked; Step 3: Find the cost-optimal solution: Use a two-stage hybrid metaheuristic algorithm to solve the task inspection task allocation optimization model; Step 4: Perform job checks: After the start of scheduling cycle K, the RPA robot performs job checks in sequence according to the assigned task priority and inspection plan, following the optimal allocation solution obtained in steps 2 and 3. When the job check succeeds, the RPA robot feeds the results back to the job check engine. The job check engine analyzes the text content based on pre-set alarm keywords and ignore keywords. If any abnormal logs are found, an alarm is generated and pushed to the alarm monitoring platform.

2. According to the RPA collaboration-based batch job log checking method of claim 1, it is characterized in that: The information that needs to be collected in step 1 also includes: the time window width T of each inspection cycle N , the unit cost of the RPA resource pool, whether each RPA resource has executed a check task in the previous cycle, a 0-1 matrix is generated. If the RPA has executed the task in the previous cycle, the matrix element is 1, otherwise the matrix element is 0, as well as the probability A of whether the RPA successfully executes a certain check task in the historical data and the time when the RPA checks a single job log.

3. According to the RPA collaboration-based batch job log checking method of claim 1, it is characterized in that: In step 2, the assumptions for establishing the optimization model for job inspection task allocation are as follows: 1) The maximum number of jobs that each RPA robot can check in each cycle is fixed; 2) The inspection time for each job depends on the complexity of the job, which is obtained from historical data; 3) RPA robots can process multiple jobs in parallel, but they are subject to resource limitations. 4) Jobs that are not checked in time can be accumulated to the next cycle; 5) The time it takes for the RPA robot to log in and out of the log server at the beginning and end of each inspection cycle is negligible; 6) At the beginning of each cycle, the robot has completed the inspection task in the previous inspection cycle.

4. According to the RPA collaboration-based batch job log checking method of claim 1, it is characterized in that: In step 3, the two-stage hybrid metaheuristic algorithm for solving the model is further processed as follows: 3.1) Initial solution generation This stage quickly generates a feasible solution to provide a starting point for neighborhood search and uses a greedy strategy to generate an initial solution. The optimization goals are as follows: 3.2) Neighborhood search; Based on the initial solution, a better solution is found by locally modifying the solution; the details are as follows: From the solution x rj Randomly select k tasks to be assigned and reset; for each selected task j, reallocate it to the RPA with the lowest cost, and get the updated solution Redistribution formula: Use the acceptance criterion of simulated annealing to decide whether to accept the new solution; that is, if the total cost of the new solution Cost(x (new) )<Cost(x (current) )or Then receive the new solution x obtained after the optimization operation (new) ; where x (current) represents the solution before optimization, ΔCost is the change in cost, T P is the probability of controlling the reception of a poor solution; After each iteration, the algorithm decides whether to accept the new solution based on the cost change ΔCost and the simulated annealing criterion. If the cost of the new solution is lower, it is accepted directly. If the cost increases, it is accepted with a certain probability. 3.3) Perturbation of the solution In order to escape from the local optimum, the current solution is regularly Make a disturbance, denoted as Randomly select k tasks and redistribute them; redistribute after perturbation: 3.4) Solution After each iteration, the termination condition is checked: 1) the set maximum number of iterations is reached; 2) the change in the current solution is less than the predetermined error range; if the termination condition is met, the algorithm ends; otherwise, it returns to the iterative loop, and the final solution is the optimal solution.

5. A batch job log checking device based on RPA collaboration, comprising a memory and one or more processors, wherein the memory stores executable code, characterized in that: When the processor executes the executable code, it implements a batch job log checking method based on RPA collaboration according to any one of claims 1 to 4.

6. A computer-readable storage medium having a program stored thereon, characterized in that: When the program is executed by a processor, a batch job log checking method based on RPA collaboration according to any one of claims 1 to 4 is implemented.

7. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the batch job log checking method based on RPA collaboration as described in any one of claims 1 to 4 is implemented.

Images