Intelligent centralized management and control platform multi-node anomaly detection method

Abstract

The application discloses a multi-node abnormality detection method of an intelligent centralized management and control platform, relates to the technical field of intelligent process automation centralized management and control, and generates a stage token for a business object, and binds the stage token to a business stage-execution node correlation graph, so that the processing states of the same business batch scattered in multiple execution nodes and multiple business stages are associated under the same batch identification; the platform generates an abnormal observation set according to stage token migration states, execution token distribution, stage state duration and abnormal fingerprints, and when multiple business stage nodes simultaneously have the abnormal observation set, the business stage nodes with token dependency relationships are screened according to the directed flow relationship of the current process template version, so that the abnormal source stage, the affected stage and the abnormal attribution category are determined, the stage stagnation state in the batch concurrent process is attributed to the corresponding business stage and the corresponding execution node, and a multi-node abnormality detection result associated with the business object is formed.

Description

Technical Field

[0001] This invention relates to the field of intelligent process automation centralized management and control technology, and in particular to a multi-node anomaly detection method for intelligent centralized management and control platforms. Background Technology

[0002] In business processes such as financial shared services, government service processing, bank operations, and customer service ticketing, RPA / low-code workflow centralized management platforms typically simultaneously schedule software robots, low-code workflow instances, interface services, OCR services, and manual approval endpoints to complete batch data entry, verification, submission, receipt retrieval, and archiving according to workflow templates. Multiple business objects within the same business batch are assigned to different execution nodes and flow concurrently through the business stages of data entry, verification, submission, approval, and archiving.

[0003] Existing multi-node anomaly detection typically relies on the running status of execution nodes, resource metrics, task execution duration, log keywords, script execution results, queue success / failure status, or task retries. Anomalies are identified through threshold alarms, process timeout checks, log aggregation, node health scoring, or failure retries. These methods primarily reflect the abnormal state of a single execution node, a single task item, or a single execution result.

[0004] When batch processes are executed concurrently, changes in external portal page fields, interface rate limiting, OCR recognition result delays, approval node backlogs, or batch invalidation of credentials may cause multiple business objects in the same business batch to remain at the same or adjacent business stages. At this time, a single execution node may still be in an online, waiting, polling, or forwarding state, and single-node resource indicators and script error codes are difficult to reflect the stage delay status at the business batch level.

[0005] When a platform judges anomalies based solely on the failure of a single execution node, task timeout, or alarm occurrence time, it is easy to categorize common anomalies at the business stage level as individual anomalies at the execution node level, triggering repeated restarts, node switching, or multiple task assignments. At the same time, the chronological relationship between the root cause business stage and the affected business stage is difficult to determine, resulting in a lack of complete stage flow basis for subsequent compensation, rollback, or manual takeover.

[0006] Therefore, in centralized management scenarios where multiple execution nodes concurrently process the same batch of business data, how to determine the source stage, affected stage, and attribution category of anomalies based on the relationship between business batches, business stages, execution nodes, and task status has become a technical problem that needs to be solved. Summary of the Invention

[0007] This application provides a multi-node anomaly detection method for an intelligent centralized management and control platform, which solves the problem of difficulty in locating the source of anomalies during stage delays in batch concurrent processes.

[0008] This invention provides a multi-node anomaly detection method for an intelligent centralized management and control platform, comprising: Parse the process template to generate business stage nodes, adjacent stage transition relationships, and directed transition relationships for the current process template version; Acquire business batch tasks, scheduling records, and execution receipts. The business batch tasks include multiple business objects, and generate stage tokens for the business objects. Generate a business stage-execution node association graph, and bind the stage token to the corresponding business stage node and the corresponding execution node; Under the same batch identifier, stage tokens are aggregated to obtain the stage token set corresponding to the business stage node and the execution token set corresponding to the execution node; An exception fingerprint is generated based on the process template version, business stage node, stage status, external object identifier, waiting object, and error category in the stage token; Based on the stage token migration status, execution token distribution, stage status duration, and anomaly fingerprint, stage tokens whose stage status duration reaches the business stage monitoring window are written into the anomaly observation set, and the anomaly source stage, affected stage, and anomaly attribution category are determined. When multiple business stage nodes have anomaly observation sets at the same time, the waiting state of subsequent business stage nodes depends on the completion state stage token of the preceding business stage node based on the directed flow relationship of the current process template version. Only business stage nodes with token dependency relationships are allowed to participate in the anomaly source stage sorting, and the business stage node with the earliest business flow order is determined as the anomaly source stage. When the business stage node participating in the anomaly source stage sorting is empty, the business stage node that generates the anomaly observation set will be marked as an anomaly source stage to be confirmed. Multi-node anomaly detection results are generated based on the anomaly source stage, affected stage, anomaly attribution category, anomaly fingerprint, business object identifier, and execution node identifier, and written into the anomaly handling queue.

[0009] In some embodiments, generating the business stage-execution node association graph includes: Business stage nodes are generated based on stage identifier data in the process template. The stage identifier data includes at least one of step code, step name, page identifier, interface identifier, approval node identifier, and script fragment identifier. Execution nodes are generated based on execution node identification data, wherein the execution node identification data includes at least one of software robot instance identifier, low-code process instance identifier, interface service identifier, OCR service identifier, and manual approval terminal identifier; Side data records are generated based on the scheduling relationship data in the scheduling records. The scheduling relationship data includes at least one of dispatch relationship, preemption relationship, retry relationship, transfer relationship and takeover relationship. The side data records record the batch identifier, business object identifier, business stage identifier, execution node identifier, dispatch time, receipt time and execution result. The edge data record is bound to the corresponding stage token, so that the flow path of the same business object between different business stage nodes is recorded by the business stage-execution node association graph.

[0010] In some embodiments, generating the stage token includes: When a business object enters a business phase node, a phase token for the entry status is generated. When a business object is dispatched to an execution node, the identifier of the corresponding execution node is written into the execution node identifier that carries the stage token; When a business object moves from the current business stage node to a subsequent business stage node, the stage token corresponding to the current business stage node is updated to the completed state, and a stage token corresponding to the entry state of the subsequent business stage node is generated. When a business object is waiting for an external page response, API return, OCR recognition result, or manual approval result, the corresponding stage token will be updated to a waiting state. When a business object triggers a script exception, interface exception, identification exception, permission exception, verification exception, or data exception, the token for the corresponding stage will be updated to a failure status. When a business object is transferred from one execution node to another, the corresponding stage token is updated to the transfer status.

[0011] In some embodiments, aggregating the stage tokens under the same batch identifier includes: Stage tokens are collected according to the business stage nodes, including entry status, completion status, waiting status, failure status, and transfer status. The execution node is assigned a stage token representing its waiting, failure, and transfer status. The duration of a phase state is determined based on the state update time and the platform clock. The stage tokens that are in at least one of the stage states—waiting, failed, or transferred—are matched with the corresponding business stage monitoring window, and the anomaly observation set is updated according to the batch identifier, business stage node, and execution node, respectively.

[0012] In some embodiments, determining process exception events includes: When the abnormal observation set of the same business stage node contains multiple stage tokens under the same batch identifier, and the adjacent subsequent business stage node does not generate an entry state stage token corresponding to the multiple stage tokens, a stage stagnation event is determined. A phase interruption event is determined when the current sequential business phase node has generated a phase token indicating completion, and the adjacent subsequent business phase node has not generated an entry phase token corresponding to the same business object within the phase transition time limit. When a business object returns from a subsequent business stage node to a preceding business stage node that has already generated a completion status stage token, and the returned path does not match the preset rollback path in the process template, a stage rollback event is determined; and the determined process exception event is written to the exception result record.

[0013] In some embodiments, the anomaly fingerprint is generated from at least three types of data selected from process template version, business stage node, stage status, external object identifier, waiting object, and error category. Page identifier, interface identifier, OCR task identifier, and approval node identifier belong to external object identifiers. Waiting object is used to represent the page control, interface resource, OCR queue, recognition result object, approval queue, approval role, credential pool, tenant, or authentication domain corresponding to the external object in the waiting state. The platform normalizes error codes, error text, interface return status, page field names, OCR task status, and approval node status to form error categories used to generate exception fingerprints. The exception fingerprints corresponding to page field changes include process template version, business stage node, stage status, page identifier, waiting object, and error category. The abnormal fingerprints corresponding to interface rate limiting include process template version, business stage node, stage status, interface identifier, waiting object, and error category; the abnormal fingerprints corresponding to OCR recognition result delay include process template version, business stage node, stage status, OCR task identifier, waiting object, and error category; the abnormal fingerprints corresponding to approval node backlog include process template version, business stage node, stage status, approval node identifier, waiting object, and error category. The abnormal fingerprints corresponding to the batch expiration of credentials include the process template version, business stage node, stage status, page identifier or interface identifier, waiting object, and error category.

[0014] In some embodiments, the anomaly attribution categories include node-specific anomalies, stage-specific anomalies, and process template anomalies. When an execution node under the same business stage node generates an abnormal fingerprint for its stage token, and other execution nodes under the same business stage node generate a completed stage token, the execution node is identified as an individual node abnormality; when multiple execution nodes under the same business stage node generate the same abnormal fingerprint for their stage tokens, the business stage node is identified as a stage common abnormality. When multiple business batch tasks generate the same common anomaly at the same business stage node in the same process template version, the process template version is identified as a process template anomaly.

[0015] In some embodiments, generating the multi-node anomaly detection result includes: Write the anomaly source stage, the affected stage, the anomaly fingerprint, the anomaly attribution category, the business object identifier, the batch identifier, and the execution node identifier into the anomaly result record; When the anomaly attribution category is node individual anomaly, at least one of the following disposal tags, namely, switching execution node, retrying task, or releasing robot session, is written into the anomaly result record. When the anomaly attribution category is a phase-common anomaly, at least one of the following handling tags is written into the anomaly result record: suspending the continued dispatch of the same business phase, transferring to manual review, or isolating external system calls. When the anomaly attribution category is process template anomaly, at least one of the following actions is written into the anomaly result record: freeze process template version, trigger template review, or stop the creation of new batches of the same process template.

[0016] In some embodiments, after writing the multi-node anomaly detection results into the anomaly handling queue, the method further includes: Obtain the handling receipt of the abnormal result record in the abnormal handling queue. The handling receipt includes at least one of the following: retry successful, switch successful, manual takeover completed, template correction completed, and external system recovery. Write the processing receipt back to the corresponding stage token and the corresponding edge data record; Update the anomaly attribution record for the corresponding business stage node, execution node, or process template version based on the aforementioned handling receipt; When subsequent business batch tasks are executed, the stage tokens corresponding to the same process template version, the same business stage node, the same execution node type, and the same exception fingerprint will be merged into the exception attribution record.

[0017] In some embodiments, the centralized management and control platform stores a stage node table, an execution node table, a side data record table, a stage token table, an abnormal result record table, and an abnormal attribution record table; The stage node table records the business stage nodes and the flow relationship between adjacent stages; The execution node table records the node type and node identifier of the execution nodes; The edge data record table records the processing relationship between business stage nodes and execution nodes; The stage token table records the stage tokens and their stage status changes; The anomaly result record table records the anomaly detection results of multiple nodes; The anomaly attribution record table records the process template version, business stage identifier, execution node type, anomaly attribution category, anomaly fingerprint, handling receipt, recovery status, and update time.

[0018] Through the above technical solution, the present invention can achieve at least the following beneficial effects: This invention generates stage tokens for business objects and binds these tokens to a business stage-execution node association graph. This associates the processing states of multiple execution nodes and business stages within the same business batch under the same batch identifier. The platform generates anomaly observation sets based on stage token migration status, execution token distribution, stage state duration, and anomaly fingerprints. When multiple business stage nodes simultaneously have anomaly observation sets, it filters business stage nodes with token dependencies based on the directed flow relationship of the current process template version. This determines the anomaly source stage, the affected stage, and the anomaly attribution category, ensuring that the stage stagnation state in the batch concurrent process is attributed to the corresponding business stage and execution node, forming a multi-node anomaly detection result associated with the business object.

[0019] By combining process template version, business stage node, stage status, external object identifier, waiting object and error category through anomaly fingerprinting, and generating corresponding anomaly merging identifiers for external portal page field changes, interface rate limiting, OCR recognition result retention, approval node backlog and batch voucher invalidation, the same abnormal behavior generated by multiple execution nodes under the same business stage can be grouped into the same anomaly source.

[0020] By using stage tokens to migrate status, stage delay events, stage interruption events, and stage reversal events are identified. The completion status stage tokens of the preceding business stage nodes correspond to the entry status stage tokens of the subsequent business stage nodes, so that the sequential relationship between the root cause business stage and the affected business stage is recorded in the process flow chain.

[0021] By distinguishing between individual node anomalies, phase-specific anomalies, and process template anomalies, the anomaly phase token carried by a single execution node, the same anomaly fingerprint carried by multiple execution nodes, and the same phase-specific anomalies in multiple business batch tasks correspond to different anomaly attribution categories, ensuring that the handling labels in the anomaly handling queue are consistent with the anomaly source.

[0022] By handling the write-back stage tokens and edge data records, and updating the anomaly attribution records, the stage tokens corresponding to the same process template version, the same business stage node, the same execution node type, and the same anomaly fingerprint in subsequent business batch tasks are merged into the corresponding anomaly attribution records, so that the anomaly detection results, handling results, and subsequent batch merging basis form a closed record. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation on the scope of this application.

[0024] Figure 1 This is a flowchart of the multi-node anomaly detection method for the intelligent centralized management and control platform in the embodiment. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0026] All terms used in this application (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0027] Furthermore, for ease of understanding, the relevant terms and concepts involved in the embodiments of this application will be introduced below: A business stage node is a processing stage in the process template that can be identified by the platform and has a defined input and output state; the flow relationship between adjacent stages is the flow relationship of business objects between two business stage nodes according to the process template; a business object is a single processing object that is entered, verified, submitted, approved, or archived in a business batch task. A stage token is a data record that documents the state of a business object within a business stage node and its state transition process. A business stage-execution node association diagram is a data structure that records business stage nodes, execution nodes, and their processing relationships. An exception fingerprint is an exception merging identifier formed by at least three of the following data types: process template version, business stage node, stage state, external object identifier, waiting object, and error category. An external object identifier is a data identifier used to identify the page, interface, OCR task, or approval node interacted with by the business stage node. A waiting object is a data object used to represent the page control, interface resource, OCR queue, recognition result object, approval queue, approval role, credential pool, tenant, or authentication domain corresponding to the business object in the waiting state. An error category is an error manifestation category normalized by the platform based on error code, error text, interface return status, page field name, OCR task status, and approval node status.

[0028] Furthermore, a business batch task is a collection of business objects formed from the same business source, the same processing template, or the same batch submission operation; a process template version is a version identifier formed after the process template is released, revised, frozen, or restored; a scheduling record is an operation record generated by the platform when dispatching, preempting, retrying, transferring, or taking over business objects; an execution receipt is a platform-identifiable result record returned by the execution node after processing the business object. A stage token migration status is the matching status of the same business object between adjacent business stage nodes, from a completed stage token to an entering stage token; an execution token distribution is the number and status distribution of waiting, failed, and transferred stage tokens carried by each execution node under the same business stage node; an anomaly observation set is the set of stage tokens that reach the business stage monitoring window and are used for anomaly judgment; a token dependency relationship is the flow relationship where the entry, continued processing, or convergence release of subsequent business stage nodes is conditional on the completed stage token of the preceding business stage node; and an anomaly attribution category is the anomaly source category generated by the platform based on the anomaly fingerprint, stage token migration status, and execution token distribution.

[0029] The "Anomaly Source to be Confirmed" stage is a business stage node marker that generates anomaly observation sets but has not yet entered the anomaly source stage sorting results.

[0030] Example 1: like Figure 1 As shown, this embodiment proposes a multi-node anomaly detection method for an intelligent centralized management and control platform. This method is applied to an RPA / low-code workflow centralized management and control platform that manages multiple execution nodes. These execution nodes include software robots, low-code workflow instances, interface services, OCR services, or manual approval endpoints. Specifically, it includes: Step S101: Parse the process template to generate business stage nodes, adjacent stage flow relationships, and directed flow relationships of the current process template version; the directed flow relationship is a set of process template flow relationships consisting of adjacent stage flow relationships, convergence node inbound edges, and preset backtracking path edges.

[0031] Step S102: Obtain business batch tasks, scheduling records, and execution receipts. Each business batch task includes multiple business objects, and a stage token is generated for each business object. Specifically, the business batch tasks, scheduling records, and execution receipts are aligned using batch identifiers, business object identifiers, business stage identifiers, and execution node identifiers. When an execution receipt lacks a business stage identifier, the platform uses the current business stage identifier in the stage token and the target business stage identifier in the scheduling record to determine the corresponding business stage node. When the same execution receipt matches multiple stage tokens, the platform selects the stage token with the closest status update time and whose stage status is at least one of the following: entering state, waiting state, or transfer state, for binding. A pending-match receipt is an execution receipt for which a corresponding stage token has not yet been determined. The pending-match receipt retains the receipt time, execution node identifier, business object identifier, and original execution result. Step S103: Generate a business stage-execution node association diagram and bind stage tokens; aggregate stage tokens under the same batch identifier to obtain a stage token set corresponding to a business stage node and an execution token set corresponding to an execution node; further, the stage token set is established according to the batch identifier and the business stage identifier, and the execution token set is established according to the batch identifier and the execution node identifier. A stage token simultaneously belongs to one stage token set and one execution token set. The platform uses the token sequence number of the stage token to distinguish retry, transfer, and rollback records generated by the same business object within the same business stage node. The stage token migration status is determined based on the current business stage identifier, the source business stage identifier, the target business stage identifier, the stage status, and the status update time; the execution token distribution is determined based on the carrying execution node identifier, the stage status, and the status update time. Step S104: Generate an exception fingerprint based on the process template version, business stage node, stage status, external object identifier, waiting object, and error category in the stage token; Step S105: Based on the stage token migration status, execution token distribution, stage status duration, and anomaly fingerprint, write the stage tokens whose stage status duration reaches the business stage monitoring window into the anomaly observation set, and determine the anomaly source stage, affected stage, and anomaly attribution category based on the anomaly observation set. Step S106: When multiple business stage nodes have anomaly observation sets at the same time, determine whether the waiting state of subsequent business stage nodes depends on the completion state stage token of the preceding business stage node based on the directed flow relationship of the current process template version. Only business stage nodes with token dependency relationships are allowed to participate in the anomaly source stage sorting, and the business stage node with the highest business flow order is determined as the anomaly source stage. When the business stage nodes participating in the anomaly source stage sorting are empty, the business stage node that generates the anomaly observation set is marked as an anomaly source stage to be confirmed. Step S107: Generate multi-node anomaly detection results based on the anomaly source stage, affected stage, anomaly attribution category, anomaly fingerprint, business object identifier, and execution node identifier, and write them into the anomaly handling queue. The platform determines the reachable paths between business stage nodes based on the directed flow relationships in the current process template version. Specifically, the directed flow relationships include adjacent stage flow relationships, convergence node inbound edges, and preset fallback path edges. Adjacent stage flow relationships represent the forward flow of business objects along the main path; convergence node inbound edges represent multiple preceding business stage nodes jointly triggering a subsequent business stage node to continue processing; and preset fallback path edges represent normal fallbacks registered in the process template. The platform uses adjacent stage flow relationships and convergence node inbound edges when determining token dependencies, and uses preset fallback path edges when identifying normal fallbacks. When multiple business stage nodes simultaneously have anomaly observation sets, the platform does not directly sort all anomaly observation sets according to the business flow order, but first determines whether the waiting state of the subsequent business stage node depends on the completion state stage token of the preceding business stage node. Only when the generation of the entry state, continued processing, or convergence release of the subsequent business stage node requires the completion state stage token of the preceding business stage node as a condition does the preceding business stage node participate in the anomaly source stage sorting.

[0032] In one implementation, generating a business phase-execution node association diagram includes: Generate business stage nodes based on the step codes, step names, page identifiers, interface identifiers, approval node identifiers, or script fragment identifiers in the process template; Execution nodes are generated based on software robot instance identifiers, low-code process instance identifiers, interface service identifiers, OCR service identifiers, or manual approval terminal identifiers; Side data records are generated based on the dispatch relationship, preemption relationship, retry relationship, transfer relationship or takeover relationship in the scheduling record. The side data records record the batch identifier, business object identifier, business stage identifier, execution node identifier, dispatch time, receipt time and execution result. Bind edge data records to corresponding stage tokens so that the flow path of the same business object between different business stage nodes is recorded by the business stage-execution node association graph. The process template includes step codes, step names, page identifiers, interface identifiers, approval node identifiers, and script fragment identifiers. The platform merges template steps with the same business meaning and corresponding to the same input / output state into a single business stage node, and splits processing content with different external interaction objects into different business stage nodes. Each business stage node stores the business stage identifier, business stage name, process template version, preceding business stage identifier, subsequent business stage identifier, and external object identifier.

[0033] Side data records include batch identifier, business object identifier, business stage identifier, execution node identifier, node type, dispatch time, start time, receipt time, execution result, receipt source, and transfer identifier. When dispatch records generate dispatch relationships, preemption relationships, retry relationships, transfer relationships, or takeover relationships, the platform generates or updates side data records; when the execution receipt returns a completion, waiting, failure, or transfer status, the platform writes the execution result to the corresponding side data record.

[0034] In one implementation, the generation phase token includes: When a business object enters a business phase node, a phase token for the entry status is generated. When a business object is dispatched to an execution node, the identifier of the corresponding execution node is written into the execution node identifier that carries the stage token; When a business object moves from the current business stage node to a subsequent business stage node, the stage token corresponding to the current business stage node is updated to the completed state, and a stage token corresponding to the entry state of the subsequent business stage node is generated. When a business object is waiting for an external page response, API return, OCR recognition result, or manual approval result, the corresponding stage token will be updated to a waiting state. When a business object triggers a script exception, interface exception, identification exception, permission exception, verification exception, or data exception, the token for the corresponding stage will be updated to a failure status. When a business object is transferred from one execution node to another, the corresponding stage token is updated to the transfer status; The stage token includes the business object identifier, batch identifier, current business stage identifier, source business stage identifier, target business stage identifier, execution node identifier, stage status, status update time, token sequence number, and receipt source. The token sequence number is used to distinguish multiple retries, transfers, or rollbacks of the same business object within the same business stage node. The status update time is determined by at least one of the platform clock, scheduling record time, and execution receipt time.

[0035] In one implementation, the aggregation phase token under the same batch identifier includes: Stage tokens are collected according to the business stage nodes, including entry status, completion status, waiting status, failure status, and transfer status. The execution node is assigned a stage token representing its waiting, failure, and transfer status. The duration of a stage state is determined based on the state update time and the platform clock. In one example, the business stage monitoring window is written as an implementation parameter to the configuration record corresponding to the process template version. The monitoring window registered in the process template version is preferred for business stage monitoring. A normal completion record is a historical record where the stage token is updated from the entry state to the completion state and is not written to the exception observation set. The historical normal flow record is a historical record of the same business object being updated from the completion state stage token of the preceding business stage node to the entry state stage token of the subsequent business stage node between adjacent business stage nodes.

[0036] When not registered, the 95th percentile of the normal completion record with the same process template version, the same business stage node, and the same execution node type is used; when there are fewer than 30 normal completion records, the stage transition time limit is used; when the stage transition time limit is empty, 10 min is used as the implementation parameter, with a value range of 1 min to 60 min.

[0037] Write the stage tokens that are in a waiting state, a failed state, or a transferred state and whose stage status duration reaches the corresponding business stage monitoring window into the anomaly observation set. The duration of a phase state begins at the time when the phase token enters the waiting state, failure state, or transfer state, and ends at the time when the phase token is updated to the completion state, transferred to another execution node, manually taken over, or written to the exception handling queue.

[0038] The anomaly watchlist includes batch identifier, business stage identifier, business object identifier, execution node identifier, stage status, status update time, stage status duration, external object identifier, error category, and receipt source. The anomaly watchlist is established according to the batch identifier and business stage identifier, and is updated as the stage token is completed, transferred, manually taken over, or abnormally closed.

[0039] In one implementation, determining a process exception event includes: When the anomaly observation set of the same business stage node contains multiple stage tokens under the same batch identifier, and the adjacent subsequent business stage node does not generate an entry state stage token corresponding to the multiple stage tokens, a stage stagnation event is determined. A phase interruption event is determined when a current business phase node has generated a completion status phase token, and an adjacent subsequent business phase node has not generated an entry status phase token corresponding to the same business object within the phase transition time limit. Furthermore, the phase transition time limit is the allowed time interval between the generation of the completion status phase token and the generation of the entry status phase token between adjacent business phase nodes. The phase transition time limit is preferentially registered by the process template version; if not registered, the 95th percentile of historical normal transition records for the same process template version and the same adjacent phase transition relationship is used; if there are fewer than 30 historical normal transition records, 5 minutes is used as the implementation parameter, with a value range of 1 minute to 30 minutes.

[0040] A stage reversal event is identified when a business object returns from a subsequent business stage node to a preceding business stage node that has already generated a completion status stage token, and the returned path does not match the preset rollback path in the process template. Process exception events are event records formed based on the migration status of stage tokens between adjacent business stage nodes. Process exception events include at least one of stage delay events, stage interruption events, and stage reversal events. The platform writes the identified process exception events into the exception result record.

[0041] In one implementation, generating multi-node anomaly detection results includes: Write the anomaly source stage, affected stage, anomaly fingerprint, anomaly attribution category, corresponding execution node identifier, and corresponding business object identifier into the anomaly result record; When the anomaly attribution category is node individual anomaly, write at least one of the following handling tags into the anomaly result record: switch execution node, retry task, or release robot session. When the anomaly attribution category is a phase-wide common anomaly, write at least one of the following handling tags into the anomaly result record: suspend the continued dispatch of the same business phase, transfer to manual review, or isolate external system calls. When the anomaly attribution category is process template anomaly, write at least one of the following handling tags into the anomaly result record: freeze process template version, trigger template review, or stop the creation of new batches of the same process template. Disposal tags are used to drive the RPA / low-code process centralized management platform to execute corresponding scheduling and control actions. Switching execution nodes corresponds to reassigning affected business objects to execution nodes of the same type. Execution nodes of the same type are those with the same node type and registered with the same identifier for the business stage they can handle. When the platform performs a switch execution node, it retains the stage token in the current business stage node and updates the identifier of the carrying execution node to the reassigned execution node identifier.

[0042] Retrying a task corresponds to re-adding the stage token to the pending queue of the current business stage node; releasing a robot session corresponds to closing the current session of the execution node and releasing its occupied resources; pausing the continued dispatch of the same business stage corresponds to stopping the addition of new business objects to that business stage node; isolating external system calls corresponds to stopping the initiation of new processing requests to the corresponding page, interface, OCR task, or approval node; freezing the process template version corresponds to stopping the creation of new business batch tasks based on that process template version.

[0043] In one implementation, after writing the multi-node anomaly detection results into the anomaly handling queue, the method further includes: Obtain the handling receipt of the abnormal result record in the abnormal handling queue. The handling receipt includes at least one of the following: retry successful, switch successful, manual takeover completed, template correction completed, and external system recovery. Write the processing receipt back to the corresponding stage token and the corresponding edge data record; Update the anomaly attribution record for the corresponding business stage node, execution node, or process template version based on the handling receipt; When subsequent business batch tasks are executed, the stage tokens corresponding to the same process template version, the same business stage node, the same execution node type, and the same exception fingerprint will be merged into the exception attribution record; The handling receipt includes the handling result, handling time, handling source, post-handling stage status, and post-handling execution node identifier. When the handling receipt indicates successful retry or successful switchover, the platform updates the corresponding stage token to a completed or entered status and updates the execution result of the corresponding edge data record. When the handling receipt indicates manual takeover completion, the platform keeps the corresponding stage token in a transferred status and writes the manual approval terminal identifier into the post-handling execution node identifier. When the handling receipt indicates template correction completion, the platform establishes a link between the corresponding process template version and the corrected process template version. When the handling receipt indicates external system recovery, the platform updates the recovery status of the corresponding anomaly attribution record.

[0044] In one implementation, the RPA / low-code process centralized management platform saves a stage node table, an execution node table, an edge data record table, a stage token table, an abnormal result record table, and an abnormal attribution record table. The stage node table records the business stage nodes and the flow relationship between adjacent stages; The execution node table records the node type and node identifier of the execution nodes; The edge data record table records the processing relationship between business stage nodes and execution nodes; The stage token table records stage tokens and their stage state changes; The anomaly result record table records the anomaly detection results of multiple nodes; The anomaly attribution record form records the anomaly attribution category, anomaly fingerprint, handling receipt, and update time; The stage node table includes business stage identifier, business stage name, process template version, preceding business stage identifier, subsequent business stage identifier, and external object identifier; the execution node table includes execution node identifier, node type, node status, and processable business stage identifier; the edge data record table includes batch identifier, business object identifier, business stage identifier, execution node identifier, dispatch time, receipt time, and execution result; the stage token table includes business object identifier, batch identifier, current business stage identifier, source business stage identifier, target business stage identifier, carrying execution node identifier, stage status, status update time, and token sequence number; the abnormal result record table includes abnormal source stage, affected stage, abnormal fingerprint, abnormal attribution category, business object identifier, batch identifier, execution node identifier, and handling tag; the abnormal attribution record table includes process template version, business stage identifier, execution node type, abnormal fingerprint, abnormal attribution category, handling receipt, recovery status, and update time.

[0045] In a preferred embodiment of Example 1, when multiple business stage nodes simultaneously meet the anomaly source stage conditions, the platform constructs a token dependency subgraph based on the directed flow relationship corresponding to the current process template version. The token dependency subgraph retains the forward flow edges of business objects between business stage nodes, the inbound edges of the convergence nodes, and the fallback path edges configured in the process template. The fallback path edges are used to identify whether a business object has undergone a normal fallback allowed by the process template and are not considered as forward reachable edges in the anomaly source stage sorting.

[0046] For any business object, the platform determines the token dependency marker between the preceding business stage node and the subsequent business stage node according to the following formula: , in, Represents business object At the business stage node With business phase nodes Token dependency markers between; Indicates a candidate preceding business stage node; Indicates a candidate subsequent business stage node; This indicates the business object corresponding to the business object identifier; This is an indicator function that takes a value of 1 when the condition within the parentheses is true and a value of 0 when the condition is false. Indicates the start of the business phase node To the business stage node The set of directed reachable paths; Represents business object At the business stage node The stage state; Indicates the business stage node Does the entry trigger condition depend on the business phase node? The generated completion status token has a value of 1 indicating that there is a dependency and a value of 0 indicating that there is no dependency. Indicates the start of the business phase node Return to business phase node Whether the path belongs to the preset backtracking path in the process template. A value of 1 indicates that it belongs to the preset backtracking path, and a value of 0 indicates that it does not belong to the preset backtracking path.

[0047] It consists of the forward flow edges and convergence node inbound edges in the current process template version, excluding preset rollback path edges used only for normal rollback identification. When the business stage node... With business phase nodes same, When the value is empty or the corresponding flow edge is not bound to a stage token, the platform will... Set to 0. Based on the business stage nodes in the process template Entry trigger conditions, business objects The source business stage identifier, target business stage identifier, and completion status stage token are the inputs; if any input is missing, the platform will... Set to 0. The business stage node only exists in the process template. Return to business phase node The value is 1 when the preset rollback path is set and the corresponding stage token can match the preset rollback path; unregistered reverse flow is not treated as normal rollback.

[0048] The quantification of the token dependency flag is as follows: among the stage tokens of the same business object, the source business stage identifier, target business stage identifier, stage status, and status update time can all match the directed flow edge in the process template, and the waiting state of subsequent business stage nodes is caused by not receiving the completion status stage token of the preceding business stage node. The token dependency flag only participates in the anomaly source stage sorting when the value is 1. When the value is 0, the corresponding business stage node is regarded as a concurrent independent anomaly node, a normal rollback node, or a waiting node without dependencies, and does not participate in the comparison of the priority of the same anomaly source stage.

[0049] In concurrent branching scenarios, if multiple business stage nodes are located in different concurrent branches, and the completion status stage token of any business stage node is not a prerequisite for another business stage node to enter or continue processing, the platform will not merge and sort them simply because they have the same anomaly fingerprint. Only when a business stage node in a concurrent branch affects the generation of the entry status of subsequent business stage nodes through a convergence node, and the subsequent business stage node has already formed a waiting status stage token, will the business stage node of that concurrent branch enter the anomaly source stage candidate range. For the convergence node, the platform checks the completion status stage tokens corresponding to each incoming edge. The preceding business stage node corresponding to an incoming edge that has not yet arrived is included in the candidate range, while the preceding business stage node corresponding to an incoming edge that has already arrived is not included in the candidate range.

[0050] The platform generates a candidate set of anomaly source stages under the same anomaly fingerprint according to the following formula: , in, Indicating abnormal fingerprints The corresponding candidate set of anomaly source stages; Indicates an abnormal fingerprint; This indicates that an abnormal observation set was generated and the abnormal fingerprint is... The set of business stage nodes; This indicates that the fingerprint was not received or is abnormal. The set of business phase nodes that generate waiting state phase tokens based on the completion state phase tokens corresponding to the anomaly observation set; This indicates the generation of abnormal fingerprints. Or affected by abnormal fingerprints The set of business objects affected by incomplete transfer; , , and The aforementioned definition will be used.

[0051] When the candidate set of anomaly source stages is empty, the platform will mark the business stage nodes that generate anomaly observation sets but have not entered the candidate set of anomaly source stages as anomaly source stages to be confirmed, and retain the anomaly observation set, anomaly fingerprint and business object identifier for subsequent processing receipt writing; the anomaly fingerprints generated within the same business batch task will be kept in their original records.

[0052] After obtaining the candidate set of anomaly source stages, the platform determines the priority of business stage nodes based on the topology level in the process template and the business flow order within the same level. For business stage nodes with the same topology level in concurrent branches and no token dependency relationship, they are not merged in order; the business flow order is the sorting value of business stage nodes generated according to the topology level in the current process template version, the configuration order of the same level, and the incoming edge order of the aggregation node.

[0053] For business stage nodes with token dependencies, the platform first compares the business flow order of each business stage node in the candidate set of anomaly source stages. The business stage node with the smallest business flow sequence is selected as the candidate output for the anomaly source stage. Indicates the business stage node In the current process template version, the business flow sequence is determined by the topology level, the configuration order at the same level, and the order of incoming edges to the aggregation node. The smaller the value, the earlier the business flow position. When the minimum business flow sequence corresponds to multiple business stage nodes, the platform then compares them according to their contribution range.

[0054] The business flow sequence is determined based on the directed acyclic main path obtained by parsing the current process template version; when there is a preset rollback path, the rollback path is only used to identify normal rollback and does not change the business flow sequence of the main path; when there is a convergence node, the incoming edges of the convergence node are determined according to the branch code or incoming edge registration order configured in the process template.

[0055] If multiple candidate business stage nodes with the same business flow sequence number exist under the same abnormal fingerprint, the platform further compares their contribution range to the waiting status of the aggregation node. The contribution range is quantified by the number of subsequent business stage nodes that remain in a waiting state because the candidate business stage node has not generated a completion stage token within the same business batch task and the same status update time statistical window. A larger number indicates a greater extent of obstruction to subsequent flows by the candidate business stage node. The status update time statistical window is an implementation parameter that groups waiting stage tokens according to their status update time. The status update time statistical window starts from the status update time of the first waiting stage token corresponding to the same abnormal fingerprint, with a default value of 5 minutes and a range of 1 to 30 minutes. Waiting stage tokens within the same status update time statistical window participate in the contribution range statistics; waiting stage tokens outside this window are entered into subsequent statistical windows.

[0056] The platform will designate candidate business stage nodes with a larger contribution range as anomaly source stages; if the contribution range is 0, the contribution range cannot be counted, or the contribution range is the same, multiple anomaly source stages will be retained and multi-node anomaly detection results will be generated separately, without forcibly merging them into a single anomaly source stage.

[0057] Using the above method, business stage nodes with the same anomaly fingerprint and the highest business flow sequence are defined as those that, under the same process template version, the same anomaly fingerprint, and the same business batch task, both generate an anomaly observation set and have a token dependency relationship with subsequent waiting state stage tokens, and have the lowest business flow sequence among the candidate business stage nodes participating in the comparison. Independent anomaly nodes in concurrent branches form anomaly result records respectively, and the stage token corresponding to the preset rollback path registered in the process template enters the normal rollback record.

[0058] Example 2: Based on Embodiment 1, this embodiment provides a method for generating anomaly fingerprints in the multi-node anomaly detection method of an intelligent centralized management and control platform; An anomaly fingerprint is generated from at least three types of data: process template version, business stage node, stage status, external object identifier, waiting object, and error category. Page identifier, interface identifier, OCR task identifier, and approval node identifier belong to external object identifiers. Waiting object is used to represent the page control, interface resource, OCR queue, recognition result object, approval queue, approval role, credential pool, tenant, or authentication domain corresponding to the external object in the waiting state. The platform normalizes error codes, error text, interface return status, page field names, OCR task status, and approval node status to form error categories used to generate exception fingerprints. The exception fingerprints corresponding to page field changes include process template version, business stage node, stage status, page identifier, waiting object, and error category. The abnormal fingerprints corresponding to interface rate limiting include process template version, business stage node, stage status, interface identifier, waiting object, and error category; the abnormal fingerprints corresponding to OCR recognition result delay include process template version, business stage node, stage status, OCR task identifier, waiting object, and error category; the abnormal fingerprints corresponding to approval node backlog include process template version, business stage node, stage status, approval node identifier, waiting object, and error category. The abnormal fingerprints corresponding to the batch expiration of credentials include the process template version, business stage node, stage status, page identifier or interface identifier, waiting object, and error category; In one implementation, the anomaly attribution categories include node-specific anomalies, stage-specific common anomalies, and process template anomalies. When an execution node under the same business stage node generates an abnormal fingerprint for its stage token, and other execution nodes under the same business stage node generate a completed stage token, the execution node is identified as an individual node anomaly; when multiple execution nodes under the same business stage node generate the same abnormal fingerprint for their stage tokens, the business stage node is identified as a stage-wide anomaly. When multiple business batch tasks generate the same common anomaly at the same business stage node in the same process template version, the process template version will be identified as the process template anomaly. Error categories are used to generate anomaly fingerprints, not as anomaly attribution categories. Error categories characterize error behavior, while anomaly attribution categories characterize the source of the anomaly.

[0059] In a preferred embodiment of Example 2, when generating an anomaly fingerprint, after the stage token enters the anomaly observation set, the platform reads the stage token, side data records, and associated fields in the process template, and first performs normalization processing on the fields before performing error category mapping and fingerprint generation. The normalization processing uses the current process template version as the field labeling standard. Step codes, page identifiers, interface identifiers, OCR task identifiers, and approval node identifiers within the same process template version use the values ​​registered in the template, not runtime temporary names. Execution nodes are bound using node types, and a single execution node identifier is not used as a fixed component field of the anomaly fingerprint, thus avoiding the same type of anomaly being split into multiple anomaly fingerprints due to different robot instances, different interface service instances, or different approval terminal accounts.

[0060] For error codes, error messages, and waiting objects, the platform first calculates the category matching score between the stage token and the error category candidates using the following formula: , in, Phase token Error category candidates Category matching scores between them; A stage token indicating entry into the anomaly observation set; Indicates the error category candidates; Indicates the weight of the error code match; This is an indicator function that takes a value of 1 when the condition within the parentheses is true and a value of 0 when the condition is false. Phase token The corresponding original error code; Indicates error category candidates The corresponding set of error codes; Indicates the weight of the incorrect copy matching item; This represents the function for calculating text similarity. Phase token Corresponding normalization error text; Indicates error category candidates The corresponding standard error message set; Indicates the weight of the matching item in the waiting object; Phase token The corresponding normalized wait object; Indicates error category candidates The corresponding set of waiting objects.

[0061] The platform will identify the candidate with the highest category matching score that is not lower than the category acceptance threshold as the stage token. The corresponding error category, and denoted as Furthermore, the error category mapping table records data such as error category candidates, error code set, standard error text set, waiting object set, weights, category acceptance threshold, and version number. The text similarity calculation function outputs a similarity value between 0 and 1; a larger output value indicates a closer similarity between the normalized error text and the standard error text set. The text similarity calculation function uses the platform's preset string similarity algorithm, and the same text similarity calculation function is used within the same error category mapping table version. When no string similarity algorithm is configured, normalized edit distance similarity is used as the text similarity calculation function. The category acceptance threshold is used as an implementation parameter, with a default value of 0.75 and a value range of 0.50 to 0.95; the default values ​​for error code matching item weight, error text matching item weight, and waiting object matching item weight are 0.50, 0.30, and 0.20, respectively, totaling 1.

[0062] When there is no single highest-ranking error category candidate, or when the category matching score is lower than the category acceptance threshold, the platform generates an unmerged error category and records the unmerged error category as a stage token. Corresponding error categories It will not be included in the error categories that are already in effect.

[0063] During the execution of the same business batch of tasks, the weight and category acceptance threshold remain at the values ​​at the beginning of the batch. When an error code is missing, the error code matching item value is 0; when the error text is missing, the error text matching item value is 0; when the waiting object is missing, the waiting object matching item value is 0.

[0064] The quantification of error categories is a weighted combination of error code hit results, error text similarity, and waiting object matching results. The error code set, standard error text set, and waiting object set are defined using the platform's error dictionary, process template configuration, and written-back handling receipts. When error codes are the same, error texts are different, and waiting objects are the same, the platform maps them to the same error category after removing dynamic time, serial number, session identifier, request identifier, object number, and node instance number. When error codes are different but all point to the same waiting object, error texts meet the same standard error text set, and the category matching score is not lower than the category acceptance threshold, the platform classifies them into the same error category. When handling receipts conflict, the error category mapping relationship that was already in effect before the start of this business batch task is used.

[0065] After field normalization is completed, the platform generates anomaly fingerprint field vectors according to fixed field positions: , in, Phase token The corresponding abnormal fingerprint field vector; This represents the normalization function for the process template version. Phase token Corresponding process template version; This represents the normalization function for business phase nodes; Phase token Corresponding business stage nodes; Represents the stage state normalization function; Phase token The corresponding stage state; This represents the page identifier normalization function; Phase token Corresponding page identifier; This represents the interface identifier normalization function; Phase token The corresponding interface identifier; This represents the OCR task identifier normalization function; Phase token Corresponding OCR task identifier; This represents the normalization function for the approval node identifier; Phase token Corresponding approval node identifier; The aforementioned definition will be used; This indicates that the object is waiting for a normalization function; Phase token The corresponding original waiting object.

[0066] The abnormal fingerprint field vector uses fixed field positions, and the field order does not change due to the absence of page identifiers, interface identifiers, OCR task identifiers, or approval node identifiers in a certain scenario. For fields that are not applicable in the process template, the platform writes a uniform null placeholder; for fields that are configured in the process template but not collected at runtime, the platform writes a missing placeholder with the field name; for cases where multiple inconsistent normalization results occur for the same field, the platform writes a conflict placeholder with the field name; for cases where the normalization function fails to execute, the platform writes a failure placeholder with the field name.

[0067] When normalizing page identifiers, the platform retains page codes, page path templates, and key control anchors, while removing session numbers, pagination numbers, and dynamic element numbers. When normalizing interface identifiers, the platform retains interface service identifiers, request methods, and resource path templates, while removing timestamps, signature strings, tracking numbers, and business object serial numbers. When normalizing OCR task identifiers, the platform retains OCR task templates, recognition model identifiers, and document field groups, while removing single recognition task numbers. When normalizing approval node identifiers, the platform retains approval node codes, approval roles, and approval queues, while removing specific approver accounts. When normalizing waiting objects, page waiting objects are merged into page controls or page response objects; interface waiting objects are merged into interface resources or rate-limiting buckets; OCR waiting objects are merged into OCR queues or recognition result objects; approval waiting objects are merged into approval queues or approval roles; and credential waiting objects are merged into credential pools, tenants, or authentication domains.

[0068] The platform generates anomaly fingerprints based on the anomaly fingerprint field vector: , in, Phase token Corresponding abnormal fingerprint; This represents the function that generates the summary; The aforementioned definition will be used.

[0069] The digest generation function generates a stable serialization result using the field names, field order, and field values ​​from the anomaly fingerprint field vector, and uses the stable serialization result as input. Specifically, the stable serialization result is a character sequence obtained by converting the field names, field states, and field values ​​according to a fixed field order in the anomaly fingerprint field vector. Field states include valid, null, missing, conflicting, and failed. The digest generation function performs a deterministic digest calculation on the stable serialization result, outputting a fixed-length character sequence; the same digest generation function version outputs the same anomaly fingerprint for the same stable serialization result. The digest generation function version is written to the anomaly result record and anomaly attribution record. During the execution of the same business batch task, the digest generation function version retains the values ​​at the beginning of the batch.

[0070] The currently active error category mapping table version is used for version binding and result backtracking during the anomaly fingerprint generation process. It is not written into the anomaly fingerprint field vector, the field order is not changed, and it is not used as an input field for the digest generation function.

[0071] When the platform detects that different abnormal fingerprint field vectors generate the same digest value, it performs a secondary comparison using the stable serialization result of the abnormal fingerprint field vector. If the secondary comparison is inconsistent, a conflict fingerprint record is generated and not merged into the same abnormal attribution record. Further, the conflict fingerprint record is used to store abnormal fingerprint generation records with the same digest value but different stable serialization results. The conflict fingerprint record includes the abnormal fingerprint, stable serialization result, process template version, business stage identifier, execution node type, business object identifier, batch identifier, and generation time. The platform writes the conflict fingerprint record into the abnormal result record and retains the corresponding abnormal attribution record according to the stable serialization result.

[0072] Under the same process template version, the same business stage node, and the same error category, as long as the normalized page identifier, interface identifier, OCR task identifier, approval node identifier, or waiting object remains consistent, the same abnormal fingerprint will be generated even if the original error text has language differences, dynamic number differences, or execution node instance differences. When any non-empty normalized field in the abnormal fingerprint field vector changes, different abnormal fingerprints will be generated. This direction of change is used to limit the scope of abnormal merging. The closer a field is to the template's stable definition, the more likely it is to be merged into the same abnormal fingerprint; the closer a field is to a runtime temporary value, the more likely it is to be removed or replaced with a placeholder corresponding to the field's state. When a field is missing, conflicts with other fields, or normalization fails, the platform adopts a conservative strategy to generate an abnormal fingerprint containing the corresponding placeholder, and does not merge it into an existing abnormal fingerprint that has been confirmed by the handling receipt and has complete fields.

[0073] The platform establishes the binding relationship between exception fingerprints and process template versions, business stage nodes, and execution node types according to the following formula: , in, Phase token The corresponding abnormal fingerprint binding key; The aforementioned definition will be used; The aforementioned definition will be used; The aforementioned definition will be used; The aforementioned definition will be used; This indicates that the node type normalization function will be executed. Phase token The corresponding execution node type; The aforementioned definition will be used.

[0074] The platform writes the error category mapping table version number into the anomaly result record and anomaly attribution record. The error category mapping table version number is used to record the basis for generating the error category and the version alignment when writing back the handling receipt, and is not used as a separate anomaly attribution category. For the same anomaly fingerprint generated under different error category mapping table versions, the stable serialization result of the anomaly fingerprint field vector must be compared before merging into the same anomaly attribution record; if the comparison is inconsistent, cross-version merging will not be performed.

[0075] The exception fingerprint binding key is used for subsequent exception attribution record merging. When the same exception fingerprint appears repeatedly under the same process template version, the same business stage node, and the same execution node type, the platform will merge the corresponding stage token into the same exception attribution record; when the same exception fingerprint appears across different execution node instances, the attribution will not be split due to different instance identifiers; when the same exception fingerprint appears across different execution node types, the platform retains the binding key for each instance and retains the execution node identifier in the exception result record to distinguish between node-specific exceptions and stage-wide common exceptions.

[0076] The error category mapping table undergoes version verification when a process template version is released, an exception handling receipt is written back, or the platform error dictionary is adjusted. The verification window is bounded by the end of the business batch. Exception fingerprints already generated within the same business batch retain their original records, and the error category mapping table version effective at the beginning of the batch continues to be used. The minimum sample size is an implementation parameter used to verify the adjustment conditions of the error category mapping table. Platform-configured records are preferred; if not configured, 20 is used, with a value range of 5-100. When the number of handling receipts does not reach the minimum sample size, the normalization merging range is not expanded, the category acceptance threshold is not lowered, and the weight of error text matching items is not increased. When handling receipts point to different handling results, the platform retains the stage tokens corresponding to different error categories or different waiting objects as different exception fingerprints.

[0077] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0078] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this application and form different embodiments. For example, all the embodiments above can be used in any combination. The information disclosed in this background section is intended only to enhance the understanding of the general background of this application and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art.

Claims

1. A multi-node anomaly detection method for an intelligent centralized management and control platform, characterized in that, include: Parse the process template to generate business stage nodes, adjacent stage transition relationships, and directed transition relationships for the current process template version; Acquire business batch tasks, scheduling records, and execution receipts. The business batch tasks include multiple business objects, and generate stage tokens for the business objects. Generate a business stage-execution node association diagram, which is a data structure that records business stage nodes, execution nodes, and their processing relationship. Bind the stage token to the corresponding business stage node and the corresponding execution node. Under the same batch identifier, stage tokens are aggregated to obtain the stage token set corresponding to the business stage node and the execution token set corresponding to the execution node; An exception fingerprint is generated based on the process template version, business stage node, stage status, external object identifier, waiting object, and error category in the stage token; Based on the stage token migration status, execution token distribution, stage status duration, and anomaly fingerprint, stage tokens whose stage status duration reaches the business stage monitoring window are written into the anomaly observation set, and the anomaly source stage, affected stage, and anomaly attribution category are determined. When multiple business stage nodes have anomaly observation sets at the same time, the waiting state of subsequent business stage nodes depends on the completion state stage token of the preceding business stage node based on the directed flow relationship of the current process template version. Only business stage nodes with token dependency relationships are allowed to participate in the anomaly source stage sorting, and the business stage node with the earliest business flow order is determined as the anomaly source stage. When the business stage node participating in the anomaly source stage sorting is empty, the business stage node that generates the anomaly observation set will be marked as an anomaly source stage to be confirmed. Multi-node anomaly detection results are generated based on the anomaly source stage, affected stage, anomaly attribution category, anomaly fingerprint, business object identifier, and execution node identifier, and written into the anomaly handling queue. Generating the business stage-execution node association diagram includes: Business stage nodes are generated based on stage identifier data in the process template. The stage identifier data includes at least one of step code, step name, page identifier, interface identifier, approval node identifier, and script fragment identifier. Execution nodes are generated based on execution node identification data, wherein the execution node identification data includes at least one of software robot instance identifier, low-code process instance identifier, interface service identifier, OCR service identifier, and manual approval terminal identifier; Side data records are generated based on the scheduling relationship data in the scheduling records. The scheduling relationship data includes at least one of dispatch relationship, preemption relationship, retry relationship, transfer relationship and takeover relationship. The side data records record the batch identifier, business object identifier, business stage identifier, execution node identifier, dispatch time, receipt time and execution result. The edge data record is bound to the corresponding stage token, so that the flow path of the same business object between different business stage nodes is recorded by the business stage-execution node association graph.

2. The multi-node anomaly detection method for the intelligent centralized management and control platform according to claim 1, characterized in that, Generating the stage token includes: When a business object enters a business phase node, a phase token for the entry status is generated. When a business object is dispatched to an execution node, the identifier of the corresponding execution node is written into the execution node identifier that carries the stage token; When a business object moves from the current business stage node to a subsequent business stage node, the stage token corresponding to the current business stage node is updated to the completed state, and a stage token corresponding to the entry state of the subsequent business stage node is generated. When a business object is waiting for an external page response, API return, OCR recognition result, or manual approval result, the corresponding stage token will be updated to a waiting state. When a business object triggers a script exception, interface exception, identification exception, permission exception, verification exception, or data exception, the token for the corresponding stage will be updated to a failure status. When a business object is transferred from one execution node to another, the corresponding stage token is updated to the transfer status.

3. The multi-node anomaly detection method for the intelligent centralized management and control platform according to claim 1, characterized in that, The phase tokens aggregated under the same batch identifier include: Stage tokens are collected according to the business stage nodes, including entry status, completion status, waiting status, failure status, and transfer status. The execution node is assigned a stage token representing its waiting, failure, and transfer status. The duration of a phase state is determined based on the state update time and the platform clock. The stage tokens that are in at least one of the stage states—waiting, failed, or transferred—are matched with the corresponding business stage monitoring window, and the anomaly observation set is updated according to the batch identifier, business stage node, and execution node, respectively.

4. The multi-node anomaly detection method for the intelligent centralized management and control platform according to claim 3, characterized in that, Identifying process exception events includes: When the abnormal observation set of the same business stage node contains multiple stage tokens under the same batch identifier, and the adjacent subsequent business stage node does not generate an entry state stage token corresponding to the multiple stage tokens, a stage stagnation event is determined. A phase interruption event is determined when the current sequential business phase node has generated a phase token indicating completion, and the adjacent subsequent business phase node has not generated an entry phase token corresponding to the same business object within the phase transition time limit. When a business object returns from a subsequent business stage node to a preceding business stage node that has already generated a completion status stage token, and the returned path does not match the preset rollback path in the process template, a stage rollback event is determined; and the determined process exception event is written to the exception result record.

5. The multi-node anomaly detection method for an intelligent centralized management and control platform according to claim 1, characterized in that, The anomaly fingerprint is generated from at least three types of data: process template version, business stage node, stage status, external object identifier, waiting object, and error category. Page identifier, interface identifier, OCR task identifier, and approval node identifier belong to external object identifiers. Waiting object is used to represent the page control, interface resource, OCR queue, recognition result object, approval queue, approval role, credential pool, tenant, or authentication domain corresponding to the external object in the waiting state. The platform normalizes error codes, error texts, interface return status, page field names, OCR task status, and approval node status to form error categories used to generate abnormal fingerprints. The anomaly fingerprints corresponding to changes in page fields include process template version, business stage node, stage status, page identifier, waiting object, and error category; The abnormal fingerprints corresponding to interface rate limiting include process template version, business stage node, stage status, interface identifier, waiting object, and error category; the abnormal fingerprints corresponding to OCR recognition result delay include process template version, business stage node, stage status, OCR task identifier, waiting object, and error category; the abnormal fingerprints corresponding to approval node backlog include process template version, business stage node, stage status, approval node identifier, waiting object, and error category. The abnormal fingerprints corresponding to the batch expiration of credentials include the process template version, business stage node, stage status, page identifier or interface identifier, waiting object, and error category.

6. The multi-node anomaly detection method for an intelligent centralized management and control platform according to claim 5, characterized in that, The anomaly attribution categories include node-specific anomalies, stage-specific common anomalies, and process template anomalies. When an execution node under the same business stage node generates an abnormal fingerprint for its stage token, and other execution nodes under the same business stage node generate a completed stage token for their stage tokens, the execution node is identified as an individual node abnormality. When multiple execution nodes under the same business stage node carry stage tokens that generate the same abnormal fingerprint, the business stage node is identified as a stage common abnormality. When multiple business batch tasks generate the same common anomaly at the same business stage node in the same process template version, the process template version is identified as a process template anomaly.

7. The multi-node anomaly detection method for an intelligent centralized management and control platform according to claim 6, characterized in that, The generation of the multi-node anomaly detection results includes: Write the anomaly source stage, the affected stage, the anomaly fingerprint, the anomaly attribution category, the business object identifier, the batch identifier, and the execution node identifier into the anomaly result record; When the anomaly attribution category is node individual anomaly, at least one of the following disposal tags, namely, switching execution node, retrying task, or releasing robot session, is written into the anomaly result record. When the anomaly attribution category is a phase-common anomaly, at least one of the following handling tags is written into the anomaly result record: suspending the continued dispatch of the same business phase, transferring to manual review, or isolating external system calls. When the anomaly attribution category is process template anomaly, at least one of the following actions is written into the anomaly result record: freeze process template version, trigger template review, or stop the creation of new batches of the same process template.

8. The multi-node anomaly detection method for an intelligent centralized management and control platform according to claim 7, characterized in that, After writing the multi-node anomaly detection results into the anomaly handling queue, the process also includes: Obtain the handling receipt of the abnormal result record in the abnormal handling queue. The handling receipt includes at least one of the following: retry successful, switch successful, manual takeover completed, template correction completed, and external system recovery. Write the processing receipt back to the corresponding stage token and the corresponding edge data record; Update the anomaly attribution record for the corresponding business stage node, execution node, or process template version based on the aforementioned handling receipt; When subsequent business batch tasks are executed, the stage tokens corresponding to the same process template version, the same business stage node, the same execution node type, and the same exception fingerprint will be merged into the exception attribution record.

9. The multi-node anomaly detection method for an intelligent centralized management and control platform according to claim 1, characterized in that, The centralized management and control platform stores the stage node table, execution node table, edge data record table, stage token table, abnormal result record table, and abnormal attribution record table; The stage node table records the business stage nodes and the flow relationship between adjacent stages; The execution node table records the node type and node identifier of the execution nodes; The edge data record table records the processing relationship between business stage nodes and execution nodes; The stage token table records the stage tokens and their stage status changes; The anomaly result record table records the anomaly detection results of multiple nodes; The anomaly attribution record table records the process template version, business stage identifier, execution node type, anomaly attribution category, anomaly fingerprint, handling receipt, recovery status, and update time.

Images