Activity process engine-based training planning process control method and system

Abstract

The invention relates to the technical field of process engine control, and discloses a training planning process control method and system based on an Activity process engine. The method comprises the following steps: extracting an instance state snapshot from a process engine, analyzing to construct a time trajectory map of process evolution, marking a key path and a branch point, and generating a process evolution mode template library; and the current evolution stage is accurately determined by matching the real-time process with the template. And then dynamically loading a corresponding control strategy, analyzing the rule to generate a node-level operation instruction, and converting the node-level operation instruction into a model adjustment command which can be identified by an engine. Synchronously monitoring the synchronization state of the resource consumption and the flow track, and automatically calculating a resource quota adjustment scheme when deviation occurs. And finally, cooperatively scheduling a model adjustment command and a resource scheme, forming a control instruction set, and distributing the control instruction set to an engine and a resource manager to realize efficient and adaptive evolution of a flow according to an expected path. According to the invention, the intelligent level of process management and the resource utilization efficiency are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of process engine control, in particular to a training planning process control method and system based on an Activity process engine. BACKGROUND

[0002] Traditional process engines such as Activity mainly run based on a predefined static process model. The execution path of a process instance is initially determined by the model structure, and the engine is responsible for driving the process nodes to flow in the intended order. Existing monitoring techniques focus on the snapshot of the current state of the process instance or the recording of the history log, and lack deep mining and patternized understanding of the internal law of the dynamic evolution of the process. The resource allocation scheme is usually statically configured according to the initial definition of the process model or the experience of the operation and maintenance personnel, and has weak relevance to the actual dynamic needs of the process instance at runtime.

[0003] The prior art has defects. The process engine cannot actively identify the macro evolution stage of the process instance, and it is difficult to predict its possible future, resulting in a lagging control strategy and lack of foresight. The analysis of the process stays at the level of node state enumeration or simple time consumption statistics, and cannot extract evolution patterns with universal guiding significance from historical data. Resource management and process execution are considered as two relatively independent subsystems, and resource adjustment is usually triggered passively after the process appears to be delayed or resource competition alarms, which is an inefficient after-the-fact remedial mechanism and is difficult to ensure sufficient supply of resources on the critical path.

[0004] The present application needs to solve the adaptability problem of the control strategy in the dynamic evolution process of the process. How is the real-time state of the process instance accurately mapped to an understandable evolution stage, and how is the corresponding control rule loaded accordingly. How is the dynamic coupling relationship between process execution and resource consumption perceived and optimized in real time, and how is the joint adjustment implemented quickly and automatically to ensure that the process is efficiently promoted as expected when the trajectories of the two deviate. SUMMARY

[0005] The present application aims to provide a training planning process control method and system based on an Activity process engine to solve the problems raised in the background.

[0006] To achieve the above-mentioned purpose, the present application provides a training planning process control method based on an Activity process engine, which comprises:

[0007] extracting a state snapshot of a process instance from an Activity process engine, performing multi-level analysis on the state snapshot, and identifying an activation state sequence of the process nodes;

[0008] Based on the activation state sequence of process nodes, a time trajectory map of process evolution is constructed, and key path nodes and branch merging points are marked in the time trajectory map;

[0009] Based on the structural characteristics of the time trajectory map, a process evolution pattern template library is generated. Real-time process instances are matched with process evolution pattern templates to determine the current evolution stage of the process.

[0010] For the current process evolution stage, dynamically load the corresponding set of process control strategies, and select control rules that are suitable for the current process context from the set of process control strategies;

[0011] The process rule executor parses the control rules, generates a sequence of operation instructions at the node level, and converts the sequence of operation instructions into process model adjustment commands that the Activity process engine can recognize.

[0012] Simultaneously, monitor the synchronization status between the resource consumption trajectory and the process evolution trajectory. When a deviation occurs, initiate the resource reallocation procedure and calculate the resource quota adjustment plan.

[0013] The process model adjustment commands and resource quota adjustment schemes are coordinated and scheduled, and the execution order is determined according to the dependencies to form the final control instruction set.

[0014] The control instruction set is sent to the Activity flow engine and resource manager through the instruction distribution channel, driving the flow instance to evolve according to the expected path.

[0015] Preferably, the state snapshot is analyzed at multiple levels to identify the activation state sequence of process nodes. Specifically, this includes: obtaining runtime data of the process instance provided by the Activity process engine, extracting node state information, transition conditions, and variable values; sorting the node state information according to the time dimension to form a node state change sequence; analyzing the fulfillment of activation conditions for each node, and marking the ready state, execution state, and completion state of the node; constructing a node activation state sequence reflecting the process evolution path based on the node state change sequence and node activation state; filtering redundant information from the node activation state sequence, removing duplicate state records, and retaining key time points where the state changes; comparing the processed node activation state sequence with the process model definition to verify the compliance of the sequence, and outputting a standardized process node activation state sequence.

[0016] Preferably, a time trajectory graph of process evolution is constructed based on the activation state sequence of process nodes. Specifically, this includes: establishing a graph structure model of process evolution with process nodes as vertices and state transitions between nodes as edges; adding time dimension information to the graph structure model to record the activation time and duration of each node; determining the successor-successor relationship between nodes based on the node activation state sequence and drawing a directed graph of process evolution; marking the starting and merging points of parallel branches in the time trajectory graph to identify concurrent execution paths in the process; calculating the temporal relationship of nodes on the critical path to determine the minimum completion time window of the process; and mapping resource allocation information to the corresponding nodes in the time trajectory graph to form an enhanced time trajectory graph containing resource constraints.

[0017] Preferably, a process evolution pattern template library is generated, and real-time process instances are matched with process evolution pattern templates. Specifically, this includes: extracting typical process evolution patterns from historical process instances, including sequential execution, parallel branching, and loop iteration patterns; establishing feature vectors for each process evolution pattern, including feature indicators such as the number of nodes, branch depth, and number of loops; performing cluster analysis on the process evolution patterns using a pattern classification algorithm to form a standardized process evolution pattern template library; extracting the structural and temporal features of real-time process instances and calculating the similarity with each template in the process evolution pattern template library; selecting the process evolution pattern template with the highest similarity as the matching template for the current process to determine the pattern category to which the process instance belongs; and identifying the differences between the current process instance and the standard template based on the matching results to provide an adjustment basis for subsequent process control.

[0018] Preferably, the corresponding set of process control strategies is dynamically loaded, and control rules suitable for the current process context are selected from the set of process control strategies. Specifically, this includes: retrieving the set of process control strategies associated with the current process stage from the strategy library based on the process evolution stage identification results; evaluating the runtime characteristics of the current process instance, including resource availability, time constraints, and priority parameters; filtering the set of process control strategies based on the evaluation results, eliminating control strategies that do not meet the constraints; calculating the weights of the remaining control strategies, considering the historical execution effects and the adaptability to the current environment; selecting the control strategy with the highest weight as a candidate strategy for feasibility verification; verifying the impact of the candidate strategy on the process instance through simulated execution, and finally determining the set of control rules suitable for the current process context.

[0019] Preferably, the process rule executor parses the control rules to generate a node-level operation instruction sequence. Specifically, this includes: decomposing the control rules into condition judgment parts and execution action parts, and establishing a rule parsing tree; evaluating the satisfaction of the condition judgment parts based on the runtime data of the current process instance; for rules that satisfy the conditions, extracting their execution action parts and converting them into specific process operation commands; sorting the process operation commands according to rule priority and dependencies to resolve possible conflicts; organizing the sorted process operation commands into a node-level operation instruction sequence to ensure logical consistency between instructions; and adding execution context information to the operation instruction sequence, including target node identifiers and parameter values, to form a complete operation instruction package.

[0020] Preferably, the synchronization status of resource consumption trajectory and process evolution trajectory is monitored. When a deviation occurs, a resource reallocation procedure is initiated. Specifically, this includes: real-time collection of resource usage data during the execution of process instances to construct a resource consumption trajectory curve; time-aligned comparison of the resource consumption trajectory curve and the process evolution trajectory to calculate the deviation between the two; when the deviation exceeds a threshold, a resource reallocation evaluation process is triggered to analyze the root cause of resource allocation imbalance; identifying process nodes with intense resource competition and process nodes with idle resources to find unreasonable points in resource allocation; recalculating the resource quota requirements of each node based on process priority and resource constraints; and formulating a resource quota adjustment plan, including resource transfer paths and adjustment time points, to ensure that the adjustment process minimizes interference with the process.

[0021] Preferably, the process model adjustment commands and resource quota adjustment schemes are coordinated and scheduled, and the execution order is determined according to the dependencies to form the final control instruction set. Specifically, this includes: analyzing the dependencies and execution timing constraints between the process model adjustment commands and resource quota adjustment schemes; establishing a sequence diagram of adjustment operations to ensure the coordination and consistency of process structure adjustment and resource adjustment; resolving conflicts between adjustment commands and determining the final execution order through a priority scheduling algorithm; grouping adjustment operations into atomic execution units to ensure the integrity and rollback of each unit; adding transaction management information to the control instruction set to ensure the atomicity and consistency of instruction execution; and generating the final control instruction set, including execution timing descriptions and exception handling mechanisms, ready for issuance and execution.

[0022] Preferably, the control instruction set is sent to the Activity flow engine and resource manager through the instruction distribution channel. Specifically, this includes: establishing a bidirectional communication connection with the Activity flow engine and verifying the security and reliability of the connection; encapsulating the flow model adjustment commands into a message format recognizable by the engine according to the execution order; establishing a control channel with the resource manager to transmit resource quota adjustment instructions and parameter settings; using a transactional message queue to ensure reliable transmission of control instructions and ensure that instructions are not lost or duplicated; monitoring the instruction execution status and collecting feedback information from the engine and resource manager; judging the instruction execution result based on the feedback information and initiating a retry or compensation mechanism for instructions that fail to execute.

[0023] Preferably, the present invention also includes a training planning process control system based on an Activity process engine. The system includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the steps of the training planning process control method based on the Activity process engine described above.

[0024] Compared with the prior art, the beneficial effects of the present invention are:

[0025] By extracting state snapshots from the process engine and performing multi-level analysis, a time trajectory graph reflecting the activation sequence of process nodes and their temporal relationship is constructed. Based on the graph's structural features, a process evolution pattern template library is generated. Real-time process instances can be matched with the template library to accurately identify the specific evolution stage of the current process. This method enables the system to transcend the perception of the current instantaneous state and grasp the overall process flow from a macroscopic perspective. This provides a prerequisite for the precise triggering of dynamic control strategies, realizing a shift from passive response to proactive prediction.

[0026] By synchronously monitoring the status of resource consumption and process evolution trajectories, a resource reallocation procedure is automatically initiated when deviations occur, and a specific resource quota adjustment plan is calculated. The node-level operation instruction sequence generated by the process rule executor is coordinated and scheduled with this resource adjustment plan, forming a unified control instruction set based on dependencies. This mechanism breaks down the barriers between process execution and resource management, achieving deep integration between the two. Process advancement is not only driven by business logic but also by real-time feedback and optimization of resource availability, avoiding resource bottlenecks from constraining overall progress and improving the overall efficiency of system resource utilization and the robustness of process execution. Attached Figure Description

[0027] Figure 1 This is a schematic diagram illustrating the working principle of the training planning process control method based on the Activity process engine described in this invention.

[0028] Figure 2 A flowchart for multi-level parsing of state snapshots and identification of node activation state sequences;

[0029] Figure 3 A flowchart for constructing a timeline of process evolution;

[0030] Figure 4 A trend chart showing the changes in resource consumption and process schedule deviation;

[0031] Figure 5 A comparison chart of processing delays for instructions of different priorities. Detailed Implementation

[0032] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] Please see Figure 1 This invention provides a training and planning process control method based on an Activity process engine. The method includes: extracting state snapshots of process instances from the Activity process engine; performing multi-level analysis on the state snapshots to identify the activation state sequences of process nodes; constructing a time trajectory graph of process evolution based on the activation state sequences of process nodes, and marking key path nodes and branch merging points in the time trajectory graph; generating a process evolution pattern template library based on the structural characteristics of the time trajectory graph, matching real-time process instances with the process evolution pattern templates to determine the current evolution stage of the process; and dynamically loading a corresponding set of process control strategies for the current process evolution stage. The system filters control rules applicable to the current process context from a set of rules; it parses the control rules through the process rule executor to generate a sequence of operation instructions at the node level, and converts the sequence of operation instructions into process model adjustment commands that the Activity process engine can recognize; simultaneously, it monitors the synchronization status between the resource consumption trajectory and the process evolution trajectory, and starts a resource reallocation program when a deviation occurs to calculate a resource quota adjustment scheme; it coordinates the process model adjustment commands and the resource quota adjustment scheme, determines the execution order according to the dependency relationship, and forms the final control instruction set; and it sends the control instruction set to the Activity process engine and resource manager through the instruction distribution channel to drive the process instance to evolve according to the expected path.

[0034] Example 1: See Figure 2The Activity flow engine continuously records various data generated by the process instance during execution through internal event listeners and a state manager. This data is stored in a structured form in the engine's runtime database. The retrieval process is implemented by calling the Java API interface provided by the Activity flow engine. Interface methods include the `getProcessInstance` method for querying process instance details, the `getActiveActivityInstances` method for retrieving activity instances, and the `getVariable` method for reading process variables. From this runtime data, node state information, transition conditions, and variable values ​​are extracted. Node state information includes the node's lifecycle state (e.g., not started, active, completed, terminated), start time, end time, and duration. Transition condition information includes expressions or scripts defined on the sequential flow between connecting nodes. Variable values ​​include the name, type, and current value of all defined variables within the scope of the process instance. The extraction operation is completed by parsing the data transfer object returned by the Activity flow engine, which contains a complete snapshot of the process instance.

[0035] In implementation, node state information is sorted according to the time dimension to form a node state change sequence. The sorting operation is based on the timestamp of each state change event obtained from the Activity flow engine, with timestamps accurate to the millisecond level. The sorting algorithm uses a stable merge sort algorithm to ensure that events with the same timestamp maintain their original logical order. The resulting node state change sequence is an ordered list, where each element represents a node's state record at a specific point in time. Each element contains a node identifier, state type, timestamp, and optional payload data. For branch nodes that execute in parallel, the sorting algorithm needs to handle the concurrency of timestamps by introducing a logical clock sequence number to distinguish truly concurrent events. The construction process of the node state change sequence also needs to consider transaction boundaries to ensure that multiple state change events belonging to the same transaction remain atomic in the sequence.

[0036] In practice, the activation conditions of each node are analyzed, and the node's ready, execution, and completion states are marked. The analysis process is based on transition condition expressions and variable values ​​extracted from the Activity flow engine, and the Boolean values ​​of the conditions are calculated using an embedded expression evaluation engine (such as the JUEL expression language engine). A node's ready state indicates that all preconditions for the node have been met, and it can begin execution immediately; the criterion is that all input transition conditions entering the node are true. A node's execution state indicates that the node has been instantiated by the flow engine and is in an active state; the criterion is the Activity flow engine's runtime state model. A node's completion state indicates that the node has completed execution and produced output results; the criterion is that the node has generated an output event and its state is marked as complete. Marking is achieved by adding state flags to the node's state record. The flags are encoded using a bitmask and support combinations of various state markings. For routing nodes such as gateway nodes, the analysis of activation conditions also needs to consider the gateway type and routing rules; for example, exclusive gateways need to evaluate the priority of all outgoing conditions.

[0037] In practical implementation, a node activation state sequence reflecting the process evolution path is constructed based on the node state change sequence and node activation state. The construction process employs a state machine model, where states correspond to different activation stages of process nodes, and transitions correspond to node state change events. The node activation state sequence is a time-ordered sequence of node activation records, with each record containing a node identifier, activation type (activation start, activation end), timestamp, and context data. The sequence construction algorithm traverses the sorted node state change sequence, identifies the activation start and activation end events of each node, and interweaves these events into a unified sequence in chronological order. For complex process patterns such as parallel branches, the sequence needs to maintain the partial order relationship of multiple concurrent activation events, using vector clock technology to maintain the causal relationship between events. The node activation state sequence also records the transition relationships between nodes, which are derived by analyzing the correlation between consecutively activated nodes.

[0038] In practice, redundant information filtering is performed on the node activation state sequence to remove duplicate state records and retain key time points where the state changes. Redundant information includes duplicate state records caused by excessively high system sampling frequency, duplicate events caused by network jitter, and temporary state changes caused by transaction rollback. The filtering algorithm uses a sliding window comparison method, with the window size dynamically adjusted according to the complexity of the process instance. The algorithm compares state records within adjacent time windows; if the state identifier and state value are exactly the same, they are determined to be redundant records and merged. Key time points are identified based on state value change detection; when a change in the state value of a node is detected, that time point is marked as a key time point. The filtered node activation state sequence only contains records where the state has undergone substantial changes, significantly reducing the sequence length while preserving the complete semantics of the process evolution.

[0039] In practice, the processed node activation state sequence is compared with the process model definition to verify its compliance. The process model definition is a BPMN 2.0 process definition file extracted from the Activity process engine's deployment package. This file uses XML format to describe the process's structure and behavior. The comparison operation matches the actual node activation sequence with the allowed node execution paths in the model definition, checking whether the sequence conforms to the constraints of the model definition. Compliance checks include node execution order checks to verify whether the actual node activation order violates the sequential flow direction defined in the model; node type consistency checks to ensure that the type of each activated node matches the node type in the model definition; and gateway decision compliance checks to verify whether the branch selection of gateway nodes conforms to the gateway's routing rules. Violations discovered during the verification process are recorded in a compliance report, indicating the specific location and type of the violation. A standardized process node activation state sequence is output. Standardization operations include a unified timestamp format, standardized node identifiers, and encoded state enumeration values. The standardized sequence uses a fixed JSON schema for easy parsing and use by subsequent processing components.

[0040] In some embodiments, extracting node state information requires processing raw data returned by the Activity flow engine, which contains various types of nodes. User task nodes need to focus on the task instance's creation time, acceptance time, completion time, and task executor information; service task nodes need to monitor the service call's start time, execution duration, and return result status; gateway nodes need to record the gateway's activation time, decision calculation time, and branch selection results. For each node type, the state information extraction strategy differs. User task nodes obtain detailed information by querying the Activity flow engine's historical task table; service task nodes reconstruct the execution process by analyzing the execution instance table and variable table; gateway nodes require comprehensive analysis combining execution flow transfer records and gateway decision logs. The extraction process employs a template method design pattern, defining a dedicated state extractor for each node type. The extractor implements a unified interface but contains type extraction logic.

[0041] In some embodiments, the extraction of transition conditions involves the evaluation of process variables and expressions. Process variables include all data objects created and modified during process execution, with variable types including basic types (such as strings, numbers, and booleans) and complex object types (such as Java objects, collections, and mappings). Expression evaluation needs to support the expression language (such as JUEL or SpringEL) used by the Activity process engine, and expressions may contain variable references, arithmetic operations, method calls, and logical comparisons. The extraction process first retrieves all available process variables from the variable table of the Activity process engine, constructing a mapping table from variable names to variable values. Then, it parses the variable names referenced in the transition conditions and looks up the corresponding variable values ​​from the mapping table. Finally, it uses the expression evaluation engine to calculate the boolean value of the condition, handling possible type conversions and null value cases. For complex conditional expressions, the extraction process employs abstract syntax tree analysis technology to decompose the expression into basic computational units for step-by-step evaluation.

[0042] It's understandable that time synchronization needs to be considered when sorting node state information by time. Since process instances may execute across multiple server nodes, there might be slight time discrepancies between different servers. The sorting algorithm uses a network time protocol to synchronize the time sources of each server, ensuring global consistency of timestamps. For events that occur concurrently, the sorting algorithm uses lexicographical order based on node identifiers as a secondary sorting key to ensure the determinism of the sorting result. The construction of the node state change sequence also needs to consider the issues of event loss and duplication. Lost events are detected through a sequence number mechanism, and duplicate events are eliminated through a deduplication mechanism.

[0043] Understandably, analyzing node activation conditions requires considering multiple factors. Data dependency factors check whether all input data required for node execution is ready; this input data may come from process variables, external system interfaces, or user input. Resource availability factors verify whether the various resources required for node execution meet allocation conditions; resource status is obtained by querying the resource management system. External event triggering factors monitor external signals that may affect node activation, such as message events, signal events, and error events. The analysis process establishes a multi-dimensional condition evaluation matrix, where rows represent different condition categories and columns represent specific condition items. Each condition item is assigned a weight coefficient, and the node activation condition is determined to be met when the overall score exceeds a threshold. The condition evaluation matrix is ​​dynamically generated based on the process definition and runtime context, ensuring the accuracy and completeness of the evaluation.

[0044] Example 2: See Figure 3 In practical implementation, constructing the time trajectory graph of process evolution begins with establishing a graph structure model of process evolution, using process nodes as vertices and state transitions between nodes as edges. The graph structure model is represented using a directed graph mathematical structure. The vertex set V contains unique identifiers for all nodes in the process, and the edge set E is defined by the sequential flow connections between nodes. Each vertex has an attached set of attributes, including node type, node name, and business function description. Each edge has an attached set of attributes, including transition condition expressions, transition probability weights, and historical execution counts. The graph structure model is constructed by parsing the BPMN2.0 process definition file, using a DOM parser to extract process elements and their relationships, and then using graph theory algorithms to build the graph data structure in memory. For complex processes containing sub-processes, the graph structure model adopts a hierarchical design, with the main process graph as the top-level graph, and each sub-process expanding into an independent subgraph, connected to the main graph through boundary event nodes.

[0045] In practical implementation, adding time dimension information to the graph structure model requires recording the activation time and duration of each node. This time dimension information is stored in the vertex attribute extension set as timestamps and interval values. Each vertex's time attributes include earliest activation time, latest activation time, average duration, and time deviation coefficient. Time information is collected through the historical data interface of the Activity flow engine. This interface provides a flow instance execution event log, containing the start and end timestamps of each node instance. Duration is calculated by subtracting the start timestamp from the end timestamp, with the result stored in milliseconds. For node instances that are not yet completed, the duration field is marked with a special value indicating that they are still executing. The addition of time dimension information transforms the static graph structure model into a dynamic time trajectory graph, reflecting the evolution path of flow instances over time. The time trajectory graph supports time interval queries, allowing for quick retrieval of the set of nodes active within a specific time period.

[0046] In practical implementation, the successor-successor relationships between nodes are determined based on the node activation state sequence, and a directed graph of the process evolution is drawn. Successor-successor relationships are determined by analyzing consecutively activated node pairs in the node activation state sequence. If the activation start time of node B is later than the activation completion time of node A, and no other node is activated between them, then node A is determined to be the predecessor node of node B. The directed graph of the process evolution is drawn using a graph drawing algorithm library. The algorithm automatically lays out the node positions based on node type and connection relationships. User task nodes are typically represented as rectangles, gateway nodes as rhombuses, and event nodes as circles. Edges use straight lines with arrows to indicate the direction of transition. The drawing of the directed graph considers aesthetic principles, such as minimizing edge intersections, uniform vertex distribution, and clear and readable labels. For large and complex processes, a hierarchical layout algorithm is used to divide the flowchart into multiple levels according to execution stages, improving readability.

[0047] In practical implementation, marking the starting and ending points of parallel branches in the timeline graph requires identifying concurrent execution paths within the process. The starting point of a parallel branch is typically a parallel gateway or an embedded sub-process containing parallel execution features. This is identified by analyzing the number of outgoing edges from the gateway node; if the number of outgoing edges is greater than one and does not contain a conditional expression, it is determined to be the starting point of a parallel branch. The ending point of a parallel branch is identified by analyzing the number of incoming edges from the gateway node; if the number of incoming edges is greater than one and all input branches need to be synchronized, it is determined to be the ending point of a parallel branch. The marking operations are visually highlighted on the timeline graph: a fork icon is added to the starting point of a parallel branch, and a convergence icon is added to the ending point. The identification of concurrent execution paths uses a depth-first search algorithm to traverse the timeline graph, finding all reachable paths from the starting point of a parallel branch to the ending point. Each concurrent path is assigned a unique identifier, and the node sequence and execution time statistics on the path are recorded.

[0048] In practical implementation, calculating the temporal relationships of nodes on the critical path requires determining the minimum completion time window of the process. The Critical Path Method (CPM) algorithm is used for critical path calculation. The algorithm first calculates the earliest start time (ES) and latest start time (LS) of each node, then calculates the time difference (LS-ES). Nodes with zero time difference constitute the critical path. Temporal relationship analysis establishes a network of temporal constraints between nodes, including four types of constraints: start-start, start-end, end-start, and end-end. The minimum completion time window is determined by finding the longest path from the start node to the end node; the path length is the sum of the durations of all nodes on the path. The calculation process uses dynamic programming, calculating the earliest time by traversing backward from the start node and calculating the latest time by traversing backward from the end node. The temporal relationships of nodes on the critical path can be expressed by the following formula:

[0049]

[0050] Where: PathDelay represents the total delay of the critical path, T exec (i) represents the execution time of the i-th node, T wait (i) represents the waiting time before the i-th node, and n represents the total number of nodes on the critical path. The minimum completion time window is the time interval obtained by adding the PathDelay value to the process start time.

[0051] In implementation, resource allocation information is mapped to corresponding nodes in the time trajectory graph to form an enhanced time trajectory graph containing resource constraints. The resource allocation information comes from the resource management system, including human resource allocation tables, equipment resource scheduling tables, and computing resource quota tables. The mapping process establishes the association between nodes and resources; each node is associated with a resource requirement descriptor, which lists all resource types and quantities required to execute that node. Resource constraints are added to the time trajectory graph as visual overlays, with different resource types encoded by different colors, and resource load levels represented by color intensity. The enhanced time trajectory graph supports resource conflict detection; when multiple nodes request the same scarce resource within the same time period, the system highlights the conflict area. The resource allocation information also includes resource availability time windows, which are matched with node execution time windows to determine the feasibility of the resource allocation scheme.

[0052] In some embodiments, the generation of the process evolution pattern template library extracts typical process evolution patterns from historical process instances. The extraction process employs process mining techniques, which discover frequently occurring execution patterns from the event logs of the Activity process engine. Sequential execution patterns are characterized by nodes being activated sequentially in a linear order, without branches or concurrency; parallel branching patterns are characterized by the process splitting into multiple simultaneously activated execution paths after the gateway node; and iterative looping patterns are characterized by a specific set of nodes being executed repeatedly. The pattern extraction algorithm employs either the alpha algorithm or a heuristic mining algorithm, analyzing direct follow-up relationships, causal relationships, and concurrency relationships in the event logs. Each extracted pattern is assigned a confidence score, representing the frequency of the pattern's occurrence in historical instances. The pattern template library uses version control, generating new versions of pattern templates when the process definition changes.

[0053] In some embodiments, matching of process evolution pattern templates is achieved by calculating the similarity between real-time process instances and a template library. The similarity calculation employs a multi-dimensional feature matching algorithm, which extracts feature vectors from real-time instances, including the number of nodes, branch depth, number of loops, average execution time, and gateway ratio. Each template in the template library also has a corresponding feature vector, and similarity is calculated using cosine similarity or Euclidean distance. A similarity threshold is set during the matching process; only templates with similarities exceeding the threshold are considered potential matches. For multiple candidate templates, a weighted scoring algorithm is used to select the best match, with weights dynamically adjusted based on feature importance. The matching results include a similarity score and a difference analysis report, which indicates the main differences between the instance and the template.

[0054] It's understandable that constructing a timeline graph requires consideration of scalability for large-scale processes. For complex processes with hundreds of nodes, a hierarchical, progressive construction method is adopted, first building a high-level stage flowchart, and then gradually expanding the detailed node graph of each stage. Graph visualization uses Level of Detail (LOD) technology, displaying information of different levels of detail based on the zoom level. The timeline graph is stored using a graph database, supporting efficient traversal and complex queries. Graph updates employ an incremental update mechanism, updating only the affected portion of the graph when the process instance state changes, improving performance. Matching process evolution pattern templates requires handling incomplete process instances. For process instances that have not yet completed execution, the matching algorithm uses a partial matching strategy, predicting the complete pattern based on the executed partial path. Prediction uses Markov models or Hidden Markov Models, where the model calculates the probability of various possible patterns based on the observed execution paths. Partial matching results are dynamically updated as the process instance progresses, and similarity is recalculated when a new node is activated. The matching algorithm also handles noisy data and abnormal paths, employing robust algorithms to eliminate the impact of outliers on the matching results.

[0055] Example 3: In specific implementation, based on the process evolution stage identification results, a set of process control strategies associated with that stage is retrieved from the strategy library. The strategy library is organized using a hierarchical index structure. The top-level index is classified by process type, the middle-level index is divided by evolution stage, and the bottom-level index stores specific strategy rules. The process evolution stage identification results include the process instance identifier, the set of currently active nodes, the completed path sequence, and the predicted remaining execution time. This information is encapsulated in the process context object. The retrieval operation is implemented through the strategy library query interface. The interface accepts the process context object as input parameters and returns a set of matching process control strategies. Each strategy entry in the strategy library includes a strategy identifier, an applicable stage description, triggering conditions, execution actions, and weight coefficients. Strategy entries are serialized and stored in XML format. The retrieval process uses a multi-level matching algorithm. First, the strategy range is filtered according to the process type, then precise matching is performed according to the evolution stage, and finally, a second filtering is performed based on resource constraints. The returned set of process control strategies is an ordered list, sorted by strategy priority, with higher priority strategies listed first.

[0056] In practice, assessing the runtime characteristics of the current process instance requires collecting multi-dimensional monitoring data. Runtime characteristics include resource availability, time constraints, and priority parameters. Resource availability is assessed by querying the resource management system's status interface, which returns metrics such as CPU utilization, memory usage, network bandwidth, and dedicated equipment availability. Time constraint assessment calculates the remaining time window between the current time and the process deadline, considering the ratio of used time to expected remaining time. Priority parameters are extracted from the process instance's metadata, which includes business importance level, customer priority, and service level agreement requirements. The assessment process establishes a feature weight matrix, assigning a weight coefficient to each feature, which is dynamically adjusted based on the process type. The assessment results generate a runtime feature profile, representing the execution environment state of the current process instance as a feature vector. The feature vector is input into a policy filtering engine, which calculates the matching degree based on the applicable conditions of the policy.

[0057] In implementation, the process control strategy set is filtered based on the evaluation results using a rule engine that performs constraint checks. The rule engine uses the Drools rule language to define filtering rules. The filtering process iterates through each strategy in the process control strategy set, checking whether the strategy's triggering conditions meet the current runtime characteristics. Triggering conditions are defined in Boolean expression form, containing sub-conditions such as resource threshold comparison, time window judgment, and priority matching. For each strategy, the rule engine evaluates the degree to which its triggering conditions are met, generating a satisfaction score. Strategies with satisfaction scores below a threshold are marked as inapplicable and removed from the candidate strategy set. The filtered strategy set only includes strategies executable in the current environment, significantly reducing the computational complexity of subsequent processing. The filtering results are recorded in a strategy screening report, which details the specific reasons for retaining or eliminating each strategy.

[0058] In practical implementation, a multi-factor scoring model is used to calculate the weights of the remaining control strategies. This model considers the historical performance of each strategy and its adaptability to the current environment. Historical performance data is extracted from a strategy execution log database, which records the number of executions, success rate, and average performance metrics for each strategy in past process instances. Current environment adaptability is calculated by comparing the matching degree between the strategy's requirement characteristics and the characteristics of the current runtime environment; the matching degree is measured using a cosine similarity algorithm. The weight calculation formula is as follows:

[0059] W = α·E history +β·A current +γ·P static

[0060] Where: W represents the overall strategy weight, E history Indicates the historical performance score, A current P represents the current environment adaptability score. static This represents the static priority of the strategy, where α, β, and γ are the weight coefficients of the three factors. The weight calculation process generates a comprehensive score between 0 and 100 for each strategy; a higher score indicates that the strategy is more suitable for the current scenario. The values ​​of the weight coefficients α, β, and γ are dynamically adjusted using a machine learning algorithm that analyzes the actual performance of the strategy under different environments in historical data.

[0061] In practical implementation, selecting the control strategy with the highest weight as a candidate strategy requires feasibility verification. The verification process includes resource reservation checks, time conflict detection, and dependency analysis. Resource reservation checks query the resource management system to confirm that the resources required for strategy execution are available and meet quantity requirements within the specified time window. Time conflict detection compares the strategy execution time with the time constraints of process nodes to ensure that strategy execution does not disrupt the time continuity of the process. Dependency analysis checks the preconditions for strategy execution, verifying whether all preceding nodes have been completed and whether the required data is ready. Feasibility verification is achieved by simulating the execution environment, cloning the state of the current process instance, and observing the process evolution after applying the strategy. Conflicts discovered during verification are recorded in a verification report, indicating the specific conflict type and scope of impact. Only strategies that pass all verification checks can become formal candidate strategies and enter the final decision-making stage.

[0062] In practical implementation, verifying the impact of candidate strategies on process instances through simulated execution requires establishing a process simulation environment. This environment includes a lightweight copy of the Activity process engine and state snapshots of the process instances. The simulation execution process applies each operation step-by-step according to the operation sequence defined by the candidate strategy, while simultaneously monitoring changes in the process state. Monitoring metrics include predicted process completion time, changes in resource utilization, adjustments to node execution order, and variable value updates. The simulation engine records a snapshot of the process state after each operation execution, including node states, variable values, and resource allocation. Impact analysis compares the differences in key metrics before and after simulation execution, calculating the expected benefits and potential risks brought by the strategy. Finally, a set of control rules applicable to the current process context is determined. This set of control rules is the specific operational rules extracted from the candidate strategies, encoded in DRL (Decision Rule Language) format. The control rule set contains complete definitions including rule number, rule description, triggering conditions, execution actions, and rollback operations.

[0063] In some embodiments, the control rule is decomposed into a conditional statement and an action statement using syntax parsing. The parser converts the rule text into an abstract syntax tree. The root node of the abstract syntax tree represents the entire rule, the left subtree represents the conditional statement, and the right subtree represents the action statement. The conditional statement is further decomposed into atomic conditional expressions, which consist of operands, comparison operators, and thresholds. The action statement is decomposed into basic operation units, each corresponding to a specific flow control command. The rule parse tree is constructed using recursive descent parsing, which parses the rule syntax structure layer by layer until the leaf nodes represent indivisible syntax elements. Syntax errors encountered during parsing trigger an exception handling process, which records the error location and type, indicating a problem with the rule definition.

[0064] In some embodiments, a data binding mechanism needs to be established to evaluate the satisfaction of the condition judgment part based on the runtime data of the current process instance. This mechanism maps variable names in the conditional expression to actual variable values ​​of the process instance. The evaluation engine traverses the abstract syntax tree of the condition judgment part, recursively calculating the value of each node from the leaf nodes upwards. The evaluation of atomic conditional expressions returns a Boolean result by comparing the actual variable values ​​with the threshold. Logical operator nodes perform AND, OR, and NOT operations based on the Boolean results of their child nodes. Finally, the value of the root node represents the satisfaction of the entire condition judgment part. The evaluation process supports short-circuit computation, skipping unnecessary subexpression evaluations when the condition result is already determined. The evaluation results are cached in the condition result library to avoid duplicate calculations of the same conditions.

[0065] It is understandable that the sequencing of process operation commands needs to resolve potential conflicts, including resource contention, time overlap, and execution order discrepancies. Resource contention occurs when multiple commands request the same scarce resource; a resource reservation mechanism is used to allocate resources to higher-priority commands. Time overlap occurs when command execution time intervals overlap; a time window adjustment algorithm is used to rearrange command execution times. Execution order discrepancies occur when there are loops in the dependencies between commands; a topological sorting algorithm is used to break these loops and form a linear sequence. The sequencing algorithm considers the urgency and impact of commands, prioritizing urgent commands and flexibly adjusting the positions of commands with smaller impact ranges. The sequencing result generates a command execution plan, specifying the start time, duration, and dependencies of each command. The execution context information of the operation instruction sequence includes authentication data such as process instance identifiers, user session tokens, and security credentials. The target node identifier uses the node ID from the process definition to ensure unique identification of the operation object. Parameter values ​​are serialized into JSON format strings, containing a triplet of parameter name, parameter type, and parameter value. Execution context information is appended to the beginning of the operation instruction packet as a message header. This header includes control information such as the version number, timestamp, and checksum. The complete operation instruction packet is encoded in Protocol Buffers binary format, and the encoded data packet is transmitted to the Activity flow engine via a message broker. Upon receiving the instruction packet, the engine first verifies the validity of the execution context information, and then parses and executes the specific operation.

[0066] Example 4: In practical implementation, real-time acquisition of resource usage data during process instance execution is achieved through a monitoring agent deployed in the process execution environment. The monitoring agent collects CPU utilization, memory usage, disk I / O, network bandwidth, and specific device resource indicators at a fixed sampling frequency. Resource usage data is encapsulated into resource metric objects, which include resource type, resource identifier, sampled value, timestamp, and unit information. A time-series database is used to store continuous resource metric data, indexed by process instance identifier and resource type. The resource consumption trajectory curve is visualized as a line graph, with the horizontal axis representing the time series and the vertical axis representing the resource utilization percentage. Curve smoothing uses a moving average algorithm to eliminate instantaneous fluctuations, and the algorithm window size is dynamically adjusted according to the process execution duration. The resource consumption trajectory curve supports overlay display of multiple resources, with different resource types distinguished by different colored lines for easy comparison of consumption patterns of various resources.

[0067] In practical implementation, aligning the resource consumption trajectory curve with the process evolution trajectory in time requires establishing a unified time reference system. This system uses the process instance start time as zero, and all event timestamps are converted into relative time offsets. The time alignment operation employs a dynamic time warping algorithm, which addresses potential differences in sampling frequency and time scaling between the two trajectories. Deviation is calculated using an area comparison method, determining the area enclosed by the two curves. The area value is obtained through numerical integration. The deviation calculation formula is:

[0068]

[0069] Where: D represents the deviation, T represents the observation time window length, R(t) represents the actual resource consumption at time point t, and R max P(t) represents the maximum resource consumption, and P(t) represents the actual process progress at time point t. max This indicates the maximum progress of the process.

[0070] In practice, triggering the resource reallocation assessment process requires analyzing the root causes of resource allocation imbalances. Root cause analysis employs a fishbone diagram approach to explore the root causes from multiple dimensions. These dimensions include insufficient resource supply, unreasonable resource allocation strategies, abnormal process execution, and changes in the external environment. Insufficient resource supply involves checking the overall capacity and current utilization of the resource pool to determine if resource shortages are causing the imbalance. Unreasonable resource allocation strategies assess whether the existing allocation algorithm is suitable for the current process characteristics and whether there are rigidity issues caused by static allocation. Abnormal process execution detects whether process instances experience deadlocks, livelocks, or performance degradation. Changes in the external environment monitor external factors such as system load, network conditions, and the status of dependent services. The analysis process generates a root cause analysis report, which identifies the primary responsible factors and secondary influencing factors, providing targeted recommendations for subsequent adjustments.

[0071] In practice, resource monitoring data analysis is used to identify process nodes with intense resource competition and those with idle resources. This method statistically analyzes the resource waiting time and holding time for each node during execution. The criterion for identifying nodes with intense resource competition is that the resource waiting time exceeds the execution time by a certain percentage; this percentage threshold is dynamically set based on the resource type. Idle resource nodes are identified by comparing the allocated resource quantity with the actual usage; the idle rate is calculated as (allocated quantity - usage) / allocated quantity. Node resource usage is recorded in the resource allocation analysis table (see Table 1), which includes node identifier, resource type, allocated quantity, actual usage, and utilization rate.

[0072] Table 1: Node Resource Usage Analysis Table

[0073]

[0074] In implementation, the resource quota requirements for each node are recalculated based on process priority and resource constraints using an optimization algorithm. The algorithm aims to minimize the process completion time, with total resources and node dependencies as constraints. The resource quota requirement calculation considers the node's historical resource consumption patterns, current load, and expected workload. A linear programming model is established for the calculation process, with the resource allocation for each node as the decision variable and the overall completion time as the objective function. Constraints include the earliest start time, latest finish time, and maximum total resources for each node. The solution algorithm uses the simplex method or interior-point method to obtain the optimal resource allocation scheme. After recalculation, the quota for nodes with intense resource competition is appropriately increased, while the quota for nodes with idle resources is reduced accordingly, ensuring that the reduced quota still meets the minimum execution requirements.

[0075] In practical implementation, developing a resource quota adjustment plan requires determining the resource transfer path and adjustment timing. The resource transfer path describes the flow of resources from idle nodes to competing nodes, and path selection considers transmission overhead and the scope of impact. The adjustment timing is chosen during a relatively idle period in the process, avoiding adjustments during critical path node execution. The adjustment plan details the specific parameters of each adjustment operation, including the source node, target node, resource type, transfer quantity, start time, and expected duration. The plan evaluation uses impact analysis to analyze the comprehensive impact of adjustment operations on process progress, resource utilization, and system stability. Measures to ensure minimal disruption to the process during adjustment include gradual adjustment, rollback mechanisms, and real-time monitoring. Gradual adjustment breaks down large-scale resource transfers into multiple smaller steps, the rollback mechanism restores the original allocation state in case of anomalies, and real-time monitoring promptly detects and addresses problems during the adjustment process.

[0076] In some embodiments, the dependency analysis between process model adjustment commands and resource quota adjustment schemes employs a directed graph modeling method. Vertices in the directed graph represent adjustment operations, and edges represent dependencies between operations. Dependency types include execution order dependencies, resource conflict dependencies, and time-constraint dependencies. Execution order dependencies require that an adjustment operation can only begin after another operation has completed; resource conflict dependencies occur when multiple operations compete for the same resource; and time-constraint dependencies require operations to execute within a specific time window. The analysis algorithm traverses all pairs of adjustment operations, detecting whether circular dependencies or contradictory constraints exist. The dependency analysis results generate a dependency matrix, which labels the dependency type and strength between each pair of operations.

[0077] In some embodiments, a topological sorting algorithm is used to establish the sequence graph of adjustment operations. This algorithm linearly sorts the vertices of the operations in the directed acyclic graph, ensuring that all predecessor operations of each operation precede it. The sequence graph is visualized as a Gantt chart, with the horizontal axis representing the timeline and the vertical axis listing each adjustment operation. Each operation is represented as a horizontal bar on the graph, with the bar length representing the operation execution time and the bar position representing the start and end times. The sequence graph supports interactive adjustments, allowing users to manually optimize the execution order by dragging and dropping operation bars. The sequence graph also displays dependency arrows between operations, visually illustrating the sequential constraints of operation execution. After the graph is generated, the feasibility of the timing needs to be verified to ensure that all operations can be completed within the specified time window and satisfy the dependency constraints.

[0078] It is understandable that resolving conflicts between adjustment commands requires establishing a conflict detection and resolution mechanism. Conflict detection is achieved by comparing the resource requirements, time intervals, and execution conditions of the operations. Conflict resolution employs a multi-strategy combination approach, including time rescheduling, resource reallocation, and operation decomposition. Time rescheduling adjusts the execution time of conflicting operations, eliminating overlap by inserting waiting intervals or adjusting the execution order. Resource reallocation allocates different resource instances to conflicting operations to avoid resource contention. Operation decomposition breaks down complex conflicting operations into multiple conflict-free sub-operations, which are executed sequentially. The conflict resolution process generates a conflict resolution report, which records the detection process, resolution method, and final result for each conflict. After conflict resolution, the integrity and consistency of the solution need to be re-verified to ensure that the resolution method does not introduce new conflicts.

[0079] See Figure 4 In the synchronous monitoring of resource consumption and process progress, the dynamic changes in deviation are achieved through time alignment analysis of real-time collected resource consumption data and process evolution trajectory. Specifically, a unified relative time reference system is established between the resource consumption trajectory and the process progress trajectory, with the process instance start time as zero. A dynamic time warping algorithm is used to complete time alignment, and the deviation is calculated by combining area comparison with numerical integration to determine the area enclosed by the two trajectories. In the figure, the red broken line represents the real-time change in deviation, the red dashed line indicates the deviation threshold (20%), and the pink area represents the range where the deviation exceeds the threshold: In the time dimension (horizontal axis) from 0 to 40 minutes, the deviation is generally below the 20% threshold; after 40 minutes, the deviation remains above the threshold and shows a fluctuating upward trend, especially around 100 minutes when the deviation climbs to over 60%, indicating a significant imbalance between resource consumption and process progress synchronization during this period. Such visualization results can directly serve as the trigger for resource reallocation procedures and provide a quantitative reference for the formulation of subsequent resource quota adjustment schemes.

[0080] Example 5: In specific implementation, a long-connection mechanism based on the WebSocket protocol is used to establish a bidirectional communication connection with the Activity flow engine. The connection establishment process includes three steps: handshake authentication, protocol negotiation, and channel initialization. During the handshake authentication phase, the client sends a connection request to the Activity flow engine, which includes identity credentials and permission statements. The Activity flow engine verifies the validity of the credentials and returns a connection confirmation. During the protocol negotiation phase, both parties determine the communication protocol version, data encoding format, and heartbeat interval parameters to ensure communication compatibility. During the channel initialization phase, a downlink channel for control commands and an uplink channel for status feedback are established. The downlink channel is used to send flow model adjustment commands, and the uplink channel is used to receive engine execution status. Connection security and reliability are verified by TLS / SSL encryption to prevent man-in-the-middle attacks and data leakage. Reliability is maintained through a heartbeat detection mechanism to keep the connection active, with heartbeat packets sent periodically to check the connection status. When a connection anomaly is detected, a reconnection mechanism is automatically triggered. The reconnection uses an exponential backoff strategy to avoid frequent reconnections that could overload the engine.

[0081] In implementation, process model adjustment commands are encapsulated into message formats recognizable by the Activity process engine according to their execution order. Message encapsulation follows the Activity process engine's REST API specification. Each adjustment command is converted into an independent command message, with the message body containing the command type, target process instance ID, operation parameters, and timestamp information. Command types include node jumps, variable updates, task allocation adjustments, gateway path modifications, and other operation types, each with a corresponding parameter structure definition. The encapsulation process employs a message factory pattern. The factory creates corresponding message objects based on the command type, and these objects are serialized into payload data in JSON or XML format. The message header contains the message ID, creation time, expiration time, and priority flag. The message ID is globally unique and used to track the message lifecycle. Execution order is guaranteed by message sequence numbers, which monotonically increase to ensure the Activity process engine processes command messages sequentially. The message format undergoes version compatibility verification to ensure it matches the target Activity process engine version, avoiding execution failures due to protocol incompatibility.

[0082] In implementation, the control channel with the resource manager adopts a publish-subscribe pattern based on message middleware. The control channel is divided into a command publishing channel and a response receiving channel. The command publishing channel sends resource quota adjustment commands to the resource manager. Channel topics are partitioned by resource type, with commands for different resource types sent to different topics. The response receiving channel receives feedback from the resource manager on the operation results. The channel is bound to each process instance to ensure that feedback messages are routed to the correct receiver. A unified command format is used to transmit resource quota adjustment commands and parameter settings. Commands include fields such as resource type, operation type, target node, quota value, and effective time. Parameter settings include resource allocation strategy parameters, priority weights, and constraints, which affect the resource manager's scheduling decisions. The control channel supports both synchronous and asynchronous communication modes. In synchronous mode, it waits for an immediate response from the resource manager; in asynchronous mode, it returns immediately after sending the command, handling subsequent responses through callback functions. Channel reliability is guaranteed through message persistence and an acknowledgment mechanism. Important commands require confirmation from the resource manager; if no confirmation is received within a timeout period, retransmission is triggered.

[0083] In implementation, a transactional message queue is used to ensure reliable transmission of control commands, providing guarantees of atomicity, consistency, isolation, and durability. During the message production phase, control commands are written to the message queue within a local transaction, ensuring that commands are either fully enqueued or fail completely. During the message consumption phase, the Activity flow engine and resource manager process messages within a transaction, confirming consumption only upon successful processing; otherwise, they are re-delivered. Command loss and duplication are ensured through unique message IDs and a deduplication mechanism. Consumers maintain a set of processed message IDs and reject duplicate messages. The message queue is deployed in a cluster to ensure high availability, with message data synchronized between cluster nodes, automatically switching to the surviving node in case of a single point of failure. Message prioritization allows high-priority commands to be delivered first, with priorities set based on the urgency and business importance of the command. Message lifespan limits prevent the accumulation of expired commands; commands exceeding their lifespan are automatically placed in a dead-letter queue for manual processing.

[0084] In implementation, monitoring the execution status of instructions is achieved through a distributed monitoring system, which includes an instruction status tracker and a feedback collector. The instruction status tracker records the entire lifecycle of each instruction from creation to termination, including states such as created, sent, received, executing, successful execution, and failed execution. The feedback collector receives execution feedback information from the Activity flow engine and resource manager, including execution result codes, error details, execution time, and resource change records. Monitoring data is stored in a time-series database, supporting real-time queries and historical trend analysis. The monitoring dashboard visually displays the distribution of instruction execution status, with different states color-coded and abnormal states highlighted. The monitoring system sets threshold alarms; alarm notifications are triggered when the instruction execution failure rate exceeds the threshold or the average execution time is abnormal. Monitoring data is also used for performance analysis and optimization, identifying instruction processing bottlenecks and areas for improvement.

[0085] In practical implementation, judging the execution result of instructions based on feedback information requires establishing a result evaluation rule engine. The rule engine analyzes the result codes, error codes, and performance metrics in the feedback information. Execution results are categorized into three levels: success, partial success, and failure. Success indicates the instruction fully achieves the expected effect; partial success indicates the instruction produced an effect but with some deviation; and failure indicates the instruction produced no effect. For instructions that fail to execute, a retry or compensation mechanism is initiated. The retry mechanism employs a progressively delayed retry strategy, with a shorter delay for the first retry and gradually increasing delays for subsequent retryes. The maximum number of retry attempts is set according to the instruction type; critical instructions are allowed more retry attempts, while non-critical instructions are allowed fewer. For failed instructions that cannot be retried, the compensation mechanism performs a reverse operation to restore the system state; the compensation operation must ensure idempotency. All operations during the retry or compensation process are recorded in the audit log, which includes the operation time, executor, and detailed parameters to meet audit trail requirements.

[0086] In some embodiments, the bidirectional communication connection with the Activity workflow engine supports multiple authentication methods, including Basic authentication based on username and password, OAuth authentication based on token, and MTLS authentication based on digital certificate. Connection parameters are configurable, including connection timeout, heartbeat interval, retries, and buffer size. The connection manager maintains a connection pool to reuse valid connections, reducing the overhead of frequent connection establishment. Connection exception handling includes network interruption detection, automatic reconnection, and connection migration to ensure the stability of the communication link. Security auditing logs all connection establishment and disconnection events, including timestamps, client identifiers, and operation results, for security analysis and troubleshooting. The workflow model adjusts the message encapsulation of commands to support batch processing mode. Batch processing packages multiple related commands into a single composite message to reduce network overhead. Batch messages contain a batch header and multiple command items. The batch header indicates the number of commands in the batch and the atomicity requirements, while the command items contain the specific operation content. After receiving a batch message, the Activity workflow engine decides whether to execute the entire batch transactionally based on the atomicity requirements. The batch size is dynamically adjusted according to network conditions and engine processing capacity to avoid processing delays caused by excessively large batches. Batch processing is particularly suitable for a set of related adjustment operations that require atomicity, such as adjusting the attributes or variable values ​​of multiple nodes simultaneously.

[0087] It is understandable that the reliable transmission mechanism of transactional message queues needs to be coordinated with business transactions to avoid inconsistencies between message sending and business operations. Distributed transaction processing adopts a best-effort once delivery model, which guarantees that messages are delivered at least once, achieving actual exact-once semantics through deduplication. Message ordering is crucial for process control; disordered ordering can lead to inconsistent process states. Ordering is guaranteed through partitioned ordered messages; all instructions for the same process instance are sent to the same message partition, and messages within the partition maintain a first-in, first-out (FIFO) order. Message persistent storage uses a multi-replica mechanism, with replicas distributed across different physical nodes, ensuring that single-point disk failures do not affect message availability. Instruction execution status monitoring needs to be correlated with the business process status, achieved through a mapping between process instance IDs and instruction IDs. Monitoring data aggregation and analysis elevates from the execution status of individual instructions to an overall health assessment of the business process, considering the execution status of critical path instructions and the effectiveness of resource allocation. Monitoring metrics include instruction success rate, average execution time, P99 latency, and error type distribution, reflecting the operational quality of the control system. The monitoring dashboard supports drill-down analysis, allowing users to drill down from summary metrics to detailed logs of specific failed instructions, quickly pinpointing the root cause of problems.

[0088] See Figure 5The analysis of processing latency for different priority instructions clearly presents the average latency (ms) and P99 latency (ms) for low, medium, high, and urgent priority instructions. Specifically, the average latency for low-priority instructions is 280ms, with a P99 latency of 420ms; the average latency for medium-priority instructions is 150ms, with a P99 latency of 230ms; the average latency for high-priority instructions is 80ms, with a P99 latency of 120ms; and the average latency for urgent priority instructions is 35ms, with a P99 latency of 55ms. The data distribution clearly shows a negative correlation between instruction priority and processing latency; the higher the priority, the significantly lower both the average latency and the P99 latency. Furthermore, at the same priority level, the P99 latency is consistently higher than the average latency, reflecting the latency fluctuations under extreme conditions. The difference between the P99 latency and the average latency is largest for low-priority instructions (140ms) and smallest for urgent priority instructions (20ms), indicating that high-priority instructions have better latency stability. This figure provides a quantitative basis for optimizing instruction scheduling strategies (such as allocating resources to high-priority instructions).

[0089] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0090] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A training planning process control method based on an Activity process engine, characterized in that, The method includes: Extract state snapshots of process instances from the Activity process engine, perform multi-level parsing on the state snapshots, and identify the activation state sequence of process nodes; Based on the activation state sequence of process nodes, a time trajectory map of process evolution is constructed, and key path nodes and branch merging points are marked in the time trajectory map; Based on the structural characteristics of the time trajectory map, a process evolution pattern template library is generated. Real-time process instances are matched with process evolution pattern templates to determine the current evolution stage of the process. For the current process evolution stage, dynamically load the corresponding set of process control strategies, and select control rules that are suitable for the current process context from the set of process control strategies; The process rule executor parses the control rules, generates a sequence of operation instructions at the node level, and converts the sequence of operation instructions into process model adjustment commands that the Activity process engine can recognize. Simultaneously, monitor the synchronization status between the resource consumption trajectory and the process evolution trajectory. When a deviation occurs, initiate the resource reallocation procedure and calculate the resource quota adjustment plan. The process model adjustment commands and resource quota adjustment schemes are coordinated and scheduled, and the execution order is determined according to the dependencies to form the final control instruction set. The control instruction set is sent to the Activity flow engine and resource manager through the instruction distribution channel, driving the flow instance to evolve according to the expected path.

2. The training planning process control method based on the Activity process engine according to claim 1, characterized in that, The process involves multi-level parsing of state snapshots to identify the activation state sequences of process nodes. Specifically, this includes: acquiring runtime data of the process instance provided by the Activity process engine, extracting node state information, transition conditions, and variable values; sorting the node state information according to the time dimension to form a node state change sequence; analyzing the fulfillment of activation conditions for each node, marking the node's ready, execution, and completion states; constructing a node activation state sequence reflecting the process evolution path based on the node state change sequence and node activation states; filtering redundant information from the node activation state sequence, removing duplicate state records, and retaining key time points where states change; comparing the processed node activation state sequence with the process model definition to verify the sequence's compliance, and outputting a standardized process node activation state sequence.

3. The training planning process control method based on the Activity process engine according to claim 2, characterized in that, Based on the activation state sequence of process nodes, a time trajectory graph of process evolution is constructed. Specifically, this includes: establishing a graph structure model of process evolution with process nodes as vertices and state transitions between nodes as edges; adding time dimension information to the graph structure model to record the activation time and duration of each node; determining the successor-successor relationship between nodes based on the node activation state sequence and drawing a directed graph of process evolution; marking the starting and merging points of parallel branches in the time trajectory graph to identify concurrent execution paths in the process; calculating the temporal relationship of nodes on the critical path to determine the minimum completion time window of the process; and mapping resource allocation information to the corresponding nodes in the time trajectory graph to form an enhanced time trajectory graph containing resource constraints.

4. The training planning process control method based on the Activity process engine according to claim 3, characterized in that, A process evolution pattern template library is generated, and real-time process instances are matched with these templates. Specifically, this involves: extracting typical process evolution patterns from historical process instances, including sequential execution, parallel branching, and iterative loops; establishing feature vectors for each process evolution pattern, including feature indicators such as the number of nodes, branch depth, and number of loops; performing cluster analysis on the process evolution patterns using a pattern classification algorithm to form a standardized process evolution pattern template library; extracting the structural and temporal features of real-time process instances and calculating their similarity to each template in the library; selecting the process evolution pattern template with the highest similarity as the matching template for the current process to determine the pattern category of the process instance; and identifying the differences between the current process instance and the standard template based on the matching results, providing a basis for subsequent process control adjustments.

5. The training planning process control method based on the Activity process engine according to claim 4, characterized in that, The corresponding set of process control strategies is dynamically loaded, and control rules suitable for the current process context are selected from the set. Specifically, this includes: retrieving the set of process control strategies associated with the current process stage from the strategy library based on the process evolution stage identification results; evaluating the runtime characteristics of the current process instance, including resource availability, time constraints, and priority parameters; filtering the set of process control strategies based on the evaluation results, eliminating control strategies that do not meet the constraints; calculating the weights of the remaining control strategies, considering the historical execution effects and the adaptability to the current environment; selecting the control strategy with the highest weight as a candidate strategy for feasibility verification; verifying the impact of the candidate strategy on the process instance through simulation execution, and finally determining the set of control rules suitable for the current process context.

6. The training planning process control method based on the Activity process engine according to claim 5, characterized in that, The process rule executor parses control rules to generate node-level operation instruction sequences. Specifically, this includes: decomposing control rules into condition judgment parts and execution action parts, and establishing a rule parse tree; evaluating the satisfaction of the condition judgment parts based on the runtime data of the current process instance; extracting the execution action parts of rules that satisfy the conditions and converting them into specific process operation commands; sorting the process operation commands according to rule priority and dependencies to resolve potential conflicts; organizing the sorted process operation commands into node-level operation instruction sequences to ensure logical consistency between instructions; and adding execution context information to the operation instruction sequences, including target node identifiers and parameter values, to form a complete operation instruction package.

7. The training planning process control method based on the Activity process engine according to claim 6, characterized in that, The system monitors the synchronization status between resource consumption trajectory and process evolution trajectory. When a deviation occurs, a resource reallocation procedure is initiated. This includes: real-time collection of resource usage data during process instance execution to construct a resource consumption trajectory curve; time-aligned comparison of the resource consumption trajectory curve and the process evolution trajectory to calculate the deviation; when the deviation exceeds a threshold, a resource reallocation assessment process is triggered to analyze the root cause of resource allocation imbalance; identifying process nodes with intense resource competition and those with idle resources to pinpoint unreasonable resource allocation points; recalculating the resource quota requirements for each node based on process priority and resource constraints; and developing a resource quota adjustment plan, including resource transfer paths and adjustment timing, to ensure minimal disruption to the process during the adjustment process.

8. The training planning process control method based on the Activity process engine according to claim 7, characterized in that, The process model adjustment commands and resource quota adjustment schemes are coordinated and scheduled, and the execution order is determined according to the dependencies to form the final control instruction set. Specifically, this includes: analyzing the dependencies and execution timing constraints between the process model adjustment commands and resource quota adjustment schemes; establishing a sequence diagram of adjustment operations to ensure the coordination and consistency of process structure adjustment and resource adjustment; resolving conflicts between adjustment commands and determining the final execution order through a priority scheduling algorithm; grouping adjustment operations into atomic execution units to ensure the integrity and rollback of each unit; adding transaction management information to the control instruction set to ensure the atomicity and consistency of instruction execution; and generating the final control instruction set, including execution timing descriptions and exception handling mechanisms, ready for issuance and execution.

9. The training planning process control method based on the Activity process engine according to claim 8, characterized in that, The control command set is sent to the Activity flow engine and resource manager through the command distribution channel. Specifically, this includes: establishing a two-way communication connection with the Activity flow engine and verifying the security and reliability of the connection; encapsulating the flow model adjustment commands into a message format that the engine can recognize according to the execution order; establishing a control channel with the resource manager to transmit resource quota adjustment commands and parameter settings; using a transactional message queue to ensure reliable transmission of control commands and ensure that commands are not lost or duplicated; monitoring the command execution status and collecting feedback information from the engine and resource manager; judging the command execution result based on the feedback information and initiating a retry or compensation mechanism for commands that fail to execute.

10. A training planning process control system based on an Activity process engine, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the training planning process control method based on the Activity process engine as described in any one of claims 1 to 9.

Images