Process management method, device and storage medium based on process template

Abstract

This application belongs to the field of data processing technology, specifically relating to a process management method, electronic device, and storage medium based on a process template. The method includes: creating a process template, which is a multi-dimensional contract set with execution semantics; compiling the process template, and during the compilation phase, parsing the dependencies between contracts in the multi-dimensional contract set to generate an execution topology sequence; creating a process instance based on the process template, and in response to user requests or preset events for the process instance, executing each contract of the process instance according to the execution topology sequence. This method, by employing a two-stage mechanism of "preprocessing during compilation" + "ordered execution during runtime" for the multi-dimensional contract set, achieves controllable orchestration of cross-contract dependencies, ensuring that contract changes primarily modify configurations rather than core logic, thereby shortening the iteration cycle and reducing release risks.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, specifically relating to a process management method, electronic device and storage medium based on process template. Background Technology

[0002] In enterprise-level business process management, process templates are typically used to define the attributes, state transition rules, and permission policies of business objects. Existing process templates are essentially just collections of static configurations—simple combinations of field definitions and flowcharts. The various configuration dimensions (such as attribute definitions, state linkage rules, notification rules, to-do rules, and permission policies) are independent of each other and lack inherent semantic relationships in execution. This architecture presents the following technical problems in actual operation: First, the field system and business rules are rigid, leading to high change costs. In existing process management systems, the definition of form fields, validation rules, and data source bindings are typically fixed in the system code or configuration files. When business needs change (e.g., adding fields, adjusting validation rules, or modifying the data source of dropdown options), software developers often need to intervene, modifying, testing, and redeploying the underlying code. This process is not only costly to maintain but also has a long response time, making adjustments to business processes lack the necessary flexibility and agility.

[0003] Second, maintaining consistent status across different levels is difficult. In complex project management scenarios, there are often multi-level task structures such as parent-child tasks and related tasks. Existing systems typically require users to manually maintain consistency across task levels; for example, once all subtasks are completed, the parent task needs to be manually marked as "completed" by the user. This reliance on manual maintenance easily leads to inconsistencies in status data, causing management distortion and statistical bias.

[0004] Third, the "query first, filter later" access control model poses a risk of data leakage. Existing process management systems typically execute access control after data querying—the system first retrieves all data from the database, then filters the results based on user roles and permissions, masking invisible fields or rows. This means that sensitive data already exists in system memory after querying but before filtering, posing a risk of unauthorized access or leakage, especially in areas such as log recording and cache storage.

[0005] Fourth, the notifications remain at the level of reminders, lacking accountability and closed-loop tracking. Existing systems typically only send reminders to relevant personnel via email or in-system messages, and the process ends once the notification is sent. The system cannot confirm whether the recipient has viewed the notification, accepted the corresponding responsibility, or completed the task; it lacks a complete closed loop from "notification" to "acceptance" to "completion."

[0006] Therefore, there is an urgent need for a technical solution that can upgrade process templates from static configuration to contract structures with verifiable execution semantics, and establish a complete mechanism from verification in the compilation stage to orderly execution in the runtime stage, in order to solve all or part of the problems existing in the above-mentioned prior art. Summary of the Invention

[0007] This application provides a process management method, electronic device, and storage medium based on a process template, aiming to solve the problems of existing process templates being merely static configuration sets lacking verifiable execution semantics, lacking execution timing guarantees between configuration dimensions, having high data access security risks, and having poor stability of state-linked execution.

[0008] In a first aspect, embodiments of this application provide a process management method based on a process template, the method comprising: Create a process template, which is a multi-dimensional contract set with execution semantics. The multi-dimensional contract set includes at least an attribute contract, a state contract, and a permission contract. The attribute contract is used to define multiple fields with a preset metadata structure, the state contract is used to define state linkage rules, and the permission contract is used to define data access strategies. The process template is compiled, and the dependencies between contracts in the multidimensional contract set are parsed during the compilation phase to generate an execution topology sequence; Based on the process template, a process instance is created. In response to a user request or preset event for the process instance, each contract of the process instance is executed according to the execution topology sequence. When executing the permission contract, query constraints and operation constraints are determined based on the data access strategy, and the query constraints are injected into the data access layer to generate a low-level data query statement to obtain restricted data. When executing the state contract, state linkage operations are executed based on the rule-directed graph constructed by the state linkage rules.

[0009] Optionally, the step of determining query constraints based on the data access strategy and injecting the query constraints into the data access layer to generate a low-level data query statement to obtain restricted data includes: Based on the data access strategy, reverse derivation is performed to generate a field projection list and row-level predicate conditions as query constraints. When constructing the underlying data query statement, the field projection list is concatenated to the selection column of the underlying data query statement, and the row-level predicate condition is concatenated to the filter condition of the underlying data query statement.

[0010] Optionally, the data access policy carries a version number, which is updated as the process template is updated. The method further includes: The parsing results of the data access strategy are cached on the server side; In response to the update of the process template, the parsing result cached on the server is invalidated, so as to dynamically apply the updated data access strategy.

[0011] Optionally, the method further includes: During the compilation phase, the following static loop detection is performed on the directed graph of the rules: Identify strongly connected components in the directed graph according to the rules; When the node size of the strongly connected component is greater than 1 or a self-loop exists, it is determined that a loop exists in the directed graph of the rules. Based on the traversal stack backtracking output, the loop path of the loop is characterized, and the process template containing the loop is rejected.

[0012] Optionally, the execution of state linkage operations based on the rule-directed graph constructed according to the state linkage rules includes: A reachable subgraph is determined in the directed graph of the rules, starting from the changed node, using a graph traversal algorithm. Perform topological sorting on the reachable subgraph to generate incremental execution paths; The condition judgment and target value writing of each state linkage rule are executed sequentially according to the incremental execution path.

[0013] Optionally, the method further includes: When executing the state contract, a multidimensional idempotent key is constructed, which includes a process instance identifier, a target field identifier, and a target value; Maintain the set of idempotent keys within a predefined sliding window; When the multidimensional idempotent key matches the idempotent key set, the corresponding state linkage operation is skipped.

[0014] Optionally, the attribute contract further defines computational dependencies between fields, and the method further includes: During the compilation phase, a directed acyclic graph of field dependencies is constructed based on the computational dependencies between fields in the attribute contract. When the attribute contract is executed, in response to a field change event, the derived fields are calculated sequentially according to the topological order of the directed acyclic graph in which the fields depend.

[0015] Optionally, the multidimensional contract set further includes notification contracts and pending contracts, wherein the notification contracts are used to define event notification rules, and the pending contracts are used to define responsibility attribution rules. The method further includes: When executing the notification contract, a notification payload is generated based on the event notification rules, and the recipient list is parsed and delivered. When executing the pending contract, the set of recipients is parsed based on the responsibility attribution rule, idempotent deduplication is performed, an external pending task is initiated, and the task identifier is written back.

[0016] Secondly, embodiments of this application provide an electronic device, including at least one processor and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to perform any of the methods described above.

[0017] Thirdly, embodiments of this application provide a computer storage medium storing instructions or programs that, when executed by at least one processor, cause the at least one processor to perform any of the methods described above.

[0018] In this embodiment of the application, a process management method based on a process template is provided, which has the following beneficial effects: (1) By abstracting the process template into a multi-dimensional executable contract structure that includes at least attribute contracts, state contracts and permission contracts, the template can be reused, reducing multiple systems and redundant development, and adapting faster; (2) By adopting a two-stage mechanism of “preprocessing during compilation” + “ordered execution during runtime” for the contract set, the controllable orchestration of cross-contract dependencies is realized, so that contract changes mainly modify the configuration rather than the core logic, thereby shortening the iteration cycle and reducing the release risk; (3) By pre-implementing the execution of the permission contract as query constraint injection, the security boundary is pushed down from the application layer to the data access layer, which completely eliminates the exposure window of sensitive data in the query transmission and memory loading process, and significantly improves the data security of the system. (4) The state linkage operation is performed by the rule-directed graph constructed based on the state linkage rules, which ensures that the state at each level can be kept consistent automatically and reduces manual error correction and statistical distortion. Attached Figure Description

[0019] Figure 1 This is a flowchart of a process management method based on a process template provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of the five-dimensional contract model provided in the embodiments of this application; Figure 3 This is a schematic diagram illustrating the execution process of the permission contract provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating the processing of the state contract during the compilation and runtime phases provided in the embodiments of this application; Figure 5This is a schematic diagram illustrating the process of applying the process management method provided in this application to the field of R&D projects. Figure 6 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0021] The technical terms used in this application are explained below: 1. Process Instance: A running entity generated by instantiating a process template, used to carry out the process execution process in a specific project.

[0022] 2. DAG (Directed Acyclic Graph): A directed acyclic graph used to describe directed dependencies that do not contain cycles.

[0023] 3. SCC (Strongly Connected Component): Strongly connected component, used to identify the set of nodes in a directed graph that may form a cycle.

[0024] 4. Tarjan's algorithm: A classic algorithm for solving strongly connected components / loop detection (an example method used in this scheme for static loop detection during configuration).

[0025] 5. Topological Sorting: Performs a linear sorting of the nodes in a directed acyclic graph, such that the starting point of each edge precedes the ending point, to determine a conflict-free execution order.

[0026] 6. Reachable Subgraph: A subgraph consisting of rules and nodes that are reachable in a directed graph of rules, triggered by a state change event.

[0027] like Figure 1 As shown, this embodiment provides a process management method based on process templates. This method achieves the safe and orderly operation of process instances by constructing a multi-dimensional contract set with execution semantics and combining underlying data access constraints and graph structure state control. Specifically, the method includes the following steps S101 to S103.

[0028] Step S101: Create a process template. The process template is a multi-dimensional contract set with execution semantics. The multi-dimensional contract set includes at least attribute contracts, state contracts, and permission contracts.

[0029] Among them, the attribute contract is used to define multiple fields with a preset metadata structure, the state contract is used to define state linkage rules, and the permission contract is used to define data access strategies.

[0030] In this embodiment, the process template is not merely a static set of configuration parameters, but is defined as a multidimensional set of executable contracts that includes the aforementioned contracts. For example... Figure 2 As shown, attribute contracts, state contracts, and permission contracts constitute the core dimensions of the multidimensional contract set, jointly supporting the runtime skeleton of the process instance. Specifically, the attribute contract defines multiple fields with a preset metadata structure. This preset metadata structure may include field identifier, type, hierarchical scope, validation constraints, default value, data source type (dictionary or interface), interface URL template and placeholder mapping, set of operable roles, enabled status, sorting weight, etc., enabling fields to have self-description, self-validation, and automatic derivation capabilities at runtime, providing executable data layer specifications for the process instance. The state contract abstracts the discrete state transition logic into a set of cross-level, cross-task linkage rules, supporting automatic state synchronization between parent and child tasks or related objects. The permission contract describes fine-grained data access control strategies. Furthermore, the multidimensional contract set may also include notification contracts and pending contracts (see subsequent embodiments for details). The notification contract defines the conditions and payload generation logic for message pushes triggered by domain events, while the pending contract clarifies the dynamic parsing rules for responsible parties and the interface protocol for external task systems. It should be understood that although... Figure 2 The paper demonstrates a structure with multiple contracts side-by-side. However, in practical applications, the types of contracts can be expanded or tailored according to business needs. For example, audit contracts or archiving contracts can be added, as long as they possess execution semantics that can be parsed by the engine. By abstracting business processes into a multi-dimensional set of contracts, this application decouples business logic from the underlying execution engine. This allows process changes to be made only by adjusting contract configurations without modifying the core code, significantly improving the system's flexibility and maintainability.

[0031] Step S102: Compile the process template and parse the dependencies between contracts in the multidimensional contract set during the compilation phase to generate an execution topology sequence.

[0032] Because contracts have implicit logical dependencies at runtime, improper execution order can lead to data inconsistencies or security vulnerabilities. Therefore, this embodiment performs static analysis on the dependencies between contracts in the multidimensional contract set during the compilation phase (i.e., before the process instance starts or when the template is released). Specifically, the system identifies dependencies such as "permission verification must precede data reading," "attribute value calculation must precede state linkage judgment," and "notification can only be triggered after the state change is completed." Based on these dependencies, a directed acyclic graph is constructed, and a linear execution topology sequence is generated through a topology sorting algorithm. For example, in a typical execution sequence, the permission contract is placed first to ensure that all subsequent operations are within the authorized scope; the attribute contract follows to complete the initialization and derivation calculation of basic data; the state contract is placed after the attribute contract to ensure that the linkage judgment is based on the latest data snapshot; the notification contract and the pending contract are usually located at the end of the sequence as the final touchpoint for business actions. This ordered execution mechanism based on dependency analysis eliminates logical conflicts caused by manual orchestration errors in traditional configuration systems, ensuring the determinism and atomicity of process execution.

[0033] Step S103: Create a process instance based on the process template, and in response to user requests or preset events for the process instance, execute each contract of the process instance according to the execution topology sequence.

[0034] During the execution of a process instance, in response to user requests or preset events for that instance, the execution engine strictly follows the topology sequence generated in step S102 to schedule the execution logic of each contract sequentially. User requests include data query requests, data change requests, etc., while preset events may include status change events, field change events, card creation events, to-do creation events, and status linkage completion events, etc.

[0035] As one implementation method, differentiated execution strategies are adopted for different user requests or events. Different user requests or events may be associated with different contracts. For example, a data query request may only trigger a permission contract, while a state change event may trigger a permission contract, an attribute contract, a state contract, a notification contract, or a pending contract. Therefore, when scheduling contracts sequentially based on the execution topology sequence, it actually means scheduling the contracts associated with user requests or events sequentially based on the execution topology sequence. By employing a two-stage mechanism of "preprocessing during compilation" + "ordered execution during runtime" for the multi-dimensional contract set, controllable orchestration of cross-contract dependencies is achieved, ensuring that each contract is logically self-consistent and temporally coordinated.

[0036] like Figure 3As shown, when executing the permission contract, query constraints and operation constraints are determined based on the data access policy. These query constraints are then injected into the data access layer to generate underlying data query statements to retrieve restricted data. Specifically, when a process instance needs to read or manipulate business data, the system does not first query the entire dataset and then filter it at the application layer. Instead, it first transforms the data access policy defined in the permission contract into query constraints and then injects them into the query builder in the data access layer. The query builder dynamically integrates the query constraints into the query logic to generate underlying data query statements, ensuring that the database or storage engine returns only a subset of data that meets the permission requirements. For example, access restrictions on sensitive fields are transformed into column selection constraints in the query statement; access restrictions on data within a specific range are transformed into row filtering conditions in the query statement. In this way, sensitive data never leaves the security boundary of the storage layer, fundamentally avoiding the risk of data leakage during transmission and memory loading. Furthermore, the data access policy defined in the permission contract is also transformed into operation constraints (i.e., a set of executable operations, which may include button and other action-like operations, such as API calls).

[0037] When executing state contracts, state linkage operations are performed based on a directed graph of rules constructed from state linkage rules. State linkage is essentially a complex event propagation process. In this embodiment, during the compilation phase of the process template, state linkage rules are modeled as a directed graph of rules, where nodes represent state fields or state entities, and edges represent linkage triggering relationships. When a change event occurs in a state field, the execution engine does not blindly traverse all rules, but instead locates the affected downstream path in the directed graph of rules based on the changed node, and propagates the state change in a controlled manner according to the graph's topology. This graph-based execution method ensures that state updates strictly follow the predefined dependency order, avoiding deadlocks caused by circular dependencies or data oscillations caused by disordered execution. At the same time, since only subgraph paths related to the current change are activated, the runtime computational overhead is significantly reduced compared to a full rule scan.

[0038] Through the above steps S101 to S103, this embodiment upgrades the process template from static configuration to an executable semantic contract system, and ensures the coordinated and orderly interaction between contracts through the execution topology sequence. In particular, through the underlying injection of permission constraints and the graph structure control of state linkage, a solid technical foundation is built in the two dimensions of data security and execution stability, providing the necessary operating environment and reference basis for more refined control mechanisms in subsequent embodiments.

[0039] Based on the aforementioned embodiments, this embodiment further refines the execution process of the permission contract, specifically explaining how to achieve precise control of data security boundaries through reverse derivation and underlying injection mechanisms, and how to achieve dynamic activation of security policies while ensuring performance.

[0040] As one implementation method, in response to a data query request for a process instance, the system performs reverse derivation based on the data access policy to generate a field projection list and row-level predicate conditions as query constraints. Specifically, when the execution engine receives a data read request from the business layer, it does not directly pass the request to the database. Instead, it first intercepts the request and loads the data access policy associated with the current process instance. Here, "reverse derivation" refers to the process of transforming an abstract, declarative data access policy into specific query constraints that the underlying data storage system can recognize. For example, if the data access policy stipulates that "ordinary members can only see non-sensitive fields and are limited to tasks created by themselves," the system will parse the policy, generating a field projection list containing identifiers of allowed fields (e.g., [task_id, task_name, status]), and row-level predicate conditions containing data range restrictions (e.g., creator_id = :current_user_id AND sensitivity_level !='high'). This process achieves automatic mapping from business semantics to data query semantics, ensuring that subsequent data acquisition operations naturally carry security boundaries, rather than relying on logical judgments from upper-layer code.

[0041] Furthermore, when constructing the underlying data query statement, the field projection list is concatenated to the selection columns of the underlying data query statement, and the row-level predicate conditions are concatenated to the filter conditions of the underlying data query statement. For example... Figure 3As shown, this concatenation action occurs within the internal processing stage of the Object-Relational Mapping (ORM) framework or SQL builder, belonging to the generation stage of the underlying data query statement. For example, assuming the original business query intent is "get a list of tasks", its initial query template might be "SELECT * FROM tasks WHERE project_id = ?". When executing the permission contract, the system will replace or modify the original "*" wildcard with the field projection list generated by the aforementioned reverse derivation, and append the row-level predicate conditions to the original WHERE clause using the logical "AND" operator, ultimately generating a target query statement in the form of "SELECT task_id, task_name, status FROM tasks WHERE project_id = ? AND creator_id = ? AND sensitivity_level != 'high'". It should be understood that although Structured Query Language (SQL) is used as an example here, this concatenation mechanism is equally applicable to the construction of query objects in non-relational databases, the assembly of query DSLs in search engines, or the construction of traversal descriptions in graph databases in other embodiments, as long as the physical fusion of security constraints is completed in the data retrieval instruction generation stage. Through this pre-query constraint mechanism, sensitive data is removed before leaving the storage medium, completely eliminating the risk of data being briefly exposed in the transmission link or application memory due to the "full query first, then memory filtering" approach in traditional solutions, significantly improving the system's data security.

[0042] To balance real-time security control with query performance in high-concurrency scenarios, this embodiment also introduces a version number-based dynamic policy activation mechanism. As one implementation method, the data access policy carries a version number, which updates with each update of the process template. The parsing results of the data access policy are cached on the server side. In response to a process template update, the cached parsing results are invalidated, dynamically activating the updated data access policy. In actual operation, frequently performing complete policy parsing and derivation for each query incurs significant computational overhead. Therefore, the system maintains a cache in memory based on the Least Recently Used (LRU) algorithm to store intermediate products such as parsed field projection lists and row-level predicate conditions. Each cache entry is bound to the version number of the corresponding process template. When an administrator modifies and publishes the permission contract in the process template, the system automatically increments the global version number of the process template and sends an invalidation notification to the cache component or directly overwrites the old version key-value when writing the new version. When the next query request arrives, the execution engine checks whether the template version number carried in the current request matches the version number of the entry in the cache. If they match, the cached parsing result is reused directly, avoiding repeated derivation. If they do not match or the cache is missed, the reverse derivation logic is re-executed and the cache is updated. This design allows changes to the permission contract to take effect immediately without restarting the service or waiting for a fixed refresh cycle. This ensures both the agility of security policy adjustments and the maintenance of system throughput under high-frequency data access through the caching mechanism, achieving a balance between security and performance.

[0043] Building upon the aforementioned embodiments, this embodiment further provides a stability guarantee mechanism for the configuration phase of state linkage rules. As one implementation method, during the compilation phase, the following static loop detection is performed on the directed graph of the rules. Specifically, although... Figure 1 The example describes the execution of state linkage operations based on a rule-oriented directed graph during the runtime phase. However, if the rule configuration itself contains a logical loop (e.g., a change in state A triggers B, and B then triggers A), the runtime phase will inevitably lead to deadlock or infinite recursion. Therefore, this example moves loop detection to the compilation phase, eliminating potential problems at the source through static analysis. This process first involves precise modeling of the rule-oriented directed graph, where the nodes correspond to state field instances defined in the process template (distinguishing between different levels of scope, such as card-level and table row-level), and the directed edges correspond to the user-configured state linkage rules, with trigger condition mappings also possible on the edges. It should be understood that this modeling method transforms discrete business rules into a standard graph theory problem, enabling subsequent deterministic analysis using mature graph algorithms.

[0044] After constructing the regular directed graph, the system identifies the strongly connected components (SCCs) within it. As a preferred implementation, linear-time algorithms such as the Tarjan algorithm or the Kosaraju algorithm can be used to solve for the SCCs. Taking the Tarjan algorithm as an example, the system performs a depth-first search (DFS) on the regular directed graph, maintaining the visit order index and the index of the earliest ancestor node that can be backtracked to for each node. When the index of a node equals its lowlink, it indicates that all nodes from that node to the top of the stack constitute a strongly connected component. It should be understood that although the Tarjan algorithm is used as an example here, in other embodiments, any algorithm capable of equivalently identifying maximal strongly connected subgraphs in a directed graph is applicable to this application, as long as it can accurately find the subset of nodes in the graph that are mutually reachable. By identifying strongly connected components, the system transforms the complex loop detection problem into a problem of determining the structure of a specific subgraph, avoiding inefficient full-path enumeration.

[0045] Furthermore, when the number of nodes in a strongly connected component is greater than one or a self-loop exists, the determination rule is that a cycle exists in the directed graph. Specifically, if a strongly connected component contains only a single node and that node has no edge pointing to itself, then that node does not constitute a cycle; conversely, if a strongly connected component contains two or more nodes, according to the definition of a strongly connected component, there must be at least one cycle between these nodes; or, even if a strongly connected component contains only one node, but that node has a self-loop edge (i.e., a certain state linkage rule is configured to trigger its own change), it also constitutes a cycle. This determination condition based on graph theory properties has mathematical completeness and determinism, and can cover all types of logical closed loops such as direct cycles, indirect cycles, and self-loops, completely eliminating the risk of missed judgments and data inconsistencies caused by relying on manual experience to check or brute-force truncation by setting the maximum recursion depth at runtime in traditional solutions.

[0046] More importantly, when a loop is detected, the system does not simply return an abstract error flag, but instead backtracks the output of the loop path representing the loop by traversing the stack, and refuses to enable the process template containing the loop. For example... Figure 4 As shown, during the execution of the Tarjan algorithm or other DFS-like algorithms, the system maintains a current search stack. When a strongly connected component is determined to be a cycle, the system can extract the node sequence belonging to that strongly connected component from the stack in reverse order, and combine it with the edge relationships in the original directed graph to reconstruct a complete and readable cycle path string (e.g., "parent task status"). Subtask completion rate Parent task progress (Parent task state). This interpretable path feedback is a key technical contribution that distinguishes this embodiment from a simple error reporting mechanism. It allows configuration personnel to intuitively locate which specific combination of rules caused the infinite loop, thereby quickly correcting configuration errors. In contrast, the common "runtime maximum recursion truncation" scheme in existing technologies not only fails to inform users of the specific loop path, but may also have written some intermediate states before truncation, resulting in the database being in a dirty data state. This embodiment, by refusing to enable templates with loops during the compilation stage, ensures that the process templates entering the production environment are logically acyclic, thus providing a deterministic and safe foundation for state linkage during the runtime stage, fundamentally guaranteeing the stability of the system and the eventual consistency of the data.

[0047] Based on the static loop detection completed during the compilation phase in the above embodiments, this embodiment further elaborates on the specific execution mechanism of state linkage during the runtime phase, focusing on solving the execution efficiency problem under large-scale linkage rules and the state consistency guarantee problem under high concurrency scenarios.

[0048] As one implementation method, the state linkage operation is performed on the rule-directed graph constructed based on state linkage rules. This includes: determining a reachable subgraph in the rule-directed graph starting from the changed node using a graph traversal algorithm; performing topological sorting on the reachable subgraph to generate incremental execution paths; and sequentially executing the condition judgment and target value writing (i.e., state linkage operation) of each state linkage rule according to the incremental execution paths. Specifically, when a state field in a process instance changes, the system does not reload or traverse the entire rule-directed graph. Instead, starting from the changed node, it uses breadth-first search (BFS) or depth-first search (DFS) algorithms to traverse along the directed edges, extracting only all downstream nodes reachable by the current change event and their associated edges, thus constructing a lightweight reachable subgraph. This incremental subgraph extraction mechanism narrows the computation scope from the global graph to locally relevant paths, avoiding invalid scanning of irrelevant nodes and significantly reducing runtime CPU and memory overhead. Subsequently, the system performs a topological sort on the reachable subgraph, for example, using the Kahn algorithm, generating incremental execution paths by continuously removing nodes with an in-degree of 0. This process ensures that the states of all preceding dependent nodes have been updated before any linkage rule is executed, thus guaranteeing the logical correctness of state propagation. During the execution of incremental paths, the engine evaluates the trigger condition expression bound to each rule one by one, and only executes the write operation of the target value when the condition is met, and uses the write result as a new change event to continue driving the execution of subsequent nodes until all nodes in the subgraph have been processed. It should be understood that although the Kahn algorithm is used as an example here, in other embodiments, equivalent topological sorting algorithms such as reverse postorder traversal based on DFS can also be used, as long as the partial order relationship of node execution can be guaranteed to conform to the rule dependency. Through the above incremental execution strategy, this application achieves efficient response capabilities decoupled from business scale while ensuring the rigor of state linkage logic.

[0049] To address the issue of duplicate state triggering caused by network jitter, message retransmission, or concurrent operations in a distributed environment, this embodiment also introduces a refined anti-oscillation mechanism. As one implementation method, a multi-dimensional idempotent key is constructed, comprising a process instance identifier, a target field identifier, and a target value. An idempotent key set is maintained within a preset sliding window. When the multi-dimensional idempotent key matches the idempotent key set, the corresponding state linkage operation is skipped. Specifically, before each state write operation, the system combines the current process instance ID (instanceId), the target field ID to be modified (fieldId), and the target value to be written into a triple as the idempotent key. These three dimensions are indispensable: instance ID and field ID alone cannot distinguish cases where the same field is legally and consecutively modified to different values ​​within a short period; and the lack of a target value may lead to normal state transitions being misjudged as duplicate operations. The system maintains a sliding window in memory, which can be time-based (e.g., the last 5 seconds) or count-based (e.g., the last 10 operations). Whenever a new state change request arrives, the system first checks if its corresponding idempotent key already exists in the current window's set. If it does, it's considered a duplicate trigger, and the request is discarded without any database writes. If it doesn't exist, the key is added to the set, and the associated logic executes normally. For example, in scenarios with unstable networks, a client might automatically retry submitting a "task completed" request due to a timeout, or the message queue might re-deliver the same state change message due to an ACK failure. In these cases, although the system receives multiple identical instructions, subsequent duplicate requests will be precisely intercepted because their generated three-dimensional idempotent keys are completely identical and fall within the same sliding window. This mechanism effectively prevents state oscillations such as database deadlocks, incorrect counter accumulation, or notification storms caused by repeated execution, ensuring the eventual consistency of business data and the robustness of the system. It should be understood that the specific parameters of the sliding window (such as time span or capacity) can be dynamically configured according to the concurrency characteristics and tolerance of the actual business, and this application does not limit this.

[0050] Building upon the aforementioned embodiments, this embodiment further refines the field computation dependencies in the attribute contract and the specific execution logic of the notification contract and the pending contract. As one implementation method, the attribute contract also defines computation dependencies between fields. During compilation, a field dependency directed acyclic graph (DAG) is constructed based on these dependencies. When the attribute contract is executed, in response to field change events, the calculations of derived fields are executed sequentially according to the topological order of the DAG. Specifically, during the process template compilation stage, the system scans the metadata definitions of all fields to identify which fields are calculated by referencing other fields through expressions or functions. For example, the "total task cost" field might be defined as "estimated working hours" multiplied by "labor unit price," and "estimated working hours" depends on the difference between "start time" and "end time." The system uses these fields as nodes and computational references as directed edges to construct a field dependency directed acyclic graph (DAG). When a fundamental field (such as "end time") changes during runtime, the execution engine does not update all related fields randomly or in parallel. Instead, it first locates the affected subset of downstream nodes in the DAG and performs a topological sort on that subset. This sorting ensures a strict partial order of computation execution: that is, the upstream field that is depended upon must be updated before the downstream field that depends on it. In the example above, the system will first recalculate the "estimated working hours," and after its persistence or memory value is refreshed, it will trigger the calculation of the "total task cost." This graph topology-based execution mechanism fundamentally avoids the problem of intermediate data pollution caused by out-of-order computation, ensuring that the derived field values ​​maintain mathematical and logical consistency with the fundamental fields at all times. It should be understood that although arithmetic operations are used as an example here, in other embodiments, the computational dependency between fields can also be any form of deterministic transformation logic, such as string concatenation, enumeration mapping, conditional branch assignment, or external interface query result filling, as long as there is a clear data flow dependency, the DAG topology execution scheme of this embodiment is applicable.

[0051] In addition to the automatic derivation of attribute data, process execution also involves cross-system message delivery and task distribution. As one implementation method, the multi-dimensional contract set also includes notification contracts and pending contracts. Notification contracts define event notification rules, and pending contracts define responsibility attribution rules. The method further includes: when executing a notification contract, generating a notification payload based on the event notification rules and parsing the recipient list for delivery; when executing a pending contract, parsing the recipient set based on the responsibility attribution rules, performing idempotent deduplication, initiating an external pending task, and writing back the task identifier.

[0052] Specifically, during the execution of the notification contract, the system first listens for domain events (such as state transitions, field changes, or task creation) in the process instance. When a preset event notification rule is matched, it first performs object parsing based on the event notification rule to determine the recipient list. Then, it dynamically renders the notification payload according to the template defined in the event notification rule. Here, "parsing the recipient list" is a runtime dynamic binding process, not a static list of email addresses or phone numbers. For example, the event notification rule might be configured to assign recipients to "the immediate superior of the current task manager" or "personnel in the project team whose role is test engineer." The system needs to query the organizational structure service or project member relationship table in real time to transform the abstract role descriptions into a specific set of user identifiers, perform deduplication and merging, and then deliver asynchronously. This dynamic parsing mechanism allows the notification strategy to adapt to personnel changes and organizational adjustments, maintaining accurate reach without modifying the configuration.

[0053] The execution of pending tasks focuses on responsibility closure and technology integration. When initiating a pending task, the system first parses the set of recipients based on responsibility attribution rules, then constructs a business idempotent key containing process instance identifiers, card identifiers, and user identifiers. Based on this business idempotent key, it calls a third-party pending task API (Application Programming Interface) through a connector to create an external pending task and writes back the external task identifier. The card identifier is a unique business identifier for each specific work item (task / requirement) in the process instance. The design intent of this business idempotent key is to ensure that the same task object under the same process instance will not be repeatedly created for the same responsible person, even if the upstream triggering event is consumed multiple times due to network retries or concurrent operations. For example, when a task is assigned to an engineer, even if the assignment message is delivered three times, the system will only call the external pending task system's API to create the task on the first successful request; the subsequent two requests will be ignored because the idempotent key already exists. More importantly, after successfully creating an external pending task, the system writes the task identifier returned by the external system back to the associated record of the local process instance. This write-back action establishes a two-way mapping relationship between the local process and the external to-do system. This allows the system to accurately call the update or shutdown interface of the external system based on the task identifier when the process status changes (e.g., task completion or cancellation), thus achieving cross-system lifecycle synchronization. Without this write-back mechanism, the local process would be unable to perceive the actual status of external to-dos and would be unable to effectively manage them, leading to a break in the collaboration chain. Therefore, the execution of the to-do contract in this embodiment is not merely a one-way message sending, but a complete technical closed loop including parsing, deduplication, creation, and identifier anchoring. This strongly supports the seamless flow of business processes between heterogeneous systems and indirectly solves the problem that existing notifications remain at the reminder level, lacking accountability and closed-loop tracking.

[0054] To more clearly illustrate the application and technical effects of this application's technical solution in actual business scenarios, a comprehensive explanation is provided below using the R&D project management system of an internet company as an example. Figure 5 The diagram illustrates the implementation process of the process management method provided in this application in the field of R&D projects. It should be understood that this embodiment is merely illustrative and intended to help those skilled in the art better understand the concept of this application, and does not constitute a limitation on the scope of protection of this application. In this application scenario, the system achieves controllable, secure, and efficient collaboration throughout the entire process from configuration and query to operation by executing the methods described in the foregoing embodiments.

[0055] Step S501: The administrator creates and configures a process template named "Internet R&D" in the system.

[0056] First, the administrator defined the following fields for the "Internet R&D" process template in the attribute contract: "Developer," "Front-end Developer," "Back-end Developer," "Hardware Test Engineer," "Software Test Engineer," "Estimated Working Hours," "Actual Working Hours," "Start Time," and "End Time." The metadata for each field can include field identifier, type, hierarchical scope, validation constraints, default value, data source type (dictionary or interface), interface URL template and placeholder mapping, set of operable roles, enabled status, and sorting weight. The "Hierarchical Scope" attribute defines the hierarchical tasks to which the field can be displayed. For example, the "Developer" and "Tester" fields are only displayed in the parent task's attribute configuration interface, while the "Front-end Developer," "Back-end Developer," "Hardware Test Engineer," and "Software Test Engineer" fields are only displayed in the sub-task's attribute configuration interface. Furthermore, the attribute contract also defines the dependency relationship between "Actual Working Hours" and the calculation of "Start Time" and "End Time."

[0057] Secondly, the administrator defines the status linkage rules between parent and child cards (i.e., tasks) in the status contract. A card bound to a task can contain multiple subtasks. When the status of a subtask changes, it can indirectly affect the status of the parent task according to the configuration. For example, the configuration can be "When all subtasks change to 'Completed', the parent task status will automatically change to 'Pending Acceptance'".

[0058] Furthermore, the administrator defines data access policies in the permission contract to control the visibility and operability of each task to the user.

[0059] In addition, administrators can define notification contracts and to-do contracts. For example, event notification rules can be defined in the notification contract, allowing tasks to send relevant notifications at different state stages according to the event notification rules; responsibility attribution rules can be defined in the to-do contract. When a to-do is initiated, the set of recipients is first parsed based on the responsibility attribution rules, and then a business idempotent key containing process instance identifiers, card identifiers, and user identifiers is constructed for idempotent deduplication before initiating the external to-do task.

[0060] In step S502, after the administrator clicks the "Save and Publish" button, the system compiles the "Internet R&D" process template in the background and performs relevant preprocessing.

[0061] Specifically, preprocessing may include: (1) Analyze the dependencies between contracts and generate an execution topology sequence.

[0062] (2) Construct a directed graph of rules based on state linkage rules, and perform static loop detection on the directed graph of rules.

[0063] (3) Based on the computational dependency relationship between fields in the attribute contract, construct a field dependency directed acyclic graph.

[0064] Step S503: The project manager creates a research and development project "CRM" in the system, binds it to the process template "Internet Research and Development", and adds a sub-process "CRMV1.0" to create a process instance.

[0065] The project manager logs into the system, clicks "Create New R&D Project", fills in the project information, and then selects the published "Internet R&D" process template from the "Process" drop-down box.

[0066] After binding is complete, the project details page displays the complete interface of the process template definition (project information + process configuration). Users can add sub-processes (i.e., process instances) under this template. The newly added process instance is a "copy version" of the process template and will inherit all the contract configuration information of the template.

[0067] In step S504, the project manager creates a task card under the process instance "CRMV1.0" and assigns the task to the relevant developer in the task card.

[0068] The project manager clicks "Add Task (Card)" under the process instance "CRMV1.0," and the system pops up a task editing dialog box. Specifically, the client generates a control tree based on the schema issued by the server. The form fields in this task editing dialog box are generated entirely by the metadata structure defined in the attribute contract. Upon submission, the client performs an initial validation of the attribute information entered in the form based on validation constraints. After passing the validation, the data is sent to the server, which then performs a second validation to prevent malicious users or abnormal requests from bypassing the client's validation logic and submitting illegal data to the server.

[0069] In step S505, the developer logs into the system and initiates a task list query request for the "CRM" R&D project. In response to the task list query request, the system executes the permission contract.

[0070] At this point, the system executes the permission contract reverse derivation mechanism. Specifically, the execution engine intercepts the query request and, based on the current user's role and project group, reverse-derives the field projection list and row-level predicate conditions. Subsequently, when constructing the underlying SQL query statement, the system concatenates the aforementioned field projection list into the SELECT clause and the row-level predicate conditions into the WHERE clause, ultimately generating a constrained query instruction and sending it to the database. The database only returns a list of tasks visible to the developer.

[0071] In step S506, the developer updates the status of a task under their name to "completed", triggering a status change event. In response to the status change event, the system executes the permission contract, attribute contract, status contract, notification contract or pending contract in sequence.

[0072] Specifically, in response to the state change event, the permission contract is executed first to check whether the developer has the permission to update the state; second, the attribute contract is executed to write the new value "Completed" of the subtask's "Status" field to the database; then, the state contract is executed, using an incremental execution strategy to update the status of each node in the affected subgraph; finally, the notification contract or to-do contract (optional) is executed to trigger "notify relevant personnel" or "create a to-do for testers".

[0073] In summary, the R&D project management scenario demonstrated in this embodiment clearly shows how the process management method based on process templates provided in this application transforms abstract multi-dimensional contract sets, dependency verification during compilation and orderly execution during runtime, reverse permission derivation, and directed graph constraints linked to state into concrete technical means to solve actual business pain points. The collaborative work of these features in real-world scenarios not only solves technical problems such as data security leaks, deadlocks and oscillations in state linkage, and broken accountability, but also significantly reduces system maintenance costs and iteration risks through configuration and automation. It should be emphasized that the above-described R&D project management scenario is only a typical application example of the technical solution of this application. Those skilled in the art will understand that the method of this application is also applicable to other business areas with similar data processing needs, such as customer service work order processing, supply chain order flow, and administrative approval processes. As long as they adopt the contractual template execution mechanism and underlying constraint injection methods described in this application, they should be covered within the scope of protection of this application.

[0074] According to an embodiment of this application, an electronic device is provided, such as... Figure 6 The diagram shown is a hardware structure schematic of an electronic device according to an embodiment of this application. The electronic device 100 includes a processor 10, a memory 20, and a communication interface 30. The processor 10, memory 20, and communication interface 30 are connected via lines. Figure 6 In the embodiment shown, the processor 10, memory 20, and communication interface 30 are connected to each other via a bus.

[0075] The memory 20 is used to store software programs, computer-executable program instructions, etc. The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created based on the use of the electronic device 100, etc.

[0076] The memory 20 can be a read-only memory (ROM), or other types of static storage devices that can store static information and instructions, or random access memory (RAM), or other types of dynamic storage devices that can store information and instructions, or electrically erasable programmable read-only memory (EEPROM). The specific type is not limited here.

[0077] For example, the aforementioned memory 20 can be Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM). This memory 20 can exist independently but is connected to the processor 10. Optionally, the memory 20 can also be integrated with the processor 10, for example, integrated within one or more chips.

[0078] In some embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and this remote memory may be connected to the electronic device 100 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0079] The processor 10 connects various parts of the electronic device 100 using various interfaces and lines. By running or executing software programs stored in the memory 20 and calling data stored in the memory 20, it performs various functions of the electronic device 100 and processes data, such as implementing the methods described in any embodiment of this application.

[0080] The processor 10 can be a field programmable gate array (FPGA), a digital signal processor (DSP), a central processing unit (CPU), or the like.

[0081] Processor 10 can be a single-core processor or a multi-core processor. For example, processor 10 can be composed of multiple FPGAs or multiple DSPs. Furthermore, processor 10 can refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions). Processor 10 can be a standalone semiconductor chip or integrated with other circuits into a single semiconductor chip. For example, it can form a system-on-a-chip (SoC) with other circuits (such as encoding / decoding circuits, hardware acceleration circuits, or various bus and interface circuits), or it can be integrated as a built-in processor within an application-specific integrated circuit (ASIC). This ASIC with integrated processor can be packaged separately or together with other circuits.

[0082] The communication interface 30 can use a transceiver device, such as a transceiver, to enable communication between the electronic device 100 and other devices or communication networks.

[0083] This application also provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example, to execute the steps of the process management method based on the process template described above.

[0084] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A process management method based on process templates, characterized in that, The method includes: Create a process template, which is a multi-dimensional contract set with execution semantics. The multi-dimensional contract set includes at least an attribute contract, a state contract, and a permission contract. The attribute contract is used to define multiple fields with a preset metadata structure, the state contract is used to define state linkage rules, and the permission contract is used to define data access strategies. The process template is compiled, and the dependencies between contracts in the multidimensional contract set are parsed during the compilation phase to generate an execution topology sequence; Based on the process template, a process instance is created. In response to a user request or preset event for the process instance, each contract of the process instance is executed according to the execution topology sequence. When executing the permission contract, query constraints and operation constraints are determined based on the data access strategy, and the query constraints are injected into the data access layer to generate a low-level data query statement to obtain restricted data. When executing the state contract, state linkage operations are executed based on the rule-directed graph constructed by the state linkage rules. The process of determining query constraints based on the data access strategy and injecting the query constraints into the data access layer to generate underlying data query statements to obtain restricted data includes: Based on the data access strategy, reverse derivation is performed to generate a field projection list and row-level predicate conditions as query constraints. When constructing the underlying data query statement, the field projection list is concatenated to the selection column of the underlying data query statement, and the row-level predicate condition is concatenated to the filter condition of the underlying data query statement; The execution of state linkage operations based on the rule-directed graph constructed according to the state linkage rules includes: A reachable subgraph is determined in the directed graph of the rules, starting from the changed node, using a graph traversal algorithm. Perform topological sorting on the reachable subgraph to generate incremental execution paths; The condition judgment and target value writing of each state linkage rule are executed sequentially according to the incremental execution path.

2. The method according to claim 1, characterized in that, The data access policy carries a version number, which is updated as the process template is updated. The method further includes: The parsing results of the data access strategy are cached on the server side; In response to the update of the process template, the parsing result cached on the server is invalidated, so as to dynamically apply the updated data access strategy.

3. The method according to claim 1, characterized in that, The method further includes: During the compilation phase, the following static loop detection is performed on the directed graph of the rules: Identify strongly connected components in the directed graph according to the rules; When the node size of the strongly connected component is greater than 1 or a self-loop exists, it is determined that a loop exists in the directed graph of the rules. Based on the traversal stack backtracking output, the loop path of the loop is characterized, and the process template containing the loop is rejected.

4. The method according to claim 1, characterized in that, The method further includes: When executing the state contract, a multidimensional idempotent key is constructed, which includes a process instance identifier, a target field identifier, and a target value; Maintain the set of idempotent keys within a predefined sliding window; When the multidimensional idempotent key matches the idempotent key set, the corresponding state linkage operation is skipped.

5. The method according to claim 1, characterized in that, The attribute contract also defines computational dependencies between fields, and the method further includes: During the compilation phase, a directed acyclic graph of field dependencies is constructed based on the computational dependencies between fields in the attribute contract. When the attribute contract is executed, in response to a field change event, the derived fields are calculated sequentially according to the topological order of the directed acyclic graph in which the fields depend.

6. The method according to claim 1, characterized in that, The multidimensional contract set also includes notification contracts and pending contracts, wherein the notification contracts are used to define event notification rules, and the pending contracts are used to define responsibility attribution rules. The method further includes: When executing the notification contract, a notification payload is generated based on the event notification rules, and the recipient list is parsed and delivered. When executing the pending contract, the set of recipients is parsed based on the responsibility attribution rule, idempotent deduplication is performed, an external pending task is initiated, and the task identifier is written back.

7. An electronic device, characterized in that, The method includes at least one processor and a memory communicatively connected to the at least one processor, the memory storing instructions executable by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1 to 6.

8. A computer storage medium, characterized in that, The computer storage medium stores instructions or programs that, when executed by at least one processor, cause the at least one processor to perform the method as described in any one of claims 1 to 6.

Images