Business collaboration tandem tracking method, device and storage medium

Abstract

The application discloses a business cooperation series tracking method and device and a storage medium, relates to the technical field of data processing, and comprises the following steps: based on a heterogeneous service event, determining event rules and service parameters corresponding to the heterogeneous service event to obtain target event data; mapping the target event data into a business process instance, performing hierarchical control on a task scheduling time sequence to obtain a to-be-executed task set; performing topology logic verification on the to-be-executed task set to obtain an executable action instruction sequence; issuing the executable action instruction sequence to a sandboxed running environment for running, and constraining a script running boundary through a security defense mechanism to obtain business tracking data of the heterogeneous service event. Through the single-pass scanning multi-mode matching, hierarchical time sequence scheduling, topology verification and isolated running event-driven architecture, the application solves the problem of low resource utilization efficiency, improves the event processing and scheduling efficiency, and realizes multi-channel business low-coupling high-safety full-link tracking.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a tracking method, device and storage medium for business collaboration. Background Technology

[0002] In multi-channel collaborative business intelligent scheduling scenarios, the ability to efficiently handle cross-system events, flexibly orchestrate business processes, and securely manage operational resources directly affects business processing efficiency, system stability, and channel expansion adaptability.

[0003] In related technologies, multi-channel business is carried out through system interface docking or middleware data interaction. Event processing and manual configuration process orchestration are completed by combining timed polling mechanism with traditional rule engine. This approach adopts a tightly coupled cross-system interconnection architecture, which relies on polling traversal and rule matching to process business events and schedule process orchestration. It is difficult to adapt to high-concurrency, multi-scenario, and large-scale node business processing scenarios, resulting in low resource utilization efficiency.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a tracking method, device, and storage medium for business collaboration and interconnection, aiming to solve the technical problem of low resource utilization efficiency.

[0006] To achieve the above objectives, this application proposes a tracking method for business collaboration, the method comprising: Based on heterogeneous business events, the event rules and business parameters corresponding to the heterogeneous business events are determined by a single-pass scanning multi-mode matching mechanism to obtain the target event data of the heterogeneous business events. The target event data is mapped to the business process instance corresponding to the heterogeneous business event, and the task scheduling sequence is managed hierarchically to obtain a set of tasks to be executed. Based on the process orchestration template and business domain data, the set of tasks to be executed is subjected to topological logic verification to obtain an executable action instruction sequence. The executable action instruction sequence is sent to an isolated runtime environment for execution, and the script execution boundary is constrained by a security defense mechanism to obtain the business tracking data of the heterogeneous business events.

[0007] In one embodiment, abnormal data filtering, format unification conversion, and standard field mapping are performed on heterogeneous business events accessed from multiple channels to generate an event text sequence with a field structure consistent with the encoding specifications. The event text sequence is input into the prefix tree finite state machine of the embedded parameter extraction node, and a single sequential scan is performed to determine the event rule and the corresponding business parameter of the event text sequence. Based on the event rules and corresponding business parameters matched in the event text sequence, rule validity and parameter format are validated to generate a set of valid matching pairs. The effective matching set is classified, tagged, and traceable to obtain the target event data of the heterogeneous business events.

[0008] In one embodiment, the current state pointer of the finite state machine is reset to the root node according to the prefix tree rule set of the node extracted by the embedded parameters, and the parameter capture buffer and the hit rule storage structure are initialized. The event text sequence is traversed character by character in order, and the corresponding node in the prefix tree is matched according to the current character and the status pointer is updated. When the state pointer jumps to the parameter extraction node in the prefix tree, the field content at the corresponding position in the event text sequence is extracted and written to the parameter capture buffer according to the field format and length constraints of the parameter extraction node. When the status pointer jumps to the rule termination node, the currently matched event rule is marked, and the field content in the parameter capture buffer is bound and mapped to the parameter slot of the event rule to generate a single set of rule parameter matching results; The matching results of the rule parameters are summarized, and rule priority deduplication and parameter integrity verification are performed to determine the event rules and corresponding business parameters that the event text sequence matches.

[0009] In one embodiment, a business process instance corresponding to the target event data is generated based on a business process template that is matched and associated with the target event data. The business process instance is decomposed into a set of initial task nodes with trigger timing, priority, and dependency identifiers; The initial set of task nodes is input into a counting-type probability filtering structure that supports dynamic counting increments and decrements. Duplicate tasks, expired tasks, and invalid scheduled tasks are filtered out through counting verification to obtain a valid set of tasks. Based on the trigger time granularity of each task, the tasks in the effective task set are distributed to the corresponding level slots of the multi-granularity hierarchical time wheel for storage, resulting in slot-based tasks, so as to realize multi-level time sequence hierarchical control. As the time wheel pointer advances slot by slot, the tasks in the current slot are verified, and the set of tasks to be executed is obtained.

[0010] In one embodiment, based on the set of tasks to be executed, invalid data query requests are intercepted in advance by a counting probability index, and the corresponding process orchestration template and business domain data are retrieved from a multi-level hierarchical cache. The set of tasks to be executed is mapped to vertices of a directed graph according to the process arrangement template. Directed connection edges between vertices are constructed by combining the business dependency rules and execution constraint configurations in the business domain data, thereby generating a task dependency directed graph model. The task-dependent directed graph is subjected to topological sorting calculation, and circular dependencies, dangling nodes and logical conflicts that violate business constraints are detected and marked, and an ordered sequence of topological nodes is obtained by filtering. The ordered sequence of topological nodes is associated and mapped one by one with the action execution parameters, service identifiers and adaptation information in the business domain data, and then arranged according to the topological dependency order to obtain the sequence of executable action instructions.

[0011] In one embodiment, based on the set of tasks to be executed and the corresponding process orchestration template, the set of tasks to be executed is mapped to independent vertices of a directed graph, and a unique task identifier, execution type and basic timing attribute are attached to the independent vertex to obtain an initial set of task vertices; Based on the business dependency rules and execution constraint configurations in the business domain data, and combined with the pre- and post-dependencies between tasks, execution condition thresholds, and mutual exclusion control rules, a set of edge constraint rules is generated. Based on the execution order of the process orchestration template, the directed connection relationship between the initial task vertices is determined. The business-level dependency edges and mutual exclusion markers are supplemented by the edge constraint rule set, and the corresponding constraint attributes are attached to the directed connection edges to obtain the preliminary task dependency directed graph. Vertex connectivity and edge constraint consistency are checked on the initial task-dependent directed graph. The start and end vertices of the process are completed, and conflicting edge constraint configurations are corrected to obtain the task-dependent directed graph model.

[0012] In one embodiment, based on the dynamic execution script and action parameters in the executable action instruction sequence, an isolated running environment is initialized, and whitelist class loading rules and bytecode enhancement verification logic are loaded to obtain an isolated running sandbox with security boundary configuration completed. The dynamically executed script is loaded into the isolated execution sandbox. High-risk syntax and prohibited system calls in the script are intercepted by syntax tree parsing and scanning. Restricted class resources are loaded by a whitelist class loader to generate an executable script instance. The executable script instance is run according to the action parameters, resource usage indicators and interface call behavior are detected, and abnormal running states are identified through the sliding window anomaly detection mechanism to obtain running logs; The operation log is loaded with event tracing identifiers and process link markers to generate the business tracking data.

[0013] In one embodiment, when the sliding window anomaly detection mechanism identifies the abnormal running state, it triggers a circuit breaker instruction to terminate the execution of the abnormal script, isolates the running context and resource allocation space corresponding to the abnormal script, and blocks the spread of the anomaly to the host system. The execution stack data, resource runtime snapshots, and call behavior records of the abnormal script are matched and associated with corresponding event identifiers and process instance identifiers to generate an abnormal scene dataset. Based on a pre-built security rule base, the abnormal scene dataset is risk-leveled and classified into anomalies, distinguishing between the abnormal attributes of resource overruns, unauthorized calls, and logical anomalies, and matching the corresponding level of handling strategies. Update the sandbox whitelist rules and sliding window circuit breaker parameters according to the handling strategy, and attach the exception details and handling results to the corresponding business process tracking link to obtain the business tracking data.

[0014] In addition, to achieve the above objectives, this application also proposes a service coordination serialization device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the service coordination serialization tracking method as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the business collaboration and serialization tracking method described above.

[0016] This application provides a tracking method for business collaboration, which includes simultaneously completing event rule matching and business parameter extraction for heterogeneous business events using a single-pass scanning multi-mode matching mechanism to generate target event data; mapping the target event data to corresponding business process instances and hierarchically managing task scheduling timing to obtain a set of tasks to be executed; performing topological logic verification on the set of tasks to be executed based on process orchestration templates and business domain data to generate a sequence of executable action instructions; and distributing the sequence of executable action instructions to an isolated runtime environment and constraining script execution boundaries through a security defense mechanism to generate business tracking data. This full-link event-driven collaboration solution solves the technical problems of high event matching complexity, high resource consumption of timed scheduling, lack of security isolation for dynamic scripts, easy logical conflicts in process orchestration, and high coupling between systems in traditional multi-channel collaborative business. It improves event processing efficiency, task scheduling throughput, and process orchestration accuracy in high-concurrency scenarios, while strengthening the security protection capabilities of dynamic script execution, and realizing low-coupling, high-efficiency connection and full-link traceability of multi-channel collaborative business.

[0017] In summary, this application solves the technical problem of low resource utilization efficiency by adopting an event-driven architecture that features single-pass scanning multi-mode matching, hierarchical time-series scheduling, topology verification, and isolated operation. This improves event processing and scheduling efficiency and enables low-coupling, high-security, end-to-end tracking of multi-channel services. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the tracking method for business collaboration in this application; Figure 2 This is the overall system architecture diagram for this application; Figure 3 Flowchart for the optimized implementation of the algorithm in this application; Figure 4 This is a flowchart illustrating the third embodiment of the tracking method for business collaboration in this application. Figure 5 This is a schematic diagram of the layered time wheel design in this application; Figure 6 This is a flowchart illustrating the sixth embodiment of the tracking method for business collaboration in this application; Figure 7 This is a diagram of the hybrid rendering architecture of this application; Figure 8 This is a flowchart illustrating the eighth embodiment of the tracking method for business collaboration in this application. Figure 9 This is a schematic diagram of the structure of the business collaboration series device in this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] In related technologies, multi-channel business is carried out through system interface docking or middleware data interaction. Event processing and manual configuration process orchestration are completed by combining timed polling mechanism with traditional rule engine. This approach adopts a tightly coupled cross-system interconnection architecture, which relies on polling traversal and rule matching to process business events and schedule process orchestration. It is difficult to adapt to high-concurrency, multi-scenario, and large-scale node business processing scenarios, resulting in low resource utilization efficiency.

[0024] This application provides a solution: First, based on heterogeneous business events, the event rules and business parameters corresponding to the heterogeneous business events are determined through a single-pass scanning multi-mode matching mechanism to obtain the target event data of the heterogeneous business events. Then, the target event data is mapped to the business process instances corresponding to the heterogeneous business events, and the task scheduling sequence is hierarchically managed to obtain a set of tasks to be executed. Next, according to the process orchestration template and business domain data, the set of tasks to be executed is subjected to topological logic verification to obtain an executable action instruction sequence. Finally, the executable action instruction sequence is sent to an isolated runtime environment for execution, and the script execution boundary is constrained through a security defense mechanism to obtain the business tracking data of the heterogeneous business events.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or business collaboration device capable of performing the above functions. The following description uses a business collaboration device as an example to illustrate this embodiment and the subsequent embodiments.

[0026] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0027] This application provides a method for tracking business collaboration and interconnection, referring to... Figure 1, Figure 1 This is a flowchart illustrating the first embodiment of the tracking method for business collaboration in this application.

[0028] In this embodiment, the tracking method for business collaboration includes steps S10 to S40: Step S10: Based on heterogeneous service events, determine the event rules and service parameters corresponding to the heterogeneous service events through a single-pass scanning multi-mode matching mechanism to obtain the target event data of the heterogeneous service events.

[0029] Heterogeneous business events are business-triggered events originating from multiple heterogeneous systems across various channels, with inconsistent formats and field specifications. Examples include third-party system callback events, user operation-triggered events, scheduled events, anomaly alarm events, data synchronization events, and manual approval events. The single-pass scan-based multi-modal matching mechanism is a matching process that performs only one sequential scan of the event text to simultaneously complete rule matching and parameter extraction. Event rules are predefined matching rules used to determine the business type and triggering conditions of an event. Examples include order completion rules, user registration rules, device alarm rules, and data synchronization rules. Business parameters are dynamic field content in the event that carries business semantics. Examples include order number, user identifier, device code, alarm level, and synchronization batch number. Target event data is standardized, schedulable event data after rule matching and parameter extraction.

[0030] In this embodiment, the aforementioned heterogeneous business events can be accessed in six ways. First, channel push triggering: third-party business systems actively push business event data to this system via interface callbacks. Upon receiving the data, the system initiates a matching process to handle cross-system collaborative business events. Second, timed polling triggering: the system actively retrieves pending event data from various business channels according to preset periodic polling rules, generates heterogeneous business events, and initiates matching to perform routine batch business event inspection processing. Third, user operation triggering: users submit operation requests through the business front-end interface. Upon receiving the request, the system generates corresponding heterogeneous business events and initiates matching to handle user-initiated immediate business events. Fourth, data write triggering: after the business database completes the write operation of specified business data, heterogeneous business events are automatically generated and matching is initiated through data change detection to perform immediate process linkage for newly added business data. Fifth, anomaly alarm triggering: when the business detection system detects an abnormal state and generates alarm information, heterogeneous business events are automatically generated and matching is initiated to trigger anomaly handling business processes. The sixth is process callback triggering. After the upstream business process is executed to a specified node, it automatically generates downstream heterogeneous business events and starts matching, which is used to connect multi-stage business collaboration across processes.

[0031] Once the business collaboration system receives the heterogeneous business event, it initiates a single-pass scanning multi-mode matching process to simultaneously complete event rule matching and business parameter extraction.

[0032] For example, there are two implementation methods for single-pass scanning multi-pattern matching. The first is a full single-pass matching of the prefix tree embedded parameter nodes. Before the matching process officially starts, the pre-built prefix tree rule set of the embedded parameter extraction nodes is loaded, the mismatch pointer link of the finite state machine is loaded, the state pointer is reset to the root node, and the parameter capture buffer is initialized. Then, the event text is fully traversed character by character. The prefix tree node is matched according to the current character and the state pointer is updated. When jumping to the parameter extraction node, the corresponding content is extracted according to the preset field constraints and stored in the buffer. When the matching is interrupted, the system jumps to the longest matching suffix state along the mismatch pointer to continue scanning. After a single scan is completed, all hit rules and captured parameters are summarized. This method has stable and rigorous matching logic, high rule hit accuracy, and controllable parameter extraction precision, which can provide comprehensive and reliable event data support for subsequent process mapping.

[0033] The second method is a streaming single-pass matching with a layered state machine and nested field constraints. During the streaming access of event data, incremental matching is performed while receiving event text fragments. The multi-modal matching state machine is divided into three layers: a rule prefix matching layer, a parameter constraint verification layer, and a rule suffix confirmation layer. Event text fragments first enter the rule prefix matching layer to complete fixed prefix hit identification. After a hit, they enter the parameter constraint verification layer to dynamically extract business parameters according to field format and length range constraints. After parameter verification is passed, they enter the rule suffix confirmation layer to complete the full rule hit determination. The matching results are generated after all event texts have been received. This method is executed synchronously with the event data access process and can start matching without waiting for all event data to be received. It can make full use of idle time periods during data transmission to complete processing and reduce end-to-end latency in event processing.

[0034] After completing a single scan and matching of the event text, the matching results can be verified and standardized in the following ways to generate target event data.

[0035] In one alternative approach, the system's preset rule validity verification rules and parameter format verification standards are first retrieved. All scanned matching rules and captured parameters are then verified item by item. Invalid rules, missing parameters, or mismatched formats are discarded. For valid matching results, event classification, tagging, and traceability identification are applied, ultimately generating standardized target event data. This method relies on preset verification rules for filtering, offering intuitive logic, low computational load, and fast execution speed.

[0036] In another alternative approach, all matching rules are first prioritized and deduplicated. The highest-priority matching rule for the same event is extracted as the primary rule, and the remaining matching rules are treated as secondary rules. Next, the captured business parameters undergo integrity verification and format normalization, supplementing missing default parameters and standardizing parameter encoding formats. Subsequently, a consistency verification is performed based on the binding relationship between rules and parameters, correcting anomalies caused by mismatches between parameters and rule slots. Finally, the globally unique event identifier, source channel marker, and matching link information are attached to generate complete target event data. This method allows for multi-dimensional optimization and standardization of matching results, resulting in higher integrity and consistency of event data.

[0037] In an exemplary scheme for determining target event data, a pre-built prefix tree rule set of embedded parameter extraction nodes is first loaded. This rule set includes four basic rule categories: business rules, alarm rules, approval rules, and synchronization rules. Each rule is pre-configured with corresponding parameter slot constraints, priority weights, and validity verification rules. Then, a single-pass scan matching is performed, resetting the status pointer to the prefix tree root node. The text content of heterogeneous business events is traversed character by character, updating the status pointer based on the current character. When a parameter extraction node is encountered, the corresponding content is extracted according to field constraints and stored in the parameter capture buffer. If matching is interrupted, the scan continues along the mismatch pointer. When the status pointer jumps to a rule termination node, the currently matched event rule is marked, and the buffer parameters are bound to the rule slots, generating a single set of matching results. After completing a full text scan, all matching results are aggregated and priority deduplication is performed, retaining the highest priority valid rule for the same event. Then, parameter integrity verification is performed, filling in missing default parameters and standardizing parameter encoding formats; finally, rule and parameter association consistency verification is performed, correcting slot mismatch anomalies. Finally, the event's unique identifier, source channel marker, and matching traceability information are attached to generate the final target event data, which is used for subsequent process mapping and task scheduling.

[0038] It should be noted that in some special cases, if there is only one event rule that completely matches the heterogeneous business event and has complete and valid parameters, the subsequent deduplication and normalization process will be skipped, and the target event data will be generated directly after attaching the traceability identifier.

[0039] Step S20: Map the target event data to the business process instance corresponding to the heterogeneous business event, manage the task scheduling sequence in a hierarchical manner, and obtain a set of tasks to be executed.

[0040] A business process instance is a process execution entity triggered by target event data, carrying complete business execution logic. Examples include order fulfillment process instances, fault handling process instances, approval workflow process instances, and data synchronization process instances. Hierarchical task scheduling is a scheduling mechanism that hierarchically manages the execution sequence according to the task's timeliness level, priority, and dependencies. The set of tasks to be executed is the set of valid tasks that, after invalid task interception and timing calibration, can proceed to subsequent orchestration and verification.

[0041] In this embodiment, the target event data is input into the process mapping engine, matched with the corresponding business process template and generated as a process instance. After being broken down into an initial set of task nodes, the hierarchical time-series scheduling and control process is started.

[0042] For example, there are two implementation methods for business process instance mapping and task decomposition. The first is template-driven static mapping and decomposition. Before the mapping process officially starts, the entire business process template library is preloaded. After receiving the target event data, the corresponding standardized process template is matched according to the event type, business domain identifier, and event level. Based on the fixed node structure of the template, a business process instance is generated and decomposed into an initial set of task nodes with time sequence attributes and dependency identifiers. This method has stable and standardized mapping logic, clear task node boundaries, and is less prone to process structure deviations, providing a reliable task foundation for subsequent hierarchical scheduling.

[0043] The second approach is event-driven dynamic mapping and decomposition. Upon receiving target event data, it first parses the event's business parameters, additional constraints, and associated context. Based on a business rule base, it dynamically assembles and adapts the process node structure to the current event, supplementing it with event-specific validation nodes, branch nodes, and exception handling nodes. This generates a customized business process instance and simultaneously decomposes it into an initial set of task nodes with dynamic time-sensitive attributes and conditional dependency identifiers. This method can flexibly adapt to the personalized business needs of events, achieving higher process adaptation accuracy and fully meeting the differentiated handling requirements of complex business scenarios.

[0044] After the initial task node set is generated, a hierarchical time-series scheduling strategy can be determined based on the following methods to perform hierarchical task management.

[0045] In one alternative approach, the system's pre-defined hierarchical scheduling rule library is retrieved. Based on the preset timeliness level and priority identifier of each task node, the initial set of task nodes is distributed to the corresponding time wheel slots for storage, and fixed-level timing control is performed. This method relies on preset rules for scheduling, resulting in simple and stable logic and low scheduling overhead.

[0046] In another alternative approach, the triggering timeliness requirements, business priorities, prerequisite dependencies, and estimated resource consumption of each task in the initial task node set are first extracted. Combined with the current system's task load status and resource availability, the timing control levels of the tasks are dynamically divided, and the granularity of the time wheel scale and the scheduling frequency of each level are adjusted to generate a hierarchical timing scheduling strategy specific to this task. This method can dynamically adapt to system load and task characteristics, resulting in higher resource utilization and better task timing accuracy.

[0047] In an exemplary scheme for determining a set of tasks to be executed, a business process template library and a hierarchical time wheel scheduling framework are first loaded. This framework includes a three-tiered time wheel structure at the second, minute, and hour levels, with each tier pre-configured with corresponding slot granularity, scheduling frequency, and task priority thresholds. Next, process instance mapping is performed. Based on the event type and business domain identifier of the target event data, the corresponding business process template is matched to generate a business process instance, which is then decomposed into an initial set of task nodes with timeliness attributes, priority, and dependency identifiers. Then, invalid task pre-filtering is performed. The initial set of task nodes is input into a counting-type probability filter structure, which filters out duplicate tasks, expired tasks, and invalid scheduled tasks through counting verification, outputting a preliminary set of valid tasks. Next, hierarchical time-series distribution is performed. Based on the timeliness level and priority of each task, the preliminary set of valid tasks is distributed to the corresponding time wheel slots for storage. As the time wheel pointer advances slot by slot, expired tasks are extracted, and time sequence consistency calibration and pre-dependency verification are performed. Tasks that do not meet dependency conditions are removed, ultimately generating a standardized set of tasks to be executed for subsequent topology logic verification and instruction generation.

[0048] It should be noted that in some special cases, if the target event data corresponds to an urgent high-priority task, the hierarchical timing control process will be skipped directly, and the task will be included in the highest priority real-time scheduling queue. After dependency verification, a set of tasks to be executed will be generated directly.

[0049] Step S30: Based on the process arrangement template and business domain data, perform topological logic verification on the set of tasks to be executed to obtain an executable action instruction sequence.

[0050] A process orchestration template is a predefined process structure template that standardizes the execution order and dependencies of tasks. Business domain data is a collective term for business rules, execution constraints, action parameters, and identification information within a corresponding business domain. Examples include business dependency rules, execution permission constraints, action interface parameters, and business entity identifiers. Topology logic validation is a validation mechanism that sorts task dependencies topologically and detects logical conflicts. Executable action instruction sequences are standardized sets of action instructions that can be directly issued and executed after topology validation and parameter binding.

[0051] After the system obtains the set of tasks to be executed, it begins to retrieve the process orchestration template and business domain data, and starts the topology logic verification and instruction generation process.

[0052] For example, there are two implementation methods for topology logic verification and instruction generation. The first is static topology verification using directed graph modeling. Before the verification process officially starts, the corresponding process orchestration template and basic business domain data are retrieved. The tasks to be executed are mapped to vertices of a directed graph, and directed connections between vertices are constructed according to the inherent execution order of the template, generating a task-dependent directed graph model. Subsequently, topology sorting calculation is performed on the directed graph, and logical conflicts such as circular dependencies and dangling nodes are detected simultaneously. An ordered sequence of topology nodes is obtained and then bound to action parameters in the business domain data to generate an executable action instruction sequence. This method has rigorous and standardized verification logic, comprehensive conflict detection, and high consistency in instruction generation, providing reliable instruction support for subsequent execution stages.

[0053] The second approach is constraint-driven dynamic topology verification. After receiving the set of tasks to be executed, it first parses the business dependency rules, execution constraint configurations, and mutual exclusion control rules in the business domain data. Combined with the basic structure of the process orchestration template, it dynamically adds business-level dependency edges, mutual exclusion markers, and conditional execution constraints to task nodes, generating a directed graph model of task dependencies with business constraint attributes. Subsequently, it performs a constrained topology sorting calculation, simultaneously detecting logical conflicts and business rule violations, and filtering out an ordered sequence of topology nodes that conform to business constraints. These nodes are then bound one by one to all action parameters and adaptation information in the business domain data to generate a sequence of executable action instructions. This method deeply integrates business domain rule constraints, resulting in stronger business compliance in topology verification and higher instruction adaptation accuracy, fully meeting the differentiated orchestration needs of complex business scenarios.

[0054] In the process of constructing a task-dependent directed graph, vertex mapping and edge construction can be completed in the following ways.

[0055] In one alternative approach, the tasks to be executed are mapped one by one to vertices of a directed graph based on the fixed node structure of the process orchestration template. Directed connections are then constructed according to the pre-defined pre- and post-relationships in the template, generating a basic task dependency directed graph. This method relies on a fixed template structure, is logically intuitive, has a fast construction speed, and is suitable for highly standardized routine business processes.

[0056] In another alternative approach, the tasks to be executed are first mapped to vertices of a directed graph and task attribute information is attached. Then, combined with business dependency rules, execution constraints, and mutual exclusion rules from the business domain data, business-level dependency edges, mutual exclusion constraint edges, and conditional trigger edges are added to the template's inherent dependency edges. Corresponding constraint attributes are attached to each edge, and then connectivity checks and constraint consistency corrections are performed to generate a task dependency directed graph with complete business constraints. This method can flexibly overlay dynamic rules from the business domain, resulting in a more adaptable directed graph with stronger business capabilities, more comprehensive verification dimensions, and adaptability to business scenarios with varied rules and complex constraints.

[0057] In an exemplary scheme for determining a sequence of executable action instructions, the corresponding process orchestration template and full business domain data are first retrieved. The business domain data includes four core categories: business dependency rules, execution constraint configurations, action interface parameters, and business identification information. Next, task vertex mapping is performed, mapping each task in the set of tasks to be executed to an independent vertex in a directed graph. Each vertex is assigned a unique task identifier, execution type, and basic timing attributes, generating an initial set of task vertices. Then, directed edge construction is performed. Based on the inherent execution order of the process orchestration template, the basic directed connections between vertices are determined. Combined with the structured constraint rules in the business domain data, business-level dependency edges and mutual exclusion markers are added, and corresponding constraint attributes are assigned to each directed edge, generating a preliminary task dependency directed graph. Finally, topology sorting and conflict detection are performed. A topology sorting calculation is performed on the preliminary directed graph, and circular dependencies, dangling nodes, and logical conflicts violating business constraints are simultaneously detected and marked. An ordered sequence of topology nodes without logical conflicts and conforming to business rules is then selected. Finally, the execution instructions are assembled, binding and mapping the ordered topology node sequence with the action execution parameters, business identifiers and adaptation information in the business domain data one by one. The standardized executable action instruction sequence is generated according to the topology dependency order for subsequent isolated operation and security protection.

[0058] It should be noted that in some special cases, if the set of tasks to be executed contains only a single independent task and has no dependencies, the topology sorting and conflict detection process will be skipped directly, and a single executable action instruction will be generated after binding business parameters.

[0059] Step S40: The executable action instruction sequence is sent to the isolated operating environment for execution, and the script execution boundary is constrained by the security defense mechanism to obtain the business tracking data of the heterogeneous business events.

[0060] An isolated runtime environment is a script execution sandbox environment isolated from host system resources and with restricted permissions. Security defense mechanisms are multi-layered protection mechanisms used to constrain script execution permissions, intercept high-risk operations, and prevent operational risks. Script execution boundaries are the restricted boundaries of system resources, interface permissions, and operational scope that the script can call. Business tracking data is traceable business data that includes execution status, business parameters, operation logs, and end-to-end node information.

[0061] Once the system obtains the sequence of executable action instructions, it begins to initialize the isolated runtime environment and starts script execution and security protection processing.

[0062] For example, there are two ways to implement isolated operation and security defense. The first is a multi-layered security protection driven by a static whitelist. During the runtime environment initialization phase, system-level whitelist rules, bytecode verification rules, and resource quota rules are pre-loaded to complete the permission boundary configuration of the sandbox environment. After the dynamically executed script is loaded into the sandbox, high-risk syntax and prohibited system calls are first intercepted through syntax tree parsing and scanning. Then, restricted class resources are loaded through the whitelist class loader. During operation, resource consumption and interface call behavior are monitored in real time, and script execution is immediately terminated when the circuit breaker threshold is triggered. This method has stable and rigorous protection rules, clear security boundaries, and high reliability in risk interception, providing a solid security guarantee for script execution.

[0063] The second approach is adaptive security protection based on dynamic behavior analysis. After the script is loaded into the isolation sandbox, basic syntax validation and initial permission allocation are performed first. During script execution, a sliding window behavior analysis mechanism collects the script's interface call trajectory, resource usage trends, and operational behavior characteristics in real time. Based on a pre-set security rule base, the operational risk level is dynamically assessed, and the script's permission scope and resource quotas are adaptively adjusted. When high-risk behavior is identified, a circuit breaker is triggered, and the execution context is isolated. This method can dynamically adapt to the script's execution behavior, providing greater protection flexibility. While ensuring security, it can also improve the execution efficiency of legitimate scripts and adapt to dynamic script scenarios with complex logic and varied behaviors.

[0064] After the script finishes execution, business tracking data can be generated in the following ways.

[0065] In one alternative approach, the execution results of the collected scripts and basic operational logs are combined, event tracing identifiers and process link markers are attached, standardized business tracing data is generated, and stored in a link tracing library. This method features simple and efficient generation logic, low storage overhead, and is suitable for tracing needs in typical business scenarios.

[0066] In another optional solution, the execution results, runtime status data, resource runtime snapshots, and call behavior records of the entire script are collected, along with associated event identifiers, process instance identifiers, and task node identifiers. The execution structure is standardized and risk level is assigned, and the timing information and status transition records of the link nodes are supplemented to generate business tracking data containing comprehensive runtime information. This method offers comprehensive tracking dimensions and fine-grained tracing, supporting various scenarios such as problem investigation, security auditing, and process optimization.

[0067] In an exemplary scheme for determining business tracking data, an isolated execution sandbox environment is first initialized, loading whitelist class loading rules, bytecode enhanced verification logic, and resource quota control strategies to complete the security boundary configuration before script execution. Then, the executable action instruction sequence is parsed, extracting the dynamically executed script and corresponding action parameters, and the script is loaded into the isolated execution sandbox. Next, a pre-security scan is performed, intercepting high-risk syntax and prohibited system calls within the script through syntax tree parsing. Restricted class resources are loaded via the whitelist class loader, generating an executable script instance that conforms to security constraints. The script is then driven to execute according to the action parameters, with real-time monitoring of resource usage indicators and interface call behavior. An abnormal execution state is identified through a sliding window anomaly detection mechanism, and script execution is terminated and the abnormal execution context is isolated when a circuit breaker condition is triggered. After script execution, execution results and full execution logs are collected, event tracing identifiers, process instance identifiers, and link node markers are attached, and structured regularization and anomaly classification markers are performed to generate business tracking data containing execution status, business parameters, and full-link node information.

[0068] It should be noted that when the sliding window anomaly detection mechanism identifies an abnormal state in the script's execution, it triggers a circuit breaker command to terminate the current script instance, isolates the script's corresponding execution context and resource allocation space, prevents the abnormal state from spreading to the host system, collects abnormal situation data and associates it with business link identifiers, and attaches the anomaly details and handling results to the business tracking data.

[0069] Further, please refer to Figure 2 , Figure 2This is the overall system architecture diagram for this application. An event-driven business process collaborative tracing system is divided into an orchestration engine layer, an event engine layer, and an execution engine layer. The overall deployment is a three-layer system architecture: user layer, application layer, and data layer. The user layer includes a configuration management page, which integrates configuration management, process canvas, and execution node viewing modules. It also configures the application programming interface (API) and distributed message queue (Kafka, Apache). Kafka), the configuration management page connects downwards to the application layer's configuration management module. This module includes sub-modules for access management, event management, process orchestration, and action management. The configuration management module connects to the execution engine via query interaction. The execution engine comprises a process engine, an event engine, a rule engine, and an action engine. The event engine belongs to the event engine layer and is responsible for event matching, parameter parsing, and scheduling. The execution engine as a whole belongs to the execution engine layer and handles process instance execution and the secure execution of dynamic scripts. Process orchestration belongs to the orchestration engine layer, which provides visual process design and logic verification. The execution engine triggers calls to business services externally. It interacts with data cache and data tracking points, generating tracking data for data tracking points and performing query operations on the data cache. The application layer also includes a real-time data module, which includes data processing and a multi-dimensional query engine. This module performs update operations on the data cache. The data layer deploys Tencent Distributed SQL (TDSQL), a memory-based cache database (Redis), and a distributed message queue (Kafka, Apache). The system utilizes Kafka, ClickHouse (a columnar analytics database), HBase (a distributed columnar storage database), and Elasticsearch (a full-text search engine) to provide upper-layer storage support. The Corasick algorithm's event matching mechanism constructs a Trie tree and adds "parameter nodes," supporting event classification and parameter extraction. It introduces mismatch pointers to form a finite state machine, completing multi-pattern matching in a single scan. For example, matching n=1000 characters of text with m=100 rules reduces the time complexity to O(1100). It employs a hierarchical time wheel and an improved Bloom filter for coordinated scheduling. The hierarchical time wheel manages events in layers with second-level and minute-level time granularity. When a slot is triggered, only the current layer's events are traversed. The improved Bloom filter uses a counter array instead of a bit array, supporting safe deletion. Under the conditions of parameters k=5 and m=9 million, the false positive rate is <1%. The system implements a layered caching and security sandbox design. The layered caching includes an L1 cache (memory) for storing frequently accessed data, an L2 cache (Redis, RemoteDictionary Server) for storing complete data domain snapshots, and a persistence layer (database) for storing all data. A Counting Bloom Filter (CBF) is introduced to intercept over 90% of invalid queries, with a false positive rate of <1% under parameters k=5 and m=100. The security sandbox uses a whitelist class loader combined with bytecode enhancement to restrict dangerous application programming interface (API) calls such as reflection and file I / O. It uses an Abstract Syntax Tree (AST) to parse and intercept high-risk syntax and employs a sliding window circuit breaker to prevent abnormal scripts. The visual orchestration engine uses a hybrid rendering scheme, rendering visible area nodes via WebGL and lightweight drawing non-interactive nodes using Canvas, reducing memory usage by 50%. It also uses the DAGRE algorithm to automatically calculate the topological order, marking circular dependencies and unconnected ports, reducing the logical conflict rate by 90%.

[0070] Second Embodiment This embodiment provides an exemplary scheme for generating target event data through single-pass scanning multi-modal matching. In this example, firstly, anomaly filtering, format conversion, and field mapping are performed on heterogeneous business events accessed from multiple channels for standardized preprocessing to generate a unified and standardized event text sequence. Then, a single-pass sequential scan is performed through a prefix tree finite state machine of embedded parameter extraction nodes to simultaneously complete event rule hit identification and in-situ capture of business parameters. After double validity verification, classification labeling and traceability identification are performed to obtain standardized target event data. Step S10 includes steps A11 to A14: Step A11: Perform abnormal data filtering, format unification conversion, and standard field mapping on heterogeneous business events accessed from multiple channels to generate event text sequences with field structures consistent with coding standards.

[0071] Step A12: Input the event text sequence into the prefix tree finite state machine of the embedded parameter extraction node, perform a single sequential scan, and determine the event rules and corresponding business parameters that the event text sequence hits.

[0072] Step A13: Based on the event rules and corresponding business parameters matched in the event text sequence, perform rule validity verification and parameter format verification to generate a set of valid matching pairs.

[0073] Step A14: Classify and label the valid matching pairs and attach traceability identifiers to obtain the target event data of the heterogeneous business events.

[0074] The event text sequence is a standardized text sequence with a consistent field structure and unified encoding specifications, after abnormal data filtering, format unification conversion, and standard field mapping. It serves as the basic input unit for multi-modal matching processing. Examples include the event body text with unified character encoding, the event attribute sequence concatenated according to standard fields, and the event content string after normalization and escaping. The prefix tree finite state machine with embedded parameter extraction nodes is a finite state matching device that embeds parameter extraction nodes with field constraints and configures mismatch jump links within the character matching path of the prefix tree. It supports simultaneous rule hit determination and dynamic parameter extraction in a single scan. The valid matching pair set is a set of matching results where event rules are bound to corresponding business parameters one-to-one and there are no abnormal missing pairs after dual filtering by rule validity verification and parameter format verification. Event classification and tagging is a processing operation that attaches corresponding classification tags to the matching results according to three dimensions: the business domain to which the event belongs, the event type, and the processing priority. The traceability identifier is a unique identifier used for tracking the event flow path throughout the entire chain, including a globally unique event number, source channel marker, and matching processing link node information.

[0075] In this example, when preprocessing heterogeneous business events from multiple channels to obtain event text sequences, a full synchronous preprocessing approach can be used. First, the full data of a single heterogeneous business event is received. Then, abnormal data cleaning, format encoding conversion, and standard field mapping are performed sequentially to generate a complete event text sequence at once, thus completing the standardized preprocessing of the event data. Alternatively, a streaming incremental preprocessing approach can be used. While receiving fragmented data packets of heterogeneous business events, abnormal filtering and format conversion are performed fragment by fragment. After all data is received, standard field mapping is performed uniformly, accumulating to obtain a complete event text sequence. This allows preprocessing to be started synchronously during the data transmission phase, reducing overall processing latency.

[0076] After generating the event text sequence, the single-pass scanning matching process of the prefix tree finite state machine is started. The event text sequence is input into the prefix tree finite state machine with embedded parameter extraction nodes. After resetting the state pointer to the root node, the system scans character by character. During the matching process, rule path jumps and parameter node content capture are completed simultaneously. After the full text scan is completed, all hit event rules and corresponding business parameters are summarized. In this way, two types of processing are completed simultaneously through a single scan, avoiding the performance overhead caused by multiple traversals of the event text.

[0077] After obtaining the matched event rules and business parameters, a validity verification process is initiated. First, the effective status and applicable business scope of the matched rules are verified, and invalid or out-of-scope rule matching results are eliminated. Then, the format, length, and value range of the corresponding business parameters are verified, and matching results with missing parameters or incorrect formats are eliminated. Finally, matching results that pass both verifications are retained, generating a set of one-to-one bound valid matching pairs. In this way, invalid matching results are filtered through layered verification to ensure the accuracy of subsequent process scheduling.

[0078] After generating a set of valid matching pairs, the classification, tagging, and traceability label mounting process is initiated. Business domain, event type, and priority labels are matched to the events in the valid matching pairs. At the same time, the globally unique identifier of the event, the source channel, and the traceability information of the matching link are mounted. Finally, complete target event data is assembled and generated. In this way, standardized tagging and full-link identification support subsequent cross-link business collaboration and trajectory tracking.

[0079] For example, there are two ways to implement single-pass scanning matching using a prefix tree finite state machine with embedded parameter extraction nodes. The first is full loading and line-by-line matching. Before the matching process officially starts, the entire event text sequence is loaded, and the pre-built prefix tree rule set of the embedded parameter extraction nodes is loaded synchronously. The mismatch pointer link loading of the finite state machine is completed, the state pointer is reset to the root node of the prefix tree, and the parameter capture buffer is initialized. Then, starting from the beginning of the event text sequence, the prefix tree node matching is performed character by character, and the state pointer is updated. When the state pointer jumps to a parameter extraction node, the text content at the corresponding position is extracted according to the preset field format and length constraints of the node and stored in the parameter capture buffer. When character matching is interrupted, the scanning continues along the mismatch pointer to the longest matching suffix state. When the state pointer jumps to a rule termination node, the currently hit event rule is marked, and the content of the parameter capture buffer is bound to the parameter slot of the rule. After the full text scan is completed, all hit results are summarized. This method employs a matching logic that loads the entire text and jumps line by line. It achieves synchronous execution of rule matching and parameter extraction through a state machine design with embedded parameter nodes, eliminating the need for multiple rounds of processing and ensuring the accuracy and stability of the matching results.

[0080] The second method employs a nested state machine and streaming parallel matching approach. This method performs segmented reading and hierarchical matching processing on the event text sequence, splitting the prefix tree finite state machine into a three-layer nested structure: a rule prefix matching layer, a parameter constraint verification layer, and a rule suffix confirmation layer. Event text segments first enter the rule prefix matching layer for fixed prefix character matching. Upon a matching prefix path, the layer proceeds to the parameter constraint verification layer, where text content of the corresponding length is dynamically extracted according to preset field constraints and format verification is performed. After successful parameter verification, the layer proceeds to the rule suffix confirmation layer for suffix character matching. Once a complete rule match is confirmed, the captured parameter content is synchronously bound. These three layers process different text segments in parallel. After the entire event text sequence is scanned, the matching results of all segments are aggregated and deduplicated. This method uses a three-layer nested state machine and streaming segmented parallel processing matching logic. By decoupling matching responsibilities and processing multiple text segments in parallel through layered processing, it improves the event matching throughput in high-concurrency scenarios. Simultaneously, it reduces the overhead of invalid suffix matching through pre-validation of the parameter layer.

[0081] Further, please refer to Figure 3 , Figure 3 This is a flowchart illustrating the algorithm optimization implementation of this application. A unified heterogeneous event processing architecture based on the Aho-Corasick Multi-pattern Matching Algorithm Engine (AC Matching Engine) is constructed. Three heterogeneous event sources—asynchronous event messages delivered by the message queue (RabbitMQ), streaming log data collected by the event log (Kafka, Apache Kafka), and synchronous callback events returned by the interface response—are collectively fed into the event preprocessing module. After undergoing three levels of preprocessing—data cleaning, formatting, and standardization—the data is output to the feature extraction module, which extracts three core feature data—timestamp, operation type, and keyword encoding—and sends them to the matching engine. Pre-stored template rules are used to construct the Trie tree (prefix tree) state structure within the engine. The input event features undergo overlapping pattern optimization, mismatch transition jumps, and dynamic parameter extraction within the engine, ultimately generating standardized structured event results. The structured event results are passed down as output to the cross-system business tracking service for consumption. On the other hand, they are sent to the event analysis module, which analyzes the event results and then passes them to the template learning module. Based on the data, the template rules are optimized and the template rule library is updated, forming a closed-loop iterative optimization mechanism for matching rules.

[0082] Third Embodiment This embodiment provides an exemplary scheme for single-pass scanning matching based on a prefix tree of embedded parameter nodes. In this example, the prefix tree rule set of the embedded parameter extraction nodes is first loaded, the finite state machine's runtime context is initialized, the state pointer is reset, and the parameter capture buffer and the hit rule storage structure are initialized. Then, the event text sequence is traversed character by character to perform prefix tree node matching and state updates. When a parameter extraction node is encountered, content is extracted according to field constraints and written to the buffer. When a rule termination node is hit, parameters are bound to generate a single set of matching results. Finally, all matching results are summarized, and deduplication and parameter integrity checks are performed with specified priorities to determine all event rules and corresponding business parameters that the event text sequence has matched. Please refer to... Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the tracking method for business collaboration in this application. Step A12 includes steps B11 to B15: Step B11: Extract the prefix tree rule set of the node according to the embedded parameters, reset the current state pointer of the finite state machine to the root node, and initialize the parameter capture buffer and the hit rule storage structure.

[0083] Step B12: Traverse the event text sequence character by character, match the corresponding node in the prefix tree according to the current character, and update the status pointer.

[0084] Step B13: When the state pointer jumps to the parameter extraction node in the prefix tree, according to the field format and length constraints of the parameter extraction node, the field content at the corresponding position in the event text sequence is extracted and written into the parameter capture buffer.

[0085] Step B14: When the status pointer jumps to the rule termination node, mark the currently matched event rule, and bind and map the field content in the parameter capture buffer with the parameter slot of the event rule to generate a single set of rule parameter matching results.

[0086] Step B15: Summarize the matching results of the rule parameters, perform rule priority deduplication and parameter integrity verification, and determine the event rules and corresponding business parameters that the event text sequence matches.

[0087] The prefix tree rule set with embedded parameter extraction nodes is a rule matching tree structure composed of multiple layers of character nodes and embedded constraint parameter nodes in the path. It serves as the core basis for the matching execution of the finite state machine. Examples include prefix tree rules for order business, alarm events, approval workflows, and data synchronization. The state pointer is a running pointer used to mark the current position of the finite state machine in the prefix tree node, serving as the core positioning identifier for state transitions and node identification. The root node is the starting node of the prefix tree rule set and the common starting point for all rule matching paths. The parameter capture buffer is a memory storage unit used to temporarily store the dynamic field content extracted by the parameter extraction nodes, used to temporarily store parameters until the binding is completed after a rule match. The hit rule storage structure is a storage structure used to persistently store the parameter matching results of the hit rules, supporting appending to and summarizing the results.

[0088] Field format and length constraints are preset parameter validation rules in the parameter extraction node, used to limit the format type and length range of the extracted content. A rule termination node is the end node in the prefix tree that marks the end of a complete event rule; jumping to this node indicates that the corresponding rule has been matched. The rule parameter matching result is a single matching unit formed by binding the matched event rule with its corresponding capture parameter. Rule priority deduplication is a process that filters and retains multiple matched rules under the same event according to preset rule priority weights. Parameter integrity validation is a process that verifies the number, format, and slot correspondence of parameters in the matching result.

[0089] In this example, during the initialization of the prefix tree finite state machine matching, a full rule synchronous loading approach can be used. First, all prefix tree rule sets for embedded parameter extraction nodes are loaded at once, completing the full calculation and loading of mismatch pointer links. Then, the state pointer is reset, the parameter capture buffer and the hit rule storage structure are initialized, completing all pre-match preparations in one go, thus ensuring the stability and continuity of the subsequent matching process. Alternatively, an incremental loading approach can be used. First, a subset of prefix tree rules corresponding to the business domain to which the event belongs is loaded. After resetting the state pointer and buffer, matching begins. If a cross-domain rule path is triggered during matching, the corresponding rule node is incrementally loaded, thereby reducing the rule loading overhead during the initialization phase and adapting to event handling scenarios with clearly defined business domains.

[0090] After the state machine initialization is completed, the character-by-character traversal matching process of the event text sequence is started. The characters in the event text sequence are read in sequence, and the corresponding child node is matched in the prefix tree according to the current character and the state pointer is updated. During the traversal, the parameter extraction node and the rule termination node are identified simultaneously. In this way, the rule path matching and parameter content capture are completed synchronously through a single round of sequential traversal, avoiding the performance loss caused by multiple rounds of traversal.

[0091] When the status pointer jumps to the parameter extraction node, the parameter truncation process is started. The preset field format and length constraints of the node are read, and the field content that meets the constraints is truncated from the current position of the event text sequence and written to the parameter capture buffer for temporary storage. After subsequent rules are matched, they are bound uniformly. In this way, the in-situ accurate extraction of dynamic parameters is achieved through the constraint configuration embedded in the node.

[0092] When the status pointer jumps to the rule termination node, the rule hit binding process is started, the event rule corresponding to the current path is marked as hit, the field content temporarily stored in the parameter capture buffer is bound to the corresponding parameter slot of the event rule, a single set of rule parameter matching results is generated and stored in the hit rule storage structure, so as to complete the parameter association binding at the same time as the rule is hit, reducing the overhead of subsequent secondary matching.

[0093] After completing the full traversal of the event text sequence, the result summary and verification process is initiated. All generated rule parameter matching results are extracted from the hit rule storage structure. First, deduplication is performed according to rule priority, retaining the highest priority matching rule under the same event. Then, parameter integrity verification is performed to remove results with missing parameters or mismatched slots. Finally, all valid event rules and corresponding business parameters that the event text sequence hits are determined. This double verification ensures the accuracy and availability of the matching results.

[0094] For example, there are two implementation methods for single-pass scanning matching based on a prefix tree finite state machine. The first is full-volume serial character-by-character state jump matching. Before the matching process officially starts, the prefix tree rule set of the embedded parameter extraction node is fully loaded, the mismatch pointer link calculation and loading of all nodes are completed, the state pointer of the finite state machine is reset to the root node of the prefix tree, and the parameter capture buffer and the hit rule storage structure are initialized synchronously. Then, starting from the beginning of the event text sequence, the prefix tree child node matching is performed character by character and the state pointer is updated. When the state pointer jumps to the parameter extraction node, the text content at the corresponding position is extracted according to the preset field format and length constraint of the node and written to the parameter capture buffer. When there is no corresponding child node for the character match, the matching is continued by jumping to the longest matchable suffix state along the mismatch pointer. When the state pointer jumps to the rule termination node, the corresponding event rule is marked as hit and the buffer parameters are bound to the rule slot to generate the matching result. After the full text traversal is completed, all matching results are summarized, and priority deduplication and parameter integrity verification are performed. This method employs a matching logic that loads all rules and jumps state line by line. Through the collaborative design of embedded parameter nodes and mismatch pointers, it can simultaneously complete rule hit determination and dynamic parameter extraction within a single scan. The matching logic is rigorous and stable, and the results are highly accurate.

[0095] The second method is segmented parallel state machine snapshot matching. This method splits the event text sequence into multiple interconnected text segments of fixed length. Each text segment is assigned an independent state machine instance and parameter capture buffer, and all segments synchronously initiate parallel matching processing. Within each segment, character-by-character node matching, parameter extraction, and rule hit determination are performed independently. Simultaneously, a state pointer snapshot and buffered temporary data are passed at the segment transition points to connect to the matching start state of the next segment. After all segments are matched, the rule parameter matching results of each segment are summarized, and cross-segment deduplication and parameter integrity verification are performed to finally obtain a full hit result. This method employs text segmentation and multi-instance parallel matching processing logic. It ensures matching continuity through segmented state snapshot passing, fully utilizes parallel computing power to improve matching throughput in long text and high-concurrency scenarios, while retaining the core characteristic of single-pass scanning without increasing the overall number of scans.

[0096] Furthermore, in the heterogeneous business event of third-party order completion accessed by the e-commerce system, the corresponding event text sequence is "Order OD2025080612345678 completed, actual payment amount 399 yuan, ordering user U10086". When performing matching, the order business prefix tree rule set with embedded parameter extraction nodes of three types, order number, payment amount and user ID, is loaded first. This set contains 12 order-type event rules. The current state pointer of the finite state machine is reset to the root node of the prefix tree, and a parameter capture buffer with a capacity of 256 bytes and a hit rule storage structure that supports chained storage are initialized synchronously. Then, starting from the first character, the event text sequence of 38 characters is traversed character by character in sequence, matching the "order" and "order" nodes and updating the status pointer. When the status pointer jumps to the order number parameter extraction node, according to the node's preset field constraint of "starting with the letter O + 15 digits, total length 16 characters", 16 characters "OD2025080612345678" are extracted from the current position of the event text and written to the parameter capture buffer. The traversal continues to match the "already", "processed", and "closed" nodes. When the status pointer jumps to the rule termination node corresponding to "order completion notification", the event rule is marked as matched, and the order number content in the parameter capture buffer is bound and mapped to the order number parameter slot of the rule, generating the first set of rule parameter matching results. During subsequent traversal, the extraction nodes for two types of parameters, payment amount and user ID, are triggered sequentially. "399 yuan" and "U10086" are extracted and written to the buffer according to the constraints of "1-6 digits + Chinese characters" and "uppercase letter U + 5 digits," respectively. Binding is completed at the corresponding rule termination node, generating a total of 3 matching results. Finally, all 3 sets of rule parameter matching results are summarized, and deduplication is performed according to the preset rule priority weights (main rule priority 90, subordinate attribute rule priority 60). The highest priority order completion main rule and its three associated business parameters are retained. Parameter integrity and format compliance checks are then performed to confirm that all parameters correspond to the rule slots and meet the constraints. Finally, it is determined that the event text sequence matches the order completion notification event rule, with the corresponding business parameters being order number OD2025080612345678, actual payment amount 399 yuan, and order user ID U10086.

[0097] Fourth embodiment This embodiment provides an exemplary scheme for generating a set of tasks to be executed through hierarchical time-series control. In this example, firstly, a business process instance is generated based on the business process template associated with the target event data. Then, the process instance is decomposed into an initial set of task nodes with trigger time, priority, and dependency identifiers. After filtering out duplicate, expired, and invalid tasks using a counting probability filtering structure, the tasks are distributed to the corresponding level slots of a multi-granularity hierarchical time wheel according to the task trigger time granularity. Finally, the task verification is completed slot by slot as the hierarchical time wheel pointer advances, and a standardized set of tasks to be executed is output. Step S20 includes steps C11 to C15: Step C11: Based on the business process template associated with the target event data, generate a business process instance corresponding to the target event data.

[0098] Step C12: Decompose the business process instance into an initial task node set with trigger timing, priority and dependency identifier.

[0099] Step C13: Input the initial task node set into a counting-type probability filtering structure that supports dynamic counting increments and decrements, and filter out duplicate tasks, expired tasks and invalid scheduled tasks through counting verification to obtain a valid task set.

[0100] Step C14: Based on the trigger time granularity of each task, distribute the tasks in the effective task set to the corresponding level slots of the multi-granularity hierarchical time wheel for storage, thereby obtaining slot-based tasks to achieve multi-level time-series hierarchical control.

[0101] Step C15: As the layered time wheel pointer advances slot by slot, verify the sub-slot tasks in the current slot and organize them to obtain the set of tasks to be executed.

[0102] Business process templates are predefined, standardized process templates that specify the order of business execution nodes, dependencies, and constraints. They are used to generate runnable business process instances. Examples include order fulfillment process templates, fault handling process templates, approval workflow templates, and data synchronization process templates. The initial task node set is a set of the smallest task units with independent execution logic, extracted from the business process instance. Each task node is assigned trigger timing, priority, and dependency identifier attributes. Examples include inventory deduction tasks, notification push tasks, data archiving tasks, and status update tasks. The counting-based probabilistic filtering structure is a filtering data structure that supports dynamic counting increments and decrements and uses probability counting to achieve fast deduplication and invalid data interception. It is used to pre-screen duplicate, expired, and invalid scheduled tasks. Examples include counting-based Bloom filters and counting-based cardinality estimation algorithm structures.

[0103] The effective task set is a collection of task nodes that, after being filtered using a counting-based probabilistic filtering structure, are non-duplicate, not expired, and have scheduling validity. A multi-granularity hierarchical time wheel is a time-series scheduling structure composed of multiple nested time wheel levels with different time scale granularities, used to implement hierarchical management of tasks with different time requirements. For example, a three-layered time wheel consisting of a second-level time wheel, a minute-level time wheel, and an hour-level time wheel. Slot-based tasks are distributed to task nodes stored in designated slots within the corresponding time wheel level according to their trigger time granularity.

[0104] In this example, when generating a business process instance based on target event data, a precise template matching approach can be used. This involves extracting the business domain identifier, event type, and event level from the target event data, matching them with template tags in the process template library, selecting the business process template with the highest matching degree, and instantiating an independent business process instance based on event parameters. This ensures the business compatibility between the process and the event. Alternatively, a dynamic assembly approach can be used. Based on the business parameters and additional constraints of the target event data, suitable node units are selected from the process node library and dynamically assembled to generate a customized business process instance, thus adapting to differentiated process requirements in complex scenarios.

[0105] After generating a business process instance, the task node decomposition process is initiated. According to the node definition and execution order of the process template, the complete business process instance is decomposed into multiple independent task nodes. Each task node is attached with the corresponding trigger sequence, business priority and prerequisite dependency identifier, and an initial task node set is generated. In this way, the macro process is decomposed into the smallest schedulable execution unit.

[0106] After obtaining the initial set of task nodes, the invalid task filtering process is initiated. All initial task nodes are input into a counting-type probability filtering structure that supports dynamic counting increments and decrements. Through counting verification, duplicate submitted tasks, expired tasks that have exceeded their trigger time, and invalid scheduled tasks without an execution subject are identified and filtered. The filtered set of valid tasks is output, thereby intercepting invalid tasks in advance and reducing the resource overhead of subsequent time-series scheduling.

[0107] After obtaining the set of valid tasks, the hierarchical time-series distribution process is initiated. The trigger time granularity and timeliness requirements of each valid task are analyzed. Tasks with timeliness of milliseconds and seconds are distributed to the corresponding slots of the bottom second-level time wheel, tasks with timeliness of minutes are distributed to the corresponding slots of the middle minute-level time wheel, and tasks with timeliness of hours and above are distributed to the corresponding slots of the top hour-level time wheel, generating slot-based tasks. In this way, multi-level time-series hierarchical management of tasks is achieved through a multi-granularity layered architecture.

[0108] After the task slot storage is completed, the time wheel pointer advances slot by slot. When the pointer points to a specified slot, all slot tasks in that slot are extracted. Task pre-dependency verification, timing consistency calibration, and execution resource pre-verification are performed. Tasks that do not meet the dependency conditions and resource requirements are removed. The final set of tasks to be executed is then organized and output to ensure the executability and timing accuracy of the output tasks.

[0109] For example, there are two ways to implement hierarchical timing control based on multi-granularity layered time wheels. The first is fixed-granularity layered time wheel serial scheduling. During the scheduling system initialization phase, three layers of fixed-granularity layered time wheels (second-level, minute-level, and hour-level) are pre-constructed. Each layer of time wheels is pre-configured with a fixed number of slots and a scale interval. At the same time, the parameter configuration of the counting probabilistic filtering structure is initialized. After receiving the initial set of task nodes, the counting probabilistic filtering structure first filters out duplicate, expired, and invalid tasks to obtain a valid task set. Then, according to the preset trigger time granularity of each task, they are sequentially distributed to the target slots of the corresponding layered time wheels for storage. As the time wheel pointer advances slot by slot according to a fixed scale, the sub-slot tasks in the current slot are extracted sequentially, and dependency verification and timing calibration are performed serially. Finally, the set of tasks to be executed is generated. This method adopts a fixed-granularity layered architecture and serial scheduling logic, with clear hierarchical boundaries, stable scheduling logic, controllable resource consumption, and is suitable for conventional scheduling scenarios with fixed business scenarios and clear task timeliness levels.

[0110] The second method is dynamic granularity adaptive time wheel parallel scheduling. Based on the timeliness distribution characteristics of the effective task set, it dynamically adjusts the number of layers and the granularity of each layer of the hierarchical time wheel. When the proportion of high-concurrency, short-term tasks is high, it expands to sub-second levels; when the proportion of long-cycle tasks is high, it expands to coarse-grained levels above the day level. Simultaneously, it allocates an independent scheduling thread to each time wheel layer. Each time wheel layer executes pointer advancement and task verification processing in parallel. A promotion and demotion mechanism enables task flow across layers. Short-term tasks are automatically degraded to a finer-grained level before expiration to improve trigger accuracy, while long-cycle tasks are automatically promoted to a coarse-grained level to reduce scheduling overhead. During the task distribution phase, intelligent routing is executed based on dynamic granularity rules. During the verification phase, multi-level parallel execution is performed, and finally, the expired tasks output from each layer are aggregated to generate a set of tasks to be executed. This method employs dynamic granularity adaptive adjustment and multi-level parallel scheduling logic, which can dynamically optimize the scheduling architecture according to task load characteristics. In high-concurrency mixed-timeliness scenarios, it balances scheduling accuracy and resource utilization, improving the throughput and adaptability of time-series scheduling.

[0111] Further, please refer to Figure 5 , Figure 5This is a schematic diagram of the layered time wheel design of this application. A layered time wheel scheduler is provided, which has a multi-layered circular time wheel structure with seconds, minutes, hours, and days arranged from the inside out. Each layer of the time wheel is divided into multiple numbered slots. The scheduler drives the time wheel to rotate based on a time advance tick (clock tick). Different levels of slots are connected by dotted lines to form task lists. Task lists formed by sequentially linking task nodes are mounted on the slots. Different slots respectively hold task lists containing two, three, or four task nodes. This hierarchical time wheel scheduler works in conjunction with an improved Bloom filter to schedule event tasks. The hierarchical time wheel manages event tasks in layers with different time granularities, such as seconds, minutes, hours, and days. When a tick is triggered, it only traverses the event tasks attached to the corresponding slot in the current layer. The improved Bloom filter uses a counter array instead of a bit array, supports safe deletion operations, and has a false positive rate of <1% under the conditions of parameters k=5 and m=9 million. Through the collaboration of the hierarchical time wheel and the improved Bloom filter, efficient filtering and scheduling of a large number of delayed event tasks can be achieved.

[0112] Fifth embodiment This embodiment provides an exemplary scheme for generating an executable action instruction sequence through topological logic verification. In this example, invalid data query requests are first intercepted based on the set of tasks to be executed using a counting probability index. The corresponding process orchestration template and business domain data are retrieved from a multi-level hierarchical cache. Then, the tasks to be executed are mapped as vertices of a directed graph. Directed connection edges between vertices are constructed by combining business dependency rules and execution constraint configurations to generate a task dependency directed graph model. Subsequently, topological sorting calculation is performed, and logical conflicts such as circular dependencies, dangling nodes, and business constraint violations are detected. An ordered topological node sequence is obtained by filtering. Finally, the node sequence is associated and mapped one by one with action execution parameters, business identifiers, and adaptation information, and the executable action instruction sequence is obtained by arranging them according to the topological dependency order. Step S30 includes steps D11 to D14: Step D11: Based on the set of tasks to be executed, invalid data query requests are intercepted in advance using a counting probability index, and the corresponding process orchestration template and business domain data are retrieved from the multi-level hierarchical cache.

[0113] Step D12: Map the set of tasks to be executed to vertices of a directed graph according to the process arrangement template, and construct directed connection edges between vertices by combining the business dependency rules and execution constraint configuration in the business domain data, thereby generating a task dependency directed graph model.

[0114] Step D13: Perform topological sorting calculation on the task-dependent directed graph, detect and mark circular dependencies, dangling nodes, and logical conflicts that violate business constraints, and filter to obtain an ordered sequence of topological nodes.

[0115] Step D14: Associate and map the ordered topology node sequence with the action execution parameters, service identifiers and adaptation information in the business domain data one by one, and organize them according to the topology dependency order to obtain the executable action instruction sequence.

[0116] A counting-based probabilistic index is a query-before-access index built on a probability counting structure. It's used to quickly identify and block invalid or duplicate template and data query requests, reducing unnecessary cache accesses and database queries. A multi-level tiered cache is a layered cache architecture composed of multiple storage media. It stores process templates and business domain data in layers according to access frequency and data volume, improving data retrieval efficiency. For example, a three-level tiered cache might include local memory caching, distributed caching, and persistent storage. Directed graph vertices are the mapping nodes of tasks to be executed in the directed graph, carrying task attribute information and connection relationships. Business dependency rules are the pre- and post-task relationships, mutual exclusion relationships, and conditional triggering rules defined at the business level, used to supplement business-level dependency constraints beyond process templates. Execution constraint configurations are the permissions, resources, and time limits that task execution must meet, used to verify the compliance and feasibility of task execution.

[0117] A directed edge is a directed edge in a directed graph that connects two vertices, used to represent the dependency and constraint attributes between tasks. A task dependency directed graph model is a directed graph data model composed of vertices and directed edges, fully representing task dependencies and constraint attributes. Topological sorting is a computational process that linearly sorts vertices based on directed graph dependencies, used to generate a task execution sequence that conforms to the dependency order. Circular dependency is a closed-loop dependency path in a directed graph, representing a logical conflict that will prevent the process from executing normally. A dangling node is an isolated task node without predecessor or successor dependencies, detached from the main process link. An ordered topological node sequence is an ordered sequence of task nodes that conforms to the dependency order and business constraints after topological sorting and conflict filtering. Action execution parameters are the set of interface parameters, business fields, and configuration parameters required for task execution. Business identifiers are unique identifiers used to mark the business domain to which a task belongs, the event source, and the process instance. Adaptation information is adaptation configuration information used to adapt to different execution environments and different calling interfaces.

[0118] In this example, when retrieving process orchestration templates and business domain data, a full pre-validation retrieval approach can be used. First, a counting probability index is used to perform pre-validation on all templates and data query requests corresponding to the set of tasks to be executed, intercepting invalid and duplicate queries. Then, matching is performed layer by layer starting from the innermost layer of the multi-level hierarchical cache. If a match is found, the full process orchestration template and business domain data are returned directly; otherwise, the data is loaded from persistent storage and written back to the cache, thus completing the loading of the basic data required for validation. Alternatively, a streaming incremental retrieval approach can be used. While parsing the task type and business domain of the set of tasks to be executed, a counting probability index is used to perform query validation on a task-by-task basis. The corresponding task's process node configuration and associated business domain data are retrieved from the multi-level hierarchical cache as needed. The remaining data is gradually added and loaded as the topology construction progresses, thus streamlining data retrieval and topology construction pipelines and reducing overall processing latency.

[0119] After retrieving the process orchestration template and business domain data, the directed graph construction process is initiated. Each task in the set of tasks to be executed is mapped to an independent vertex of the directed graph, with a unique task identifier, execution type, and timing attribute attached. Based on the inherent execution order of the process orchestration template, basic directed connection edges are constructed. Business-level dependency edges, mutual exclusion constraint edges, and condition trigger edges are added by combining the business dependency rules and execution constraints in the business domain data. Corresponding constraint attributes are attached to each edge to generate a complete task dependency directed graph model. This integrates the inherent logic of the process with dynamic business rules, improving the business adaptability of the directed graph.

[0120] After generating the task-dependent directed graph model, the topology sorting and conflict detection process is initiated. The directed graph is subjected to a topology sorting calculation with decreasing in-degree. During the sorting process, circular dependency nodes with closed loops, dangling nodes with no in-degree and no out-degree, and violation edges and nodes that do not conform to business dependency rules and execution constraints are detected and marked simultaneously. Nodes and branches with logical conflicts are removed, and an ordered sequence of topology nodes without conflicts and conforming to business constraints is obtained. In this way, the logical correctness and business compliance of the task execution sequence are ensured through multi-dimensional conflict detection.

[0121] After obtaining the ordered topology node sequence, the instruction assembly process is initiated. Each node in the ordered topology node sequence is bound and mapped one by one to the action execution parameters, business identifiers, and adaptation information in the business domain data. Interface call addresses, permission verification identifiers, and environment adaptation configurations are added. Then, all node instructions are sorted and organized strictly according to the order of topology dependencies. Finally, a standardized executable action instruction sequence is generated, which outputs complete execution instructions that can be directly issued and run, ensuring the availability of subsequent execution stages.

[0122] For example, there are two implementation methods for topology logic verification based on task-dependent directed graphs. The first is a static template-driven serial topology verification. Before the verification process officially starts, a full query verification is performed using a counting probability index to retrieve the complete process orchestration template and basic business domain data from a multi-level hierarchical cache. Then, according to the fixed node structure of the process template, each task to be executed is mapped to a directed graph vertex, and directed connection edges are constructed based on the preset dependency relationships of the template to generate a task-dependent directed graph model with a fixed structure. Next, a single-threaded serial in-degree decreasing algorithm is used to perform topology sorting, sequentially detecting two types of basic logic conflicts: circular dependencies and dangling nodes, and filtering to obtain an ordered topology node sequence. Finally, the node sequence is bound to preset action parameters and business identifiers one by one, and assembled into an executable action instruction sequence according to the topology order. This method uses static templates and serial verification processing logic, with clear dependency relationships, stable verification logic, strong result consistency, and is suitable for conventional business scenarios with fixed process structures and few changes in business rules.

[0123] The second approach is a dynamically constrained, domain-specific parallel topology verification. First, invalid queries are intercepted using a counting probabilistic index. Then, corresponding process segment templates and domain-specific business rule data are retrieved from a multi-level hierarchical cache, segmented by business subdomain. The set of tasks to be executed is divided into multiple task subsets by business subdomain, and an independent topology construction thread is assigned to each task subset. Each thread maps tasks within a subdomain to vertices of a subgraph in parallel. Directed edges are constructed in the subgraph based on the corresponding subdomain's business dependency rules and execution constraint configurations, generating multiple independent subdomain task dependency subgraphs. After all subgraphs are constructed, cross-subgraph dependency edge concatenation and global constraint verification are performed, merging to generate a complete task dependency directed graph model. Subsequently, a multi-source parallel topology sorting algorithm is used, synchronously advancing sorting calculations from multiple zero-in-degree starting points. Simultaneously, three types of logical conflicts—circular dependencies, dangling nodes, and business constraint violations—are detected, resulting in a globally ordered topology node sequence. Finally, action parameters and adaptation information are bound in parallel by subdomain, and a globally aggregated and sorted sequence generates an executable action instruction sequence. This method employs a processing logic of domain-based parallel construction and multi-source parallel sorting. By splitting subdomains, it fully utilizes parallel computing power and deeply integrates dynamic business constraints. In complex multi-domain business scenarios, it significantly improves the processing efficiency of topology verification and the accuracy of business adaptation, and adapts to complex scheduling scenarios involving multi-business domain collaboration and dynamic rule changes.

[0124] Furthermore, in the set of pending tasks for order fulfillment in the e-commerce transaction domain, which includes four tasks: inventory deduction, coupon redemption, logistics order placement, and user notification, the topology verification first performs a pre-verification of data query requests using a counting probability index with a preset false positive rate of 0.01%, intercepting two duplicate template queries and one invalid data query request. Then, the order fulfillment process orchestration template and transaction domain business data are retrieved from a three-level hierarchical cache consisting of local memory, distributed cache, and persistent storage. The local cache directly hits the core data, reducing data retrieval time by 72% compared to direct database connection. Subsequently, according to the process orchestration template, the four pending tasks are mapped one by one to directed graph vertices carrying unique task identifiers, execution types, and time sequence attributes. Combining the business dependency rule of "logistics order placement depends on both inventory deduction and coupon redemption" and the execution constraint configuration of "coupon redemption must meet user level ≥ 3" in the business domain data, five directed connection edges with constraint attributes are constructed, including two supplementary business-level constraint edges, generating a complete task dependency directed graph model. Next, the Kahn algorithm is used to perform topological sorting on the directed graph, simultaneously detecting and marking three types of logical conflicts: circular dependencies, dangling nodes, and violations of business constraints. After verification, the directed graph has no circular dependency links, no isolated dangling nodes, and all constraint edges conform to business rules, resulting in an ordered topological node sequence of "inventory deduction, coupon redemption, logistics order placement, and user notification". Finally, the four nodes in the ordered topological node sequence are associated and mapped one by one with the 12 action execution parameters, 3 types of business identifiers, and 2 environmental adaptation information in the business domain data. The instructions are ordered and formatted according to the order of topological dependencies, generating an executable action instruction sequence containing four standardized runnable instructions.

[0125] Sixth Embodiment This embodiment provides an exemplary scheme for constructing a task-dependent directed graph model. In this example, based on the set of tasks to be executed and the corresponding process orchestration template, the tasks to be executed are first mapped to independent vertices of a directed graph with attached attributes, resulting in an initial set of task vertices. Then, dependency rules and constraint configurations in the business domain data are parsed, and a set of structured edge constraint rules is generated by combining the dependency relationships between tasks, condition thresholds, and mutual exclusion rules. Subsequently, basic directed connections between vertices are constructed based on the template execution order. Business-level dependency edges and mutual exclusion markers are supplemented by edge constraint rules to obtain a preliminary task-dependent directed graph. Finally, the start and end vertices of the process are completed through connectivity and consistency checks, and conflict constraint configurations are corrected to generate a complete and usable task-dependent directed graph model. Please refer to... Figure 6 , Figure 6 This is a flowchart illustrating the sixth embodiment of the tracking method for business collaboration in this application. Step D12 includes steps E11 to E14: Step E11: Based on the set of tasks to be executed and the corresponding process orchestration template, map the set of tasks to be executed into independent vertices of a directed graph, and attach a unique task identifier, execution type and basic timing attribute to each independent vertex to obtain an initial set of task vertices.

[0126] Step E12: Based on the business dependency rules and execution constraint configuration in the business domain data, and combined with the pre- and post-dependencies between tasks, execution condition thresholds, and mutual exclusion control rules, generate a set of edge constraint rules.

[0127] Step E13: Based on the execution order of the process orchestration template, determine the directed connection relationship between the initial task vertices, supplement the business-level dependency edges and mutual exclusion markers with the set of edge constraint rules, and attach corresponding constraint attributes to the directed connection edges to obtain a preliminary task dependency directed graph.

[0128] Step E14: Perform vertex connectivity verification and edge constraint consistency verification on the preliminary task-dependent directed graph, complete the start and end vertices of the process, and correct conflicting edge constraint configurations to obtain the task-dependent directed graph model.

[0129] Each independent vertex in a directed graph is a mapping of a task to be executed within the graph, with each vertex corresponding to an independent task unit. A unique task identifier is a globally unique identifier used to identify task nodes and for vertex location and relationship binding. Examples include a global task ID and a node serial number. Execution type is an attribute label representing the logical category of task execution, used to distinguish different task execution modes. Examples include interface call classes, data calculation classes, message notification classes, and manual approval classes. Basic timing attributes describe the task triggering time, execution duration, and timeout threshold, supporting subsequent timing verification and scheduling. The initial task vertex set is the set of vertices after task-to-vertex mapping and basic attribute mounting; it is the initial vertex set for constructing the directed graph. Pre- and post-task dependencies are execution order constraints between tasks; a post-task can only start after the preceding task has been completed. Execution condition thresholds are business indicator thresholds that must be met to trigger task execution; tasks cannot be executed if the threshold is not met. Mutual exclusion control rules define the mutual exclusion relationships between tasks; tasks with mutual exclusion relationships cannot be executed simultaneously. The edge constraint rule set is a set of rules used to guide the construction of directed edges, after the business dependency rules and execution constraint configurations have been structurally transformed. A directed connection is a directional connection between vertices, used to characterize the execution order of tasks.

[0130] Business-level dependency edges are directed edges built upon business dependency rules, used to carry business-level dependency constraints. Mutual exclusion markers are attribute markers attached to directed edges, used to identify the mutual exclusion control relationship between corresponding vertices. Constraint attributes are attribute information attached to directed edges, used to describe the dependency type, condition threshold, control rules, and other constraint content corresponding to that edge. The preliminary task dependency directed graph is the initial directed graph after the basic edge construction and business constraint edge supplementation, and has not yet been verified or corrected. Vertex connectivity verification is a verification operation that checks whether all vertices in the directed graph are connected to the main process link and whether there are any isolated nodes. Edge constraint consistency verification is a verification operation that checks whether the constraint rules of all edges in the directed graph have logical conflicts and whether they match vertex attributes. Process start and end vertices are special vertices that mark the start and end of the process, used to clarify the boundaries of the process and the start and end points of execution.

[0131] In this example, when constructing the initial task vertex set, a full batch mapping approach can be used. All tasks to be executed and their corresponding orchestration templates are read at once. After aligning each task with the template node, they are batch-mapped into independent vertices of a directed graph. Simultaneously, a unique task identifier, execution type, and basic timing attributes are attached to each vertex, generating a complete initial task vertex set in one go, thus ensuring the consistency and integrity of vertex mapping. Alternatively, a streaming incremental mapping approach can be used. Tasks to be executed are received and template nodes are matched simultaneously. After each task's matching and mapping is completed, the corresponding attributes are simultaneously attached, accumulating to generate the initial task vertex set. This adapts to scenarios with streaming task access, shortening the overall processing wait time.

[0132] After obtaining the initial set of task vertices, the edge constraint rule generation process is initiated. The business dependency rules and execution constraint configurations in the business domain data are parsed, and the pre- and post-dependencies, execution condition thresholds, and mutual exclusion control rules between tasks are extracted. The unstructured business rules are converted into a standardized set of edge constraint rules that can be directly invoked, thereby providing a clear rule basis for the subsequent construction of directed edges and ensuring the accurate implementation of business constraints.

[0133] After generating the set of edge constraint rules, the directed edge construction and preliminary directed graph generation process is initiated. First, based on the inherent execution order of the process orchestration template, the basic directed connection relationships between the initial task vertices are determined, and the main links of the directed graph are built. Then, based on the set of edge constraint rules, business-level dependency edges are added between the corresponding vertices, mutual exclusion markers are attached to vertex pairs with mutual exclusion relationships, and corresponding constraint attributes are attached to all directed connection edges. Finally, a preliminary task dependency directed graph is generated, thereby integrating the template's main logic with dynamic business constraints and improving the business adaptability of the directed graph.

[0134] After obtaining the initial task-dependent directed graph, the verification, correction, and model generation process is initiated. First, vertex connectivity verification is performed to identify isolated dangling vertices and complete the access links. Then, edge constraint consistency verification is performed to identify and correct edge constraint configurations with logical conflicts. At the same time, standardized process start and end vertices are completed to clarify process boundaries. Finally, a structurally complete and logically self-consistent task-dependent directed graph model is generated to ensure the logical correctness of the directed graph and the availability of subsequent topology calculations.

[0135] For example, there are two ways to construct a task-dependent directed graph model. The first is a template-based, backbone-first, serial construction and verification. Before the construction process starts, a complete process orchestration template and business domain data are loaded. All tasks to be executed are mapped to vertices in batches to generate an initial set of task vertices. Then, a full set of edge constraint rules is generated. Subsequently, backbone directed connections are constructed serially based on the template execution order. Then, edge constraint rules are traversed one by one to supplement business-level dependency edges and mutual exclusion markers, generating a preliminary task-dependent directed graph. Finally, connectivity and constraint consistency checks are performed serially to complete the start and end vertices and correct conflicting constraints, outputting the final task-dependent directed graph model. This method uses a serial, progressive construction logic, with a clear process chain, controllable rule implementation, strong traceability of the construction process, and adaptability to typical business scenarios with stable process structures and moderate business rule complexity.

[0136] The second approach involves domain-specific parallel construction and global convergence verification. First, the set of tasks to be executed is divided into multiple task subsets according to business subdomains. An independent construction thread is assigned to each subdomain. Each thread performs parallel tasks to vertices, resolves edge constraint rules, and constructs directed edges in the subgraph, simultaneously generating multiple independent preliminary directed graphs for each subdomain. After all subdomain subgraphs are constructed, cross-subgraph dependency edge concatenation and global constraint alignment are performed, merging to generate a preliminary global task dependency directed graph. Subsequently, multi-dimensional parallel verification is initiated, simultaneously performing vertex connectivity verification, edge constraint consistency verification, and business rule compliance verification. Based on the verification results, the start and end vertices of the process are uniformly completed, and cross-domain conflicting edge constraint configurations are corrected, ultimately converging to generate a complete task dependency directed graph model. This method employs domain-specific parallel construction and global convergence verification processing logic. By splitting subdomains, it fully utilizes parallel computing power while ensuring the consistency of global constraints. In complex scenarios with multi-business domain collaboration and a large number of task nodes, it can improve the construction efficiency and business adaptation accuracy of directed graphs.

[0137] Furthermore, in the set of tasks to be executed in the bank's retail lending business, there are 5 tasks: personal credit inquiry, credit limit verification, electronic contract signing, core system loan disbursement accounting, and customer payment notification. When constructing the directed graph model, the 5 tasks to be executed are mapped to independent vertices of the directed graph based on the retail lending process arrangement template. Each vertex is attached with a unique task identifier (LOAN-TASK-001 to LOAN-TASK-005), execution type (interface call class, data verification class, interaction trigger class, accounting processing class, message push class) and basic timing attributes (single task timeout thresholds are 30s, 10s, 300s, 20s, and 15s respectively), resulting in an initial task vertex set containing 5 vertices. Further analysis of the business dependency rules and execution constraint configurations in the credit business domain data reveals pre- and post-dependent relationships between tasks, execution condition thresholds, and mutual exclusion control rules. This generates a set of eight structured edge constraint rules, comprising five dependency rules, two threshold rules, and one mutual exclusion rule. These rules clarify constraint logic such as "loan disbursement and accounting require simultaneous verification of credit history and credit limit," "credit score ≥ 650 is required to proceed to credit limit verification," and "the existence of current overdue records will block loan disbursement." Subsequently, based on the standard execution order of the process orchestration template, four main directed connections are determined between the five initial task vertices. These connections are then supplemented with two business-level strong dependency edges and one mutual exclusion marker edge. Each directed connection edge is then assigned a corresponding constraint type, threshold parameter, and effective condition attribute, resulting in a preliminary task dependency directed graph containing five vertices and seven directed edges. Finally, vertex connectivity and edge constraint consistency checks were performed on the initial directed graph. The process start and end vertices were completed and unified. One redundant dependency edge was found and merged and corrected. The constraint attributes of two edges were adjusted to eliminate logical conflicts. Finally, a logically consistent directed graph model of retail credit lending task dependency was obtained, which contains 7 vertices, 8 directed edges with complete constraint attributes, and is logically consistent.

[0138] Seventh Embodiment This embodiment provides an exemplary scheme for isolated script execution and security protection to generate business tracking data. In this example, the isolated execution environment is first initialized based on the dynamically executed script and action parameters in the executable action instruction sequence. Whitelist class loading rules and bytecode enhancement verification logic are loaded to complete the security boundary configuration. Then, the dynamically executed script is loaded into the isolation sandbox. After high-risk syntax and prohibited calls are intercepted by syntax tree scanning, and restricted resources are loaded by the whitelist class loader, an executable script instance is generated. Subsequently, the script is driven to run according to the parameters. Resource usage and interface call behavior are detected through a sliding window anomaly detection mechanism, and an execution log is generated. Finally, event tracing identifiers and process link markers are attached to the execution log to generate complete business tracking data. Step S40 includes steps F11~F14: Step F11: Based on the dynamic execution script and action parameters in the executable action instruction sequence, initialize the isolated runtime environment, load the whitelist class loading rules and bytecode enhancement verification logic, and obtain the isolated runtime sandbox with the security boundary configured.

[0139] Step F12: Load the dynamically executed script into the isolated execution sandbox, intercept high-risk syntax and prohibited system calls in the script through syntax tree parsing and scanning, and load restricted class resources through the whitelist class loader to generate an executable script instance.

[0140] Step F13: Run the runnable script instance according to the action parameters, detect resource usage indicators and interface call behavior, and identify abnormal running states through the sliding window anomaly detection mechanism to obtain the running log.

[0141] Step F14: Attach the event tracing identifier and process link marker to the running log to generate the business tracking data.

[0142] Dynamically executed scripts are runnable code snippets that carry specific business execution logic and are the core execution entity of the isolated sandbox. Examples include API call scripts, data calculation scripts, message push scripts, and accounting scripts. Action parameters are the input parameters and configuration items that drive script execution, used to control the script's execution logic and business processing objects. Examples include business entity identifiers, API call addresses, data processing scope, and execution timeout thresholds. The isolated runtime environment is an independent running space isolated from the host system resources and with restricted permissions, used to prevent script risks from spreading to the host system. Whitelist class loading rules are preset permission rules that only allow scripts to load specified class resources, used to constrain the resource access scope of scripts. Examples include whitelists of allowed business utility classes, data processing classes, and message sending classes.

[0143] Bytecode enhancement verification logic is runtime verification logic implemented based on bytecode enhancement technology, used to intercept illegal operations and unauthorized calls. Security boundary configuration restricts permissions, resources, and call scope within the isolated environment, defining the security boundaries of script execution. An isolated execution sandbox is an isolated execution instance that can be directly loaded and executed after security boundary configuration. Syntax tree parsing and scanning is a scanning and verification method that parses the script into an abstract syntax tree and then traverses it to identify high-risk syntax nodes. High-risk syntax refers to syntax structures that may pose security risks, such as reflection calls, dynamic class loading, and system command execution syntax. Prohibited system calls are prohibited low-level system interface calls, such as file system read / write calls, process control calls, and network port detection calls. A whitelisted class loader is a class loading component that follows whitelisted class loading rules, allowing scripts to load only class resources within the whitelist.

[0144] Restricted resources are those within a whitelist that are allowed for script access; resources outside this whitelist will be blocked. Runnable script instances are script instances that have completed security checks and resource loading and can be started and executed normally. Resource usage metrics are quantitative indicators of system resources used during script execution, such as CPU utilization, memory usage, number of threads, and number of handles. Interface call behavior refers to external interface calls initiated during script execution, including call address, call frequency, and call parameters. The sliding window anomaly detection mechanism is a detection mechanism based on a fixed time window that scrolls and statistically analyzes running metrics to identify abnormal fluctuations, used to detect abnormal running states in real time. Abnormal running states are abnormal operating states that occur during script execution, such as resource overruns, unauthorized calls, and logical anomalies. Examples include CPU overruns, memory overflow, unauthorized call triggering, and execution infinite loops. Running logs are log data that records the entire lifecycle of the script, including execution process, resource status, call behavior, and anomaly information. Event tracing identifiers are unique identifiers used to locate the original business event and trace the source of the business event. Process link markers are link identifiers used to mark the process instance and nodes to which the current execution belongs, used to connect the entire process execution trajectory.

[0145] In this example, when initializing the isolated runtime sandbox, a full rule preloading approach can be used. First, the script type and execution parameters in the executable action instruction sequence are parsed, and all whitelist-based loading rules and bytecode enhancement verification logic are loaded at once. This completes the full configuration of resource quotas, permission scopes, and call boundaries for the sandbox environment, generating an isolated runtime sandbox with complete security boundaries, thus ensuring the integrity and execution stability of the sandbox security rules. Alternatively, a dynamic on-demand loading approach can be used. First, the basic isolated runtime environment is initialized, and then, based on the business type and resource requirements of the dynamically executed scripts, matching whitelist rules and verification logic are loaded on demand, gradually completing the security boundary configuration. This reduces the overhead of loading invalid rules and improves the sandbox initialization efficiency.

[0146] After the isolated execution sandbox is initialized, the script loading and security verification process is initiated. After the dynamically executed script is loaded into the sandbox, the entire script code is first scanned through syntax tree parsing to identify and block high-risk syntax and prohibited system calls. Then, the script's resource loading requests are verified through a whitelist class loader, and only restricted class resources within the whitelist are loaded. After the verification is passed, an executable script instance is generated. In this way, script risks are intercepted through a double-layer pre-verification to ensure operational security.

[0147] After generating a runnable script instance, the script execution and real-time detection process is initiated. The runnable script instance is driven to execute business logic according to the action parameters. During the execution, the script's resource usage indicators and interface call behavior data are collected in real time. The average value and fluctuation characteristics of the indicators in the sliding window are scrolled through the anomaly detection mechanism to identify abnormal running states such as resource overruns and abnormal calls. The entire running process data is recorded synchronously to generate a running log, thereby achieving real-time security control and full behavior traceability during the running process.

[0148] After obtaining the operation logs, the tracking data assembly process is initiated, attaching the corresponding event traceability identifiers and process link markers to the operation logs, associating the original business events with the current process node information, binding the log data with the business links, and finally generating structured and traceable business tracking data to support full-link business tracking and problem tracing and troubleshooting.

[0149] For example, there are two ways to implement isolated script execution and security protection. The first is a static whitelist-driven serial security protection. Before the execution process starts, the isolated execution sandbox is initialized based on the executable action instruction sequence. The preset static whitelist class loading rules and bytecode enhancement verification logic are fully loaded to complete the fixed security boundary configuration. Then, the dynamically executed script is loaded into the sandbox, and the syntax tree high-risk scan and whitelist class resource loading are executed serially. After the verification is passed, an executable script instance is generated. During the execution of the script, a sliding window anomaly detection mechanism with a fixed window size is used to collect resource usage and interface call data at a fixed frequency. Anomaly identification and logging are executed serially. After the script execution is completed, source tracing and link marking are attached to generate business tracking data. This method uses static rules and serial processing protection logic, with clear and stable security boundaries and controllable verification logic, and is suitable for general business scenarios with fixed script logic and high security requirements.

[0150] The second approach is adaptive security protection based on dynamic behavior analysis. First, a basic isolated execution sandbox is initialized, loading basic whitelist rules and bytecode verification logic. The dynamically executed script is then loaded into the sandbox, and basic verification is completed to generate an initial runnable script instance. During script execution, a multi-dimensional sliding window anomaly detection mechanism is employed, simultaneously collecting three types of runtime data: resource usage, API calls, and behavioral patterns. Based on a pre-built security rule base, the script's risk level is dynamically assessed, adaptively adjusting the script's permission scope and resource quotas. Upon identifying high-risk behavior, a circuit breaker is immediately triggered, isolating the runtime context. Simultaneously, the entire runtime process and anomaly handling information are fully recorded to generate a runtime log. After script execution, multi-dimensional event tracing identifiers and full-link node markers are attached, generating business tracking data containing a complete behavioral profile and handling records. This method, employing dynamic behavior analysis and adaptive protection processing logic, can adapt to dynamic script scenarios with complex logic and variable behavior. It improves the running efficiency of legitimate scripts while ensuring a minimum level of security, and is suitable for dynamic script execution scenarios with complex business logic.

[0151] Further, please refer to Figure 7 , Figure 7 This is a diagram of the hybrid rendering architecture of this application. A visual orchestration hybrid rendering processing flow based on the X6 Graph Model is presented. The X6 Graph Model serves as the data source, internally maintaining five types of data: nodes, edges, viewports, styles, and events. Data is input to the event aggregation and change detection module, which outputs to the change marking (node / edge / viewport / style) module. Change marking is performed on nodes, edges, viewports, and styles. The data then flows to the layout calculation module for topology layout calculation. The calculation result is sent to the rendering scheduler, which performs visual culling combined with Level of Detail (LOD). The rendering process involves several steps. If the result is "invisible," rendering is skipped. If the result is "visible," the rendering enters the layered pipeline and is sent to the layered rendering processing module. Within this module, the rendering pipelines schedule parallel rendering of the WebGL layer (node ​​rendering), Canvas2D layer (edge / viewport / special effects rendering), and HTML / DOM layer (interaction / overlay / input). The outputs from these three layers are then sent to the compositing module to complete the image composition. After compositing, the output enters the interaction detection module to capture user interactions. The interaction detection module then dispatches the interaction events back to the X6 module, which in turn sends the events back to the event aggregation and change detection module, forming a complete closed loop. This visual orchestration engine uses hybrid rendering: WebGL renders visible area nodes, while Canvas lightweightly draws non-interactive nodes, reducing memory usage by 50%. It also uses the DAGRE algorithm to automatically calculate the topological order, marking circular dependencies and unconnected ports, reducing the logical conflict rate by 90%.

[0152] Eighth embodiment This embodiment provides an exemplary solution for handling script execution anomalies via circuit breaking and for closed-loop updating of the business tracking link. In this example, a sliding window anomaly detection mechanism is first used to identify abnormal script execution states, triggering a circuit breaker command to terminate the abnormal script execution and isolate the corresponding execution context and resource allocation space, preventing the anomaly from propagating to the host system. Then, execution stack data, resource execution snapshots, and call behavior records of the abnormal script are collected, and associated event identifiers and process instance identifiers are matched to generate a structured anomaly scenario dataset. Subsequently, risk assessment and anomaly classification are performed on the anomaly scenario dataset based on a pre-built security rule base, distinguishing between three attributes: resource overrun, unauthorized calls, and logical anomalies, and matching corresponding handling strategies. Finally, the sandbox whitelist rules and sliding window circuit breaker parameters are updated according to the handling strategy, and the anomaly details and handling results are attached to the corresponding business process tracking link to obtain business tracking data containing complete anomaly handling information. Please refer to... Figure 8 , Figure 8 This is a flowchart illustrating the eighth embodiment of the tracking method for business collaboration in this application. Following step F13, steps G11-G14 are also included: Step G11: When the sliding window anomaly detection mechanism identifies the abnormal running state, it triggers a circuit breaker instruction to terminate the execution of the abnormal script, isolates the running context and resource allocation space corresponding to the abnormal script, and blocks the spread of the anomaly to the host system.

[0153] Step G12: Match and associate the execution stack data, resource running snapshots, and call behavior records of the abnormal script with the corresponding event identifiers and process instance identifiers to generate an abnormal scene dataset.

[0154] Step G13: Based on the pre-set security rule base, perform risk assessment and anomaly classification on the abnormal scene dataset, distinguish the abnormal attributes of resource overrun, unauthorized calls and logical anomalies, and match the corresponding level of handling strategy.

[0155] Step G14: Update the sandbox whitelist rules and sliding window circuit breaker parameters according to the handling strategy, and attach the exception details and handling results to the corresponding business process tracking link to obtain the business tracking data.

[0156] Circuit breakers are control instructions used to forcibly terminate script execution and trigger security isolation operations; they are the core execution instructions for exception handling. An exception script is a dynamically executed script instance that triggers an abnormal running state; it is the object of exception handling and risk isolation. The runtime context is a collection of the exception script's runtime environment state, variable data, and execution stack information; it is the core data for reconstructing the exception situation. Resource allocation space is the system resource quota space allocated to the exception script, including memory space, CPU time slices, and network resource quotas. The host system is the underlying business system that hosts the isolated runtime sandbox; it is the object of exception propagation prevention. Execution stack data is the call stack, execution thread state, and variable snapshot data at the moment the exception script triggers the exception; it is used to locate the code location and logical path that triggered the exception. Resource runtime snapshots are panoramic snapshot data of the script's resource usage at the moment the exception is triggered, including core resource indicators such as CPU utilization, memory usage, handle count, and thread count.

[0157] The call behavior log records the behavioral trajectory of all interface calls, system accesses, and resource operations throughout the entire lifecycle of the abnormal script. The event identifier is a unique identifier for the original business event associated with the abnormal script, used to trace the business trigger source of the abnormality. The process instance identifier is a unique identifier for the business process instance associated with the abnormal script, used to locate the node position of the abnormality in the business chain. The abnormal scenario dataset is a structured abnormal dataset formed by integrating abnormal execution data and business association identifiers; it is the foundational data for risk rating and abnormal analysis. The pre-configured security rule base is a pre-configured set of security rules containing risk judgment standards, abnormal classification rules, and mapping relationships with handling strategies; it serves as the rule basis for abnormal analysis and handling. Risk rating is a risk level divided according to the scope, severity, and potential for spread of the abnormality. For example, there are four risk levels: low risk, medium risk, high risk, and high risk. Abnormal classification is an abnormal category divided according to the triggering cause and manifestation of the abnormality. Resource overrun is an abnormal type caused by the script's use of system resources exceeding a preset quota threshold.

[0158] Unauthorized calls are exceptions caused by scripts executing prohibited system calls or API accesses outside the whitelist. Logical exceptions are runtime exceptions caused by errors in the script's execution logic, infinite loops, or data anomalies. Handling strategies are pre-defined execution plans for different risk levels and exception categories, including rule updates, parameter adjustments, and link marking. Sandbox whitelist rules are whitelist configuration rules within the isolated sandbox that control the loading of script-related resources and API call permissions. Sliding window circuit breaker parameters are configuration parameters for the sliding window exception detection mechanism, including thresholds, window size, and trigger sensitivity. The business process tracking link is a tracking link that connects the execution status and trajectory of each node in the entire business process, used to carry all business data across the entire link.

[0159] In this example, upon identifying an abnormal operational state and implementing circuit breaker isolation, an immediate forced circuit breaker can be used. Once the sliding window anomaly detection mechanism determines that the anomaly trigger threshold has been reached, a circuit breaker command is issued to forcibly terminate the execution thread of the abnormal script. Simultaneously, the execution context data and dedicated resource allocation space corresponding to the script are frozen and isolated, cutting off all resource interaction channels between the script and the host system. This prevents the abnormal state from spreading to the host system as soon as possible. Alternatively, a tiered, progressive circuit breaker approach can be used. First, a level-one rate-limiting circuit breaker is triggered to restrict the script's resource quota and calling permissions. It is observed whether the abnormal state converges. If the anomaly continues to escalate, a level-two forced circuit breaker is triggered to terminate the script's execution and completely isolate the context and resources. This approach aims to block risks while minimizing the impact on normal business execution.

[0160] After completing the circuit breaker isolation of the abnormal script, the abnormal scene data collection process is initiated to extract the execution stack data, full resource operation snapshot, and call behavior records of the entire operation cycle at the moment when the abnormal script triggers the circuit breaker. The three types of abnormal data are bound and associated with the corresponding event identifiers and process instance identifiers, and integrated into a complete abnormal scene dataset according to the structured data specifications. This preserves complete abnormal scene information and provides data support for subsequent risk analysis and problem localization.

[0161] After generating the abnormal scene dataset, the risk assessment and anomaly classification process is initiated. The abnormal scene dataset is input into the pre-set security rule base, and the corresponding risk judgment rules and classification standards are matched. First, the risk level is assessed based on the scope and severity of the anomaly's impact. Then, based on the cause of the anomaly, three types of anomaly attributes are distinguished: resource overrun, unauthorized calls, and logical anomalies. Finally, the corresponding risk level and anomaly category are matched with the handling strategy for this anomaly, thereby achieving accurate hierarchical classification and handling of anomalies and avoiding over- or under-handling.

[0162] After obtaining the corresponding handling strategy, the rule update and link mounting process is initiated. On the one hand, the sandbox whitelist rules are dynamically updated according to the requirements of the handling strategy, and prohibited call interception entries are added. The detection threshold, window size, and other circuit breaker parameters of the sliding window are adjusted simultaneously to optimize the sensitivity and accuracy of subsequent anomaly detection. On the other hand, the detailed information, handling actions, and handling results of this anomaly are fully mounted to the corresponding business process tracking link and merged with the original operation log data to finally obtain business tracking data containing complete anomaly handling information. This achieves closed-loop optimization of security rules and full traceability of the business link.

[0163] For example, there are two implementation methods for script execution exception handling and tracking data updates. The first is a fixed rule-driven serial exception handling. After detecting an abnormal execution state, a fixed circuit breaker instruction is triggered to terminate the abnormal script execution, fully isolating the execution context and resource allocation space. Subsequently, execution stack data, resource execution snapshots, and call behavior records are collected serially, and events and process identifiers are associated to generate an exception scene dataset. Then, based on fixed judgment rules of a pre-set security rule base, risk rating and exception classification are executed serially, matching corresponding preset handling strategies. Finally, sandbox whitelist rules and sliding window circuit breaker parameters are updated serially according to the strategy, and exception details and handling results are appended to the business process tracking link to generate final business tracking data. This method adopts a fixed rule and serial handling processing logic, with a stable handling process standard, strong rule execution consistency, and adaptability to regular business script execution scenarios with clear exception scenarios and fixed security rules.

[0164] The second approach is adaptive anomaly handling based on dynamic risk assessment. When an anomaly is detected by the sliding window, the risk of its spread and its impact on business are dynamically assessed based on real-time operational data. Based on the assessment results, circuit breaker isolation operations of corresponding strength are triggered. Low-risk anomalies are isolated by resource rate limiting, while high-risk anomalies are isolated by full context isolation. Subsequently, multi-dimensional anomaly data is collected in parallel, and intelligent risk grading and anomaly classification are performed by combining historical anomaly samples with real-time business scenarios, dynamically generating customized handling strategies adapted to the current anomaly. Finally, the sandbox whitelist's interception granularity and the sliding window's circuit breaker sensitivity parameters are adaptively updated according to the handling strategy. Simultaneously, the entire lifecycle data of the anomaly and the assessment results of the handling effect are fully integrated into the business process tracking link, generating business tracking data containing risk profiles and optimization records. This method employs dynamic risk assessment and adaptive handling logic, matching differentiated handling strengths according to the actual risk level of the anomaly. It ensures system security while reducing the impact on normal business operations, and simultaneously achieves closed-loop iterative optimization of security rules, adapting to dynamic business operation scenarios with complex script logic and diverse anomaly scenarios.

[0165] Furthermore, in the dynamic accounting script for corporate payroll processing, when the sliding window anomaly detection mechanism detects for three consecutive windows (5-second window granularities) that the script's CPU usage is consistently above 85% and there are two prohibited local file write calls, a circuit breaker is triggered to forcibly terminate the execution thread of the abnormal accounting script. This isolates the script's execution context data from its allocated two CPU cores and 200MB of dedicated memory resources, cutting off all interaction channels with the host core accounting system to prevent the anomaly from spreading. Subsequently, the execution stack data at the moment the circuit breaker is triggered, a resource snapshot showing 92% CPU usage and 186MB of memory usage, and a full record of all call behaviors including 12 business interface calls and 2 prohibited file operations are collected. These are matched and associated with the corresponding payroll business event identifier BIZ-PAY-20250812001 and process instance identifier FLOW-PAY-0076 to generate a structured abnormal scenario dataset. Next, based on the bank's pre-built security rule base, risk assessment and anomaly classification were performed on the abnormal dataset. It was rated as high-risk, indicating that it simultaneously possessed the dual anomaly attributes of resource overrun and unauthorized access. The corresponding high-risk level was matched with the "tightening of permissions and stricter thresholds" handling strategy. Finally, the sandbox whitelist rules were updated according to the handling strategy, adding 3 interception rules for local file system operations. Simultaneously, the sliding window circuit breaker detection granularity was adjusted from 5 seconds to 3 seconds, and the consecutive hit threshold was lowered from 3 times to 2 times. The triggering cause, handling actions, and final result of this anomaly were completely attached to the process tracking link of the payroll business, generating full-link business tracking data with anomaly handling tags.

[0166] This application provides a service coordination serialization device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the service coordination serialization tracking method in Embodiment 1 above.

[0167] The following is for reference. Figure 9 The diagram illustrates a structural schematic suitable for implementing the service collaboration serialization device in the embodiments of this application. The service collaboration serialization device in the embodiments of this application may include, but is not limited to, mobile terminals such as serial programmable logic controllers, industrial computers, industrial gateways, photoelectric sensors, etc., and fixed terminals such as event engine layers, orchestration engine layers, execution engine layers, etc. Figure 9 The business collaboration and serialization device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0168] like Figure 9As shown, the service coordination serialization device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the service coordination serialization device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the service co-operation serial device to communicate wirelessly or wiredly with other devices to exchange data. Although service co-operation serial devices with various systems are shown in the figure, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented alternatively.

[0169] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0170] The service coordination serialization device provided in this application, employing the service coordination serialization tracking method described in the above embodiments, can solve the technical problem of low resource utilization efficiency. Compared with the prior art, the beneficial effects of the service coordination serialization device provided in this application are the same as those of the service coordination serialization tracking method described in the above embodiments, and other technical features of this service coordination serialization device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0171] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0172] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0173] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the service coordination serialization tracking method in the above embodiments.

[0174] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0175] The aforementioned computer-readable storage medium may be included in the business coordination serial device; or it may exist independently and not be assembled into the business coordination serial device.

[0176] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the business collaboration and concatenation device, the business collaboration and concatenation device: based on heterogeneous business events, determines the event rules and business parameters corresponding to the heterogeneous business events through a single-pass scanning multi-mode matching mechanism to obtain the target event data of the heterogeneous business events; maps the target event data to business process instances corresponding to the heterogeneous business events, hierarchically manages the task scheduling sequence, and obtains a set of tasks to be executed; performs topological logic verification on the set of tasks to be executed according to the process orchestration template and business domain data to obtain an executable action instruction sequence; and distributes the executable action instruction sequence to an isolated operating environment for execution, and constrains the script execution boundary through a security defense mechanism to obtain the business tracking data of the heterogeneous business events.

[0177] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0178] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0179] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0180] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described service coordination and cascading tracking method, thereby solving the technical problem of low resource utilization efficiency. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the service coordination and cascading tracking method provided in the above embodiments, and will not be repeated here.

[0181] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A tracking method for business collaboration, characterized in that, The method includes: Based on heterogeneous business events, the event rules and business parameters corresponding to the heterogeneous business events are determined by a single-pass scanning multi-mode matching mechanism to obtain the target event data of the heterogeneous business events. The target event data is mapped to the business process instance corresponding to the heterogeneous business event, and the task scheduling sequence is managed hierarchically to obtain a set of tasks to be executed. Based on the process orchestration template and business domain data, the set of tasks to be executed is subjected to topological logic verification to obtain an executable action instruction sequence. The executable action instruction sequence is sent to an isolated runtime environment for execution, and the script execution boundary is constrained by a security defense mechanism to obtain the business tracking data of the heterogeneous business events.

2. The tracking method for business collaboration as described in claim 1, characterized in that, The step of determining the event rules and business parameters corresponding to the heterogeneous business events based on heterogeneous business events through a single-pass scanning multi-modal matching mechanism, and obtaining the target event data of the heterogeneous business events, includes: Perform abnormal data filtering, format unification conversion, and standard field mapping on heterogeneous business events accessed from multiple channels to generate event text sequences with field structures consistent with coding standards; The event text sequence is input into the prefix tree finite state machine of the embedded parameter extraction node, and a single sequential scan is performed to determine the event rule and the corresponding business parameter of the event text sequence. Based on the event rules and corresponding business parameters matched in the event text sequence, rule validity and parameter format are validated to generate a set of valid matching pairs. The effective matching set is classified, tagged, and traceable to obtain the target event data of the heterogeneous business events.

3. The tracking method for business collaboration as described in claim 2, characterized in that, The step of inputting the event text sequence into the prefix tree finite state machine of the embedded parameter extraction node, performing a single-pass sequential scan, and determining the event rule and corresponding business parameter of the event text sequence includes: Based on the prefix tree rule set of the extracted nodes according to the embedded parameters, the current state pointer of the finite state machine is reset to the root node, and the parameter capture buffer and the hit rule storage structure are initialized. The event text sequence is traversed character by character, and the corresponding node in the prefix tree is matched according to the current character and the status pointer is updated. When the state pointer jumps to the parameter extraction node in the prefix tree, the field content at the corresponding position in the event text sequence is extracted and written to the parameter capture buffer according to the field format and length constraints of the parameter extraction node. When the status pointer jumps to the rule termination node, the currently matched event rule is marked, and the field content in the parameter capture buffer is bound and mapped to the parameter slot of the event rule to generate a single set of rule parameter matching results; The matching results of the rule parameters are summarized, and rule priority deduplication and parameter integrity verification are performed to determine the event rules and corresponding business parameters that the event text sequence matches.

4. The tracking method for business collaboration as described in claim 1, characterized in that, The step of mapping the target event data to business process instances corresponding to the heterogeneous business events, hierarchically managing task scheduling timing, and obtaining a set of tasks to be executed includes: Based on the business process template associated with the target event data, generate a business process instance corresponding to the target event data; The business process instance is decomposed into a set of initial task nodes with trigger timing, priority, and dependency identifiers; The initial set of task nodes is input into a counting-type probability filtering structure that supports dynamic counting increments and decrements. Duplicate tasks, expired tasks, and invalid scheduled tasks are filtered out through counting verification to obtain a valid set of tasks. Based on the trigger time granularity of each task, the tasks in the effective task set are distributed to the corresponding level slots of the multi-granularity hierarchical time wheel for storage, resulting in slot-based tasks, so as to realize multi-level time sequence hierarchical control. As the time wheel pointer advances slot by slot, the tasks in the current slot are verified, and the set of tasks to be executed is obtained.

5. The tracking method for business collaboration as described in claim 1, characterized in that, The step of performing topological logic verification on the set of tasks to be executed based on the process orchestration template and business domain data to obtain an executable action instruction sequence includes: Based on the set of tasks to be executed, invalid data query requests are intercepted in advance by a counting probability index, and the corresponding process orchestration template and business domain data are retrieved from the multi-level hierarchical cache. The set of tasks to be executed is mapped to vertices of a directed graph according to the process arrangement template. Directed connection edges between vertices are constructed by combining the business dependency rules and execution constraint configurations in the business domain data, thereby generating a task dependency directed graph model. The task-dependent directed graph is subjected to topological sorting calculation, and circular dependencies, dangling nodes and logical conflicts that violate business constraints are detected and marked, and an ordered sequence of topological nodes is obtained by filtering. The ordered sequence of topological nodes is associated and mapped one by one with the action execution parameters, service identifiers and adaptation information in the business domain data, and then arranged according to the topological dependency order to obtain the sequence of executable action instructions.

6. The tracking method for business collaboration as described in claim 5, characterized in that, The steps of mapping the set of tasks to be executed to vertices of a directed graph according to the process arrangement template, and constructing directed connection edges between vertices by combining the business dependency rules and execution constraint configurations in the business domain data to generate a task dependency directed graph model include: Based on the set of tasks to be executed and the corresponding process orchestration template, the set of tasks to be executed is mapped to independent vertices of a directed graph, and a unique task identifier, execution type and basic timing attribute are attached to each independent vertex to obtain an initial set of task vertices; Based on the business dependency rules and execution constraint configurations in the business domain data, and combined with the pre- and post-dependencies between tasks, execution condition thresholds, and mutual exclusion control rules, a set of edge constraint rules is generated. Based on the execution order of the process orchestration template, the directed connection relationship between the initial task vertices is determined. The business-level dependency edges and mutual exclusion markers are supplemented by the edge constraint rule set, and the corresponding constraint attributes are attached to the directed connection edges to obtain the preliminary task dependency directed graph. Vertex connectivity and edge constraint consistency are checked on the initial task-dependent directed graph. The start and end vertices of the process are completed, and conflicting edge constraint configurations are corrected to obtain the task-dependent directed graph model.

7. The tracking method for business collaboration as described in claim 1, characterized in that, The steps of sending the executable action instruction sequence to an isolated runtime environment for execution and constraining the script execution boundaries through a security defense mechanism to obtain the business tracking data of the heterogeneous business events include: Based on the dynamic execution script and action parameters in the executable action instruction sequence, the isolated running environment is initialized, and the whitelist class loading rules and bytecode enhancement verification logic are loaded to obtain an isolated running sandbox with security boundary configuration completed. The dynamically executed script is loaded into the isolated execution sandbox. High-risk syntax and prohibited system calls in the script are intercepted by syntax tree parsing and scanning. Restricted class resources are loaded by a whitelist class loader to generate an executable script instance. The executable script instance is run according to the action parameters, resource usage indicators and interface call behavior are detected, and abnormal running states are identified through the sliding window anomaly detection mechanism to obtain running logs; The operation log is loaded with event tracing identifiers and process link markers to generate the business tracking data.

8. The tracking method for business collaboration as described in claim 7, characterized in that, After the steps of running the runnable script instance according to the action parameters, detecting resource usage indicators and interface call behavior, identifying abnormal running states through a sliding window anomaly detection mechanism, and obtaining running logs, the business collaboration linkage tracking method further includes: When the sliding window anomaly detection mechanism identifies the abnormal running state, it triggers a circuit breaker instruction to terminate the execution of the abnormal script, isolates the running context and resource allocation space corresponding to the abnormal script, and blocks the spread of the anomaly to the host system. The execution stack data, resource runtime snapshots, and call behavior records of the abnormal script are matched and associated with corresponding event identifiers and process instance identifiers to generate an abnormal scene dataset. Based on a pre-built security rule base, the abnormal scene dataset is risk-leveled and classified into anomalies, distinguishing between the abnormal attributes of resource overruns, unauthorized calls, and logical anomalies, and matching the corresponding level of handling strategies. Update the sandbox whitelist rules and sliding window circuit breaker parameters according to the handling strategy, and attach the exception details and handling results to the corresponding business process tracking link to obtain the business tracking data.

9. A business collaboration serial device, characterized in that, The service coordination serialization device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the service coordination serialization tracking method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the tracking method for business coordination and serialization as described in any one of claims 1 to 8.

Images