Digital employee data processing system and method

Abstract

The application discloses a kind of digital employee data processing system and method, applied to robot process automation technical field. Including: data adaptation layer obtains the original task state data of subordinate robot of each vendor console and is converted into standard task state data;Data perception layer constructs standard data correlation model and calculates cross-vendor global task execution index data and same-vendor grouping task execution index data;Monitoring alarm layer determines target vendor console and triggers exception alarm when monitoring index exception;Resource scheduling layer executes exception scheduling strategy in response to exception alarm.The application realizes the unified standardized processing of multi-vendor robot operation data and cross-vendor exception monitoring and automatic scheduling.

Description

Technical Field

[0001] This application relates to the field of robotic process automation technology, and in particular to a digital employee data processing system and method. Background Technology

[0002] Robotic Process Automation (RPA) technology automates repetitive and routine business processes by simulating human actions on computers, and has become an important technological means for enterprise digital transformation. As the scale of RPA applications expands, enterprises typically introduce RPA products (i.e., digital employees) from multiple vendors to meet the needs of different business scenarios.

[0003] In existing technologies, there are significant differences in the underlying communication protocols and state definitions of different RPA vendors, resulting in severe heterogeneity and silo effects in digital employee operation data, making it difficult to globally schedule robot resources across vendors and causing low resource utilization. Summary of the Invention

[0004] This application provides a digital employee data processing system and method to solve the problem of low utilization rate of cross-vendor robot resources in the prior art. The technical solution provided by this application is as follows: On the one hand, this application provides a digital employee data processing system, including: The data adaptation layer connects to the consoles of various manufacturers to obtain the original task status data, task execution trajectory data, and task-related attribute data of each robot under each manufacturer's console when performing tasks, and converts the original task status data of each robot into standard task status data. The data perception layer, connected to the data adaptation layer, is used to construct a standard data association model between each robot's standard task status data, task execution trajectory data, and task association attribute data and the corresponding digital employee business scenario, based on the mapping relationship between the pre-configured digital employee business scenario and task-related attribute data. Based on the standard data association model, it calculates cross-vendor global task execution index data and same-vendor grouped task execution index data. The monitoring and alarm layer, connected to the data perception layer, is used to detect when anomalies occur in cross-vendor global task execution indicator data. Based on the task execution indicator data of the same vendor group, it determines the target vendor console that triggered the anomaly and triggers an anomaly alarm for the target vendor console. The resource scheduling layer, connected to the monitoring and alarm layer, is used to respond to abnormal alarms and execute abnormal scheduling strategies for tasks assigned to each robot under the target manufacturer's console.

[0005] Optionally, the data adaptation layer is used to extract the robot's manufacturer identifier and original status code from the original task status data of each robot; based on the manufacturer identifier, match the corresponding status mapping rule in a preset multi-manufacturer status mapping table; and map the original status code to a standard status code as standard task status data according to the status mapping rule.

[0006] Optionally, the task-related attribute data includes process version data, scene flow data, and resource usage data; The data perception layer is used to write process version data and scene flow data from the task association attribute data into a pre-created scene master data table for each robot's standard task status data, task execution trajectory data, and task association attribute data; it generates a task operation fact table based on the task execution trajectory data, generates a task identifier for the task operation fact table, and writes the scene identifier from the scene master data table into the task operation fact table to establish the attribution relationship between the task operation fact table and the scene master data table; it generates a measurement cache table based on resource usage data, generates a measurement identifier for the measurement cache table, and writes the task identifier from the task operation fact table into the measurement cache table to establish the traceability relationship between the measurement cache table and the task operation fact table; and it generates a standard data association model based on the scene master data table, task operation fact table, and measurement cache table.

[0007] Optionally, the data awareness layer is used to calculate the cross-vendor global task success rate as cross-vendor global task execution indicator data based on the standard data association model, and to calculate the task success rate, queuing time distribution, queuing time sorting and anomaly classification statistics of each vendor's console as grouped task execution indicator data within the same vendor.

[0008] Optionally, the monitoring and alarm layer is used to determine an anomaly when the cross-vendor global task success rate is lower than a preset global success rate threshold; to determine the target vendor console that triggered the anomaly based on the comparison results of the task success rate of each vendor console with the preset vendor success rate threshold; to determine the anomaly type of the target vendor console based on the queuing time distribution, queuing time sorting and anomaly classification statistics of the target vendor console, and to trigger an anomaly alarm containing the anomaly type.

[0009] Optionally, the digital employee data processing system provided in this application also includes: The visualization layer, connected to the data perception layer and the monitoring and alarm layer, is used to visualize the cross-vendor global task execution indicator data and the same-vendor group task execution indicator data based on the anomaly monitoring results.

[0010] Optionally, the resource scheduling layer is used to, when an anomaly alarm indicates a vendor-level failure, suspend the assignment of new tasks to each robot under the target vendor's console, and transfer tasks that have been assigned to each robot under the target vendor's console but have not yet started to the global task queue for reallocation to each robot under other vendors' consoles, and maintain the execution of tasks being executed by each robot under the target vendor's console until the task is completed or the task execution is abnormal; when an anomaly alarm indicates a task execution abnormality, the abnormal task is added back to the global task queue for rescheduling, or the abnormal task is forcibly terminated.

[0011] Optionally, the resource scheduling layer is also used to respond to external scheduling instructions by adding the tasks corresponding to the external scheduling instructions to the global task queue; matching target scheduling strategies for the tasks in the global task queue; and allocating the tasks in the global task queue to the corresponding robots based on the target scheduling strategies; wherein the target scheduling strategy is one of the following: automatic allocation, allocation by label, and allocation by robot instance.

[0012] Optionally, the digital employee data processing system provided in this application also includes: The orchestration and execution layer is used to load pre-orchestrated target processes based on task-bound process version data, and execute the target processes of tasks through robots specified for the tasks. The orchestration topology of the target processes is a pre-orchestrated and stored static topology. The orchestration topology includes multiple nodes, including automated execution nodes, human-machine interaction nodes, and artificial intelligence cognitive components. During the execution of the target processes, the execution of subsequent nodes in the orchestration topology is triggered based on the running status of the nodes and the preset flow control strategy.

[0013] On the other hand, this application provides a digital employee data processing method, applied to the aforementioned digital employee data processing system, comprising: Obtain the original task status data, task execution trajectory data, and task-related attribute data of each robot under the control console of each manufacturer when performing tasks, and convert the original task status data of each robot into standard task status data. Based on the mapping relationship between pre-configured digital employee business scenarios and task-related attribute data, a standard data association model is constructed between the standard task status data, task execution trajectory data, and task-related attribute data of each robot and the corresponding digital employee business scenarios. Calculate cross-vendor global task execution index data and same-vendor grouped task execution index data based on standard data association model; When an anomaly is detected in the global task execution metrics data across vendors, the target vendor's console that triggered the anomaly is determined based on the task execution metrics data grouped within the same vendor. The system triggers an abnormal alarm on the target manufacturer's console and executes an abnormal scheduling strategy for tasks that have been designated to be performed by each robot under the target manufacturer's console.

[0014] The beneficial effects of this application are as follows: This application transforms heterogeneous raw task status data from multiple vendors into unified standard task status data through a data adaptation layer, eliminating semantic ambiguity caused by differences in underlying protocols. This enables unified cross-vendor analysis and control based on standardized task status data. A standard data association model is constructed through a data perception layer to link robot operation data with digital employee business scenarios. Based on this model, cross-vendor global task execution indicator data and same-vendor group task execution indicator data are calculated, achieving multi-level operational situation awareness from global to group levels. Anomaly monitoring of cross-vendor global indicators and linked analysis of same-vendor group indicators through a monitoring and alarm layer quickly locates the vendor of the anomaly and automatically triggers alarms, upgrading fault detection and response from manual inspection to system automation. The resource scheduling layer automatically executes anomaly scheduling strategies in response to anomaly alarms, achieving automatic task recovery and load balancing in fault scenarios, improving system fault tolerance and resource utilization efficiency.

[0015] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description or may be learned by practicing this application. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram of the composition structure of the digital employee data processing system in the embodiments of this application; Figure 2 This is a schematic diagram outlining the digital employee data processing method in the embodiments of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and beneficial effects of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] Example 1 This embodiment provides a digital employee data processing system. The system employs a layered, decoupled architecture to uniformly collect, standardize, perform real-time calculations, and implement closed-loop scheduling of heterogeneous operational data generated by multi-vendor robotic process automation (RoMA) tools. For example... Figure 1 As shown, the digital employee data processing system 100 provided in this embodiment includes at least a data adaptation layer 101, a data perception layer 102, a monitoring and alarm layer 103, and a resource scheduling layer 104. Each layer communicates and interacts with the others through standardized internal interfaces, collectively forming a complete control chain from data acquisition to anomaly response; wherein: The data adaptation layer 101 connects to the consoles of various vendors to acquire the raw task status data, task execution trajectory data, and task-related attribute data of each robot under each vendor's console during task execution. It converts the raw task status data of each robot into standard task status data. Specifically, the vendor console refers to the central control management platform provided by each robotic process automation (RoLA) vendor. Each vendor's console manages several robots responsible for executing specific automation tasks. Due to significant differences in data structure, communication protocols, and status definitions among different vendor consoles, the data adaptation layer 101 acts as the connection boundary between the system and each vendor's console. Through a protocol adaptation module and message buffering mechanism, it masks the differences in the underlying transmission protocols and collects three types of raw data generated by each robot during task execution in real time. The raw task status data reflects the robot's current operating status, such as waiting to execute, running, successful execution, and failed execution. The task execution trajectory data records the complete process log of the robot's task execution, including the start time, end time, and input / output parameters of each step. The task-related attribute data contains contextual information related to task execution, such as process version, scene affiliation, and resource usage. The core function of the data adaptation layer 101 is to convert the heterogeneous raw task status data reported by various vendors' consoles into unified standard task status data within the system, thereby eliminating the semantic differences of multi-source data at the system entry point and providing a standardized data foundation for unified processing at subsequent levels.

[0019] The data perception layer 102, connected to the data adaptation layer 101, is used to construct a standard data association model between each robot's standard task status data, task execution trajectory data, and task association attribute data and the corresponding digital employee business scenario, based on the pre-configured mapping relationship between digital employee business scenarios and task-related attribute data. Based on this standard data association model, it calculates cross-vendor global task execution indicator data and same-vendor grouped task execution indicator data. Specifically, a digital employee business scenario refers to an automated application scenario defined by an enterprise according to actual business needs. Each digital employee business scenario corresponds to a specific set of business processes and robot configurations. The data perception layer 102, through pre-configured mapping relationships, associates each robot's standard task status data, task execution trajectory data, and task association attribute data with the corresponding digital employee business scenario, constructing a standard data association model. This standard data association model structurally associates dispersed robot operation data with the business scenario definition, enabling the system to aggregate and analyze robot operation data from a business scenario perspective. Building upon this foundation, the data perception layer 102 calculates two types of indicator data based on a standard data association model: cross-vendor global task execution indicator data provides a comprehensive assessment of the task execution quality of robots under all vendors' consoles from a global perspective; while same-vendor grouped task execution indicator data is statistically grouped by vendor dimension, reflecting the independent operating status of robots under each vendor's console. This two-layer indicator system provides multi-dimensional data support for subsequent anomaly monitoring and localization.

[0020] The monitoring and alarm layer 103, connected to the data perception layer 102, is used to detect anomalies in cross-vendor global task execution indicator data. Based on the same-vendor group task execution indicator data, it identifies the target vendor console that triggered the anomaly and triggers an anomaly alarm for that console. Specifically, the monitoring and alarm layer 103 continuously consumes cross-vendor global task execution indicator data from the data perception layer 102 and compares it with preset alarm thresholds. When the cross-vendor global task execution indicator data deviates from the normal range, the monitoring and alarm layer 103 determines that the overall system operation is abnormal and further uses the same-vendor group task execution indicator data for anomaly tracing analysis to determine which vendor console's abnormal operation caused the deterioration of the global indicators. For example, when the global task success rate decreases, the monitoring and alarm layer 103 compares the group task success rates of each vendor console one by one, identifying the vendor console with a significantly lower success rate than the benchmark as the target vendor console that triggered the anomaly. After identifying the target vendor console, the monitoring and alarm layer 103 triggers an anomaly alarm for that console, pushing the alarm information to maintenance personnel or automatically triggering subsequent scheduling actions. This hierarchical analysis mechanism, from global monitoring to group location, enables managers to quickly pinpoint the source of anomalies and shorten fault response time.

[0021] The resource scheduling layer 104, connected to the monitoring and alarm layer 103, is used to respond to anomaly alarms and implement anomaly scheduling strategies for tasks assigned to robots under the target vendor's console. Specifically, when the monitoring and alarm layer 103 triggers an anomaly alarm, the resource scheduling layer 104 receives the alarm information and automatically executes the anomaly scheduling strategy for tasks undertaken by robots under the target vendor's console. The specific form of the anomaly scheduling strategy can be configured according to the anomaly type and severity, such as suspending the assignment of new tasks to robots under the target vendor's console, transferring tasks assigned to robots under that vendor's console but not yet started to robots under other vendors' consoles, and maintaining the execution of ongoing tasks until completion or an anomaly occurs. Through this automated anomaly scheduling response, the system can automatically take measures to limit the expansion of the anomaly's impact after detecting an anomaly, ensuring the continuity and stability of overall task execution and avoiding global business interruption due to the failure of a single vendor's console.

[0022] This embodiment constructs a complete closed loop from data acquisition standardization, perception modeling, monitoring and alarming to scheduling response through the collaborative work of the above four-layer architecture. Each layer is connected layer by layer through standardized interfaces, facilitating both the independent evolution of each module and ensuring the coordinated operation of the entire chain. It should be understood that, although... Figure 1 The diagram illustrates a four-layer architecture, but in actual deployment, each layer can adopt various physical forms such as microservices, containerization, or modular monoliths, as long as the logical integrity of functional division and data flow is maintained. This layered and decoupled design breaks down the management barriers of independent multi-vendor consoles, enabling visible, controllable, and measurable cross-vendor digital employee operations.

[0023] Example 2 In this embodiment, the process by which the data adaptation layer 101 converts the raw task status data of each robot into standard task status data in Embodiment 1 is further described in detail. As one implementation method, the data adaptation layer 101 extracts the robot's vendor identifier and original status code from the raw task status data of each robot. Specifically, the raw task status data reported by robots under various vendor consoles when performing tasks typically uses structured data formats such as JSON, XML, or Protobuf. The system obtains this information by reading specific fields in the data message through a pre-built parser. For example, for a robot under a vendor console, the system can extract the vendor identifier from the vendor_id field and the original status code from the status_code field; for script-based custom agents, the corresponding information may be obtained by parsing log keywords or enumeration values ​​in heartbeat packets. This extraction mechanism enables the system to be compatible with data sources of different protocols and data formats, providing atomic input parameters for subsequent standardization processing.

[0024] Based on the vendor identifier, the system matches the corresponding state mapping rules in a pre-defined multi-vendor state mapping table. Specifically, the multi-vendor state mapping table is a static data structure stored in the system configuration center or database, defining the translation logic from each vendor's private state semantics to the platform's general state semantics. This mapping table can be implemented using key-value pair configurations, relational database tables, or YAML configuration files. For example, the mapping table can contain a set of mapping records, each consisting of a vendor identifier, the original state code, and a standard state code. When the system receives raw task state data, it queries the table using the extracted vendor identifier and the original state code as a composite index to obtain the corresponding state mapping rules. It should be understood that this mapping table exists independently of the core business code. This means that when a new automation vendor is integrated or an existing vendor upgrades its state definitions, only the configuration data needs to be updated without recompiling the system program, thus giving the platform strong scalability and ease of maintenance.

[0025] According to the state mapping rules, the original state codes are mapped to standard state codes as standard task state data. Specifically, the standard state codes belong to a unified set of standard states, which includes waiting state, running state, success state, abnormal state, and stopped state. These five states constitute the minimum complete abstraction of the robot's behavior throughout its entire lifecycle in this application. Among them, the waiting state covers semantics such as Pending, Queued, Waiting, and Scheduled, defined by various manufacturers, indicating that the task has been received but has not yet started execution; the running state covers semantics such as Running, Executing, and Processing, indicating that computing resources are being consumed; the success state covers semantics such as Completed, Success, and Finished, indicating that the task has ended normally; the abnormal state covers semantics such as Failed, Error, Faulted, and SystemError, indicating unexpected termination; and the stopped state covers semantics such as Stopped, Terminated, Cancelled, and Paused, indicating human intervention or strategic interruption. Through this many-to-one semantic convergence, the upper-layer modules can shield the differences between dozens or even hundreds of heterogeneous status codes at the lower layer. Based on these five standard status codes alone, a general monitoring dashboard, alarm strategy, and scheduling algorithm can be built, fundamentally solving the data silo problem in a multi-vendor environment.

[0026] Building upon the aforementioned state mapping, this embodiment also provides an adaptive mapping method for standard status codes to address status code changes caused by vendor version upgrades and the automatic discovery and learning of unknown status codes. Specifically, based on the vendor identifier and original status code contained in the original task status data obtained by the data adaptation layer 101 from various vendor consoles, a set of candidate version mapping rules corresponding to the vendor identifier is determined in a preset state mapping knowledge base. Compared to the aforementioned multi-vendor state mapping table, the state mapping knowledge base further introduces version-level management capabilities, meaning that multiple sets of version mapping rules can be maintained under each vendor identifier, and each set of version mapping rules corresponds to the status code definition of a specific version of that vendor. Based on the vendor version number carried in the original task status data, a target version mapping rule corresponding to the vendor version number is determined from the set of candidate version mapping rules. Based on the mapping relationship between the original status code and the standard status code recorded in the target version mapping rule, the original status code is mapped to the corresponding standard status code. This precise matching mechanism based on version numbers enables the accurate differentiation and handling of status code differences defined by the same vendor in different versions, avoiding state mapping errors caused by vendor version upgrades.

[0027] When the target version mapping rules do not contain a mapping record for the original status code, the original task status data is temporarily stored in a preset unknown status buffer, and an unknown status alarm is triggered. Specifically, the unknown status buffer is a dedicated storage area in the system for temporarily storing original task status data that cannot be automatically mapped. When a vendor's console reports a new status code that has not yet been registered in the mapping rules, the system does not discard the data but temporarily stores it and issues an alarm to notify administrators for manual annotation. In response to the mapping annotation operation submitted for the unknown status alarm, the system determines and obtains the annotated mapping relationship. Based on the annotated mapping relationship, the target version mapping rules corresponding to the vendor identifier and vendor version number in the status mapping knowledge base are updated, enabling subsequent identical status codes to be automatically mapped. Based on the annotated mapping relationship, the system retrieves the original task status data stored in the unknown status buffer and the historical task records recorded in the task execution fact table that correspond to the vendor identifier and original status code, and updates the retrieved original task status data and the original status codes in the historical task records to the mapped standard status codes. Based on the updated historical task records, the corresponding cross-vendor global task execution indicator data and same-vendor group task execution indicator data are recalculated. This closed-loop mechanism of "temporary storage-labeling-backfilling-recalculation" ensures that newly added status codes can be automatically backfilled into historical data after being manually confirmed, so that the calculation results of historical indicator data can be corrected and historical data loss or statistical bias caused by unmapped status codes can be avoided.

[0028] It should be noted that the state mapping knowledge base also records the confidence score of the target version mapping rule. Therefore, the confidence score of the target version mapping rule can be determined based on the cumulative number of times it has been marked as corrected by the management backend within a preset time period. When the confidence score falls below a preset confidence threshold, a mapping rule review alarm is triggered, and the target version mapping rule is marked as pending review. Specifically, the confidence score reflects the stability and reliability of the mapping rule. If a mapping rule is frequently corrected within a short period, it indicates that the rule may be inaccurately defined or that the state semantics on the vendor side have changed. The system lowers its confidence score and triggers a review alarm, prompting administrators to conduct a comprehensive review of the rule. This adaptive management mechanism based on confidence scores enables the state mapping knowledge base to continuously self-optimize during long-term operation, maintaining the accuracy and timeliness of the mapping rules.

[0029] Example 3 In this embodiment, the process of constructing a standard data association model by the data perception layer 102 in Embodiment 1 is further described in detail. As one implementation method, the task association attribute data includes process version data, scenario flow data, and resource consumption data. Specifically, process version data records the version information of the process files executed by the robot, including process identifier, version number, release status, etc., used to trace the process definition upon which each task execution is based; scenario flow data records the history of the status changes of the automated scenario from requirement submission to online operation, including scenario identifier, current stage, change timestamp, etc.; resource consumption data records the computing resources consumed by the robot during task execution, such as CPU utilization, memory usage, license usage status, network bandwidth consumption, etc. These three types of data describe the context of task execution from different dimensions and are the basic inputs for constructing a complete data association model.

[0030] The data perception layer 102, for each robot's standard task status data, task execution trajectory data, and task-related attribute data, writes the process version data and scenario flow data from the task-related attribute data into a pre-created scenario master data table. Specifically, the scenario master data table is a structured data table pre-created in the system database, used to store the basic attributes and configuration information of digital employee business scenarios. The scenario master data table uses the scenario identifier as the primary key, and each record corresponds to a digital employee business scenario, recording metadata such as the associated process version, current flow status, department, proposer, and implementation engineer. After receiving the task-related attribute data, the data perception layer 102 writes the process version data and scenario flow data into the corresponding records in the scenario master data table, thereby establishing a direct association between the process version information and scenario status information involved in each task execution and the corresponding digital employee business scenario.

[0031] A task execution fact table is generated based on task execution trajectory data. A task identifier is generated for the task execution fact table, and a scenario identifier from the scenario master data table is written into the task execution fact table to establish the attribution relationship between the task execution fact table and the scenario master data table. Specifically, the task execution fact table is a structured data table used to record each task execution process, with each record corresponding to a complete task execution instance. The data awareness layer 102 generates a new task execution fact record based on the received task execution trajectory data and assigns a unique task identifier to this record. Simultaneously, the data awareness layer 102 writes the corresponding scenario identifier from the scenario master data table as a foreign key into this task execution fact record, thereby establishing the attribution relationship between the task execution fact table and the scenario master data table. This attribution relationship allows each task execution record to be traced back to its respective digital employee business scenario, supporting aggregated queries and statistical analysis of task execution data by scenario dimension.

[0032] A metric cache table is generated based on resource usage data, and a metric identifier is generated for the metric cache table. A task identifier from the task execution fact table is also written into the metric cache table to establish a tracing relationship between the metric cache table and the task execution fact table. Specifically, the metric cache table is a structured data table used to store resource consumption metric data during task execution, with each record corresponding to a snapshot of resource usage during task execution. The data awareness layer 102 generates the metric cache table based on the received resource usage data and assigns a unique metric identifier to each metric record. Simultaneously, the corresponding task identifier from the task execution fact table is written into the metric cache table as a foreign key, thereby establishing a tracing relationship between the metric cache table and the task execution fact table. The metric cache table uses a caching mechanism for storage, supporting high-frequency writes and fast queries, meeting the low-latency access requirements for resource metric data in real-time monitoring scenarios.

[0033] A standard data association model is generated based on the scenario master data table, task execution fact table, and metric cache table. Specifically, the standard data association model is a structured data model composed of these three tables through hierarchical relationships between scenario identifiers, task identifiers, and metric identifiers. The scenario master data table is located at the top layer of the model, defining the basic framework of the digital employee business scenario; the task execution fact table is located in the middle layer, recording the detailed process of each task execution in each scenario; and the metric cache table is located at the bottom layer, recording the resource consumption details of each task execution. These three tables form a complete data link from scenario to task to metric through foreign key relationships, enabling the system to perform multi-dimensional data queries and analyses along this link. This hierarchical data association model provides a unified data query path for subsequent indicator calculations, anomaly analysis, and value assessment, eliminating the problems of data dispersion and missing relationships in multi-vendor environments.

[0034] Example 4 In this embodiment, the process of the data perception layer 102 calculating various task execution indicator data and the process of the monitoring and alarm layer 103 performing anomaly monitoring and alarm judgment in Embodiment 1 are further explained in detail. As one implementation method, the data perception layer 102 calculates the cross-vendor global task success rate as cross-vendor global task execution indicator data based on a standard data association model, and calculates the task success rate, queuing time distribution, queuing time sorting, and anomaly classification statistics of each vendor's console as task execution indicator data for the same vendor group. Specifically, the cross-vendor global task success rate is a success rate indicator obtained by summarizing and calculating the tasks completed by robots under all vendors' consoles within the statistical period, reflecting the overall task execution quality of the system. For example, the system uses the task running fact table in the standard data association model to count the ratio of the number of records in the successful state to the total number of records in all task running records within a specified time window, as the cross-vendor global task success rate. The task success rate of each vendor's console is calculated by grouping according to the vendor dimension, only counting the task execution records of robots under a specific vendor's console, for horizontal comparison of the differences in running quality among different vendors. Queuing time distribution statistics track the time interval between a task entering the global task queue and being scheduled to the robot for execution, reflecting the timeliness of task response from each vendor's console. Queuing time sorting arranges the average queuing times of each vendor's console in descending order to identify resource supply bottlenecks. Anomaly classification statistics categorize and count various anomalies occurring during task execution by cause, such as network timeouts, insufficient permissions, application crashes, and data anomalies, creating an anomaly cause distribution map. Through this dual-layer calculation of global and grouped indicators, the system can grasp the overall operational health status from a macro perspective and obtain detailed operational profiles of each vendor from a micro perspective, providing complete data support for subsequent anomaly localization.

[0035] Building upon this, this embodiment further elaborates on the anomaly monitoring and alarm determination mechanism of the monitoring and alarm layer 103. As one implementation method, the monitoring and alarm layer 103 determines an anomaly when the cross-vendor global task success rate falls below a preset global success rate threshold. Specifically, the preset global success rate threshold is a pre-configured global health baseline value in the system, for example, set to 95%. When the cross-vendor global task success rate calculated by the data perception layer 102 drops below this threshold, the monitoring and alarm layer 103 determines that the overall system operating quality has deviated from the normal range, thus identifying an anomaly. This triggering mechanism based on global indicators ensures that alarms are only triggered when the overall operating quality has indeed declined, avoiding false alarms due to local fluctuations in a single vendor.

[0036] Based on the comparison between the task success rate of each vendor's console and the preset vendor success rate threshold, the target vendor console that triggered the anomaly is determined. Specifically, the preset vendor success rate threshold is a health benchmark value set for a single vendor, which can be the same as or different from the global threshold, for example, set to 90%. The monitoring and alarm layer 103 compares the task success rate of each vendor's console with the preset vendor success rate threshold one by one, and identifies the vendor console with a success rate lower than the threshold as the target vendor console that triggered the anomaly. For example, when the global success rate drops to 93%, the system compares the task success rates of the first vendor console (98%), the second vendor console (72%), and the third vendor console (96%), and then identifies the second vendor console as the target vendor console that triggered the anomaly. This hierarchical location mechanism from global to group eliminates the need for maintenance personnel to check the data of each vendor one by one; the system automatically completes the screening and confirmation of the anomaly source.

[0037] Based on the queuing time distribution, queuing time ranking, and anomaly classification statistics of the target vendor's console, the anomaly type of the target vendor's console is determined, and an anomaly alarm containing the anomaly type is triggered. Specifically, the anomaly type can include various categories such as resource insufficiency anomalies, application failure anomalies, and network anomalies. After identifying the target vendor's console, the monitoring and alarm layer 103 further analyzes the queuing time distribution of the vendor's console to determine if there is a task backlog; analyzes the queuing time ranking to determine the severity of the queuing among all vendors; and analyzes the anomaly classification statistics to determine the main causes of the anomalies for the vendor. The system comprehensively determines the anomaly type based on the above analysis results. For example, when the queuing time ranking is high and the anomaly classification is mainly "application crash," the anomaly type is determined to be application failure; when the queuing time distribution shows a large backlog of tasks and the anomaly classification is mainly "resource insufficiency," the anomaly type is determined to be resource insufficiency. The final triggered anomaly alarm contains the determined anomaly type information, enabling operations and maintenance personnel to directly understand the nature of the anomaly and take targeted handling measures.

[0038] Example 5 In this embodiment, the visualization layer in Embodiment 1 is further described in detail. As one implementation, the digital employee data processing system 100 also includes a visualization layer 105, connected to the data perception layer 102 and the monitoring and alarm layer 103. This layer is used to visualize the cross-vendor global task execution indicator data and the same-vendor group task execution indicator data based on anomaly monitoring results. Specifically, the visualization layer 105 transforms the various indicator data calculated by the data perception layer 102 and the anomaly monitoring results from the monitoring and alarm layer 103 into an intuitive graphical interface, which is the main way for managers to understand the system's operating status. In a specific implementation, the cross-vendor global task execution indicator data can be displayed through a global dashboard, including components such as a global task success rate trend chart, a total task statistics card, and a global anomaly rate indicator. The same-vendor group task execution indicator data can be displayed through a vendor comparison view, including components such as a task success rate bar chart for each vendor's console, a box plot of queuing time distribution, and anomaly classification stacking bar chart. When the monitoring and alarm layer 103 detects an anomaly, the visualization layer 105 overlays an anomaly marker on the corresponding graphic component, such as turning the bar chart of the anomaly vendor red, popping up an alarm pop-up window, or marking the anomaly time point on the trend chart.

[0039] It should be understood that the specific graphical form and interaction method of the visualization layer 105 can be flexibly designed according to actual needs. For example, the global dashboard can be implemented using a web front-end framework, supporting real-time data refresh and historical data backtracking; the vendor comparison view can support filtering and drill-down by time range, vendor type, business scenario, and other dimensions. The visualization layer 105 can also support multi-level data drill-down operations. For example, managers can click on an abnormal indicator from the global dashboard to enter the group details view of that vendor, and then click on an abnormal task from the group view to enter the execution trajectory details of that task. As long as the data content displayed originates from the indicator data calculated by the data perception layer 102 and reflects the abnormal monitoring results of the monitoring and alarm layer 103, it should be covered within the protection scope of this application.

[0040] Example 6 In this embodiment, the abnormal scheduling strategy and normal scheduling strategy of the resource scheduling layer 104 in Embodiment 1 are further described in detail. As one implementation, when an abnormal alarm indicates a vendor-level failure, the resource scheduling layer 104 suspends the allocation of new tasks to each robot under the target vendor's console, and transfers tasks already designated for execution by each robot under the target vendor's console but not yet started to the global task queue for reallocation to robots under other vendors' consoles. It also maintains the execution of tasks currently being performed by each robot under the target vendor's console until task completion or an abnormal task execution occurs. Specifically, a vendor-level failure refers to a situation where the target vendor's console as a whole experiences service unavailability or widespread performance degradation, such as a crash in the central control service of the vendor's console, network connection interruption, or license server failure. When an abnormal alarm indicates such a failure, the resource scheduling layer 104 first suspends the allocation of new tasks to all robots under that vendor's console to prevent new tasks from being assigned to an unavailable environment. For tasks that have been designated to be executed by robots under the vendor's console but have not yet started, the resource scheduling layer 104 removes these tasks from the original vendor's task queue and puts them back into the global task queue, so that they can be reassigned to robots under other normally functioning vendor consoles. For tasks that are being executed by robots under the target vendor's console, the resource scheduling layer 104 maintains their execution status until the task completes naturally or an execution exception occurs, rather than forcibly interrupting them, because forcibly interrupting an executing task may lead to inconsistent business data or damage to the system state.

[0041] When an anomaly alarm indicates a task execution error, the abnormal task is either re-added to the global task queue for rescheduling or forcibly terminated. Specifically, a task execution error refers to a localized failure occurring during the execution of a single task, rather than a system-level failure of the entire vendor console. The resource scheduling layer 104 selects different handling strategies based on the nature of the error. For recoverable transient anomalies, such as connection timeouts due to network jitter or execution failures due to temporary resource contention, the resource scheduling layer 104 re-adds the abnormal task to the global task queue, waiting for it to be reallocated to an available robot in the next scheduling cycle, thus achieving automatic task retry. For unrecoverable severe anomalies, such as data verification failures due to process logic errors or execution failures due to permanent changes to the target system interface, the resource scheduling layer 104 forcibly terminates the abnormal task, releasing the robot resources and licenses occupied by the task to prevent invalid tasks from occupying system resources for extended periods.

[0042] In terms of normal scheduling, as one implementation method, the resource scheduling layer 104 is also used to respond to external scheduling instructions by adding the tasks corresponding to the external scheduling instructions to the global task queue; matching target scheduling strategies to the tasks in the global task queue; and allocating the tasks in the global task queue to the corresponding robots based on the target scheduling strategies. Specifically, external scheduling instructions can come from task execution requests manually triggered by administrators through the management interface, execution requests automatically triggered by scheduled task plans, or task triggering requests initiated by external systems through API interfaces. After receiving an external scheduling instruction, the resource scheduling layer 104 adds the task corresponding to the instruction to the global task queue for unified management.

[0043] The target scheduling strategy includes one of three methods: automatic allocation, allocation by tag, and allocation by robot instance. Specifically, automatic allocation means the system automatically selects the optimal robot to perform the task based on factors such as the current status and load of each robot, suitable for routine tasks without special requirements on the execution environment. Allocation by tag means matching the tags carried by the task with the tags carried by the robot, assigning the task to a robot that meets the tag conditions, suitable for tasks requiring a specific execution environment. Allocation by robot instance means that administrators or external scheduling instructions directly specify a particular robot instance to perform the task, suitable for debugging, testing, or scenarios requiring specific robots to perform tasks. This multi-strategy scheduling mechanism enables the system to flexibly respond to different business needs and operational scenarios.

[0044] Example 7 In this embodiment, the orchestration execution layer 106 in Embodiment 1 is further described in detail. As one implementation, the digital employee data processing system 100 also includes an orchestration execution layer 106, used to load pre-orchestrated target processes based on task-bound process version data, and execute the target processes of tasks through robots assigned to those tasks. Specifically, the orchestration execution layer 106 is the system's business logic execution carrier, responsible for driving predefined business processes to run on actual robots. The task-bound process version data records the process file and its version number that the task should execute. The orchestration execution layer 106 retrieves and loads the corresponding version of the target process definition from the process repository into memory based on this version data, ensuring that the task is executed according to the correct process version. This version-based loading mechanism supports parallel management of multiple versions of the same process. For example, when a process is upgraded from V1.0 to V2.0, existing tasks can still be executed according to version V1.0, while newly created tasks are executed according to version V2.0, avoiding the impact of version upgrades on existing tasks.

[0045] The orchestration topology of the target process is a pre-arranged and stored static topology. This topology includes multiple nodes, including automated execution nodes, human-computer interaction nodes, and artificial intelligence cognitive components. Specifically, the orchestration topology is a process structure pre-defined and persistently stored by the user during the design phase using a visual canvas, containing node configuration information and the connections between nodes. Automated execution nodes in the orchestration topology drive robots to complete deterministic system operations, such as standardized automated actions like logging into application systems, reading and writing files, and performing database queries. Human-computer interaction nodes are used to insert human decision-making or data entry breakpoints into the process, handling exceptional cases that the machine cannot complete autonomously. Artificial intelligence cognitive components encapsulate the logic of calling large models and are used to handle tasks related to understanding, generating, or reasoning about unstructured data. These three types of nodes differ fundamentally in their execution characteristics: automated execution nodes are typically synchronous and deterministic, human-computer interaction nodes are asynchronous with uncertain response times, and artificial intelligence cognitive components are probabilistic and rely on external large model services. The orchestration execution layer 106 manages the three types of nodes in the same process instance through a unified topology description language, enabling complex business processes to seamlessly connect machine automation, human intelligence and machine cognitive capabilities in a coherent execution context.

[0046] During the execution of the target process, the execution of subsequent nodes in the orchestration topology is triggered based on the running status of nodes and the preset flow control strategy. Specifically, the flow control strategy defines the evolution rules between nodes in the orchestration topology and is the core mechanism driving the dynamic operation of the process. In hybrid orchestration scenarios, due to the diversity of node types, the flow control strategy not only includes simple sequential triggering but also needs to handle complex control structures such as parallel synchronization, conditional branching, timeout jumps, and exception retries. The orchestration execution layer 106 monitors the running status of each node in real time, such as completion, failure, timeout, and locking, and automatically calculates the next hop node according to the flow control strategy. For example, when an automated execution node completes successfully, the flow control strategy triggers the execution of the next sequential node; when a human-computer interaction node does not receive human feedback within a specified time, the flow control strategy can automatically trigger skipping the node or switching to an exception handling branch, rather than blocking the entire process indefinitely; when a conditional branch node's branch condition is met, the flow control strategy selects that branch according to a mutual exclusion judgment mechanism and terminates the evaluation of the remaining branches. This state-driven automated workflow mechanism ensures that even in complex processes with many uncertainties, the system can maintain a controllable execution pace and robustness.

[0047] Based on the aforementioned flow control strategy, this embodiment also provides an intelligent timeout prediction and dynamic intervention method for human-computer interaction nodes to address the poor adaptability of traditional fixed timeout mechanisms in human-computer interaction scenarios. Specifically, based on the execution trigger of the target flow in the orchestration execution layer 106, the human-computer interaction node in the orchestration topology of the target flow is initiated. Based on the initiation of the human-computer interaction node, the task attribute data associated with the human-computer interaction node is obtained, including the processor identifier, task type, number of form fields, and current queue backlog. Based on the task attribute data and the timeout prediction model, the predicted completion time and prediction confidence interval of the human-computer interaction node are output.

[0048] The timeout prediction model is constructed as follows: Based on historical human-computer task execution data acquired by the data perception layer 102, a training sample set is extracted. Each sample in the training sample set includes the sample handler's identifier, the sample task type, the number of fields in the sample form, the sample processing time period, and the actual time consumed. Based on the training sample set, a regression model is trained as the timeout prediction model. It should be understood that this regression model can be implemented using algorithms such as gradient boosting trees, random forests, or neural networks, as long as it can output a predicted value and confidence interval for the completion time based on task attribute features. Through this data-driven modeling approach, the system can learn the actual time consumption patterns of different handlers processing different types of tasks at different times, thereby providing personalized timeout predictions for each new human-computer interaction node, rather than relying on a uniform fixed timeout set by experience.

[0049] Based on the preset fixed timeout threshold and predicted completion time of the human-computer interaction node, the target timeout threshold is calculated according to the preset timeout strategy. The preset timeout strategy includes: when the timeout strategy is conservative, the target timeout threshold is determined as the larger of the preset fixed timeout threshold and the P90 quantile of the predicted completion time; when the timeout strategy is standard, the target timeout threshold is determined as the larger of the preset fixed timeout threshold and the P75 quantile of the predicted completion time; when the timeout strategy is aggressive, the target timeout threshold is determined as the P50 quantile of the predicted completion time. Specifically, the conservative strategy is suitable for scenarios with high requirements for task completion quality and where skipping key approvals due to timeouts is not allowed; it takes the larger of the fixed threshold and the predicted P90 value to ensure that most tasks have sufficient processing time. The standard strategy is suitable for routine business scenarios, balancing processing quality with process timeliness. The aggressive strategy is suitable for batch processing scenarios with extremely high process throughput requirements, directly using the predicted median as the timeout threshold to maximize process flow speed. Managers can flexibly select the timeout strategy level according to the importance and urgency of the business scenario.

[0050] Based on the predicted completion time and the target timeout threshold, when the runtime of the human-computer interaction node reaches a preset percentage of the target timeout threshold, a pre-timeout warning notification is triggered. This pre-timeout warning notification includes sending a reminder to the handler and a timeout warning notification to the task initiator. Specifically, the preset percentage can be configured to 80% or other values. When the runtime of the human-computer interaction node reaches 80% of the target timeout threshold, the system automatically sends a reminder to the handler to prompt them to complete the task as soon as possible, and simultaneously sends a timeout warning notification to the task initiator to inform them that the task may be about to time out. This early warning mechanism allows the handler and initiator to take action before the timeout actually occurs, effectively reducing the probability of timeout events.

[0051] When the runtime of a human-machine interaction node reaches the target timeout threshold and no manual input data is received, the system triggers either skipping the human-machine interaction node or executing abnormal workflow logic, and generates an escalation work order. Specifically, the process of generating an escalation work order includes: based on the handler's identifier, determining the corresponding superior handler's identifier or backup handler group identifier in a preset hierarchical relationship table; based on the task identifier of the human-machine interaction node and the superior handler's identifier or backup handler group identifier, generating an escalation work order containing the task identifier and the target timeout threshold, and sending the escalation work order to the superior handler or backup handler group. This automatic escalation mechanism ensures that when a frontline handler fails to complete a task within the specified time, the system can automatically escalate the task to a higher-level manager or backup handler group, avoiding long-term process blockage due to single-point personnel unavailability, and realizing unattended automated operation in human-machine collaboration scenarios.

[0052] Example 8 This embodiment provides a digital employee data processing method, applied to the digital employee data processing system 100 described in the foregoing embodiment. Specifically, as follows: Figure 2 As shown, the method includes the following steps: Step S201: Obtain the original task status data, task execution trajectory data, and task-related attribute data of each robot under each manufacturer's console when performing tasks, and convert the original task status data of each robot into standard task status data.

[0053] Step S202: Based on the pre-configured mapping relationship between digital employee business scenarios and task-related attribute data, construct a standard data association model between the standard task status data, task execution trajectory data, and task-related attribute data of each robot and the corresponding digital employee business scenarios.

[0054] Step S203: Calculate cross-vendor global task execution index data and same-vendor grouped task execution index data based on the standard data association model.

[0055] Step S204: When an anomaly is detected in the cross-vendor global task execution indicator data, the target vendor console that triggered the anomaly is determined based on the same vendor group task execution indicator data.

[0056] Step S205: Trigger an abnormal alarm for the target manufacturer's console and execute an abnormal scheduling strategy for the tasks that have been specified to be executed by each robot under the target manufacturer's console.

[0057] The specific implementation process and technical effects of the above method steps can be found in the detailed description of the digital employee data processing system 100 in the foregoing embodiments, and will not be repeated here. It should be understood that the method embodiments and the foregoing system embodiments are based on the same technical concept, and the executing entities of each step correspond to the corresponding functional layers in the system. Technical details not described in detail in the method embodiments can be found in the corresponding descriptions in the system embodiments.

[0058] Example 9 This embodiment provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the aforementioned digital employee data processing method. Specifically, the computer instructions may be built into or installed in a processor, enabling the processor to implement the aforementioned digital employee data processing method by executing the built-in or installed computer instructions.

[0059] In addition, this embodiment also provides a program product, which includes program code that, when executed by a processor, implements the above-described digital employee data processing method.

[0060] As one implementation, the program product provided in this embodiment can employ any combination of one or more readable media. The readable media can be a readable signal medium or a readable storage medium. The readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or any combination thereof. Specifically, more specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, RAM, ROM, an erasable programmable read-only memory (EPROM), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0061] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0062] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0063] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

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

Claims

1. A digital employee data processing system, characterized in that, include: The data adaptation layer connects to the consoles of various manufacturers to obtain the original task status data, task execution trajectory data, and task-related attribute data of each robot under each manufacturer's console when performing tasks, and converts the original task status data of each robot into standard task status data. The data perception layer, connected to the data adaptation layer, is used to construct a standard data association model between standard task status data, task execution trajectory data, and task association attribute data of each robot and the corresponding digital employee business scenario, based on the mapping relationship between the pre-configured digital employee business scenario and task-related attribute data. Based on the standard data association model, it calculates cross-vendor global task execution index data and same-vendor grouped task execution index data. The monitoring and alarm layer, connected to the data perception layer, is used to detect when the cross-vendor global task execution indicator data is abnormal, determine the target vendor console that triggered the abnormality based on the same vendor group task execution indicator data, and trigger an abnormal alarm for the target vendor console. The resource scheduling layer, connected to the monitoring and alarm layer, is used to respond to the abnormal alarm and execute abnormal scheduling strategies for tasks that have been designated to be executed by each robot under the target manufacturer's console.

2. The digital employee data processing system as described in claim 1, characterized in that, The data adaptation layer is used to extract the manufacturer identifier and original status code of each robot from the original task status data; based on the manufacturer identifier, match the corresponding status mapping rule in a preset multi-manufacturer status mapping table; and map the original status code to a standard status code as the standard task status data according to the status mapping rule.

3. The digital employee data processing system as described in claim 1, characterized in that, The task-related attribute data includes process version data, scene flow data, and resource usage data. The data perception layer is used to write the process version data and scene flow data in the task association attribute data into a pre-created scene master data table for each robot's standard task status data, task execution trajectory data and task association attribute data. A task execution fact table is generated based on the task execution trajectory data, and a task identifier is generated for the task execution fact table. A scene identifier from the scene master data table is written into the task execution fact table to establish the attribution relationship between the task execution fact table and the scene master data table. A metric cache table is generated based on the resource usage data, a metric identifier is generated for the metric cache table, and a task identifier from the task execution fact table is written into the metric cache table to establish a tracing relationship between the metric cache table and the task execution fact table. Based on the scenario master data table, the task execution fact table, and the metric cache table, the standard data association model is generated.

4. The digital employee data processing system as described in claim 1, characterized in that, The data perception layer is used to calculate the cross-vendor global task success rate as the cross-vendor global task execution indicator data based on the standard data association model, and to calculate the task success rate, queuing time distribution, queuing time sorting and anomaly classification statistics of each vendor's console as the same vendor group task execution indicator data.

5. The digital employee data processing system as described in claim 4, characterized in that, The monitoring and alarm layer is used to determine an anomaly when the cross-vendor global task success rate is lower than a preset global success rate threshold; to determine the target vendor console that triggered the anomaly based on the comparison between the task success rate of each vendor console and the preset vendor success rate threshold; to determine the anomaly type of the target vendor console based on the queuing time distribution, the queuing time sorting, and the anomaly classification statistics, and to trigger an anomaly alarm containing the anomaly type.

6. The digital employee data processing system as described in claim 1, characterized in that, Also includes: The visualization layer, connected to the data perception layer and the monitoring and alarm layer, is used to visualize the cross-vendor global task execution indicator data and the same-vendor group task execution indicator data based on the anomaly monitoring results.

7. The digital employee data processing system as described in claim 1, characterized in that, The resource scheduling layer is used to, when the abnormal alarm indicates a vendor-level fault, suspend the allocation of new tasks to each robot under the target vendor's console, and transfer tasks that have been designated to be executed by each robot under the target vendor's console but have not yet started to the global task queue for reallocation to each robot under other vendors' consoles, and maintain the execution of tasks being executed by each robot under the target vendor's console until the task is completed or the task execution is abnormal; when the abnormal alarm indicates a task execution abnormality, the abnormal task is added back to the global task queue for rescheduling, or the abnormal task is forcibly terminated.

8. The digital employee data processing system as described in claim 1, characterized in that, The resource scheduling layer is further configured to respond to external scheduling instructions by adding the tasks corresponding to the external scheduling instructions to a global task queue; matching target scheduling strategies to the tasks in the global task queue; and allocating the tasks in the global task queue to corresponding robots based on the target scheduling strategies; wherein the target scheduling strategy is one of automatic allocation, allocation by tag, and allocation by robot instance.

9. The digital employee data processing system as described in claim 1, characterized in that, Also includes: The orchestration execution layer is used to load a pre-orchestrated target process based on task-bound process version data, and execute the target process of the task through a robot specified for the task; wherein, the orchestration topology of the target process is a pre-orchestrated and stored static topology; the orchestration topology includes multiple nodes, including automated execution nodes, human-machine interaction nodes, and artificial intelligence cognitive components; during the execution of the target process, the execution of subsequent nodes in the orchestration topology is triggered based on the running status of the nodes and the preset flow control strategy.

10. A method for processing digital employee data, characterized in that, The system is applied to the digital employee data processing system as described in any one of claims 1-9, comprising: Obtain the original task status data, task execution trajectory data, and task-related attribute data of each robot under the control console of each manufacturer when performing tasks, and convert the original task status data of each robot into standard task status data. Based on the mapping relationship between pre-configured digital employee business scenarios and task-related attribute data, a standard data association model is constructed between the standard task status data, task execution trajectory data, and task-related attribute data of each robot and the corresponding digital employee business scenarios. Based on the standard data association model, calculate cross-vendor global task execution index data and same-vendor grouped task execution index data; When an anomaly is detected in the cross-vendor global task execution metric data, the target vendor console that triggered the anomaly is determined based on the same vendor group task execution metric data. An abnormal alarm is triggered for the target manufacturer's console, and an abnormal scheduling strategy is implemented for the tasks that have been designated to be executed by each robot under the target manufacturer's console.

Images