White-box asynchronous process orchestration system supporting intermediate state observability and intervention

Abstract

The application discloses a white-box asynchronous process arrangement system supporting intermediate state observability and intervention, relates to the field of process arrangement, and comprises a data persistence layer, an observation interaction layer, a core execution layer and a module management layer. The core execution layer is configured to: realize data flow between nodes through a token pool mechanism; each token in the token pool mechanism carries a data reference identifier, a source node identifier and an error identifier; provide the state of each node to the observation interaction layer; receive a control instruction sent by the observation interaction layer and control the data flow between nodes according to the control instruction; and the observation interaction layer is configured to: receive and display the state of each node provided by the core execution layer; and receive a user interference request and convert the user interference request into a control instruction to be sent to the core execution layer. Data persistence and calculation execution are separated, cross-layer data transmission is realized through a data reference mechanism, and the problem of repeated serialization and transmission of data between layers in a traditional architecture is avoided.

Description

Technical Field

[0001] This application relates to the field of process orchestration, and in particular to a white-box asynchronous process orchestration system that supports the observability and intervention of intermediate states. Background Technology

[0002] Existing workflow orchestration systems are primarily based on the Directed Acyclic Graph (DAG) model, abstracting tasks as nodes and dependencies as edges, determining the execution order through topological sorting. Typical technologies include: Static orchestration systems based on DAGs: such as Apache Airflow and Luigi. Users write workflow definition code, the scheduler parses the DAG to generate an execution plan, triggers tasks sequentially according to dependencies, and triggers subsequent tasks after a task is completed. Web-based visualization platforms: such as Node-RED and n8n. These provide browser-based visual editors, allowing users to build flowcharts through drag-and-drop. The front-end uses React or Vue, and the flowchart is serialized into JSON for transmission to the back-end for parsing and execution. Event-driven workflow engines: such as Apache Kafka Streams and Flink. Based on an event stream model, data is transmitted in stream form, primarily for real-time data processing.

[0003] Existing process orchestration systems are based on directed acyclic graph models and have the following problems: they cannot natively support loop structures, and loop logic needs to be implemented through workarounds in iterative processing scenarios; branch merging lacks aggregation semantics, and cannot provide clear semantics for result aggregation when multiple parallel branches converge; dynamic process adjustment is difficult, as the complete structure of the flowchart is fixed in the parsing stage, making it difficult to support runtime adjustments.

[0004] The existing system adopts a black-box execution mode, which has the following problems: data flow is completely invisible, tasks exchange data through implicit mechanisms, and the data flow path and content changes cannot be observed; the execution status granularity is too coarse, the system can only provide task-level status, and cannot provide fine-grained execution information; intermediate results cannot be viewed, and users cannot view the input and output data of any node in a unified way; and the runtime is completely uncontrollable, once the process starts execution, users cannot intervene in any way during the execution process.

[0005] The existing system's error handling mechanism has the following problems: a single point of failure leads to global failure, and the failure of any task usually causes the entire process to terminate; there is a lack of fault tolerance strategy for aggregation points, and there is a lack of flexible fault tolerance strategy when the results of multiple parallel tasks are converged; the error information propagation mechanism is imperfect, and error information cannot be effectively transmitted to downstream tasks and users.

[0006] The existing system has the following problems in data transmission: low efficiency in transmitting big data objects, with direct serialization incurring huge overhead for big data objects; tight coupling between storage and transmission, resulting in a lack of flexibility; lack of a lazy loading mechanism, where all input data is loaded into memory when a task starts, causing resource waste; and difficulty in cross-process data sharing, with complex data sharing in multi-process scenarios.

[0007] This application is made in order to at least address the problems of the aforementioned black-box execution mode and data transmission. Summary of the Invention

[0008] The purpose of this application is to provide a white-box asynchronous process orchestration system that supports intermediate state observability and intervention, avoiding the problem of repeated data serialization and transmission between layers in traditional architecture, while breaking through the limitations of traditional black-box execution.

[0009] To achieve the above objectives, this application provides the following solution: This application provides a white-box asynchronous process orchestration system that supports intermediate state observability and intervention, including: a data persistence layer, an observation interaction layer, a core execution layer, and a module management layer; The data persistence layer is configured to: receive and store data objects provided by the core execution layer and return the corresponding data reference identifiers to the core execution layer; receive data reference identifiers provided by the core execution layer and return the corresponding data objects to the core execution layer; The core execution layer is configured to: manage data flow between nodes through a token pool mechanism, where each token carries a data reference identifier, a source node identifier, and an error identifier; determine a node in the pending execution state with an input token in the token queue as a ready node; extract the data reference identifier from the input token of the ready node and provide it to the data persistence layer, and receive the corresponding data object and provide it to the ready node to enable its execution; provide the data object generated by the successfully executed node n to the data persistence layer and receive the corresponding data reference identifier to generate the output token of node n, which also carries the identifier of node n and an error identifier of "false"; generate an output token carrying the identifier of node i and an error identifier of "true" for the node i that failed to execute; use the output tokens of node n and / or node i as the input tokens of its successor nodes; the completed node enters a termination state; provide the status of each node to the observation interaction layer; receive control commands sent by the observation interaction layer and control the data flow between nodes according to the control commands; The observation interaction layer is configured to: receive and display the status of each node provided by the core execution layer; receive user interference requests and convert them into control commands to send to the core execution layer; The module management layer is configured to manage the modules in the data persistence layer, the core execution layer, and the observation interaction layer.

[0010] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides a white-box asynchronous process orchestration system that supports intermediate state observability and intervention. The orchestration system adopts a layered architecture design, consisting of four layers from bottom to top: a data persistence layer, a core execution layer, a module management layer, and an observation and interaction layer. Each layer interacts through clearly defined interfaces, achieving a loosely coupled modular design. The innovative layered architecture design separates data persistence from computation execution, enabling cross-layer data transfer through a data reference mechanism, avoiding the problem of repeated data serialization and transmission between layers in traditional architectures. Simultaneously, the separation of the observation and interaction layer from the core execution layer makes the process execution completely observable and interventionable, breaking through the limitations of traditional black-box execution. Furthermore, the token pool mechanism explicitly models the data flow, with tokens carrying data references flowing visiblely, and the source, destination, and state of each token are traceable. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is an overall architecture diagram of a white-box asynchronous process orchestration system that supports intermediate state observability and intervention in one embodiment of this application; Figure 2 This is a flowchart of token flow management and logic backtracking provided in an embodiment of this application; Figure 3 This is a white-box status management and intervention flowchart provided in one embodiment of this application; Figure 4 A flowchart of data storage and retrieval processing with storage and computing separation provided in an embodiment of this application; Figure 5 This is a diagram of the barrier fault-tolerant aggregation execution logic provided in one embodiment of this application; Figure 6 A flowchart of hybrid concurrent scheduling processing provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all 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.

[0014] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0015] This invention provides a white-box asynchronous process orchestration system that supports intermediate state observability and intervention, comprising a data persistence layer, an observation and interaction layer, a core execution layer, and a module management layer.

[0016] The data persistence layer is configured to: receive and store data objects provided by the core execution layer and return the corresponding data reference identifiers to the core execution layer; receive data reference identifiers provided by the core execution layer and return the corresponding data objects to the core execution layer.

[0017] The core execution layer is configured as follows: It manages data flow between nodes through a token pool mechanism, where each token carries a data reference identifier, a source node identifier, and an error identifier. Nodes in a pending execution state with input tokens in the token queue are identified as ready nodes. The data reference identifier is extracted from the input tokens of ready nodes and provided to the data persistence layer. The corresponding data object is received and provided to the ready node for execution. The data object generated by successfully executed node n is provided to the data persistence layer, and the corresponding data reference identifier is received to generate node n's output token. Node n's output token also carries node n's identifier and an error identifier indicating "false". An output token carrying node i's identifier and an error identifier indicating "true" is generated for node i that failed to execute. The output tokens of node n and / or node i are used as input tokens for their successor nodes. Nodes that have completed execution enter a termination state. The status of each node is provided to the observation interaction layer. Control commands sent by the observation interaction layer are received, and data flow between nodes is controlled according to these commands.

[0018] The observation and interaction layer is configured to: receive and display the status of each node provided by the core execution layer; receive user interference requests and convert them into control commands to be sent to the core execution layer.

[0019] The module management layer is configured to manage modules in the data persistence layer, core execution layer, and observation interaction layer.

[0020] In the above technical solution, the workflow orchestration system adopts a layered architecture design, divided into four layers from bottom to top: data persistence layer, core execution layer, module management layer, and observation and interaction layer. Figure 1 As shown, the layers interact through clearly defined interfaces, achieving a loosely coupled modular design.

[0021] The innovative layered architecture design separates data persistence from computation execution, enabling cross-layer data transfer through a data reference mechanism. This avoids the problem of repeated data serialization and transmission between layers in traditional architectures. Simultaneously, the separation of the observation and interaction layer from the core execution layer makes the process execution fully observable and operable, breaking through the limitations of traditional black-box execution. Furthermore, the token pool mechanism explicitly models the data flow, with tokens carrying data references flowing visiblely; the source, destination, and state of each token are traceable.

[0022] The following is a detailed explanation of each layer.

[0023] The core execution layer includes a token flow management and logic backtracking module, a hybrid concurrency scheduling module, and a barrier fault tolerance aggregation module. The observation and interaction layer includes a white-box state management and intervention module, and the data persistence layer includes a storage-compute separated data reference and management module.

[0024] In the core execution layer, the token flow management and logic backtracking modules are configured to: pass the set of ready nodes and their corresponding task configurations to the hybrid concurrency scheduling module and obtain the execution results of each ready node from the hybrid concurrency scheduling module. The execution results include data objects generated when execution fails or succeeds. The hybrid concurrency scheduling module is configured to: allocate ready nodes to the process pool or coroutine pool for execution according to the task configuration and return the execution results of each ready node to the token flow management and logic backtracking modules. The barrier fault tolerance aggregation module is configured to: aggregate the input tokens of the aggregation nodes to generate the output token of the aggregation node, which then serves as the input token for its successor nodes.

[0025] I. Token flow management and logic backtracking module.

[0026] The token flow management and logic backtracking module is the central scheduling component of the core execution layer, responsible for implementing explicit data flow modeling and loop control functions. For example... Figure 2 As shown, the execution flow of this module is divided into three main parts: initialization phase, execution phase, and logic backtracking. It manages the flow of data between nodes through a token pool mechanism and achieves native loop support through loop condition evaluation.

[0027] The core innovation of the token flow management and logic backtracking module lies in introducing a token flow mechanism to achieve explicit data flow modeling. Unlike traditional directed acyclic graph models, in this invention, each data transfer is explicitly expressed through a token object. The token carries a data reference, source node identifier, and error flag, making the data flow path fully traceable. Simultaneously, the token backtracking mechanism natively supports loop structures, eliminating the need to expand the iteration process into multiple static nodes.

[0028] Specifically, the execution flow of the token flow management and logic backtracking modules includes a first initialization phase, an execution phase, and a logic backtracking judgment phase. These phases are sequentially linked to form a complete closed-loop process scheduling.

[0029] The first initialization phase includes the following steps: obtaining process definition data, which includes a node configuration list and a list of connections between nodes; identifying the process starting node based on the list of connections between nodes and constructing an edge adjacency list, an inbound edge adjacency list, an outbound edge adjacency list, and a circular edge index table; generating an initial token for each process starting node; creating a token queue data structure and allocating an independent token queue for each node; creating a node state mapping table and setting the initial state of all nodes to the pending execution state; and storing the initial token in the token queue of the corresponding starting node.

[0030] Specifically, such as Figure 2 As shown, the first initialization phase is located at the top of the process and includes three sequentially executed steps: identifying the process start node, generating an initial token, and storing it in the start node token pool. After completion, the process enters the execution phase.

[0031] The initialization phase receives process definition data as input, which includes a list of node configurations and a list of connections between nodes. First, the module iterates through the connection list to count the in-degree of each node, identifying nodes with an in-degree of zero as the process start node. Simultaneously, it constructs an edge adjacency list, out-edge adjacency list, in-edge adjacency list, and a cycle edge index table for subsequent token distribution, dependency checks, and cycle detection. After identifying the start node, the module generates an initial token for each start node. The token's data reference field is set to null to indicate no input data, the source node field is set to the system initialization flag, and the error flag field is set to false. Subsequently, the module creates a token pool data structure and allocates an independent token queue for each node. It also creates a node state mapping table and sets the initial state of all nodes to the pending execution state. Finally, the initial token is stored in the token queue of the corresponding start node. After the first initialization phase is completed, the module outputs the token pool and the node state mapping table. At this point, the start node's token queue contains the initial token, while the token queues of other nodes are empty, indicating that the process is ready to start execution.

[0032] The innovation of the first initialization phase lies in the dynamic determination of the node's pending execution status through a token pool mechanism. Traditional systems fix the execution order during the process parsing phase, while in this embodiment, the ready node is determined by the token queue status at runtime, supporting dynamic adjustment of the process execution order.

[0033] The execution phase process includes token extraction and readiness determination steps, business logic execution steps, token generation steps, and token distribution steps.

[0034] The token extraction and readiness determination steps include: determining the nodes in the pending execution state according to the node state mapping table; determining whether the predecessor nodes of the nodes in the pending execution state have all entered the termination state according to the edge adjacency list; determining whether there is an input token in the token queue of the nodes in the pending execution state; and if both conditions are met, then the nodes in the pending execution state are included in the ready node set.

[0035] The business logic execution steps include: for each ready node in the ready node set, extracting the data reference identifier from its input token, calling the data retrieval interface of the data persistence layer to obtain the corresponding data object, determining the parameter configuration and task configuration of the ready node in conjunction with the node configuration list, submitting the ready node set to the hybrid concurrency scheduling module for execution, the hybrid concurrency scheduling module assigning computationally intensive task nodes to the process pool and input / output intensive task nodes to the coroutine pool, collecting the execution result list after the node execution is completed, providing the data object generated by the successfully executed node n to the data persistence layer and receiving the corresponding data reference identifier, and recording detailed error information of the unsuccessfully executed node i.

[0036] The output token generation step includes: based on the execution result list, generating an output token for successfully executed node n, carrying node n's identifier, the corresponding data reference identifier, and an error identifier of "false"; generating an output token for unsuccessfully executed node i, carrying node i's identifier, detailed error information, and an error identifier of "true"; simultaneously updating the node state mapping table, updating the state of successfully executed node n to a successful termination state, updating the state of unsuccessfully executed node i to a failed termination state, and publishing a state change event to the observation interaction layer.

[0037] The token distribution steps include: traversing the output token list, obtaining all successor nodes of the source node of each output token according to the outgoing edge adjacency list, generating a copy of the output token and adding it to the token queue of each successor node.

[0038] Specifically, refer to Figure 2The execution phase is the core loop process of the module, which includes four steps: the node extracts a token from the token pool, obtains input data and executes business logic, generates an output token, and distributes it to the token pool of the successor node. After the execution phase is completed, the process enters the logic backtracking judgment.

[0039] Token extraction and readiness determination: During the execution phase, the module first traverses all nodes in the node state mapping table that are in the pending state. For each node, two conditions are checked: first, the dependency condition is met, i.e., all predecessor nodes of the node have entered the terminated state by checking the adjacency list of incoming edges; second, the token availability condition is met, i.e., the token queue of the node in the token pool is not empty. Nodes that meet both conditions are added to the ready node set. Then, the module performs a dequeue operation to extract tokens from the token queues of these nodes and updates the node state to running.

[0040] Business logic execution: For each node in the ready node set, the module extracts a data reference identifier from its input token, calls the data retrieval interface of the data persistence layer to obtain the actual input data object, and combines the execution module identifier and parameter configuration in the node configuration to submit the task to the hybrid concurrency scheduling module for execution. The hybrid concurrency scheduling module allocates computationally intensive tasks to the process pool and input / output intensive tasks to the coroutine pool based on task type, achieving differentiated and efficient scheduling. After task execution, the module collects the execution result list. For successful tasks, it calls the data persistence layer to store the output data and obtains the output data reference identifier; for failed tasks, it records detailed error information.

[0041] Output Token Generation: Based on the execution result list, the module generates an output token for each completed node. Successfully executed nodes generate a normal token, with its data reference field set to the output data reference identifier and the error flag set to false; failed nodes generate an error token, with its error flag set to true and detailed error information entered. Simultaneously, the node state mapping table is updated, changing the state of successful nodes to "completed" and the state of failed nodes to "failed," and a state change event is published to notify the white-box state management module using the observer pattern.

[0042] Token distribution: The module iterates through and outputs the token list, retrieves all successor nodes of each token source node based on the outgoing edge adjacency list, and adds a copy of the token to the token queue of each successor node. After token distribution is complete, the successor node's token queue already contains tokens from the preceding node, meeting the conditions for readiness. The process then proceeds to logical backtracking for judgment.

[0043] The innovation in the execution phase lies in the fact that tokens carry data references instead of actual data, enabling lightweight data transfer. Token distribution only requires copying the token object; the actual data is stored in the data persistence layer and loaded on demand, significantly reducing data transfer overhead. The error token mechanism ensures that error information propagates along the data flow path, providing a basis for error handling for downstream nodes and aggregation points.

[0044] The logical backtracking judgment phase includes: determining whether a loop back edge with the currently executed node as the source node exists based on the loop edge index table; if so, defining the currently executed node as a loop node; otherwise, defining the currently executed node as a non-loop node; passing the output token of the non-loop node to its successor node; evaluating whether the loop node satisfies the loop condition and has not reached the loop limit; if not, the evaluation result is negative; if satisfied, extracting the data reference identifier from the output token of the loop node, calling the data persistence layer to obtain the data object corresponding to the data reference identifier, using the data object as a condition variable to calculate the Boolean result of the loop condition expression; if the expression result is true, the evaluation result is positive; if the result is false, the evaluation result is negative; when the evaluation result is positive, the subsequent process of the loop node enters the logical backtracking path, sequentially executing the trigger control flow reset mechanism and resetting the state of the starting node; when the evaluation result is negative, terminating the loop process and passing the output token of the loop node to its successor node.

[0045] Specifically, such as Figure 2 As shown, after the execution phase is completed, the logic backtracking judgment process is entered. This process includes two decision points: first, it is determined whether the current node is a loop node. If so, it is evaluated whether the loop condition is met and the iteration limit has not been reached. Based on the evaluation result, it is decided to trigger the control flow reset mechanism to continue iteration, or terminate the loop and continue execution along the normal path.

[0046] Cyclic node determination: such as Figure 2 As shown, the first decision point in the logical backtracking judgment is "whether it is a loop node". The module checks whether there is a loop back edge with the current completed node as the source node in the loop edge index table. If there is no loop back edge, the current node is not a loop node, and the process returns directly to the execution stage to process other nodes along the "no" branch; if there is a loop back edge, the current node is a loop node, the module extracts the loop target node identifier, the loop condition expression and the maximum number of iterations configuration, and the process enters the loop condition evaluation along the "yes" branch.

[0047] Cyclic condition evaluation: such as Figure 2As shown, the second decision point is "evaluating whether the loop condition is satisfied and has not reached the upper limit". The module first checks whether the iteration counter has reached the maximum number of iterations and whether a user termination command has been received. If either condition is true, the evaluation result is no; otherwise, the module extracts the data reference from the output token of the loop node, calls the data persistence layer to obtain the actual data object, uses this data as the condition variable to calculate the Boolean result of the loop condition expression. If the expression result is true, the evaluation result is yes; if the result is false, the evaluation result is no.

[0048] Control flow reset: such as Figure 2 As shown, when the loop condition evaluation result is "yes", the process enters the logical backtracking path along the "yes" branch, and executes "trigger control flow reset mechanism" and "reset start node state" in sequence. The module increments the iteration counter to record the current iteration round, resets the state of the loop start node and all nodes on the loop path to "pending execution", generates a loop token carrying the loop node's output data reference and adds it to the token queue of the loop start node, notifies the white-box state management module to record the loop trigger event through the observer pattern, and then returns to the starting step of the execution phase to start a new round of iteration.

[0049] Loop termination: such as Figure 2 As shown, when the loop condition evaluation result is negative, the process follows the "No" branch to "terminate the loop" and "continue along the normal path". The module obtains the successor node of the loop node from the outgoing edge adjacency list and excludes the loop back edge target to identify the successor node of the normal path. It generates a termination token carrying the final iteration result data reference and distributes it to the token queue of the successor node of the normal path. It records the loop termination event including the total number of iterations and the termination reason, and then returns to the execution phase to continue processing other nodes.

[0050] The core innovation of the logic backtracking phase lies in achieving native loop support through a token backtracking mechanism. Traditional directed acyclic graph models cannot express loop structures and can only achieve loops by expanding iterations into multiple static nodes or external control, which leads to complex process definitions and high resource overhead. This embodiment achieves true loop semantics while maintaining the simplicity of the graph structure through loop edge indexing and control flow resetting mechanisms. The node definitions within the loop body only need to be defined once, and multiple executions are achieved through state resetting and token backtracking, significantly reducing the complexity of process definitions. At the same time, loop conditions can be dynamically evaluated based on runtime data, supporting data-driven iterative control, which has greater flexibility and adaptability compared to static expansion methods.

[0051] The token flow management and logic backtracking module, as the central scheduling component of the core execution layer, has a clear data transmission relationship with other modules of the system.

[0052] Interaction with the data persistence layer: During the execution phase, the data retrieval interface is called, and the data reference identifier in the token is passed to obtain the actual input data object. After execution, the data storage interface is called, and the output data object is passed to obtain the output data reference identifier. During the logic backtracking phase, the data retrieval interface is called to obtain the data required for loop condition evaluation.

[0053] Interaction with the white-box state management module: During the execution phase, node state change events are pushed through the observer pattern; during the logic backtracking phase, loop trigger or loop termination events are pushed; and user intervention instructions forwarded by the white-box state management module are received to support runtime flow control.

[0054] Interaction with the hybrid concurrency scheduling module: During the execution phase, the ready node set and task configuration are passed to the hybrid concurrency scheduling module, which allocates them to the process pool or coroutine pool for execution according to the task type. Then, the execution result list returned by the hybrid concurrency scheduling module is received.

[0055] Interaction with the barrier fault tolerance aggregation module: During the token distribution phase, the token is added to the token queue of the barrier node to trigger barrier waiting and aggregation processing. After the barrier fault tolerance aggregation module completes the processing, the output token is returned to this module for subsequent distribution.

[0056] II. White-box status management and intervention module.

[0057] The white-box state management and intervention module is a core component of the observation and interaction layer, responsible for achieving full observability and runtime controllability of process execution. For example... Figure 3 As shown, the execution flow of this module is divided into two main parts: second initialization and parallel processing. After the second initialization is completed, normal execution monitoring, cross-process synchronization and user intervention requests are processed simultaneously through three parallel branches. The three branches eventually converge to push observer notification to achieve unified output of the status.

[0058] The core innovation of this module lies in achieving complete transparency and runtime controllability in process execution. Traditional process orchestration systems employ a black-box execution model, where users can only view the results after the process ends, unable to know the internal state of the task during execution or intervene. This invention, through a combination of a global state mapping table, the observer pattern, and multiple types of intervention interfaces, enables users to view the execution status and intermediate results of any node in real time, and to perform intervention operations such as pausing, parameter modification, data injection, and node skipping during runtime, achieving a fundamental shift from a black-box to a white-box approach.

[0059] The second initialization phase includes: receiving the node configuration list from the process definition data; creating a global state mapping table data structure, with node identifiers as keys and complete state records as values. Each complete state record includes the basic state, start timestamp, end timestamp, execution time, input data references, output data references, error messages, and extended states; traversing the node configuration list, creating an initial state record for each node and setting the basic state field to the pending execution state, while setting other fields to empty or default values; and registering itself as a state change observer for the token flow management and logic backtracking modules to receive node state changes. The process initializes an inter-process communication listening channel to receive status reports from worker processes and a user intervention request listening interface to receive user interference requests. It outputs a global state mapping table, an observer registration completion flag, and a communication channel ready flag. The parallel processing node phase includes three concurrently running processing branches A, B, and C. Processing branch A is responsible for normal execution monitoring, processing branch B is responsible for cross-process synchronization, and processing branch C is responsible for user intervention. Each of the three processing branches (A, B, and C) independently processes its own input events. After processing, they converge on the observer notification push step, pushing the state change information to all registered observers.

[0060] Processing branch A consists of three sequentially executed steps: listening to node state transitions, updating the state mapping table, and pushing observer notifications. It is responsible for handling node state change events pushed by the token stream management and logic backtracking modules. Processing branch B consists of three sequentially executed steps: receiving reports from worker processes, parsing internal states, and updating extended state fields. These steps ultimately converge on the push observer notification step, which is responsible for processing fine-grained state update messages sent by worker processes through the inter-process communication channel.

[0061] Processing branch C includes: receiving user interference requests, and then dividing them into four parallel processing branches based on the user interference requests: pause / resume, modify parameters, inject data, and skip nodes. Each branch executes its corresponding logic and updates its status before converging into the push observer notification step, which is responsible for handling various intervention operations initiated by users during the process.

[0062] The observer notification process includes: receiving status update messages from three processing branches A, B, and C, with message types including node status change notifications, progress update notifications, and intervention result notifications, and pushing the status update messages to the status change observers.

[0063] Specifically, such as Figure 3As shown, the initialization phase is located at the top of the process and includes two sequentially executed steps: creating a global state mapping table and initializing node states to be executed. After completion, the process enters the parallel processing phase. The initialization phase receives the node configuration list from the process definition data as input. The module first creates a global state mapping table data structure, which uses node identifiers as keys and complete state records as values. The state record includes fields such as basic state, start timestamp, end timestamp, execution time, input data reference, output data reference, error information, and extended state. Then, the module traverses the node configuration list, creates an initial state record for each node, sets the basic state field to be executed, and sets other fields to empty or default values. The initialization phase also completes observer registration and communication channel preparation: the module registers itself as a state change observer of the token stream management and logic backtracking modules to receive node state transition events, and initializes the inter-process communication listening channel to receive status reporting messages from worker processes, and initializes the user intervention request listening interface to receive user operation instructions. After initialization, it outputs the ready global state mapping table, observer registration completion flag, and communication channel ready flag, and the module then enters the parallel processing phase to begin concurrent execution of the three branches.

[0064] The innovation of the second initialization phase lies in the establishment of a unified state management center. The global state mapping table not only records the basic execution state of the nodes, but also supports custom state information of arbitrary granularity by extending the state fields, laying the data foundation for subsequent fine-grained observability.

[0065] like Figure 3 As shown, after initialization, the process enters the parallel processing stage, which includes three concurrently running processing branches: branch A is responsible for normal execution monitoring, branch B is responsible for cross-process synchronization, and branch C is responsible for user intervention. Each of the three branches independently processes its own input events, and after processing, they converge on the observer notification push step, pushing the state change information to all registered observers.

[0066] like Figure 3 As shown, branch A is located on the left side of the parallel processing area and includes three sequentially executed steps: listening to node state transitions, updating the state mapping table, and pushing observer notifications. It is responsible for handling node state change events pushed by the token stream management and logic backtracking modules.

[0067] Branch A's data source is node state change events pushed by the token flow management and logic backtracking modules during the execution phase using the observer pattern. The event content includes the node identifier, state change type, and timestamp information. The module continuously waits for state change events to arrive through an asynchronous listening mechanism. Upon receiving an event, it parses the event content, locates the corresponding record in the global state mapping table based on the node identifier, updates the basic state fields according to the state change type, and records the corresponding timestamp information.

[0068] State change types include various transitions such as from pending execution to running, from running to completed, and from running to failed. For completion state transitions, the module calculates and records the execution time; for failure state transitions, the module records the error information field. After the state mapping table is updated, the module constructs a state update notification message and pushes it to all registered observers, driving the user interface to refresh and display the latest node status in real time.

[0069] The innovation of branch A lies in realizing real-time push of state changes through the observer pattern. Traditional systems require users to actively poll and query the state, which is delayed and resource-intensive. In this invention, state changes are immediately pushed to the observation layer, achieving true real-time observability.

[0070] like Figure 3 As shown, branch B is located in the middle of the parallel processing area and includes three sequentially executed steps: receiving reports from worker processes, parsing internal states, and updating extended state fields. It eventually converges to push observer notifications and is responsible for processing fine-grained state update messages sent by worker processes through inter-process communication channels.

[0071] Branch B's data source is the status update messages periodically sent by worker processes in the hybrid concurrent scheduling module during the execution of computationally intensive tasks. These messages contain node identifiers, progress types, and progress values. The module continuously receives these status update messages through an asynchronous inter-process communication channel, parses the message content, and extracts the node identifiers and progress information.

[0072] Progress types include iteration progress, completion percentage, key metrics, and others, used to describe the internal execution status of long-running tasks. The module locates the corresponding record in the global state mapping table based on the node identifier and appends or updates the parsed progress information to the extended state fields. After the extended state fields are updated, the module constructs a progress update notification message and pushes it to observers, allowing users to see the internal execution progress of computationally intensive tasks.

[0073] The core innovation of branch B lies in achieving fine-grained state synchronization across processes. In traditional systems, tasks submitted to worker processes are like entering a black hole; the main process cannot know the execution progress of the task. This invention establishes a state synchronization mechanism between worker processes and the main process through an inter-process communication channel, allowing users to see key information such as the number of iterations in model training and changes in loss values ​​in real time, breaking through the limitation of unobservable cross-process tasks.

[0074] like Figure 3 As shown, branch C is located on the right side of the parallel processing area. It first receives an intervention request, and then divides it into four parallel processing branches according to the request type: pause / resume, modify parameters, inject data, and skip nodes. Each branch executes its corresponding logic and updates its status before converging to push observer notifications, which are responsible for handling various intervention operations initiated by users during the process.

[0075] Branch C receives its data from user intervention requests initiated via the intervention interface. These requests include the intervention type, target node identifier, and operation parameters. The module continuously waits for user intervention requests via an asynchronous listening mechanism. Upon receiving a request, it parses the request type and routes it to the corresponding processing branch.

[0076] ① Pause / Resume Operation: When a user requests to pause the process, the module sets the global pause flag to true. When the token flow management and logic backtracking modules detect this flag while searching for ready nodes, they block and wait, while updating the status of all running nodes to paused. When a user requests to resume the process, the module clears the global pause flag and restores the status of paused nodes, waking up the token flow management and logic backtracking modules to continue execution.

[0077] ② Parameter modification operation: The module first verifies whether the current status of the target node is pending execution or paused. Only nodes that have not started execution or have been paused are allowed to modify parameters. After successful verification, the module parameters in the node configuration are updated. If the verification fails, an error response is returned.

[0078] ③ Data injection operation: The module obtains the target node identifier and the data object to be injected, calls the data persistence layer to store the data object and obtains the data reference identifier, creates a new token and sets the data reference to the obtained identifier and the source to the user injection mark. Finally, the new token is added to the token queue of the target node and triggers the token flow management and logic backtracking module to re-check the ready node.

[0079] ④ Skip Node Operation: The module verifies whether the current state of the target node allows skipping. If the verification is successful, the target node state is updated to "skipped", an empty token is generated and distributed to all successor nodes of the target node, so that the process can bypass the node and continue to execute.

[0080] After various intervention operations are completed, the module updates the status records of relevant nodes in the global state mapping table, constructs intervention result notification messages and pushes them to observers, so that users can see the effect of the intervention operations.

[0081] Branch C's innovation lies in providing rich runtime intervention capabilities. Traditional systems cannot be intervened once they start execution; if problems occur, they can only be terminated and restarted, resulting in low efficiency in debugging and exception handling. This invention supports pausing to observe the current state during process execution, modifying the parameter configuration of nodes to be executed, injecting test data into any node, and skipping faulty nodes to continue execution, greatly improving the flexibility of process debugging and exception handling, transforming the process orchestration system from "uncontrollable after startup" to "fully interventionable."

[0082] like Figure 3 As shown, after completing their respective state update processes, the three parallel branches converge on the observer notification push step. This step is responsible for pushing state change information to all registered observers via a publish-subscribe mechanism, including user interface components, logging components, and monitoring and alerting components.

[0083] The push observer notification step receives status update messages from three branches. Message types include node status change notifications, progress update notifications, and intervention result notifications. The module iterates through the observer registry, calls the notification interface of each observer to push the message out, and the observer executes corresponding processing logic based on the message type and content, such as interface refresh, log recording, and alarm triggering.

[0084] After the notification is pushed out, each branch returns to continue listening for the next input event, forming a continuously running parallel processing loop until the process is completed or the system shuts down.

[0085] The white-box state management and intervention module, as a core component of the observation and interaction layer, has a clear data transmission relationship with other modules of the system: Interaction with the token flow management and logic backtracking modules: Branch A receives node state change events pushed by the token flow management and logic backtracking modules through the observer pattern. The intervention operation of branch C performs operations such as pausing and resuming and token injection by calling the control interface of the token flow management and logic backtracking modules, thereby realizing runtime control of the process execution.

[0086] Interaction with the hybrid concurrent scheduling module: Branch B receives fine-grained state update messages reported by worker processes in the hybrid concurrent scheduling module through the inter-process communication channel, realizing cross-process state synchronization and observability.

[0087] Interaction with the data persistence layer: The injected data operation in branch C calls the data storage interface of the data persistence layer to save the user-injected data object and obtain the data reference identifier. The status query service calls the data retrieval interface of the data persistence layer to obtain the actual input and output data content of the node for the user to view.

[0088] Interaction with external observers: The push observer notification step pushes status update messages to all registered external observers through a publish-subscribe mechanism, supporting various application scenarios such as real-time user interface refresh, execution log recording, and anomaly monitoring and alarms.

[0089] III. Data reference and management module with separation of storage and computing.

[0090] The data reference and management module, which separates storage and computation, is the core component of the data persistence layer of this invention, responsible for implementing data storage, retrieval, and lifecycle management functions. For example... Figure 4 As shown, this module contains three independent sub-processes: Sub-process 1 is responsible for the data storage stage, Sub-process 2 is responsible for the data retrieval stage, and Sub-process 3 is responsible for the data cleaning stage. The three sub-processes work together to achieve full lifecycle management of data.

[0091] The core innovation of this module lies in decoupling data storage from data transmission, enabling indirect data access through data reference identifiers. In traditional systems, data is serialized and transmitted along with tasks, resulting in significant overhead and inefficiency for large data objects. In this invention, tasks only transmit lightweight data reference identifiers, with actual data loaded from the persistence layer on demand. Simultaneously, a parallel write mechanism separates metadata from payload data, achieving a balance between storage and access efficiency. Furthermore, the module supports transparent data sharing across processes; the main process and worker processes can access the same data using the same data reference identifier, eliminating the need for complex serialization transmission.

[0092] like Figure 4 As shown, the data reference and management module with storage and computing separation includes three sub-processes: data storage stage, data retrieval stage, and data cleaning stage. Each sub-process runs independently and is associated with another through a data reference identifier.

[0093] (a) First sub-process: Data storage stage.

[0094] like Figure 4 As shown, the data storage stage is located on the left side of the module. It receives data from the receiving node as input, and after three main processing stages—data serialization, parallel writing, and aggregation—it finally outputs a data reference. The parallel writing stage is divided into two parallel branches: the left branch is responsible for writing file system load data, while the right branch sequentially extracts metadata and writes database metadata. The two branches are merged at the aggregation node after completion.

[0095] Data Serialization: During the data storage phase, the module receives node output data objects and associated node identifiers generated during the execution phase of the token stream management and logic backtracking modules as input. The module first performs serialization processing on the business data objects, converting them into a persistent byte stream format. Simultaneously, it calculates the length of the byte stream as a data size indicator and calculates the checksum of the byte stream for subsequent data integrity verification. The serialization process employs a general serialization method to ensure that various types of business data objects can be correctly converted and restored.

[0096] Parallel writing: such as Figure 4 As shown, after serialization, the process enters the parallel write phase, which includes two concurrently executing branches to improve write efficiency. The left branch is responsible for writing the file system payload data, writing the serialized byte stream to the specified storage path in the file system. The file path is automatically generated based on the data reference identifier and timestamp to avoid naming conflicts. The right branch first performs the metadata extraction operation, generating a globally unique data reference identifier and constructing a metadata record. The metadata record includes fields such as data reference identifier, storage type, data size, checksum, associated node identifier, creation timestamp, and storage path; then, it performs the database metadata write operation, persistently storing the metadata record in the metadata database. The two branches execute in parallel, fully utilizing the concurrent write capabilities of the file system and database.

[0097] Convergence and output: such as Figure 4 As shown, after the two parallel write branches are completed, they are merged at the aggregation node. The module verifies that both file writing and metadata writing have been successfully completed. If either branch fails, a rollback mechanism is triggered to clean up the written data. After successful aggregation, the module returns a data reference identifier as output, which can be used for subsequent data retrieval and cross-process data sharing.

[0098] Innovation: The innovation in the data storage phase lies in using a parallel write mechanism to separate metadata from workload data. Metadata is small in size but frequently accessed, so it is stored in the database to support fast queries; workload data is large in size but accessed relatively infrequently, so it is stored in the file system to avoid database bloat. This separate storage strategy, combined with the parallel write mechanism, maximizes write throughput while ensuring data consistency.

[0099] (ii) Second sub-process: Data retrieval stage.

[0100] like Figure 4 As shown, the data retrieval stage is located in the middle of the module. It receives data references as input and goes through three sequential steps: querying the database to obtain metadata / paths, extracting from the file system, and deserialization. Finally, it outputs a returned data object.

[0101] Input and Metadata Query: During the data retrieval phase, the module receives data reference identifiers from the hybrid concurrent scheduling module or other modules as input, and records the request source identifier to distinguish between main process requests and worker process requests. The module first parses the data reference identifier, extracting the unique identifier and storage type flag. Then, it performs a database query to retrieve metadata / path information, using the data reference identifier as the query condition to retrieve the corresponding metadata record from the metadata database, extracting key information such as storage path, data size, and checksum. If the metadata record does not exist, the module returns a data non-existent error.

[0102] Extracting the file system: such as Figure 4 As shown, after obtaining the metadata, the process proceeds to the file system extraction step. The module locates the data file in the file system based on the storage path recorded in the metadata, reads the file content as a byte stream, and verifies whether the length of the byte stream matches the data size recorded in the metadata to detect data truncation issues. After reading, the module calculates the checksum of the byte stream and compares it with the checksum recorded in the metadata. If the checksums do not match, it indicates that the data has been corrupted during storage, and the module returns a data corruption error.

[0103] Deserialization and output: such as Figure 4 As shown, after file reading and verification pass, the process proceeds to the deserialization step. The module uses the same serialization method as during storage to reconstruct the byte stream into a business data object. If deserialization fails, it returns a data format error. Upon successful deserialization, the module returns a data object as output, which the caller can directly use for business processing.

[0104] Innovation: The innovation in the data retrieval phase lies in achieving transparent data sharing across processes. In traditional systems, transferring large data objects between the main process and worker processes requires complete serialization and deserialization, resulting in significant communication overhead. In this invention, the main process and worker processes use the same data reference identifier to call the same retrieval interface, accessing the same data through a shared file system and database. This eliminates the need to transfer actual data content between processes, significantly reducing the overhead of cross-process data sharing. Simultaneously, a checksum mechanism ensures the integrity of data transmission and storage, allowing for timely detection of any data corruption.

[0105] (III) Third sub-process: Data cleaning stage.

[0106] like Figure 4 As shown, the data cleanup phase is located on the right side of the module. It is initiated by triggering the expiration / end event and completes the automatic cleanup of expired data through three sequential steps: scanning expired metadata, deleting file system files, and deleting database records.

[0107] Trigger cleanup: such as Figure 4As shown, the data cleanup phase is initiated by triggering expired / end events. Triggering conditions include three types: scheduled triggers, process end triggers, and storage quota triggers. Scheduled triggers execute periodically according to the configured cleanup cycle; process end triggers execute automatically after the associated process completes; and storage quota triggers execute when storage space utilization exceeds a threshold. The triggering event carries the cleanup strategy configuration, including parameters such as the data retention period, storage quota threshold, and associated process status.

[0108] Scan expired metadata: such as Figure 4 As shown, after the cleanup is triggered, the process enters the step of scanning expired metadata. The module constructs query conditions according to the cleanup strategy configuration and retrieves a list of data records that meet the cleanup conditions from the metadata database. The cleanup conditions include: data whose creation time exceeds the retention period, data whose associated process has been completed and has exceeded the retention period, and data exceeding the quota selected according to the least recently used principle. After the scan is completed, the module records the total number of entries and the total size of the data to be cleaned, which is used for the statistical report after the cleanup is completed.

[0109] Delete files in the file system: such as Figure 4 As shown, after the scan is complete, the process proceeds to the file system deletion step. The module iterates through the list of data records to be cleaned, locates the corresponding data file in the file system based on the storage path in each record, and performs the file deletion operation. During the deletion process, the number of files successfully deleted and the storage space freed are recorded. If the deletion of a file fails, an error message is recorded, but other files are processed, ensuring the fault tolerance of the cleanup process.

[0110] Delete database records: such as Figure 4 As shown, after file deletion is complete, the process proceeds to the database record deletion step. The module iterates through the list of data records to be cleaned and deletes the corresponding metadata records from the metadata database, ensuring consistency between the metadata and the load data. After deletion, the module generates a cleanup statistics report, including the number of data entries cleaned, the amount of storage space released, cleanup time, failure records, and other information, for system management and monitoring purposes.

[0111] Innovation: The innovation in the data cleaning phase lies in the automated management of the data lifecycle. Traditional systems typically lack automatic cleaning mechanisms, leading to the continuous accumulation of temporary data and intermediate results that eventually exhaust storage space. This invention, through multiple triggering conditions and flexible cleaning strategies, automatically identifies and cleans expired data while ensuring the consistency of the file system and database, maintaining healthy storage space usage without manual intervention.

[0112] The data reference and management module, which separates storage and computation, is a core component of the data persistence layer and has a clear data transmission relationship with other modules in the system. Interaction with the token flow management and logic backtracking modules: During the execution phase, the token flow management and logic backtracking modules call the data storage interface of the first sub-process, pass in the node output data object and the associated node identifier, and obtain the data reference identifier to construct the output token; during the execution phase, they call the data retrieval interface of the second sub-process, pass in the data reference identifier in the input token, and obtain the actual input data object for task execution.

[0113] Interaction with the hybrid concurrent scheduling module: The worker process in the hybrid concurrent scheduling module calls the data retrieval interface of the second sub-process to obtain the input data required for task execution through the data reference identifier; after the task is executed, it calls the data storage interface of the first sub-process to store the output data and obtain the data reference identifier to return to the main process.

[0114] Interaction with the white-box state management module: The state query service of the white-box state management module calls the data retrieval interface of the second sub-process to obtain the actual input and output data content of the node for the user to view; the data injection operation in user intervention calls the data storage interface of the first sub-process to store the test data injected by the user and obtain the data reference identifier.

[0115] Interaction with the barrier fault tolerance aggregation module: During the execution phase, the barrier fault tolerance aggregation module calls the data retrieval interface of the second sub-process to obtain the output data of multiple front-end nodes for merging processing; after merging, it calls the data storage interface of the first sub-process to store the merging result and obtain a new data reference identifier.

[0116] IV. Barrier Fault Tolerance Aggregation Module.

[0117] The barrier fault-tolerant aggregation module is a crucial component of the core execution layer of this invention, responsible for handling the convergence synchronization and fault-tolerant aggregation functions of multi-branch parallel processes. For example... Figure 5 As shown, the execution flow of this module is divided into three main parts: waiting phase, aggregation phase, and execution phase. Branch synchronization is achieved by checking the status of the preceding nodes, flexible error handling is achieved through evaluation of various fault tolerance strategies, and finally, data merging or error handling is performed based on the evaluation results.

[0118] The core innovation of this module lies in providing flexible fault tolerance strategies and unified aggregation semantics for multi-branch convergence scenarios. Traditional systems, when multiple parallel branches converge, either require all branches to execute successfully—an overly strict requirement that makes the process fragile—or lack explicit aggregation semantics, requiring users to handle them manually, increasing development complexity. This invention provides three configurable fault tolerance strategies: strict mode, best effort mode, and threshold mode. Users can choose the most suitable fault tolerance level based on their business scenario. Simultaneously, the module automatically completes the merging of multi-branch output data, significantly simplifying the design and fault tolerance handling of multi-branch processes.

[0119] like Figure 5 As shown, the complete execution flow of the barrier fault tolerance aggregation module consists of three parts: the waiting phase, the aggregation phase, and the execution phase. These phases are sequentially connected and work together to achieve synchronous waiting, fault tolerance assessment, and data aggregation functions across multiple branches.

[0120] (a) Waiting phase.

[0121] like Figure 5 As shown, the waiting phase is located within the dashed box at the top of the process. It includes checking the status of the preceding nodes. Depending on whether all the preceding nodes have entered the termination state, there are two paths: if not all of them have terminated, the process enters the continuous waiting step and then returns to continue checking; if all of them have entered the termination state (complete / failed / skipped), the process enters the preceding token collection step. After completion, the process enters the aggregation phase.

[0122] Checking the status of preceding nodes: During the waiting phase, the module receives the barrier node configuration and the incoming edge adjacency list as input. First, it retrieves the list of all preceding node identifiers for the current barrier node from the incoming edge adjacency list and records the total number of preceding nodes. The module then enters a state detection loop, periodically traversing the preceding node list and querying the current state of each preceding node from the node state mapping table, counting the number of preceding nodes that have entered the termination state. For example... Figure 5 As shown, if the check result is that not all are terminated, the process enters the continuous waiting step along the left path, waits for the set detection interval time, and then returns to the check predecessor node status decision point to continue checking; if the check result is that all are terminated (complete / failed / skipped), the process enters the collect predecessor token step along the right path.

[0123] Collect prerequisite tokens: such as Figure 5 As shown, once all preceding nodes have entered the terminated state, the module performs a preceding token collection operation. The module retrieves the token queue of the current barrier node from the token buffer pool, iterates through all tokens in the queue, and matches the corresponding preceding node based on the token's source node field. Simultaneously, it checks the error flag field of each token. Tokens with a false error flag are added to the successful token list, and tokens with a true error flag are added to the failed token list. After collection is complete, the module counts the number of successful and failed tokens; these statistics will be used for fault tolerance evaluation in subsequent aggregation phases.

[0124] Innovation highlights: The innovation in the waiting phase lies in separating barrier synchronization from token collection, achieving more precise synchronization control by checking node status rather than simple counting. Termination status includes three types: completed, failed, and skipped. This ensures that even if some branches fail or are skipped by the user, the barrier node can correctly identify and continue processing, avoiding the problem in traditional systems where a single branch failure can block the entire process.

[0125] (ii) Aggregation stage.

[0126] like Figure 5 As shown, the aggregation phase is located within the dashed box in the middle of the process. First, the step of reading the aggregation strategy configuration is executed, and then the decision point for evaluating the fault tolerance condition is entered. This decision point is divided into three parallel paths according to the configured strategy type: strict mode, best effort mode, and threshold mode. Each path enters the execution phase to perform specific condition judgments and processing.

[0127] Read aggregation strategy configuration: such as Figure 5 As shown, the aggregation phase first executes the step of reading the aggregation strategy configuration. The module reads the aggregation strategy type field from the barrier node configuration. The strategy type can have three values: strict mode, best effort mode, and threshold mode. For threshold mode, the module additionally reads the success rate threshold parameter, which defines the minimum percentage of successful branches required for fault tolerance.

[0128] Assess fault tolerance conditions: such as Figure 5 As shown, after reading the configuration, the process enters the decision point for evaluating fault tolerance conditions. Based on the strategy type, it enters the execution phase through three paths. The strict mode path requires all preceding branches to execute successfully; any failure will cause the barrier node to fail. The best effort mode path only requires at least one preceding branch to execute successfully, allowing the process to continue even with partial failures. The threshold mode path requires the proportion of successful branches to reach the configured threshold, providing a flexible choice between strict and lenient approaches.

[0129] Innovation Highlights: The innovation in the aggregation phase lies in providing configurable multi-level fault tolerance strategies. Users can choose the most suitable fault tolerance level based on the reliability requirements of their business scenarios: a strict mode is used for critical business processes such as financial transactions to ensure data integrity and consistency; a best-effort mode is used for scenarios such as log collection where partial failures are tolerable to improve process availability; and a threshold mode is used for scenarios such as batch processing that require precise control over fault tolerance to set specific success rate requirements. This flexibility is lacking in traditional systems, which typically only offer a binary choice of all-success or all-failure.

[0130] like Figure 5 As shown, the execution phase, located within the dashed box at the bottom of the process, contains the specific judgment logic corresponding to the three fault-tolerance modes. The strict mode path checks for the existence of an erroneous token; the best effort mode path checks if the number of successful tokens is greater than zero; the threshold mode path first calculates the success rate, then checks if the success rate is greater than or equal to the threshold. The "yes" branches of each judgment converge to the data merging step, and the "no" branches converge to the failure-setting step. After data merging, a normal token containing the merged data is generated; after failure-setting, an erroneous token containing error details is generated.

[0131] Strict mode execution logic: such as Figure 5As shown, in strict mode, the path enters a decision point where an error token exists. The module checks if the failure token list is empty. If no error tokens exist (the number of failure tokens is zero), the process proceeds along the "No" branch to the data merging step; if error tokens exist (the number of failure tokens is greater than zero), the process proceeds along the "Yes" branch to the failure setting step. Strict mode ensures that the barrier node will only continue processing if all preceding branches have executed successfully; the failure of any single branch will cause the entire barrier node to fail.

[0132] Optimal effort mode execution logic: such as Figure 5 As shown, in the best effort mode, the path enters the decision point where the number of successful tokens is greater than zero. The module checks if the list of successful tokens is not empty. If the number of successful tokens is greater than zero, the process proceeds along the "Yes" branch to the data merging step; if the number of successful tokens is equal to zero (i.e., all branches have failed), the process proceeds along the "No" branch to the failure setting step. The best effort mode allows some branches to fail; as long as at least one branch executes successfully, the barrier node will continue processing the data from the successful branches.

[0133] Threshold mode execution logic: such as Figure 5 As shown, the threshold mode path first executes the success rate calculation step, dividing the number of successful tokens by the total number of preceding nodes to obtain the success rate value. The process then proceeds to the decision point where the success rate is greater than or equal to the threshold. The module compares the calculated success rate with the configured threshold parameter. If the success rate is greater than or equal to the threshold, the process proceeds along the "Yes" branch to the data merging step; if the success rate is less than the threshold, the process proceeds along the "No" branch to the failure step. Threshold mode provides precise fault tolerance control; for example, configuring a threshold of 80% means that a maximum of 20% of branches are allowed to fail.

[0134] Merging data and generating normal tokens: such as Figure 5 As shown, after each mode judgment passes, the process converges on the data merging step. The module iterates through the list of successful tokens, extracts the data reference identifier from each token, and calls the data retrieval interface of the data persistence layer to obtain the actual data object, constructing a list of data objects. Subsequently, the module executes the data merging operation according to the merging strategy configured in the barrier node. The merging strategy includes three types: list merging, dictionary merging, and custom merging. After merging is complete, the module calls the data storage interface of the data persistence layer to store the merged data objects and obtain the new data reference identifier, updating the barrier node status to "completed." Finally, as shown... Figure 5 As shown, the process enters the step of generating a normal token containing merged data. The module creates an output token, sets the data reference to the data reference identifier of the merged result, sets the source node to the barrier node identifier, and sets the error flag to false.

[0135] Set as failure and generate error token: such as Figure 5As shown, when each mode fails a judgment, the process converges into the "set as failed" step. The module iterates through the failure token list, extracts the error information field from each error token, summarizes all error information into an error details list, and constructs an aggregated error information containing the number of failed preceding nodes, the specific error information of each failed node, the type of fault tolerance strategy used, and evaluation details. The barrier node status is then updated to failed, and the aggregated error information is recorded. Subsequently, as... Figure 5 As shown, the process enters the step of generating an error token containing error details. The module creates the error token, sets the data reference to empty, sets the source node to the barrier node identifier, sets the error flag to true, and fills the error information field with aggregated error information.

[0136] Token distribution: Regardless of whether a normal token or an error token is generated, the module finally obtains a list of all successor node identifiers of the barrier node from the outgoing edge adjacency list, adds a copy of the output token to the token queue of each successor node, and publishes the state change event of the barrier node to notify the white-box state management module through the observer pattern.

[0137] The innovation in the execution phase lies in separating fault tolerance judgment from data aggregation, achieving flexible error handling and unified aggregation semantics. Traditional systems typically hard-code error handling logic into business code, requiring the repetitive writing of similar fault tolerance logic at different aggregation points. This invention, through configurable fault tolerance strategies and automated data merging, allows users to simply declare their desired fault tolerance level and merging method; the module automatically completes complex judgment and processing logic, significantly reducing the development difficulty of multi-branch processes. Simultaneously, error tokens carry detailed aggregated error information, enabling downstream nodes and users to accurately understand the cause of failure, facilitating problem diagnosis and handling.

[0138] As a crucial component of the core execution layer, the barrier fault-tolerant aggregation module has a clearly defined data transmission relationship with other modules in the system: Interaction with the token flow management and logic backtracking modules: During the token distribution phase, the token flow management and logic backtracking modules add the output tokens of the preceding nodes to the token queue of the barrier nodes to trigger barrier waiting; During the waiting phase, the barrier fault tolerance aggregation module collects the preceding tokens from the token buffer pool, and after the execution phase is completed, returns the generated output tokens to the token flow management and logic backtracking modules for subsequent distribution.

[0139] Interaction with the data persistence layer: During the execution phase, the barrier fault-tolerant aggregation module calls the data retrieval interface to obtain the output data of the successful branch for merging processing. After merging, it calls the data storage interface to store the merging result and obtain a new data reference identifier.

[0140] Interaction with the white-box state management module: After the execution phase is completed, the barrier fault tolerance aggregation module publishes a state change event through the observer pattern, notifying the white-box state management module to update the state information of the barrier nodes in the global state mapping table, including execution results, completion time, and error information.

[0141] Interaction with the node state mapping table: During the waiting phase, the barrier fault tolerance aggregation module queries the node state mapping table to obtain the current state of the preceding nodes, which is used to determine whether all preceding nodes have entered the termination state; during the execution phase, it updates the state of the barrier node itself in the node state mapping table to complete or fail.

[0142] V. Hybrid Concurrency Scheduling Module.

[0143] The hybrid concurrent scheduling module is a crucial component of the core execution layer of this invention, responsible for employing differentiated scheduling strategies based on task characteristics to achieve efficient concurrent execution. For example... Figure 6 As shown, the execution flow of this module is divided into three main parts: task classification, task submission and execution, and state synchronization. By querying the module's metadata, the task type is identified, and computationally intensive tasks are assigned to the process pool for execution, while input / output intensive tasks are assigned to the event loop for execution. At the same time, the state synchronization mechanism ensures the observability of cross-process tasks.

[0144] The core innovation of this module lies in employing differentiated scheduling strategies based on task characteristics. Traditional systems typically use a single scheduling mechanism, which cannot fully leverage the performance potential of different task types. This invention categorizes tasks into computationally intensive and input / output intensive types. Computationally intensive tasks are allocated to a multi-process pool for execution to overcome the limitations of the global interpreter lock and achieve true parallel computing. Input / output intensive tasks utilize asynchronous coroutines to achieve efficient concurrency within a single thread, avoiding thread switching overhead. Simultaneously, an inter-process communication mechanism synchronizes the states of worker processes and the main process, ensuring the observability of cross-process tasks and overcoming the limitation of unmonitorable cross-process tasks in traditional systems.

[0145] like Figure 6 As shown, the complete execution flow of the hybrid concurrent scheduling module includes three parts: task classification, task submission and execution, and state synchronization. After the task classification is completed, the task is split into two parallel execution paths according to the task type. The state synchronization and execution phases run in parallel to ensure real-time state updates.

[0146] (a) Task Classification Phase like Figure 6As shown, the task classification stage is located within the dashed box at the top of the process. It receives ready nodes as input and enters the task type identification decision point after querying the module's metadata. This decision point is divided into two paths based on the task type: computationally intensive and input / output intensive. These paths lead to the left and right branches of the task submission and execution stages, respectively.

[0147] Input ready nodes: such as Figure 6 As shown, the task classification phase receives the set of ready nodes generated during the execution phase by the token stream management and logic backtracking modules as input. This set contains identifiers of all nodes that meet the execution conditions and their corresponding input tokens. The module creates two empty lists: a list of computationally intensive tasks and a list of input / output intensive tasks, for subsequent task classification and storage.

[0148] Query module metadata: such as Figure 6 As shown, the module iterates through each node in the ready node set, extracts the associated execution module identifier from the node configuration, and calls the metadata query interface of the module management layer to obtain the metadata information of the execution module. The module metadata includes fields such as module identifier, module description, parameter specifications, and task type identifier, among which the task type identifier field clearly indicates the task characteristics of the module.

[0149] Identify task type: such as Figure 6 As shown, the module categorizes tasks based on the retrieved task type identifier field. If the task type identifier is "computation-intensive," it indicates that the task involves a large number of numerical calculations, matrix operations, or model inferences. The process adds this node to the computation-intensive task list along the left path. If the task type identifier is "input-output-intensive," it indicates that the task mainly involves input-output operations such as network requests, file read / write operations, or database queries. The process adds this node to the input-output-intensive task list along the right path. After categorization, the module records the quantity statistics for both types of tasks.

[0150] The innovation in the task classification phase lies in the automatic identification of task types through module metadata. Traditional systems typically determine task types through runtime dynamic detection or manual user configuration; the former increases runtime overhead, and the latter increases the burden on users. This invention declares task types as part of the module metadata during module registration. The scheduler can quickly obtain type information and allocate tasks before execution, without runtime detection or user intervention.

[0151] (ii) Task submission and execution phase.

[0152] like Figure 6As shown, the task submission and execution phase is located within the dashed box in the middle of the process, comprising two parallel branches: the first branch (left) and the second branch (right). The left branch (first branch) handles computationally intensive tasks, sequentially executing three steps: encapsulation into a process pool task, submission to the process pool, and multi-process parallel execution. The right branch (second branch) handles input / output intensive tasks, sequentially executing three steps: encapsulation into an asynchronous coroutine, submission to the event loop, and single-threaded concurrent execution. After both branches complete execution, they converge on the asynchronous waiting step for all tasks to complete, followed by the sequential execution of the steps for collecting execution results and generating output tokens.

[0153] Left branch: Process pool scheduling for computationally intensive tasks Encapsulate as a process pool task: such as Figure 6 As shown, the left branch first executes the step of encapsulating the task into a process pool. The module traverses each node in the list of computationally intensive tasks, retrieves the input token for that node from the token buffer pool and extracts the data reference identifier, extracts the execution module identifier and module parameter configuration from the node configuration, and obtains an execution context snapshot containing the process identifier, node identifier, iteration count, and inter-process communication channel identifier. The module constructs the above information into a task object and serializes the task object into a format that can be transmitted across processes. The serialization process ensures that the data reference identifier, rather than the actual data, is transmitted to reduce communication overhead.

[0154] Submit to the process pool: such as Figure 6 As shown, after encapsulation, the process proceeds to the step of submitting to the process pool. The module submits the serialized task object to a pre-created task queue in the process pool. The process pool maintains multiple worker processes and retrieves tasks from the task queue, assigning them to idle worker processes for execution. The module records the task submission timestamp for subsequent execution time calculation.

[0155] Multi-process parallel execution: such as Figure 6 As shown, after submission, the process enters a multi-process parallel execution step, which runs in independent worker processes. Each worker process receives serialized task objects from the task queue and performs deserialization. It loads the execution module from the module management layer based on the execution module identifier, retrieves the actual input data object by calling the data retrieval interface of the data persistence layer based on the data reference identifier, and uses the module parameter configuration and the input data object to call the business logic methods of the execution module to complete the computation. Multiple worker processes can execute different tasks simultaneously, achieving true parallel computing to fully utilize multi-core processor resources.

[0156] Innovation: The innovation of the left branch lies in achieving true parallel execution of computationally intensive tasks. Many programming languages ​​have a global interpreter lock mechanism, which limits the parallel computing capabilities of multi-threaded programs. This invention overcomes the limitation of the global interpreter lock by allocating computationally intensive tasks to independent worker processes, each with its own independent interpreter instance. This allows computationally intensive tasks to be executed in true parallel on multiple processor cores, fully leveraging the hardware's computing power.

[0157] Right-hand branch: Coroutine scheduling for input / output intensive tasks Encapsulate as an asynchronous coroutine: such as Figure 6 As shown, the right-hand branch first executes the step of encapsulating the process into an asynchronous coroutine. The module traverses each node in the list of input / output intensive tasks, retrieves the input token for that node from the token buffer pool and extracts the data reference identifier, and extracts the execution module identifier and module parameter configuration from the node configuration. The module creates a coroutine function that encapsulates the following execution logic: calling the data persistence layer to obtain the input data object, loading the execution module, executing the business logic, storing the output data and obtaining the data reference identifier, and returning the execution result.

[0158] Submit to the event loop: such as Figure 6 As shown, after encapsulation, the process enters the step of submitting to the event loop. The module submits the created coroutine functions to the execution queue of the event loop, which is responsible for scheduling and driving the execution of all coroutines. The module records the task submission timestamp for subsequent execution time calculation.

[0159] Single-threaded concurrent execution: such as Figure 6 As shown, after submission, the process enters the single-threaded concurrent execution step. The event loop drives the execution of all coroutines within this single thread. When a coroutine encounters an input / output operation during execution, it voluntarily relinquishes control and registers the input / output operation with the event loop. The event loop then switches to another ready coroutine to continue execution. When the input / output operation is complete, the event loop receives a completion notification and marks the corresponding coroutine as pending execution, resuming coroutine execution at an appropriate time. This mechanism enables a single thread to efficiently handle a large number of concurrent input / output operations, avoiding the thread switching overhead and synchronization complexity of multi-threaded models.

[0160] Innovation Explanation: The innovation of the right-hand branch lies in fully utilizing the asynchronous coroutine mechanism to achieve efficient concurrency for input / output intensive tasks. In traditional synchronous execution modes, tasks block threads while waiting for input / output operations, leading to resource waste. While multithreaded modes can achieve concurrency, they incur thread switching overhead and synchronization complexity. This invention uses a coroutine mechanism to allow tasks to actively relinquish control while waiting for input / output, enabling a single thread to concurrently process a large number of input / output operations. This significantly improves the utilization efficiency of input / output bandwidth while maintaining code simplicity and maintainability.

[0161] Task aggregation and result processing: Asynchronous waiting for all tasks to complete: such as Figure 6 As shown, after the execution of the left and right branches, the process converges to the asynchronous waiting step for all tasks to complete. The module uses an asynchronous waiting mechanism to simultaneously wait for the completion of all tasks in the process pool and all coroutines in the event loop. During this waiting process, the main process is not blocked and can handle messages from the state synchronization phase. Once all tasks have completed execution, the module continues with subsequent processing.

[0162] Collect execution results: such as Figure 6 As shown, after the waiting period is complete, the process proceeds to the step of collecting execution results. The module collects the execution results returned by the process pool tasks and the coroutine tasks, merging the two sets of results into a unified execution result list. Each execution result includes a node identifier, execution status (success or failure), output data reference identifier (for success) or error message (for failure), execution time, and other information.

[0163] Generate output tokens: such as Figure 6 As shown, after collecting the results, the process proceeds to the step of generating output tokens. The module iterates through the execution result list, creating a normal token for each successful execution result, setting the data reference to the output data reference identifier and the error flag to false; for each failed execution result, it creates an error token, setting the error flag to true and filling the error information field with detailed error content. The generated output token list, along with the execution result list, is returned to the token flow management and logic backtracking modules for subsequent status updates and token distribution operations.

[0164] (III) State synchronization phase.

[0165] like Figure 6 As shown, the state synchronization phase is located within the dashed box in the lower left corner of the process and runs in parallel with the task submission and execution phases. This phase includes two steps: worker processes sending state byte streams and the main process updating the global state table. Cross-process state synchronization is achieved through a periodic reporting mechanism and a monitoring update mechanism.

[0166] Periodic reporting and worker processes sending status byte streams: such as Figure 6 As shown, during the parallel execution of multiple processes, worker processes send execution progress information to the main process through a periodic reporting mechanism. Worker processes trigger status reporting at key checkpoints in the business logic execution process. These checkpoints include the completion of each iteration of the iterative loop, the completion of a stage of processing, and the completion of key indicator calculations. The worker processes construct status update messages containing node identifiers, progress types, progress values ​​or status descriptions, timestamps, etc., and send these messages to the main process through an inter-process communication channel. The status messages use a lightweight serialization format to reduce communication overhead.

[0167] Listening for updates and the main process updating the global state table: such as Figure 6 As shown, the main process continuously receives status update messages from worker processes through a monitoring update mechanism. The main process asynchronously listens to the inter-process communication channel, and upon receiving a message, parses the message content to extract the node identifier and progress information. It then calls the status update interface of the white-box state management module to update the progress information in the extended state field of the global state mapping table. After the update is complete, the white-box state management module pushes the progress update to all registered observers using the observer pattern, allowing users to see the internal execution progress of long-running tasks in real time.

[0168] Innovation Explanation: The core innovation of the state synchronization phase lies in achieving fine-grained state synchronization across processes. In traditional systems, tasks submitted to worker processes are like entering a black hole; the main process can only wait for the task to complete and obtain the final result, unable to know the internal execution progress of the task. This invention establishes a bidirectional communication mechanism between worker processes and the main process through an inter-process communication channel. Worker processes can periodically report their execution progress, and the main process can update the state table in real time and push it to observers, allowing users to see key information such as the number of iterations in model training, changes in loss values, and data processing progress. This overcomes the limitation of unobservable cross-process tasks and achieves improved observability from the task granularity to the step granularity.

[0169] As a crucial component of the core execution layer, the hybrid concurrency scheduling module has a clearly defined data transmission relationship with other modules in the system: Interaction with the token flow management and logic backtracking modules: During the execution phase, the token flow management and logic backtracking modules pass the set of ready nodes and the corresponding input tokens to the hybrid concurrency scheduling module for task classification and execution; after the hybrid concurrency scheduling module completes the execution, it returns the execution result list and the output token list to the token flow management and logic backtracking modules for subsequent status updates and token distribution.

[0170] Interaction with the data persistence layer: Before executing business logic, worker processes and coroutines call the data retrieval interface, passing in the data reference identifier in the input token to obtain the actual input data object; after the business logic is executed, they call the data storage interface, passing in the output data object to obtain the output data reference identifier and return it to the main process.

[0171] Interaction with the white-box state management module: During the state synchronization phase, the main process listens for updates and calls the state update interface of the white-box state management module to update the progress information reported by the worker processes to the global state mapping table. The white-box state management module is responsible for subsequent observer notification pushes.

[0172] Interaction with the module management layer: During the task classification phase, the metadata query interface of the module management layer is called to obtain the task type identifier of the execution module; when the worker process and coroutine execute business logic, the module loading interface of the module management layer is called to obtain the execution module instance.

[0173] I. The technical effects of each module are as follows: (a) Technical effects of token flow management and logic backtracking module.

[0174] 1. Native Loop Support: The loop structure is implemented through the token backtracking mechanism, eliminating the need to expand the iteration into multiple static nodes, which reduces node definition overhead compared to the traditional expansion method.

[0175] 2. Explicit Data Flow: Each token carries a clear data reference and source node identifier, and the data flow path is fully traceable.

[0176] 3. Dynamic process adjustment: Whether a node is ready is dynamically determined by the token queue status, and the execution order of the process can be dynamically adjusted at runtime.

[0177] (ii) Technical effects of white-box status management and intervention module.

[0178] 1. Real-time observability: Node state changes are pushed out instantly through the observer pattern, allowing users to view the execution status and intermediate results of any node in real time.

[0179] 2. Cross-process state synchronization: worker processes can periodically report their execution progress, and the main process can obtain the internal execution progress of computationally intensive tasks.

[0180] 3. Runtime intervention capability: Supports various intervention operations such as pause and resume, parameter modification, data injection, and node skipping, without requiring a process restart.

[0181] (III) Technical effects of data reference and management modules with storage and computing separation.

[0182] 1. Storage efficiency optimization: Automatically select the optimal storage method based on the data scale, and use file storage for big data objects to reduce database pressure.

[0183] 2. Lazy loading: The actual data is loaded only when the task is executed, through data references, to avoid unnecessary memory usage.

[0184] 3. Cross-process data sharing: Efficient data sharing between the main process and worker processes is achieved through data reference identifiers, without the need for complex serialization transmission.

[0185] (iv) The technical effect of the barrier fault-tolerant aggregation module.

[0186] 1. Flexible fault tolerance strategy: Supports three fault tolerance strategies: strict mode, best effort mode and threshold mode, to adapt to the needs of different business scenarios.

[0187] 2. Intelligent data aggregation: Automatically merges the output results of multiple parallel branches, providing unified aggregation semantics.

[0188] 3. Error message propagation: Error tokens carry detailed error information, ensuring that error information is effectively transmitted to downstream nodes and users.

[0189] (v) Technical effects of the hybrid concurrent scheduling module.

[0190] 1. Optimized scheduling of heterogeneous tasks: Computation-intensive tasks are assigned to the process pool to break the global interpreter lock restriction, and input / output-intensive tasks use asynchronous coroutines to achieve high-efficiency concurrency.

[0191] 2. Improved resource utilization: Select the optimal scheduling strategy based on task characteristics to make full use of computing resources and input / output bandwidth.

[0192] 3. Fine-grained progress feedback: The work process can periodically report the execution progress, realizing real-time progress monitoring of long-term tasks.

[0193] II. Overall technical effect of the system.

[0194] This invention solves four key problems of existing workflow orchestration systems through the collaborative work of five functional modules: To address the limitations of process control models, the token flow management and logic backtracking module provides native loop support and dynamic process adjustment capabilities.

[0195] To address the lack of observability: the white-box state management and intervention module enables fully transparent monitoring of the execution process and runtime intervention capabilities.

[0196] To address the issue of inflexible fault tolerance mechanisms, the barrier fault tolerance aggregation module provides a variety of fault tolerance strategies and intelligent data aggregation functions.

[0197] To address the issue of data transfer efficiency: the data reference and management module with storage and computing separation implements an efficient data storage and cross-process sharing mechanism.

[0198] The modules form a complete execution loop through clear data transmission relationships: the token flow management module, as the core scheduling engine, coordinates the collaborative work of the other four modules; the white-box state management module provides observability and intervention capabilities; the data persistence module provides data storage and retrieval services; the barrier fault-tolerant aggregation module handles multi-branch convergence scenarios; and the hybrid concurrent scheduling module achieves efficient task execution.

[0199] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0200] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. In summary, the content of this specification should not be construed as a limitation of this application.

Claims

1. A white-box asynchronous workflow orchestration system supporting intermediate state observability and intervention, characterized in that, include: Data persistence layer, observation and interaction layer, core execution layer, and module management layer; The data persistence layer is configured to: receive and store the data object provided by the core execution layer and return the corresponding data reference identifier to the core execution layer; Receive the data reference identifier provided by the core execution layer and return the corresponding data object to the core execution layer; The core execution layer is configured to manage and implement data flow between nodes through a token pool mechanism, wherein each token in the token pool mechanism carries the data reference identifier, the source node identifier, and the error identifier. A node that is in a pending execution state and has an input token in the token queue is determined to be a ready node. The data reference identifier is extracted from the input token of the ready node and provided to the data persistence layer. The corresponding data object is received and provided to the ready node so that it can be executed. The data object generated by the successfully executed node n is provided to the data persistence layer and receives the corresponding data reference identifier to generate the output token of the node n. The output token of the node n also carries the identifier of the node n and an error identifier that is "false". Generate an output token for node i that failed to execute, carrying the identifier of node i and an error identifier of "true"; Use the output tokens of node n and / or node i as the input tokens of their successor nodes; Once the execution is complete, the node enters the terminated state. Provide the status of each node to the observation interaction layer; receive control commands sent by the observation interaction layer and control the data flow between nodes according to the control commands; The observation interaction layer is configured to receive and display the status of each node provided by the core execution layer; Receive user interference requests and convert them into control commands, which are then sent to the core execution layer. The module management layer is configured to manage the modules in the data persistence layer, the core execution layer, and the observation interaction layer.

2. The white-box asynchronous workflow orchestration system supporting intermediate state observability and intervention according to claim 1, characterized in that, The core execution layer includes a token flow management and logic backtracking module, a hybrid concurrency scheduling module, and a barrier fault tolerance aggregation module; The token flow management and logic backtracking module is configured to: pass the set of ready nodes and the corresponding task configuration to the hybrid concurrency scheduling module and obtain the execution results of each ready node fed back by the hybrid concurrency scheduling module, the execution results including data objects generated when execution fails or succeeds; The hybrid concurrent scheduling module is configured to: allocate the ready nodes to the process pool or coroutine pool for execution according to the task configuration, and feed back the execution results of each ready node to the token stream management and logic backtracking module; The barrier fault-tolerant aggregation module is configured to aggregate the input tokens of the aggregation node to generate the output token of the aggregation node as the input token of its successor node.

3. The white-box asynchronous workflow orchestration system supporting intermediate state observability and intervention according to claim 2, characterized in that, The execution flow of the token flow management and logic backtracking module includes a first initialization phase, an execution phase, and a logic backtracking judgment phase; the observation and interaction layer includes a white-box state management and intervention module; and the data persistence layer includes a storage-compute separated data reference and management module.

4. The white-box asynchronous process orchestration system supporting intermediate state observability and intervention according to claim 3, wherein the process of the first initialization phase includes: Obtain process definition data, which includes a node configuration list and a list of connections between nodes; The process starting node is identified based on the list of connections between nodes, and edge adjacency tables, inbound edge adjacency tables, outbound edge adjacency tables, and circular edge index tables are constructed. Generate an initial token for each of the process initiation nodes; Create a data structure for the token queue and assign an independent token queue to each node; Create a node state mapping table and set the initial state of all nodes to the pending execution state; The initial token is stored in the token queue of the corresponding starting node.

5. The white-box asynchronous process orchestration system supporting intermediate state observability and intervention as described in claim 4, wherein the process of the execution phase includes a token extraction and readiness determination step, a business logic execution step, an output token generation step, and a token distribution step; The token extraction and readiness determination steps include: determining the nodes in the pending execution state according to the node state mapping table, determining whether the predecessor nodes of the nodes in the pending execution state have all entered the termination state according to the edge adjacency table, determining whether there is an input token in the token queue of the nodes in the pending execution state, and if both are satisfied, then the nodes in the pending execution state are included in the ready node set. The business logic execution steps include: for each ready node in the ready node set, extracting a data reference identifier from its input token, calling the data retrieval interface of the data persistence layer to obtain the corresponding data object, determining the parameter configuration and task configuration of the ready node in conjunction with the node configuration list, submitting the ready node set to the hybrid concurrency scheduling module for execution, the hybrid concurrency scheduling module allocating computationally intensive task nodes to the process pool and input / output intensive task nodes to the coroutine pool, after the node execution is completed, collecting the execution result list, providing the data object generated by the successfully executed node n to the data persistence layer and receiving the corresponding data reference identifier, and recording detailed error information of the unexecuted node i; The output token generation step includes: based on the execution result list, generating an output token for successfully executed node n, carrying the identifier of node n, the corresponding data reference identifier, and an error identifier of "false"; generating an output token for unsuccessfully executed node i, carrying the identifier of node i, detailed error information, and an error identifier of "true"; simultaneously updating the node state mapping table, updating the state of successfully executed node n to a successful termination state, updating the state of unsuccessfully executed node i to a failed termination state, and publishing a state change event to the observation interaction layer; The token distribution step includes: traversing the output token list, obtaining all successor nodes of the source node of each output token according to the outgoing edge adjacency list, generating a copy of the output token and adding it to the token queue of each successor node.

6. The white-box asynchronous workflow orchestration system supporting intermediate state observability and intervention according to claim 5, characterized in that, The logical backtracking judgment stage includes: Based on the circular edge index table, determine whether there is a circular back edge with the currently executed node as the source node. If so, define the currently executed node as a circular node; otherwise, define the currently executed node as a non-circular node. Pass the output token of the non-cyclic node to its successor node; Evaluate whether the loop node satisfies the loop condition and has not reached the loop limit; if it does not satisfy the condition, the evaluation result is negative; if it satisfies the condition, extract the data reference identifier from the output token of the loop node, call the data persistence layer to obtain the data object corresponding to the data reference identifier, use the data object as a condition variable to calculate the Boolean result of the loop condition expression, and if the expression result is true, the evaluation result is positive, and if the result is false, the evaluation result is negative. When the evaluation result is yes, the subsequent process of the loop node enters the logical backtracking path, and executes the trigger control flow reset mechanism and reset the state of the starting node in sequence. If the evaluation result is negative, the loop process is terminated, and the output token of the loop node is passed to its successor node.

7. The white-box asynchronous workflow orchestration system supporting intermediate state observability and intervention according to claim 5, characterized in that, The execution flow of the white-box state management and intervention module includes a second initialization phase and a parallel processing node phase; The second initialization phase includes: Receive the node configuration list in the process definition data; Create a global state mapping table data structure, wherein the global state mapping table data structure uses node identifiers as keys and complete state records as values. The complete state record includes basic state, start timestamp, end timestamp, execution time, input data reference, output data reference, error information, and extended state. Iterate through the node configuration list, create an initial state record for each node, set the basic state field to the pending state, and set other fields to empty or default values; Register itself as a state change observer of the token flow management and logic backtracking modules to receive state change events of nodes. At the same time, initialize the inter-process communication listening channel to receive state reporting messages from worker processes, and initialize the user intervention request listening interface to receive user interference requests. Output the global state mapping table, the observer registration completion flag, and the communication channel ready flag; The parallel processing node stage includes three concurrently running processing branches A, B, and C. Processing branch A is responsible for normal execution monitoring, processing branch B is responsible for cross-process synchronization, and processing branch C is responsible for user intervention. The three processing branches A, B, and C independently process their respective input events. After processing, they are all converged into the push observer notification step to push the state change information to all registered observers. The processing branch A includes three sequentially executed steps: listening to node state transitions, updating the state mapping table, and pushing observer notifications. It is responsible for handling node state change events pushed by the token flow management and logic backtracking modules. The processing branch B includes three sequentially executed steps: receiving reports from worker processes, parsing internal states, and updating extended state fields. These steps ultimately converge on the push observer notification step, which is responsible for processing fine-grained state update messages sent by worker processes through the inter-process communication channel. The processing branch C includes: receiving the user's interference request, and then dividing it into four parallel processing branches based on the user's interference request: pause / resume, modify parameters, inject data, and skip nodes. Each branch executes its corresponding logic and updates its status before converging into the push observer notification step, which is responsible for handling various intervention operations initiated by the user during the process. The observer notification step includes: receiving status update messages from three processing branches A, B, and C, where the message types include node status change notification, progress update notification, and intervention result notification; and pushing the status update messages to the status change observer.

8. The white-box asynchronous workflow orchestration system supporting intermediate state observability and intervention according to claim 5, characterized in that, The storage-compute separation data reference and management module includes three independent sub-processes: the first sub-process, the second sub-process, and the third sub-process. The first sub-process is responsible for the data storage stage, the second sub-process is responsible for the data retrieval stage, and the third sub-process is responsible for the data cleaning stage. The three sub-processes work together to achieve full lifecycle management of data. The data storage stage receives object data output from the receiving node as input, and after three processing stages—serialization, parallel writing, and aggregation—it finally outputs the corresponding data reference identifier. The parallel writing stage is divided into two parallel branches: one branch is responsible for writing file system load data, and the other branch sequentially performs metadata extraction and database metadata writing. After the two branches are completed, they are merged at the aggregation node. The data retrieval stage receives a data reference identifier as input, and performs three sequential steps: querying the database to obtain metadata / path, extracting the file system, and deserialization, and finally outputs the corresponding object data. The data cleanup phase is initiated by triggering an expired / end cleanup event. It involves three sequential steps: scanning expired metadata, deleting file system files, and deleting database records, to complete the automatic cleanup of expired data.

9. The white-box asynchronous workflow orchestration system supporting intermediate state observability and intervention according to claim 5, characterized in that, The execution flow of the barrier fault-tolerant aggregation module is divided into a waiting phase, an aggregation phase, and an execution phase. The waiting phase includes checking the status of the preceding nodes: depending on whether all preceding nodes have entered the termination state, there are two paths; if not all have terminated, the process enters the continuous waiting step and then returns to continue checking; if all have entered the termination state, the process enters the step of collecting preceding tokens, and after completion, the process enters the aggregation phase. The aggregation phase includes: first, executing the step of reading the aggregation strategy configuration, and then entering the evaluation of the fault tolerance condition decision point. The evaluation of the fault tolerance condition decision point is divided into three parallel paths according to the configured strategy type: strict mode, best effort mode, and threshold mode. Each path enters the execution phase to perform specific condition judgment and processing. The execution phase includes condition judgment and data processing; the condition judgment includes: strict mode path judgment to determine whether there is an erroneous token; best effort mode path judgment to determine whether the number of successful tokens is greater than zero; threshold mode path first calculates the success rate, and then judges whether the success rate is greater than or equal to the threshold; the data processing includes: the "yes" branches of each condition judgment converge to the data merging step, and the "no" branches converge to the failure setting step.

10. The white-box asynchronous workflow orchestration system supporting intermediate state observability and intervention according to claim 5, characterized in that, The hybrid concurrent scheduling module is responsible for using differentiated scheduling strategies based on task characteristics to achieve efficient concurrent execution. Its execution process is divided into three main parts: task classification stage, task submission and execution stage, and state synchronization stage. By querying the module's metadata, it identifies the task type, assigns computationally intensive tasks to the process pool for execution, and assigns input / output intensive tasks to the event loop for execution. At the same time, it ensures the observability of cross-process tasks through the state synchronization mechanism. The task classification stage includes: receiving ready nodes as input, and after querying the module's metadata, entering the task type identification decision point. This decision point is divided into two paths based on the task type: computationally intensive and input / output intensive, which respectively enter the first branch and the second branch of the task submission and execution stage. The task submission and execution phase includes a first branch and a second branch that are executed in parallel. The first branch handles computationally intensive tasks and executes three steps in sequence: encapsulating the task into a process pool, submitting it to the process pool, and executing it in parallel with multiple processes. The second branch handles input / output intensive tasks and executes three steps in sequence: encapsulating the task into an asynchronous coroutine, submitting it to the event loop, and executing it concurrently with a single thread. After the first and second branches are completed, they converge into an asynchronous waiting step for all tasks to complete, followed by the sequential execution of steps to collect execution results and generate output tokens. The asynchronous waiting for all tasks to complete steps include: simultaneously waiting for the completion of all tasks in the process pool and all coroutines in the event loop through an asynchronous waiting mechanism. During the waiting process, the main process is not blocked and can process messages in the state synchronization phase. After all tasks have been completed and executed, subsequent processing continues. The step of collecting execution results includes: collecting the execution results returned by the process pool task and the execution results returned by the coroutine task, and merging the two sets of results into a unified execution result list; The step of generating output tokens includes: traversing the execution result list, creating a normal token for each successful execution result, setting the data reference to the output data reference identifier, and setting the error flag to false; creating an error token for each failed execution result, setting the error flag to true, and filling the error information field with detailed error content; The state synchronization phase runs in parallel with the task submission and execution phase and includes two steps: the worker process sending a state byte stream and the main process updating the global state table. Cross-process state synchronization is achieved through a periodic reporting mechanism and a monitoring update mechanism. The periodic reporting and status byte stream transmission by the worker processes include: during the parallel execution of multi-process steps, the worker processes send execution progress information to the main process through a periodic reporting mechanism; the worker processes trigger status reporting at key checkpoints in the business logic execution process, including the completion of each iteration of the iterative loop, the completion of a stage processing, and the completion of key indicator calculation; the worker processes construct status update messages containing node identifiers, progress types, progress values ​​or status descriptions, timestamps, etc., and send the status update messages to the main process through inter-process communication channels; The monitoring update and the main process update of the global state table include: the main process continuously receives state update messages sent by worker processes through the monitoring update mechanism; the main process asynchronously monitors the inter-process communication channel, and after receiving a message, it parses the message content to extract the node identifier and progress information, and calls the state update interface of the white-box state management module to update the progress information to the extended state field of the global state mapping table.

Images