A method for RPA cluster anomaly attribution analysis

Abstract

This invention relates to an RPA cluster anomaly attribution analysis method, belonging to the field of RPA anomaly handling technology. The method includes: for each RPA process in the RPA cluster, splitting the RPA process into multiple preset process breakpoints, setting anomaly verification rules and evidence collection methods for each process breakpoint, and identifying the first abnormal process breakpoint according to the breakpoint sequence; collecting evidence of the first abnormal process breakpoint and constructing an abnormal process breakpoint fingerprint; collecting the abnormal process breakpoint fingerprints of the first abnormal process breakpoint of each RPA process in the RPA cluster within a preset time window; and performing attribution analysis on all the first abnormal process breakpoints collected within the preset time window to obtain the anomaly cause. Compared with existing technologies, this method can improve the accuracy and processing efficiency of RPA cluster anomaly attribution.

Description

Technical Field

[0001] This invention relates to the field of RPA anomaly handling technology, and specifically to an RPA cluster anomaly attribution analysis method. Background Technology

[0002] In large hospitals or medical groups, a large number of RPA robots often handle repetitive tasks such as registration verification, medical record archiving, test result feedback, image downloading, medical insurance reconciliation, and follow-up data synchronization. Once the system is upgraded, there are network fluctuations, interface timeouts, login failures, or changes in page structure, a large number of anomalies can emerge in a short period. However, current handling methods mainly rely on error logs, error screenshots, or manual review to troubleshoot each error, which is inefficient. Furthermore, the same root cause may manifest as different error messages in different processes, making it difficult to accurately attribute the cause based solely on error codes or keywords. Summary of the Invention

[0003] The technical problem to be solved by this application is to provide an RPA cluster anomaly attribution analysis method, which has the characteristics of improving the accuracy and processing efficiency of RPA cluster anomaly attribution.

[0004] In a first aspect, one embodiment provides an RPA cluster anomaly attribution analysis method, including:

[0005] For each RPA process in the RPA cluster, the RPA process is broken down into multiple preset process breakpoints, and exception verification rules and evidence collection methods are set for each process breakpoint.

[0006] Based on the aforementioned anomaly verification rules and evidence collection methods, the first abnormal process breakpoint is identified according to the order of process breakpoints.

[0007] Collect evidence of the first abnormal process breakpoint and construct the abnormal process breakpoint fingerprint;

[0008] Collect the abnormal process breakpoint fingerprint of the first abnormal process breakpoint of each RPA process in the RPA cluster within a preset time window;

[0009] Attribution analysis is performed on all the first abnormal process breakpoints collected within the preset time window to obtain the cause of the abnormality.

[0010] The beneficial effects of this invention are:

[0011] Because each RPA process in the RPA cluster is broken down into multiple preset process breakpoints, and anomaly verification rules and evidence collection methods are set for each process breakpoint, the use of process breakpoints and evidence chains makes the attribution results easier to interpret and more suitable for engineering implementation and manual review. Since the first abnormal process breakpoint of each RPA process is collected, it effectively avoids mistaking outcome errors for the true root cause, reducing misjudgments and improving anomaly localization efficiency. Furthermore, by collecting the anomaly breakpoint fingerprints of the first abnormal process breakpoint of each RPA process in the RPA cluster within a preset time window, and performing attribution analysis on all the first abnormal process breakpoints collected within the preset time window to obtain the anomaly cause, it is possible to more effectively identify the common fault domains behind batch anomalies, making it more suitable for complex scenarios like medical RPA with multiple systems, multiple dependencies, and multiple concurrent processes. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of an RPA cluster anomaly attribution analysis method according to an embodiment of this application;

[0013] Figure 2 This application Figure 1 A schematic diagram of the method flow of one embodiment of step S10;

[0014] Figure 3 This application Figure 1 A schematic diagram of the method flow for one embodiment of step S20. Detailed Implementation

[0015] The present invention will now be described in further detail with reference to specific embodiments and accompanying drawings. Similar elements in different embodiments are referred to by associated similar element reference numerals. In the following embodiments, many details are described to facilitate a better understanding of this application. However, those skilled in the art will readily recognize that some features may be omitted in different situations, or may be replaced by other elements, materials, or methods. In some cases, certain operations related to this application are not shown or described in the specification. This is to avoid obscuring the core parts of this application with excessive description. For those skilled in the art, detailed description of these related operations is not necessary; they can fully understand the related operations based on the description in the specification and general technical knowledge in the art.

[0016] Furthermore, the features, operations, or characteristics described in the specification can be combined in any suitable manner to form various embodiments. At the same time, the steps or actions in the method description can be rearranged or adjusted in a manner obvious to those skilled in the art. Therefore, the various orders in the specification and drawings are only for the clear description of a particular embodiment and do not imply a necessary order, unless otherwise stated that a particular order must be followed.

[0017] The serial numbers assigned to components in this document, such as "first" and "second," are used only to distinguish the described objects and have no sequential or technical meaning. The terms "connection" and "linkage" used in this application, unless otherwise specified, include both direct and indirect connections (linkages).

[0018] To facilitate the explanation of the inventive concept of this application, the RPA anomaly attribution technology will be briefly described below.

[0019] Current methods for attributing RPA anomalies involve analyzing error codes or keywords based on the apparent nature of the RPA error to determine the cause and address it. Current attribution analysis collects each anomaly point in the RPA process and analyzes each one to achieve attribution. However, the applicant's research revealed that RPA executes in a chain; if one process point fails, subsequent page redirects, field reads, API calls, file generation, or database writes may continue running on the premise of the error, resulting in a series of new errors. However, most of these subsequent errors are merely outcome-related, not the true root cause. Therefore, non-first anomalies may be derived or accompanying anomalies caused by the first anomaly. Since these derived or accompanying anomalies are not primary anomalies, they lack research value, and continuous research could lead to misjudgment of the anomaly cause and consume excessive computing resources.

[0020] In view of this, this application provides an RPA cluster anomaly attribution analysis method. For each RPA process in the RPA cluster, the RPA process is broken down into multiple preset process breakpoints, and anomaly verification rules and evidence collection methods are set for each process breakpoint. The method uses process breakpoints and evidence chains, making the attribution results easier to interpret and more suitable for engineering implementation and manual review. Since the first abnormal process breakpoint of each RPA process is collected, it effectively avoids mistaking outcome errors for the true root cause, reducing misjudgments and improving anomaly localization efficiency. Because it collects the abnormal process breakpoint fingerprints of the first abnormal process breakpoint of each RPA process in the RPA cluster within a preset time window, and performs attribution analysis on all the first abnormal process breakpoints collected within the preset time window to obtain the anomaly cause, it can more effectively identify the common fault domain behind batch anomalies, making it more suitable for complex scenarios such as medical RPA with multiple systems, multiple dependencies, and multiple concurrent processes.

[0021] Please refer to Figure 1 One embodiment of this application provides an RPA cluster anomaly attribution analysis method, including:

[0022] Step S10: For each RPA process in the RPA cluster, the RPA process is divided into multiple preset process breakpoints, and the exception verification rules and evidence collection methods for each process breakpoint are set.

[0023] In this embodiment, the RPA cluster contains multiple parallel-running RPA processes, and each parallel-running RPA process is divided into multiple preset process breakpoints. In one embodiment, dividing the RPA process into multiple preset process breakpoints includes: dividing the RPA process into multiple process breakpoints by process identifier, process version identifier, a set of process breakpoints arranged in execution order, a set of expected verification conditions corresponding to each process breakpoint, a set of shared dependency resources associated with each process breakpoint, and a set of waiting time limits, retry counts, and evidence triggering strategies for each process breakpoint.

[0024] The core of process breakpoint decomposition is not simply dividing the process into segments, but rather clearly deconstructing how the existing RPA process runs, then identifying the key monitoring points and creating a verifiable sequence of process breakpoints. For ease of explanation later, the process breakpoint model can be denoted as:

[0025] BM=<Fid, Ver, {Bi}, {Ei}, {Ri}, {Ti}> ;

[0026] Wherein, BM represents the process breakpoint model, Fid represents the process identifier, Ver represents the process version identifier, {Bi} represents the set of process breakpoints arranged in execution order, {Ei} represents the set of expected verification conditions corresponding to each process breakpoint, {Ri} represents the set of shared dependent resources associated with each process breakpoint, and {Ti} represents the set of waiting time limits, retry counts, and evidence triggering strategies for each process breakpoint.

[0027] In one embodiment of this application, the process breakpoints that can be broken down into RPA processes may include: login preparation stage, page loading stage, data reading stage, core business operation stage, submission confirmation stage, and result write-back stage.

[0028] Those skilled in the art will understand that the above-described process breakpoints are merely a general framework to aid understanding, and are not fixed at only six stages. In actual use, there can be fewer or more stages; the key is to ultimately obtain a chain of breakpoints arranged in the order of execution.

[0029] In one specific embodiment of this application, please refer to Figure 2 Step S10 may include:

[0030] Step S101: Read the target RPA process script, component configuration and runtime orchestration information, restore the original execution path of the process, and identify the execution actions included.

[0031] In one embodiment, the actions performed may include specific actions such as opening a page, switching pages, logging in to an account, querying data, reading fields, calling an API, uploading or downloading files, accessing a database, submitting confirmation, and writing back the results.

[0032] Step S102: Extract candidate breakpoints from the executed actions.

[0033] Any location that causes a critical change in the process state is considered a candidate breakpoint. This critical change includes at least entering a new page, initiating a new request, reading critical data, writing critical fields, generating a result file, writing to a database, or entering a shared dependent resource.

[0034] Step S103: Select key breakpoints from the candidate breakpoints as process breakpoints.

[0035] Prioritize retaining locations where failure would cause the process to veer off course and trigger a chain reaction of anomalies in subsequent steps. These should include at least shared dependency entry points, cross-system interaction points, critical data writing points, result generation points, and nodes that are most frequently monitored during manual troubleshooting.

[0036] Step S104: Generate a unique process breakpoint number for each process breakpoint according to the execution order, and establish the connection relationship between the process breakpoints so that each process breakpoint forms a process breakpoint sequence that can be verified sequentially.

[0037] Step S105: Establish expected verification conditions for each process breakpoint.

[0038] The expected verification conditions clarify what evidence should appear when the process breakpoint passes normally, what evidence will be missing when it fails abnormally, or what conflicting evidence that is inconsistent with the expectations will appear.

[0039] Step S106: Configure an evidence collection strategy for each process breakpoint.

[0040] This evidence collection strategy clarifies which pages, interfaces, fields, files, databases, or authentication evidence should be collected when the process reaches a breakpoint, as well as the corresponding collection timing, waiting time limit, number of retries, and supplementary collection rules.

[0041] Based on the above process breakpoint decomposition and analysis, each execution action can record the following information: action name, system or page, input object, output object, preceding action, subsequent action, whether it depends on shared resources, and expected result upon normal completion. In this way, the originally vague business description is broken down into a specific chain of analyzable actions. For example, the name "image download" is very broad, but in actual modeling, it can be reduced to a set of sequentially arranged execution actions such as "open login page, enter username and password, submit login, wait for homepage to load, enter image query page, enter check number, execute query, wait for result list generation, trigger download request, wait for interface return, confirm file generation, and write back download status." Therefore, it is more conducive to anomaly attribution analysis.

[0042] Based on the above, in one embodiment, the attributes of each process breakpoint Bi can be represented as:

[0043] Bi =<Bid, Stage, Act, Prev, Next, Sys, Dep, Rule, Wait, Retry> ;

[0044] Wherein, Bid is the process breakpoint number, Stage is the execution stage, Act is the action type, Prev is the preceding process breakpoint, Next is the succeeding process breakpoint, Sys is the associated business system type, Dep is the associated shared dependency resource identifier, Rule is the process breakpoint determination rule, Wait is the process breakpoint waiting time limit, and Retry is the number of retries allowed after a process breakpoint failure.

[0045] As one embodiment of this application, in order to make the process breakpoint model more reusable and easier to compare across processes, the method of splitting an RPA process into multiple preset process breakpoints may further include:

[0046] Configure at least one page class, interface class, field class, file class, database class, or authentication class evidence template for each process breakpoint; establish a mapping relationship between process breakpoints and shared dependent resources, including unified login entry, page template version, interface service node, database connection pool, file sharing directory, message middleware, network node, or authentication service; establish standardized naming for semantically equivalent process breakpoints in different processes, such as "homepage loading breakpoint after login", "receipt generation breakpoint after submission", and "database write confirmation breakpoint", to facilitate cross-process comparison; establish separate process breakpoint models for different versions of the same process to avoid breakpoint judgment distortion caused by page template upgrades, field rule changes, or interface version switching.

[0047] In one specific embodiment, different types of medical RPA processes can be configured with breakpoints and verification conditions according to a process template, including:

[0048] For login-related processes, breakpoints can be set sequentially: "Open Login Page Breakpoint", "Submit Account and Password Breakpoint", and "Homepage Loading Breakpoint". The "Open Login Page Breakpoint" verifies whether the login page title or login box element appears; the "Submit Account and Password Breakpoint" verifies whether a request and response are generated after the login button is clicked; and the "Homepage Loading Breakpoint" verifies whether the homepage welcome text, menu tree, user name label, or session token is valid.

[0049] For query and download processes, you can set breakpoints in sequence: "Query condition input breakpoint", "Query result list generation breakpoint", "Download trigger breakpoint", and "File generation breakpoint". Among them, the "Query result list generation breakpoint" verifies whether the number of rows in the result table is greater than zero or whether the result area appears; the "Download trigger breakpoint" verifies whether the download request has been issued and returned an acceptance mark; and the "File generation breakpoint" verifies whether the corresponding file has been generated in the target directory within the specified time.

[0050] For data submission and write-back processes, you can set "Target Record Open Breakpoint", "Field Backfill Breakpoint", "Submission Action Breakpoint", "Receipt Confirmation Breakpoint", and "Write Database Confirmation Breakpoint" in sequence. Among them, "Field Backfill Breakpoint" verifies whether the key field has been updated from the original value to the target value, "Receipt Confirmation Breakpoint" verifies whether the page pops up a success message, whether the receipt number is generated, or whether the interface returns a success code, and "Write Database Confirmation Breakpoint" verifies whether the database status has been updated.

[0051] For cross-system synchronization processes, you can set "Source System Read Breakpoint", "Intermediate Data Conversion Breakpoint", "Target System Write Breakpoint", and "Synchronization Completion Breakpoint" in sequence. Among them, "Source System Read Breakpoint" verifies whether the source data is successfully obtained, "Intermediate Data Conversion Breakpoint" verifies whether the field mapping result is complete, "Target System Write Breakpoint" verifies whether the target interface or target page is successfully submitted, and "Synchronization Completion Breakpoint" verifies whether the record status of the target system is consistent with the status of the source system.

[0052] For batch reconciliation or batch verification processes, you can set "batch task receiving breakpoint", "item-by-item verification loop breakpoint", "abnormal record output breakpoint", and "summary result write-back breakpoint". Among them, "item-by-item verification loop breakpoint" verifies whether the processing count continues to advance, "abnormal record output breakpoint" verifies whether the abnormal list file or abnormal table record is generated, and "summary result write-back breakpoint" verifies whether the summary quantity is consistent with the detailed quantity.

[0053] Based on any of the above embodiments, the abnormal process breakpoint identification method outputs no longer a general process description, but a structured process breakpoint model that can be directly used for the subsequent first abnormal process breakpoint location and process breakpoint fingerprint generation. It adopts the process breakpoint and evidence chain approach, so the attribution results are easier to interpret and more suitable for engineering implementation and manual review.

[0054] Step S20: Based on the anomaly verification rules and evidence collection methods, identify the first abnormal process breakpoint according to the order of process breakpoints.

[0055] For each process breakpoint, it is possible to predefine "what constitutes success and what constitutes failure". These verification conditions can be divided into two categories: first, the necessary evidence condition, which is used to determine whether a certain piece of evidence exists; and second, the consistency evidence condition, which is used to determine whether the collected evidence is consistent with the expected state.

[0056] Therefore, anomaly verification rules and evidence collection methods may include at least one or more of the following: the appearance of a specific page element on the current page, a specific button being clickable, the interface returning the expected state or expected field, a change in the value of a key field, successful generation or download of a file, writing of a database record, and the login status or token still being valid.

[0057] To determine whether a specific page element appears on the current page, a set of location rules for the target element can be pre-saved in the process breakpoint model. These location rules can include element ID, name, XPath, CSS selectors, text anchors, control class names, automation IDs, relative position expressions, or image template features. When RPA execution reaches this process breakpoint, it polls each location rule according to priority within a preset waiting time window. If any location rule successfully locates the target element and satisfies the following conditions: the element is visible, the element size is greater than zero, the element is not hidden, or the target text recognition similarity is higher than a preset threshold, then the page element is determined to have appeared. Specifically, for browser page scenarios, element recognition is preferably achieved through DOM tree parsing, element handles returned by the browser driver, or key fragment matching of the page source code. For client interface scenarios, element recognition is preferably achieved through window handles, UI automation control trees, control class names, control text, or image recognition. For older system interfaces where structured control attributes cannot be directly read, it is preferable to use a screenshot followed by OCR recognition and template area comparison to determine whether the target element has appeared.

[0058] To determine whether a specific button is clickable, after the target button is identified, its operable state, disabled attribute, occluded state, focus state, and whether the expected page response occurs after clicking can be further checked. If the button exists but is grayed out, read-only, covered by a mask, or has no page response after clicking, the breakpoint is determined to fail.

[0059] To determine whether an interface returns the expected status or fields, the interface identifier, request method, status code whitelist, required field set, and field constraint expression can be pre-defined for the target interface in the process breakpoint model. When the response status code belongs to the expected set, and the key fields exist, the field types are correct, and the field values ​​satisfy non-empty, enumerated values, range values, or regular expression matching rules, the interface verification is deemed to have passed; otherwise, it is deemed as evidence of interface conflict.

[0060] To determine whether the values ​​of key fields have changed, the baseline field value V_before can be read before the process breakpoint is executed, and the result field value V_after can be read after the process breakpoint is executed. The relationship between the two can be determined according to the field rules. The field rules may include changes in value, values ​​remaining consistent, values ​​changing from empty to non-empty, status codes changing from processing to success, and quantities increasing or decreasing to the target range. The field validation is considered successful only when the baseline field value and the result field value meet the preset requirements.

[0061] To determine whether a file was successfully generated or downloaded, the system can detect whether the file was generated within a preset time window, provided that the target directory, target file name rules, or file type rules are known. Preferably, the system will further detect whether the file size is greater than the corresponding preset threshold, the file extension is correct, the last modification time is within the current running window, and the file can be opened or the hash value is stable, thereby eliminating false judgments caused by empty files, partially downloaded files, or historical residual files.

[0062] To determine whether a database record has been written, a write confirmation query statement or confirmation condition can be preset in the process breakpoint model. Confirmation conditions may include checking if the target record exists based on the business primary key, whether the record status field has been updated, whether the number of affected rows is greater than zero, whether the transaction has been successfully committed, and whether the write time falls within the current execution window. The write verification is considered successful only if at least one write confirmation condition is met.

[0063] Whether the login state or token is still valid can be determined by checking whether the current page redirects to the login page, whether the session cookie exists, whether the remaining validity period of the token is greater than the preset threshold, whether the authentication interface returns an unauthorized status code, and whether the unified authentication center returns an invalidation mark. When the login state is invalidated, the user is redirected back to the login page, the token expires, the session expires, or the authentication interface returns a 401 / 403 status.

[0064] Based on the above approach, step S20 is not simply collecting logs, but rather gathering sufficient evidence to determine whether a process has passed each breakpoint. In other words, it collects a structured evidence package bound to each breakpoint, rather than scattered logs. This structured evidence Ai can be represented as:

[0065] Ai =<RunID, Fid, Rid, Bi, Ts, Te, Log, Page, Api, Field, File, DB,Auth, Env>

[0066] Among them, RunID is the identifier of a single run instance, Fid is the identifier of the process breakpoint, Rid is the identifier of the robot or execution node, Bi is the current breakpoint number, Ts is the breakpoint start timestamp, Te is the breakpoint end timestamp, Log is the step log evidence, Page is the page status evidence, Api is the interface interaction evidence, Field is the key field evidence, File is the file result evidence, DB is the database status evidence, Auth is the login status or authentication evidence, and Env is the runtime environment evidence.

[0067] As one embodiment of this application, such as Figure 3 As shown, step S20 may include:

[0068] Step S201: When RPA reaches the moment before, during, or after any process breakpoint, trigger the corresponding evidence collection operation and establish an evidence collection session for this process breakpoint.

[0069] To ensure that the collected evidence can truly be used to determine the first abnormal breakpoint, the evidence collection triggering methods can include any one or more of the following: evidence collection before the process breakpoint, evidence collection after the process breakpoint, evidence collection triggered by timeout, supplementary evidence collection triggered by anomaly, and evidence collection comparing before and after retry. Specifically, evidence collection before the process breakpoint records the baseline state before the process breakpoint execution; evidence collection after the process breakpoint records the result state after the process breakpoint execution; evidence collection triggered by timeout records on-site evidence in scenarios where timeout occurs; supplementary evidence collection triggered by anomaly additionally collects screenshots, error pages, interface message summaries, and authentication redirection information when an anomaly is captured; and evidence collection comparing before and after retry distinguishes between one-time jitter faults and stability faults.

[0070] Step S202: Collect process breakpoint log evidence.

[0071] The process breakpoint log evidence includes the current process breakpoint number, action name, start time, end time, execution time, return status, exception text, number of retries, and the number of the last successful process breakpoint.

[0072] Step S203: Determine the breakpoint type involved in the current process breakpoint and collect the corresponding verification evidence.

[0073] When the breakpoint involved in the current process is a page-related breakpoint, the corresponding verification evidence includes page state evidence, including: any one or more of the following: recorded page address, window title, page template identifier, target element location expression, element existence, visibility, clickability, element text value, screenshot hash value, and page structure summary.

[0074] When the breakpoint involved in the current process is an interface request breakpoint, the corresponding verification evidence includes interface interaction evidence, including: any one or more of the following: record interface identifier, request method, target address, response status code, error code, key response fields, response time, return message digest, and service node identifier.

[0075] When the breakpoint involved in the current process is a field change breakpoint, a file generation breakpoint, or a database write breakpoint, the corresponding verification evidence includes result status evidence, including: any one or more of the following: the values ​​of key fields before and after execution, whether the fields have changed, file path, whether the file has been generated, file size, file checksum, database operation status, number of affected records, whether the primary key has been generated, and write time.

[0076] Step S204: Collect authentication and environmental evidence.

[0077] Authentication and environment evidence may include any one or more of the following: login session identifier, remaining token validity period, whether a redirect to the login page occurred, system type, runtime segment, data volume range, process version, robot identifier, execution host identifier, network node identifier, and shared dependent resource identifier.

[0078] Step S205: Locate the first abnormal process breakpoint based on the obtained evidence.

[0079] Once the process breakpoint model and evidence are obtained, we can start to find out which step the process first went astray in sequence, and finally determine the first abnormal process breakpoint.

[0080] In one embodiment, the judgment model B_break for the first abnormal process breakpoint can be represented as:

[0081] B_break = min { Bi | Verify(Ei, Ai) = 0};

[0082] Where Verify(Ei, Ai) represents the verification result of breakpoint Bi, which takes the value 1 when the verification passes and 0 when the verification fails. min { Bi | Verify(Ei, Ai) = 0} represents the breakpoint number with the smallest verification value of 0.

[0083] Based on the judgment model of the first abnormal process breakpoint, we are not concerned with what error the process finally reported, but rather with the position where the process first deviates from the normal state. Therefore, we take the "first abnormal breakpoint" as the primary attribution object, and mark subsequent failures as derived or accompanying anomalies, no longer using it as the core input for root cause judgment.

[0084] In some embodiments, Verify(Ei, Ai) can be evaluated sequentially starting from the initial breakpoint. When a breakpoint passes the verification, the next breakpoint is evaluated. When a breakpoint fails the first verification, it is recorded as the first abnormal candidate breakpoint B_candidate. Supplementary verification of B_candidate is performed, including waiting for window re-sampling, one or more retry evaluations, cross-validation of primary and secondary evidence, and review of the success status of the preceding breakpoint, to eliminate false anomalies caused by instantaneous loading jitter, evidence failure, or misidentification. If B_candidate still fails after supplementary verification, it is identified as the first abnormal breakpoint B_break, and its preceding successful breakpoint B_prev, the type of failed evidence, the associated resource identifier, and the failure timestamp are recorded. For breakpoints located after B_break, if the execution prerequisites upon which their failure depends have been broken at B_break, such failures are marked as derived anomalies E_follow, saved only as auxiliary on-site information, and not used as the primary input for root cause fingerprinting. Output the judgment result of "first abnormal process breakpoint + previous successful process breakpoint + evidence of first abnormal process breakpoint + list of derived exceptions".

[0085] In one specific embodiment, in a login scenario, the breakpoint sequence for a certain registration verification RPA process can be "open login page breakpoint B1", "submit account and password breakpoint B2", "homepage loading breakpoint B3", and "query patient information breakpoint B4". When the system detects that the authentication request has been sent after clicking login at B2, but the homepage menu tree does not appear within the waiting time window at B3, and the page jumps back to the login page, then B3 is identified as the first abnormal breakpoint; subsequent errors such as "patient query button does not exist" and "query results are empty" at B4 are all derived exceptions caused by the failure to successfully enter the homepage and are no longer considered as the root cause.

[0086] In one specific embodiment, in a query download scenario, the breakpoint sequence of a certain image download RPA process is: "Breakpoint B1 for filling in check number", "Breakpoint B2 for requesting download", "Breakpoint B3 for returning interface result", "Breakpoint B4 for generating file", and "Breakpoint B5 for writing back download result". When an interface status code of 500 or the critical field downloadUrl is detected at B3, B3 is immediately determined as the first abnormal process breakpoint; subsequently, B4's "No file generated in directory" and B5's "Failed to write back download success flag" are both derived exceptions caused by interface failure.

[0087] In one specific embodiment, in a page input scenario, the breakpoint sequence of a certain outpatient billing synchronous RPA is "Breakpoint B1 for opening the billing page", "Breakpoint B2 for locating patient information", "Breakpoint B3 for backfilling the fee field", "Breakpoint B4 for submitting confirmation", and "Breakpoint B5 for generating the receipt number". If it is found at B3 that the value of the target fee field does not change before and after execution, and the target input box is identified as read-only, then B3 is determined as the first abnormal process breakpoint; the subsequent unclickable submit button at B4 and the failure to generate a receipt number at B5 are both considered derived anomalies.

[0088] The collection of the first abnormal process breakpoint mentioned above can effectively avoid mistaking the result error as the real root cause, reduce misjudgment, and improve the efficiency of anomaly localization.

[0089] Step S30: Collect evidence of the first abnormal process breakpoint and construct the abnormal process breakpoint fingerprint.

[0090] After finding the first abnormal process breakpoint, the next step is not to immediately look at the final log, but to extract the most critical evidence around this first abnormal process breakpoint to construct an abnormal process breakpoint fingerprint. Evidence for an abnormal process breakpoint includes: the process breakpoint location number, the number of the last successful process breakpoint before this process breakpoint, the type of missing evidence, the type of conflicting evidence, the type of application system to which it belongs, the runtime segment, the data volume range, the identifier of shared dependent resources, whether it occurs synchronously across more than two processes, and whether it occurs synchronously across multiple robots.

[0091] Once we have evidence of the abnormal process breakpoint, we can construct the abnormal process breakpoint fingerprint, which can be represented as:

[0092] FP=<Fid, B_break, B_prev, E_miss, E_conflict, S_type, T_slot, D_band, R_dep> ;

[0093] Wherein, Fid represents the process breakpoint identifier, B_break represents the first abnormal process breakpoint, B_prev represents the last successful process breakpoint before the abnormal process breakpoint, E_miss represents the missing evidence type, E_conflict represents the conflict evidence type, S_type represents the application system type, T_slot represents the time window identifier, D_band represents the data volume range identifier, and R_dep represents the shared dependency resource identifier.

[0094] Step S40: Collect the abnormal process breakpoint fingerprint of the first abnormal process breakpoint of each RPA process in the RPA cluster within the preset time window.

[0095] As one embodiment of this application, the preset time window is the time of one cycle of the current RPA cluster operation, so as to better locate the cause of the current RPA cluster operation abnormality.

[0096] Step S50: Perform attribution analysis on all the first abnormal process breakpoints collected within the preset time window to obtain the cause of the abnormality.

[0097] When many anomalies occur simultaneously in the application system, the task at this step is to determine whether these anomalies are many independent problems or actually point to a common external fault domain.

[0098] In one embodiment of this application, the attribution analysis is not a simple comparison of error text, but rather a correlation analysis based on multiple abnormal breakpoint fingerprints. Therefore, in one embodiment of this application, step S50 includes:

[0099] Step S501: Determine whether there is a first abnormal process breakpoint above the first set threshold that depends on the same external resource. If so, perform batch attribution.

[0100] In some embodiments, external resources can be login portals, interfaces, database links, page templates, or network nodes, etc. That is, whether they all go through the same login portal, interface, database link, page template, or network node, etc. If not, it means that there is no common dependency and it can be handled as an independent exception.

[0101] Step S502: Determine whether there is a first abnormal process breakpoint above the second set threshold stuck at the same process breakpoint position. If so, perform batch attribution.

[0102] Based on breakpoint fingerprints, the location of each first abnormal process breakpoint can be determined. If multiple first abnormal process breakpoints appear at the same process breakpoint or the same type of abnormal breakpoint, for example, all stuck at the "homepage loading breakpoint after login", it means that they are not randomly broken in different places, but rather that they started to deviate from the same type of process position.

[0103] The applicant also found in their research that, even when stuck at the "homepage loading breakpoint after login," if multiple initial abnormal process breakpoints all resulted in the homepage menu not appearing, login status failing, or the page redirecting back to the login page, it further indicates that they are experiencing the same type of failure. If the breakpoints are the same but the reasons for failure are completely different, they cannot be simply categorized into the same fault domain.

[0104] Therefore, step S502 further includes: if there is a first abnormal process breakpoint above the second set threshold stuck at the same process breakpoint position, then determine whether there is a first abnormal process breakpoint above the third set threshold with the same missing evidence type or conflicting evidence type, and if so, perform batch attribution.

[0105] Step S503: Determine whether there is a first abnormal process breakpoint above the fourth set threshold that occurs simultaneously across two or more robots. If so, perform batch attribution.

[0106] If the anomaly only occurs in one robotic process, it may simply be due to a misconfiguration of that process or a problem with its environment. However, if the anomaly occurs in multiple robotic processes simultaneously, it is more likely that a shared external resource has encountered a problem. Therefore, step S503 is to determine whether the impact has spread.

[0107] As will be understood by those skilled in the art, steps S501 to S503 are not sequential and can be performed independently.

[0108] It should be noted that the first, second, third, and fourth setting thresholds mentioned above can be the same setting threshold, partially the same setting threshold, or all different setting thresholds. In addition, the setting thresholds can be a number or a proportion, and the specific settings are based on the actual needs of those skilled in the art, all of which are within the protection scope of this application.

[0109] Based on batch attribution, routine batch processing actions may include: 1. Refreshing login status or re-issuing authentication; 2. Switching to backup entry points, backup interfaces, or backup nodes; 3. Automatically relaxing waiting policies or reloading pages; 4. Updating page positioning rules; 5. Suspending downstream batch tasks that depend on the fault domain; 6. Pushing unified fault alarms to the corresponding system team.

[0110] The method in this application may also include: storing truly valuable information from the anomaly analysis and handling process in a knowledge base, such as: 1. breakpoint fingerprints; 2. fault domain tags; 3. triggering conditions; 4. corresponding handling actions; 5. handling results; 6. applicable process scope; 7. effective time and version information. This way, when a new anomaly occurs in the future, the historical fault domains and existing handling solutions can be matched based on the breakpoint fingerprints, eliminating the need to analyze from scratch each time.

[0111] Based on any of the above embodiments, the attribution results are easier to interpret and more suitable for engineering implementation and manual review. It can effectively avoid mistaking result-related errors as the real root cause, reduce misjudgments, improve the efficiency of anomaly localization, and more effectively identify the common fault domains behind batch anomalies. It is more suitable for complex scenarios such as medical RPA with multiple systems, multiple dependencies, and multiple concurrent processes.

[0112] One embodiment of this application provides a computer-readable storage medium storing a program, the stored program including methods that can be loaded by a processor and processed in any of the above embodiments.

[0113] Those skilled in the art will understand that all or part of the functions of the various methods in the above embodiments can be implemented by hardware or by computer programs. When all or part of the functions in the above embodiments are implemented by computer programs, the program can be stored in a computer-readable storage medium, which may include: read-only memory, random access memory, disk, optical disk, hard disk, etc., and the program is executed by a computer to achieve the above functions. For example, the program can be stored in the memory of a device, and when the program in the memory is executed by the processor, all or part of the above functions can be achieved. In addition, when all or part of the functions in the above embodiments are implemented by computer programs, the program can also be stored in a server, another computer, disk, optical disk, flash drive, or external hard drive, etc., and can be downloaded or copied to the memory of a local device, or the system of the local device can be updated. When the program in the memory is executed by the processor, all or part of the functions in the above embodiments can be achieved.

[0114] The above examples illustrate the present invention only to aid in understanding it and are not intended to limit the scope of the invention. Those skilled in the art can make various simple deductions, modifications, or substitutions based on the principles of this invention.

Claims

1. A method for attribution analysis of RPA cluster anomalies, characterized in that, include: For each RPA process in the RPA cluster, the RPA process is broken down into multiple preset process breakpoints, and exception verification rules and evidence collection methods are set for each process breakpoint. Based on the aforementioned anomaly verification rules and evidence collection methods, the first abnormal process breakpoint is identified according to the order of process breakpoints. Collect evidence of the first abnormal process breakpoint and construct the abnormal process breakpoint fingerprint; Collect the abnormal process breakpoint fingerprint of the first abnormal process breakpoint of each RPA process in the RPA cluster within a preset time window; Attribution analysis is performed on all the first abnormal process breakpoints collected within the preset time window to obtain the cause of the abnormality.

2. The RPA cluster anomaly attribution analysis method as described in claim 1, characterized in that, The method of splitting the RPA process into multiple preset process breakpoints includes: The RPA process is divided into multiple process breakpoints based on process identifier, process version identifier, a set of process breakpoints arranged in execution order, a set of expected verification conditions corresponding to each process breakpoint, a set of shared dependency resources associated with each process breakpoint, and a set of waiting time limits, retry counts, and evidence triggering strategies for each process breakpoint.

3. The RPA cluster anomaly attribution analysis method as described in claim 2, characterized in that, For each RPA process in the RPA cluster, the RPA process is divided into multiple preset process breakpoints, and exception verification rules and evidence collection methods are set for each process breakpoint, including: Read the target RPA process script, component configuration, and runtime orchestration information to restore the original execution path of the process and identify the execution actions it contains; Extract candidate breakpoints from the executed actions; Select key breakpoints from the candidate breakpoints and use them as process breakpoints; Generate a unique process breakpoint number for each process breakpoint according to the execution order, and establish the connection relationship between the process breakpoints so that the process breakpoints form a process breakpoint sequence that can be verified sequentially. Establish expected verification conditions for each process breakpoint; Configure an evidence collection strategy for each process breakpoint.

4. The RPA cluster anomaly attribution analysis method as described in any one of claims 1 to 3, characterized in that, The process breakpoints include the login preparation stage, page loading stage, data reading stage, core business operation stage, submission confirmation stage, and result write-back stage.

5. The RPA cluster anomaly attribution analysis method as described in claim 1, characterized in that, The anomaly verification rules and evidence collection methods include at least one or more of the following: the appearance of a specific page element on the current page, a specific button being clickable, the interface returning the expected state or expected field, a change in the value of a key field, successful generation or download of a file, writing of a database record, and the login status or token still being valid.

6. The RPA cluster anomaly attribution analysis method as described in claim 1 or 5, characterized in that, The method of identifying the first abnormal process breakpoint according to the order of process breakpoints based on the aforementioned anomaly verification rules and evidence collection methods includes: When RPA executes to any process breakpoint, within the time before, during, or after a preset time period, it triggers the corresponding evidence collection operation and establishes an evidence collection session for this process breakpoint. Collect process breakpoint log evidence, including: current process breakpoint number, action name, start time, end time, execution time, return status, exception text, number of retries, and the number of the last successful process breakpoint; Determine the breakpoint type involved in the current process breakpoint and collect corresponding verification evidence; the breakpoint types include page-related breakpoints, interface request breakpoints, field change breakpoints, file generation breakpoints, and database write breakpoints; Collect authentication and environmental evidence, including any one or more of the following: login session identifier, token remaining validity period, whether a redirect to the login page occurred, system type, runtime segment, data volume range, process version, robot identifier, execution host identifier, network node identifier, and shared dependent resource identifier; Locate the first abnormal process breakpoint based on the obtained evidence.

7. The RPA cluster anomaly attribution analysis method as described in claim 1, characterized in that, The evidence of abnormal process breakpoints includes: process breakpoint location number, the number of the last successful process breakpoint before the process breakpoint, the type of missing evidence, the type of conflicting evidence, the type of application system to which it belongs, the runtime segment, the data volume range, the shared dependency resource identifier, and whether it occurs synchronously across more than two robots. The abnormal process breakpoint fingerprint includes: FP=<Fid, B_break, B_prev, E_miss, E_conflict, S_type, T_slot, D_band, R_dep> ; Wherein, FP represents the fingerprint of the abnormal process breakpoint, Fid represents the process breakpoint identifier, B_break represents the first abnormal process breakpoint, B_prev represents the last successful process breakpoint before the abnormal process breakpoint, E_miss represents the missing evidence type, E_conflict represents the conflict evidence type, S_type represents the application system type, T_slot represents the time window identifier, D_band represents the data volume range identifier, and R_dep represents the shared dependency resource identifier.

8. The RPA cluster anomaly attribution analysis method as described in claim 1, characterized in that, The preset time window is the time for the current RPA cluster to run for one cycle.

9. The RPA cluster anomaly attribution analysis method as described in claim 7, characterized in that, Attribution analysis was performed on all the first abnormal process breakpoints collected within the preset time window to obtain the causes of the abnormalities, including: Determine if the first abnormal process breakpoint above the first set threshold depends on the same external resource; if so, perform batch attribution. Determine if there is a first abnormal process breakpoint above the second set threshold stuck at the same process breakpoint position; if so, perform batch attribution. Determine if there exists a first abnormal process breakpoint that exceeds the fourth set threshold and occurs simultaneously across two or more robots. If so, perform batch attribution.

10. The RPA cluster anomaly attribution analysis method as described in claim 9, characterized in that, The determination of whether there is a first abnormal process breakpoint above the second set threshold stuck at the same process breakpoint position, and if so, performing batch attribution, further includes: if there is a first abnormal process breakpoint above the second set threshold stuck at the same process breakpoint position, determining whether there is a first abnormal process breakpoint above the third set threshold with the same missing evidence type or conflicting evidence type, and if so, performing batch attribution.

Images