A modular task management system based on dynamic process configuration

Abstract

This invention relates to the field of data processing technology, and more particularly to a modular task management system based on dynamic process configuration. The system includes a dynamic process configuration module, a task status flow engine, a visual interactive interface module, a historical trajectory tracking module, and modular extension interfaces. The dynamic process configuration module dynamically binds enterprise configuration data with regional process source data using process template IDs, generating an enterprise-specific process topology structure including regional identifiers, node relationships, and process classification tags. The task status flow engine updates task status data based on event-driven and atomic transaction locking mechanisms, synchronizing it to the change management master table. This invention enables flexible configuration of process logic, visual display of task status, and rapid cross-enterprise adaptation, improving system scalability and operational efficiency.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a modular task management system based on dynamic process configuration. Background Technology

[0002] Existing process management systems generally employ fixed process configurations, leading to frequent system architecture adjustments for different enterprises. Their interfaces are complex and task progress displays are not intuitive, requiring users to navigate through multiple layers of process interfaces to obtain current status information, thus reducing operational efficiency. Especially in change management scenarios, traditional systems struggle to dynamically adapt to diverse business process requirements, resulting in high deployment and maintenance costs and insufficient flexibility. Task status transitions rely on preset static paths, hindering the ability to quickly adjust process logic based on actual business needs, thus limiting the system's versatility and scalability. Therefore, there is an urgent need for a task management system that supports dynamic process configuration, modular design, and an intuitive visual interface. This system should utilize a dynamic mapping mechanism between region identifiers and nodes to achieve flexible definition of process paths and efficient task status transitions, thereby improving cross-enterprise deployment adaptability and user convenience. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a modular task management system based on dynamic process configuration. This invention solves the technical problems of existing process management systems, such as poor cross-enterprise deployment adaptability, unintuitive task status display, and inflexible process logic adjustment caused by fixed configurations.

[0004] To solve the above-mentioned technical problems, the specific technical solution of the present invention is as follows:

[0005] This invention provides a modular task management system based on dynamic process configuration, comprising:

[0006] The dynamic process configuration module is used to build a structured data table based on the pre-configured regional process original data and enterprise configuration data. It dynamically binds the enterprise configuration data and process original data through the process template ID, and configures an enterprise-specific process topology structure including regional identifier, next node association relationship and process type classification label.

[0007] The task status transition engine is connected to the dynamic process configuration module. It receives the enterprise-specific process topology, parses the legality of the current region identifier and the existence of the target node, triggers task status migration based on event-driven mechanism, updates the real-time region identifier field in the task status data through atomic transaction lock mechanism, and synchronizes the updated real-time region identifier field and associated operation instructions to the change management master table.

[0008] The visual interactive interface module is connected to the task status flow engine and is used to load the process topology to generate an interface for parallel display of multiple regions. Based on the real-time region identifier field in the change management master table, it dynamically renders the region tree structure and its real-time task volume, and integrates cross-database query function and task and resource mapping table to call associated image data.

[0009] The historical trajectory tracking module is connected to the task status flow engine. Based on the real-time area identifier field and timestamp sequence in the change management master table, it constructs a task lifecycle record chain and stores the area identifier change sequence and operation information.

[0010] The modular extension interface connects to the dynamic process configuration module and the visual interactive interface module. It is used to extend process nodes, functional components and interface plugins through standardized data access specifications, update the structured data table based on the newly added regional nodes, and dynamically load third-party business modules to the visual interactive interface.

[0011] Furthermore, in the modular task management system based on dynamic process configuration described in this invention, the data defined by the dynamic process configuration module includes:

[0012] Process definition data includes the region identifier, process version number, and process type classification label from the original data of the regional process;

[0013] Enterprise configuration data, including node display rules bound to the enterprise ID and button visibility rules associated with the role permissions;

[0014] Dynamic rule data, including node jump conditions, fallback strategy configuration, and automatic archiving trigger rules in the dynamic rule configuration;

[0015] The process template ID dynamically binds the process definition data with the enterprise configuration data to generate an enterprise-specific process instance, and updates the real-time region identifier field in the task status data through the mapping relationship between the region identifier and the task ID.

[0016] Furthermore, the modular task management system based on dynamic process configuration described in this invention also includes:

[0017] The dynamic process configuration module establishes a dynamic mapping mechanism for regional nodes through a two-way binding technology between regional identifiers and node numbers, generating an enterprise-specific process topology structure that includes the mapping relationship between regional identifiers and physical node numbers. When a user triggers a task flow operation, the task status flow engine parses the node number corresponding to the current regional identifier based on the enterprise-specific process topology structure, and determines the target regional identifier and associated operation instructions according to the association relationship of the next node.

[0018] The task status transition engine submits the target area identifier and operation instructions to the change management master table, updates the real-time area identifier field in the task status data through the atomic transaction lock mechanism, and simultaneously backs up the change records to the history record master table to form an unalterable operation trajectory.

[0019] When the task status transition engine performs a rollback operation, it verifies whether the number of rollbacks for the current task exceeds the maximum rollback threshold based on the rollback strategy configuration in the dynamic rule data. It also searches for allowed rollback paths in the enterprise-specific process topology according to the rollback reason classification and verifies whether the target area identifier is within the set of legal paths. If the verification passes, the task status data is updated; otherwise, the operation is intercepted and an abnormal alarm log is generated.

[0020] Furthermore, in the modular task management system based on dynamic process configuration described in this invention, the task status transition engine executes the following verification rules:

[0021] Before the task state transition, based on the conditional triggering rules in the dynamic rule data, verify whether the jump condition of the current region identifier meets the preset threshold, including:

[0022] Extract the node jump conditions associated with the current region identifier from the dynamic rule data and match them with the operation parameters in the task status data;

[0023] If the jump condition meets the preset threshold, an operation instruction allowing migration is generated; otherwise, an alarm is triggered and the process is terminated. In cross-regional operations, if the task status migration involves updating multiple region identifiers, a two-phase commit protocol is used to handle the data consistency in the change management master table, including:

[0024] Pre-commit phase: Lock all associated region identifier fields and verify whether the status of each region node meets the commit conditions;

[0025] Formal commit phase: If the pre-commit verification passes, the real-time region identifier field and timestamp sequence in the task status data are updated in batches using the atomic transaction lock mechanism; if there is a conflict, the system is rolled back to the state before the operation.

[0026] Before the operation command is executed, the access control model associated with the role permissions dynamically verifies whether the user role has the operation permissions corresponding to the current area identifier, including:

[0027] Based on the real-time area identifier in the task status data, retrieve the list of allowed operations from the role permission rule base;

[0028] If the user's role permissions do not match the target operation command, the operation will be intercepted and a permission alert log will be generated.

[0029] Furthermore, in the modular task management system based on dynamic process configuration described in this invention, the visual interactive interface module includes:

[0030] The mold list area, connected to the task status transition engine, dynamically loads the regional task list based on the enterprise-specific process topology and displays the process path relationships, specifically including:

[0031] Extract the real-time region identifier field from the change management master table, and parse the number and status of tasks in the current region;

[0032] Generate a tree structure view based on process type classification labels, and label the real-time task volume and node jump path of each area;

[0033] When a user selects a specific area, the associated task data is located through the mapping relationship between the task ID and the area identifier, and the current area and associated nodes are highlighted simultaneously.

[0034] The quick query area, linked to the mold list area and task status data, integrates an SQL parsing engine to execute cross-database structured query commands, covering file database association retrieval within the task status data, specifically including:

[0035] It receives query conditions input by the user and converts them into executable instructions for the target database through an SQL parsing engine;

[0036] Retrieve matching task records from the file database and map them to the task list in the mold list area through the association between task ID and area identifier, dynamically refreshing the interface display;

[0037] It supports sorting or filtering query results by task attributes and synchronously updating task status through the aforementioned change management master table;

[0038] The image preview area, linked to the mold list area and the task and resource mapping table, retrieves image data via task ID index and renders part drawings and mold drawings in real time. Specifically, it includes:

[0039] Based on the task ID selected in the mold list area, retrieve the task and resource mapping table to obtain the associated part 3D model file path and mold design drawing storage address;

[0040] It calls the graphics rendering engine to load image resources and generate a high-precision preview view, supporting zoom, rotation and cross-sectional viewing operations.

[0041] When the real-time region identifier field in the task status data changes, the consistency of image resources is verified by version tagging, and the latest version of the design drawings is automatically loaded.

[0042] Furthermore, in the modular task management system based on dynamic process configuration described in this invention, the data stored in the historical trajectory tracing module includes:

[0043] Basic task attribute data, including task ID, task title, creator information, and the type of process to which it belongs;

[0044] Real-time area identifier change sequence records the flow path of tasks in the process topology and stores area identifier change records in chronological order, including the current area identifier and historical area identifier sequence;

[0045] A timestamp sequence that marks the time dimension information of task creation time, estimated completion time, actual completion time, and key operation nodes;

[0046] The historical trajectory tracing module constructs a task lifecycle record chain in the following ways:

[0047] The data synchronization mechanism is to use an atomic transaction lock mechanism to incrementally synchronize the real-time area identifier field and operation information to the historical record table when the task status flow engine updates the change management master table, thereby generating an unalterable operation trajectory.

[0048] The index construction rule is to use the task ID as the primary index in the history table to associate the task's basic attributes and the sequence of changes in the region identifier, and use the timestamp as the secondary index to arrange the data records in the order of operation, forming a combined index of task ID and timestamp.

[0049] Forward process backtracking involves retrieving the region identifier change sequence from the historical record table based on the task ID, generating a visual flowchart in timestamp order, and marking the operation time, execution role, and associated operation instructions for each node.

[0050] Reverse operation tracing involves reversing the history of task status changes based on timestamp indexes, locating the predecessor and successor states of specific operation nodes, and extracting associated operation logs and context data for abnormal operation rollback or fault analysis.

[0051] Furthermore, in the modular task management system based on dynamic process configuration described in this invention, the modular extension interface includes:

[0052] The process extension interface is used to allow the fields of the structured data table to be extended when adding new regional nodes, while maintaining compatibility with existing process topologies;

[0053] The function extension interface is used to embed third-party business modules into the task state transition engine through reserved hook functions;

[0054] The interface extension interface is used to dynamically load new functional components into the visual interactive interface module using a plug-in architecture.

[0055] Beneficial effects of this invention;

[0056] The beneficial effects of this invention are as follows: A dynamic process configuration module dynamically binds enterprise configuration data with regional process metadata based on process template IDs, generating an enterprise-specific process topology that can flexibly adapt to different business scenarios, solving the problem of poor cross-enterprise deployment adaptability caused by fixed configurations in traditional systems; a visual interactive interface module dynamically renders a multi-region parallel display interface based on the real-time regional identifier field of the change management master table, and realizes the linked display of task status, search results, and design drawings through task and resource mapping tables and cross-database query functions, improving task status visualization and operational efficiency; a modular extension interface adopts standardized data access specifications to support the dynamic extension of process nodes, functional logic, and interface components, and achieves seamless integration of third-party business modules through hook functions and a plug-in architecture, enabling the system to quickly respond to business process adjustment needs without reconstructing the core architecture, effectively overcoming the technical defects of rigid process logic in traditional systems; and a historical trajectory tracing module constructs a task lifecycle record chain through combined indexes and incremental synchronization mechanisms, supporting forward process backtracking and reverse operation tracing, providing complete data support for anomaly handling and process optimization. Attached Figure Description

[0057] To more clearly illustrate the technical solution of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on the drawings without creative effort.

[0058] Figure 1 This is a system architecture diagram of a modular task management system based on dynamic process configuration, provided for an embodiment of the present invention. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention. The technical solutions provided by various embodiments of this invention will be described in detail below with reference to the accompanying drawings. To better understand the objectives of this invention, it will be described in further detail below.

[0060] Please see Figure 1 This invention provides a modular task management system based on dynamic process configuration, comprising:

[0061] The dynamic process configuration module is used to build a structured data table based on the pre-configured regional process original data and enterprise configuration data. It dynamically binds the enterprise configuration data and process original data through the process template ID, and configures an enterprise-specific process topology structure including regional identifier, next node association relationship and process type classification label.

[0062] The dynamic process configuration module constructs a structured data table using pre-configured regional process source data and enterprise configuration data. The regional process source data includes a region identifier, process version number, and process type classification label. The region identifier uniquely identifies logical nodes in the process topology; the process version number supports parallel management of multiple process versions; and the process type classification label categorizes processes based on business scenarios (such as "production approval" or "design review"). Enterprise configuration data includes node display rules bound to the enterprise ID and button visibility rules associated with role permissions, such as defining display colors for different region names or restricting specific roles' access to the "return" button. Dynamic rule data includes node jump conditions, return strategy configurations, and automatic archiving trigger rules, such as setting thresholds for the number of tasks completed in a region or path constraints for returning reason classifications.

[0063] The process template ID serves as the core association key, dynamically binding regional process source data with enterprise configuration data. During the binding process, the process template ID calls upon the regional identifier, node relationships, and rule configurations in the general process template, combined with the display rules and permission policies corresponding to the enterprise ID, to generate an enterprise-specific process instance. The structured data table reserves extended fields through dynamic table structure management technology. For example, when a "urgency level" field is added, the system automatically expands the table structure and marks the version number, adapting to the old and new data patterns based on the version number during loading. New fields are dynamically bound to the enterprise-specific process topology through the process template ID, ensuring compatibility between the expanded process logic and the existing topology.

[0064] The dynamic process configuration module establishes a mapping relationship between logical nodes and physical operations through a two-way binding technology of region identifiers and node numbers. The region identifier serves as the logical marker of the process path, while the node number associates the operation instructions and resource addresses of the actual business nodes. When the process topology is generated, the system parses the number of tasks in each region and marks the real-time task volume, generating a tree view as the data source for the visualization interface. Process version numbers support the coexistence management of historical and current processes. For example, company A can generate versions V1.0 and V2.0 based on the same process template, adapting to different business scenarios, and using version numbers to distinguish data table structures and rule configurations.

[0065] Enterprise configuration data is dynamically linked with enterprise IDs and process template IDs to generate differentiated process instances. For example, enterprise B's node display rules define high-priority areas as red and pinned to the top, while enterprise C uses blue markings. The system loads the corresponding configuration rules based on the enterprise ID and dynamically adjusts the display logic of interface elements. Node jump conditions and return strategies in the dynamic rule data are bound to the process topology through process template IDs. For example, when the number of tasks in the completed area reaches a threshold, an automatic jump to the archive node is triggered, or "material error" type returns are restricted to only returning to the review node. Modular extension interfaces support adding new rule types or adjusting thresholds, and the configuration is dynamically updated through standardized data specifications without modifying the core code.

[0066] The above technical solution enables flexible generation and adaptation of enterprise-specific process topologies through dynamic binding of process template IDs, expansion mechanisms of structured data tables, and version control strategies. The mapping relationship between logical nodes and physical operations, the parallel management of multi-version processes, and the decoupling design of enterprise configuration data jointly solve the problem of poor cross-enterprise deployment adaptability caused by fixed configurations in traditional systems, providing dynamic data support for subsequent task status transitions and interface interactions.

[0067] The task status transition engine is connected to the dynamic process configuration module. It receives the enterprise-specific process topology, parses the legality of the current region identifier and the existence of the target node, triggers task status migration based on event-driven mechanism, updates the real-time region identifier field in the task status data through atomic transaction lock mechanism, and synchronizes the updated real-time region identifier field and associated operation instructions to the change management master table.

[0068] The task state transition engine connects to the dynamic process configuration module. After receiving the enterprise-specific process topology, it parses the legality of the current region identifier and the existence of the target node. This parsing process is based on node transition conditions in dynamic rule data, such as verifying whether the current region identifier conforms to the preset process path definition and whether the target node exists in the process topology's association relationships. If the parsing is successful, the system triggers task state transitions based on an event-driven mechanism. For example, when a user submits an operation command or the task meets the automatic transition conditions, the engine calls a predefined business logic module to execute the state change.

[0069] During state transition, the task state transition engine updates the real-time region identifier field in the task state data through an atomic transaction lock mechanism. This atomic transaction lock employs a two-phase commit protocol to handle data consistency: in the pre-commit phase, the associated region identifier field is locked and preconditions are verified, such as checking whether the target node's resources are ready or whether the preceding tasks are completed; in the formal commit phase, the real-time region identifier field and timestamp sequence are updated in batches. If a data conflict is detected (such as inconsistencies caused by concurrent operations), a rollback operation is triggered to restore the state to its pre-operation state. The updated real-time region identifier field and associated operation instructions are synchronized to the change management master table through transaction log records, generating an immutable record containing the task ID, operation type, and timestamp.

[0070] The data synchronization mechanism of the change management master table is linked with the historical trajectory tracing module. Change records of the real-time area identifier field are incrementally backed up and written to the historical record master table, forming a complete operation trajectory. The synchronization process generates a unique digest value based on a hash algorithm and combines it with a timestamp to mark the operation sequence, ensuring data integrity and traceability. When the task status flow engine executes a rollback operation, it configures the rollback number threshold and path legality verification according to the rollback strategy configuration in the dynamic rule data. For example, when the rollback reason is classified as "material missing", it only allows jumping to the material review node. If the verification fails, an abnormal alarm log is generated and the relevant responsible person is notified. The engine's verification rules work in conjunction with the access control model, retrieving the role permission rule library based on the real-time area identifier, and dynamically constraining user operation permissions. For example, it only allows the final review role to trigger the archiving instruction, thereby ensuring the consistency between process logic and business rules.

[0071] The visual interactive interface module is connected to the task status flow engine and is used to load the process topology to generate an interface for parallel display of multiple regions. Based on the real-time region identifier field in the change management master table, it dynamically renders the region tree structure and its real-time task volume, and integrates cross-database query function and task and resource mapping table to call associated image data.

[0072] The visual interactive interface module connects to the task status flow engine, dynamically rendering a multi-region parallel display interface based on the real-time region identifier field in the change management master table. The template list area extracts the real-time region identifier field from the change management master table, parses the number and status of tasks in the current region, and generates a structured dataset containing task IDs, task titles, and execution progress. A tree-structured view is generated based on process type classification tags, marking the real-time task volume and node jump paths for each region, for example, using color to distinguish high-priority regions or timed-out tasks. When a user selects a specific region, the system locates the associated task data through the mapping relationship between task IDs and region identifiers, synchronously highlighting the current region and associated nodes, and displaying task details in the sidebar, including creation time, responsible personnel, and operation logs, achieving dynamic linkage between task status and interface elements.

[0073] The quick query area integrates an SQL parsing engine, converting user-input natural language query conditions into executable instructions for the target database. For example, it parses "unfinished tasks this week" into an SQL statement with time range and status filtering. The system retrieves matching task records from the file database and maps them to the task list in the mold list area through the association between task IDs and area identifiers, dynamically refreshing the interface display. Query results can be sorted or filtered by task attributes, such as sorting by priority in descending order or displaying only timed-out tasks. Simultaneously, task status is updated synchronously through the change management master table, triggering real-time updates of the tree view in the mold list area to maintain data consistency.

[0074] The image preview area retrieves the path to the associated 3D model file of the part and the storage address of the mold design drawing from the task and resource mapping table based on the selected task ID in the mold list area. The graphics rendering engine loads the image resources and generates a high-precision preview view, supporting zoom, rotation, and section viewing operations. For example, it uses WebGL technology to enable 3D model interaction on the browser side. When the real-time area identifier field in the task status data changes, the system verifies the consistency of image resources through version tagging. For example, it compares the version number of the design drawing with the latest version associated with the current task area identifier, automatically loads the latest resources, and updates the preview view to avoid image display lag due to task status migration. Data interaction between functional areas is based on a unified data bus. Changes in task status trigger collaborative updates of interface elements. For example, when the area identifier field is updated, the task quantity statistics in the mold list area and the drawing version in the image preview area are refreshed simultaneously, realizing a closed-loop operation and real-time data synchronization.

[0075] The historical trajectory tracking module is connected to the task status flow engine. Based on the real-time area identifier field and timestamp sequence in the change management master table, it constructs a task lifecycle record chain and stores the area identifier change sequence and operation information.

[0076] The historical trajectory tracking module connects to the task status flow engine, constructing a task lifecycle record chain based on the real-time region identifier field and timestamp sequence in the change management master table. When the task status flow engine updates the change management master table, the system uses an atomic transaction lock mechanism to incrementally synchronize the real-time region identifier field and operation information to the historical record master table, generating a transaction log containing the task ID, operation type, and timestamp. The atomic transaction lock adopts a two-phase commit protocol. In the pre-commit phase, the target data record is locked and an operation log is generated. In the formal commit phase, the changed data is written to the historical record master table in batches. If a concurrent conflict is detected, a rollback operation is triggered to restore the state before the operation, ensuring the integrity and consistency of data synchronization.

[0077] The historical record table uses the task ID as the primary index, linking basic task attributes and the sequence of region identifier changes. It uses timestamps as secondary indexes, arranging data records in chronological order to form a composite index structure. The primary index utilizes a B+ tree structure for fast retrieval, such as querying the complete workflow by task ID. The secondary indexes support filtering operation records by time range, such as locating the sequence of region identifier changes within a specific time period. The composite index optimizes the efficiency of range queries and precise retrieval, such as retrieving all operation nodes of a task within a specified time window or context data at a specific point in time.

[0078] Forward process backtracking traverses the region identifier change sequence in the historical record table based on the task ID, generating a visual flowchart in timestamp order. The system extracts basic task attributes, region identifier change records, and timestamp sequences, and uses a graphics rendering engine to generate a flowchart that includes node jump paths, operation times, and execution roles. For example, it includes an operation instruction labeled "Jump to the final review node" and the corresponding user role information. Reverse operation tracing reversely parses the change history based on timestamp indexes. When an abnormal operation is detected, the system reversely traverses the historical record to locate the operation node that caused the abnormality and extracts the predecessor and successor state data. For example, when a task is rolled back due to data conflict, the system retrieves the timestamp and region identifier of the most recent valid state, triggers the engine to restore to that state, and correlates the transaction log to restore the operation context and resource change records, providing a complete data chain for fault analysis. A version marking mechanism verifies data consistency, prevents state errors caused by version conflicts during recovery, and ensures the reliability and auditability of traceable data.

[0079] The modular extension interface connects to the dynamic process configuration module and the visual interactive interface module. It is used to extend process nodes, functional components and interface plugins through standardized data access specifications, update the structured data table based on the newly added regional nodes, and dynamically load third-party business modules to the visual interactive interface.

[0080] The modular extension interface connects with the dynamic process configuration module and the visual interactive interface module, enabling dynamic expansion of system functions through standardized data access specifications. When a new regional node is added, the process extension interface expands the fields of the structured data table, such as adding "urgency" or "priority" fields. Dynamic table structure management technology automatically expands the data table structure and marks it with a version number. New fields are dynamically bound to the enterprise-specific process topology structure through the process template ID. During loading, the system identifies and adapts to the old and new data patterns based on the version number; for example, it fills the new fields with default values ​​from the old version data, avoiding process logic interruptions and achieving a smooth transition between old and new nodes.

[0081] The functional extension interface pre-defines hook functions at key nodes in task state transitions, such as triggering permission verification before a region identifier change or calling the archiving module after a change. Third-party business modules connect through standardized interface protocols, defining input parameters as task ID, region identifier, and operation context, and output parameters as operation instructions or verification results. For example, when integrating a quality inspection module, the system calls this module to perform parameter compliance checks before the task jumps to the final review node; if the check fails, a state rollback is triggered. The interface enables independent deployment of modules through dynamic link libraries or microservice architectures, supporting hot loading and unloading to adapt to the dynamic adjustment needs of business processes.

[0082] The interface extension uses a plug-in architecture to dynamically load new functional components into the visual interactive interface module. This plug-in architecture is based on a component registration mechanism, defining the resource paths, dependencies, and permission requirements of new components through configuration files. For example, when adding a data analysis panel, the system loads the corresponding front-end component file and registers it in the extended function area of ​​the template list, dynamically binding the data source through the association between task ID and region identifier. Plug-in components share the same data bus with the core interface, responding in real-time to data updates in the change management master table; for example, when task status migrates, the data analysis panel automatically refreshes statistical charts. The architecture isolates the plug-in runtime environment through a sandbox mechanism to prevent resource conflicts between components, while also supporting on-demand loading and unloading, optimizing system performance and resource utilization.

[0083] Each extended interface collaborates through data flow and event-driven mechanisms. New fields added to the process extended interface are synchronized to the hook function parameter list of the functional extended interface via the process template ID, driving the logical adaptation of third-party business modules. For example, when a "urgent task" field is added, the functional extended interface calls the emergency task processing module during state transitions to adjust the jump condition threshold. The execution results of the functional extended interface notify the plugin components of the interface extended interface via the event bus, triggering dynamic rendering of interface elements. The display logic of newly added components is bound to the data source. For example, the emergency task highlighting plugin dynamically adjusts the color markers based on the field values ​​of the process extended interface, achieving dynamic linkage between process rules, business logic, and interface interaction. This allows the system to quickly respond to diverse needs across enterprise scenarios without refactoring the core architecture.

[0084] The dynamic process configuration module, based on pre-configured regional process source data and enterprise configuration data, establishes dynamic binding relationships through process template IDs to generate an enterprise-specific process topology. The regional process source data includes a regional identifier, process version number, and process type classification tags. The enterprise configuration data includes node display rules bound to the enterprise ID and button visibility rules associated with role permissions. The process template ID serves as the association key, combining a general process template with enterprise-customized configurations to construct a structured data table containing a regional identifier, next node associations, and process type classification tags. This structured data table reserves extended fields through dynamic table structure management technology, supporting compatibility with existing process topologies when adding new regional nodes. When the enterprise-specific process topology is generated, the system parses the number of tasks in each region and marks the real-time task volume, generating a regional tree view to provide a dynamic data source for subsequent task status transitions.

[0085] The task status transition engine receives the enterprise-specific process topology generated by the dynamic process configuration module and parses the legality of the current region identifier and the existence of the target node. Based on an event-driven mechanism, when a user triggers a task transition operation, the system extracts the node jump conditions from the dynamic rule data and matches them with the operation parameters in the task status data. If the jump conditions meet a preset threshold, the task status transition engine updates the real-time region identifier field in the task status data through an atomic transaction lock mechanism and synchronizes the updated field and associated operation instructions to the change management master table. The atomic transaction lock mechanism adopts a two-phase commit protocol. In the pre-commit phase, the associated region identifier field is locked and the preconditions are verified. In the formal commit phase, data is updated in batches. If a conflict exists, a rollback operation is triggered. The change management master table records the current region identifier, historical region identifier sequence, and operation timestamp of the task, providing real-time input for other modules.

[0086] The visual interactive interface module loads the enterprise-specific process topology and dynamically renders a multi-region parallel display interface based on the real-time region identifier field in the change management master table. The mold list area extracts the real-time region identifier field from the change management master table, parses the task quantity and status of each region, generates a tree-structured view, and marks the process path relationships. The quick query area integrates an SQL parsing engine, converting user-input query conditions into cross-database commands, retrieving task records from the file database, and updating the display content of the mold list area through the mapping relationship between task IDs and region identifiers. The image preview area, based on the task ID selected in the mold list area, calls the task-resource mapping table to obtain the associated image resource address, loads the 3D model file and mold design drawing, and supports real-time rendering and interactive operations. All functional areas are linked through a unified data bus, and interface elements are refreshed synchronously when task status changes.

[0087] The historical trajectory tracing module constructs a complete lifecycle record chain for tasks based on the real-time region identifier field and timestamp sequence in the change management master table. Basic task attributes, region identifier change sequences, and timestamp sequences are written to the historical record master table via an incremental synchronization mechanism, and efficient retrieval is achieved using a combined index of task ID and timestamp. Forward process backtracking traverses the region identifier change sequence by task ID, generating a visual flowchart and marking operation time and execution role; reverse operation tracing reversely parses the change history based on timestamps, locates abnormal operation nodes, and extracts contextual data. The historical record master table uses a version marking mechanism to prevent data overwriting, and the transaction log records operation types and associated user information, ensuring the integrity and consistency of the traceability data.

[0088] Modular extension interfaces support dynamic expansion of system functions through standardized data access specifications. When a new regional node is added, the process extension interface expands the structured data table fields, dynamically binding the new fields to the enterprise-specific process topology based on the process template ID. Function extension interfaces pre-define hook functions at key nodes in task state transitions. Third-party business modules access the interface through standardized interface protocols, with input parameters including task ID, regional identifier, and operation context, and output parameters being operation instructions or verification results. Interface extension interfaces employ a plug-in architecture to load new components. A component registration mechanism defines resource paths and dependencies. Plugins share a data bus with the core interface and respond in real-time to updates in the change management master table. All extension interfaces collaborate through data flow and event-driven mechanisms; new fields drive the logic adaptation of functional modules, and execution results trigger dynamic rendering of interface components.

[0089] Specifically, in the modular task management system based on dynamic process configuration described in this invention, the data defined by the dynamic process configuration module includes:

[0090] Process definition data includes the region identifier, process version number, and process type classification label from the original data of the regional process;

[0091] Enterprise configuration data, including node display rules bound to the enterprise ID and button visibility rules associated with the role permissions;

[0092] Dynamic rule data, including node jump conditions, fallback strategy configuration, and automatic archiving trigger rules in the dynamic rule configuration;

[0093] The process template ID dynamically binds the process definition data with the enterprise configuration data to generate an enterprise-specific process instance, and updates the real-time region identifier field in the task status data through the mapping relationship between the region identifier and the task ID.

[0094] The process definition data defined by the dynamic process configuration module includes the region identifier, process version number, and process type classification label from the original regional process data. The region identifier is a unique logical marker for nodes in the process topology, used to locate the current region of a task and its next jump path. The process version number supports parallel management of multiple process versions, allowing enterprises to generate different versions of process instances based on the same template and distinguish between historical and current processes by version number. The process type classification label marks process attributes based on business scenarios, such as categorizing by "production approval" and "design review," enabling independent configuration and parallel operation of multiple process types. The process definition data is stored in a structured data table and linked with the regional task count statistics module to update the task volume of each region in real time, providing a data source for the dynamic rendering of the process topology.

[0095] Enterprise configuration data includes node display rules bound to the enterprise ID and button visibility rules associated with role permissions. Node display rules define the display format, color coding, and sorting priority of area names in the visualization interface; for example, high-priority areas are marked in red and displayed at the top. Button visibility rules associated with role permissions constrain user operation permissions through an access control model; for example, only allowing the review role to trigger the "Archive" button at the final review node. Enterprise configuration data is dynamically bound to the enterprise ID and process template ID to generate enterprise-specific process display and permission policies. When the process topology is loaded, the system parses the configuration rules corresponding to the enterprise ID and dynamically adjusts the display logic and operation permissions of interface elements to adapt to the management needs of different organizations.

[0096] Dynamic rule data includes node jump conditions, rollback strategy configurations, and automatic archiving trigger rules. Node jump conditions define the trigger thresholds for task state transitions, such as allowing a jump to the next node when the number of completed tasks reaches a preset limit. Rollback strategy configurations set the maximum number of rollbacks and rollback reason categories, such as restricting rollbacks for "material error" categories to only allow return to the material review node. Automatic archiving trigger rules are associated with preset business logic, such as triggering the automatic archiving procedure when a task is in the final review node for more than a preset time. Dynamic rule data is bound to the enterprise-specific process topology through process template IDs, and verifies the legality of operations in real time during task state transitions to prevent state jumps that violate business logic.

[0097] The process template ID serves as the core association key, dynamically binding process definition data with enterprise configuration data. During the binding process, the process template ID calls upon the region identifier, node relationships, and rule configurations in the general process template, combined with the node display rules and permission policies corresponding to the enterprise ID, to generate an enterprise-specific process instance. This process instance stores the mapping relationship between region identifiers and task IDs through a structured data table, updating the region identifier field in the task status data in real time. When a task status transitions, the update of the region identifier field triggers a synchronization operation in the change management master table, recording the current region identifier, historical region identifier sequences, and operation timestamps, providing real-time data input for visual interface rendering and historical tracing. The mapping relationship between region identifiers and task IDs persists throughout the entire task lifecycle, driving the dynamic linkage between task status data updates and interface elements.

[0098] Specifically, the modular task management system based on dynamic process configuration described in this invention further includes:

[0099] The dynamic process configuration module establishes a dynamic mapping mechanism for regional nodes through a two-way binding technology between regional identifiers and node numbers, generating an enterprise-specific process topology structure that includes the mapping relationship between regional identifiers and physical node numbers. When a user triggers a task flow operation, the task status flow engine parses the node number corresponding to the current regional identifier based on the enterprise-specific process topology structure, and determines the target regional identifier and associated operation instructions according to the association relationship of the next node.

[0100] The task status transition engine submits the target area identifier and operation instructions to the change management master table, updates the real-time area identifier field in the task status data through the atomic transaction lock mechanism, and simultaneously backs up the change records to the history record master table to form an unalterable operation trajectory.

[0101] When the task status transition engine performs a rollback operation, it verifies whether the number of rollbacks for the current task exceeds the maximum rollback threshold based on the rollback strategy configuration in the dynamic rule data. It also searches for allowed rollback paths in the enterprise-specific process topology according to the rollback reason classification and verifies whether the target area identifier is within the set of legal paths. If the verification passes, the task status data is updated; otherwise, the operation is intercepted and an abnormal alarm log is generated.

[0102] The dynamic process configuration module establishes a dynamic mapping mechanism for regional nodes through a two-way binding technology between regional identifiers and node numbers, generating an enterprise-specific process topology structure that includes the mapping relationship between regional identifiers and physical node numbers. This two-way binding technology stores the one-to-one correspondence between regional identifiers and physical node numbers in a structured data table. The regional identifier serves as a logical marker for defining the process path, while the physical node number is associated with the operation instructions and resource addresses of the actual business nodes. When a user triggers a task flow operation, the task status flow engine parses the physical node number corresponding to the current regional identifier based on the enterprise-specific process topology structure, retrieves the next node association relationship, and determines the target regional identifier and operation instruction set. The operation instruction set includes jump conditions, permission verification rules, and related business module call paths, such as the approval interface to be called for a rollback operation or the data cleanup program triggered by archiving.

[0103] The task status transition engine submits the target region identifier and operation instructions to the change management master table, updating the real-time region identifier field in the task status data through an atomic transaction lock mechanism. This atomic transaction lock mechanism employs a two-phase commit protocol: in the pre-commit phase, it locks the current region identifier field and verifies the legality of the target node's status; in the formal commit phase, it batch updates the real-time region identifier field and timestamp sequence. After the change management master table is synchronously updated, the system incrementally backs up the change records to the historical record master table, generating a transaction log containing operation type, target region identifier, and user information. This transaction log generates a unique identifier using a hash algorithm, combining it with a timestamp to form an immutable operation trajectory, providing a data foundation for subsequent traceability.

[0104] When executing a rollback operation, the task status transition engine performs a validity check based on the rollback strategy configuration in the dynamic rule data. The rollback strategy configuration defines the maximum number of rollbacks and the classification of rollback reasons, such as classifying rollback reasons into categories like "design error" and "material missing," with each category associated with a set of allowed rollback paths. The system checks whether the number of rollbacks for the current task exceeds the threshold. If it does not, it searches the set of legal paths in the enterprise-specific process topology based on the rollback reason and verifies whether the target area identifier exists in that set. If the verification passes, the real-time area identifier field is updated and the rollback reason is recorded; if the verification fails, the operation is intercepted and an exception alarm log containing the task ID, rollback reason, and error code is generated, triggering the notification module to send alarm information to the relevant responsible party.

[0105] The synergy between the dynamic mapping mechanism for regional nodes and the rollback strategy is achieved through structured data tables. The rollback path set in the dynamic rule data is generated based on the mapping relationship between regional identifiers and node numbers, and the real-time regional identifier field in the task status data drives the data synchronization between the change management master table and the historical record master table. The visual interactive interface module dynamically renders interface elements based on the rollback operation results, such as highlighting valid rollback paths in the regional tree view or displaying abnormal alarm information in a pop-up window. The modular extension interface supports adding rollback reason categories or adjusting path sets, and dynamically updates the rollback strategy configuration through standardized data specifications to adapt to the business process needs of different enterprises.

[0106] Specifically, in the modular task management system based on dynamic process configuration described in this invention, the task status transition engine executes the following verification rules:

[0107] Before the task state transition, based on the conditional triggering rules in the dynamic rule data, verify whether the jump condition of the current region identifier meets the preset threshold, including:

[0108] Extract the node jump conditions associated with the current region identifier from the dynamic rule data and match them with the operation parameters in the task status data;

[0109] If the jump condition meets the preset threshold, an operation instruction that allows migration is generated; otherwise, an alarm is triggered and the process is terminated.

[0110] In cross-regional operations, if the task state transition involves updating multiple region identifiers, a two-phase commit protocol is used to handle data consistency in the change management master table, including:

[0111] Pre-commit phase: Lock all associated region identifier fields and verify whether the status of each region node meets the commit conditions;

[0112] Formal commit phase: If the pre-commit verification passes, the real-time region identifier field and timestamp sequence in the task status data are updated in batches using the atomic transaction lock mechanism; if there is a conflict, the system is rolled back to the state before the operation.

[0113] Before the operation command is executed, the access control model associated with the role permissions dynamically verifies whether the user role has the operation permissions corresponding to the current area identifier, including:

[0114] Based on the real-time area identifier in the task status data, retrieve the list of allowed operations from the role permission rule base;

[0115] If the user's role permissions do not match the target operation command, the operation will be intercepted and a permission alert log will be generated.

[0116] Before migrating a task status, the task status transition engine executes verification rules, verifying whether the jump conditions of the current region identifier meet preset thresholds based on condition-triggered rules in the dynamic rule data. The system extracts the node jump conditions associated with the current region identifier from the dynamic rule data, such as the threshold for the number of tasks completed or time window limits, and matches them with operation parameters in the task status data, including the number of completed tasks, execution timestamps, and associated resource status. If the jump conditions meet the preset thresholds, an operation instruction set allowing migration is generated. This instruction set includes the target region identifier, operation type, and the call path of the associated business logic module. If the conditions are not met, an alarm is triggered, the process is terminated, exception information is recorded in the log system, and the responsible party is notified to handle the unqualified task.

[0117] In cross-regional operation scenarios, when task status migration involves updating multiple region identifiers, a two-phase commit protocol is used to handle data consistency in the change management master table. During the pre-commit phase, all associated region identifier fields are locked, and the status of each region node is verified to meet the commit conditions, such as checking whether the preceding tasks have been completed or resources have been allocated. During the formal commit phase, if the pre-commit verification passes, the real-time region identifier field and timestamp sequence in the task status data are updated in batches using an atomic transaction locking mechanism. If there are node status conflicts or abnormal resource usage, a rollback operation is triggered to restore the data to its pre-operation state, and the conflict information is written to the transaction log. After the change management master table is updated, incremental backup operations are recorded to the historical record master table, generating an immutable trace containing the task ID, operation type, and timestamp, supporting subsequent traceability and auditing.

[0118] Before an operation command is executed, the system dynamically verifies whether the user role possesses the operation permissions corresponding to the current region identifier through an access control model associated with role permissions. Based on the real-time region identifier in the task status data, the system retrieves the list of allowed operations from the role permission rule base. This rule base stores role permission policies bound to the enterprise ID, such as "the review role can only perform rollback operations" or "the final review role has archiving permissions." If the user role permissions do not match the target operation command, the operation is intercepted and a permission alarm log is generated. The log includes the task ID, user role, target operation type, and reason for interception, triggering the notification module to push alarm information to the administrator terminal. The permission verification result is fed back to the visual interactive interface module in real time, dynamically adjusting the visibility and operation status of interface elements, such as disabling buttons for operations without permission or hiding sensitive functional areas.

[0119] Specifically, the modular task management system based on dynamic process configuration described in this invention includes a visual interactive interface module comprising:

[0120] The mold list area, connected to the task status transition engine, dynamically loads the regional task list based on the enterprise-specific process topology and displays the process path relationships, specifically including:

[0121] Extract the real-time region identifier field from the change management master table, and parse the number and status of tasks in the current region;

[0122] Generate a tree structure view based on process type classification labels, and label the real-time task volume and node jump path of each area;

[0123] When a user selects a specific area, the associated task data is located through the mapping relationship between the task ID and the area identifier, and the current area and associated nodes are highlighted simultaneously.

[0124] The quick query area, linked to the mold list area and task status data, integrates an SQL parsing engine to execute cross-database structured query commands, covering file database association retrieval within the task status data, specifically including:

[0125] It receives query conditions input by the user and converts them into executable instructions for the target database through an SQL parsing engine;

[0126] Retrieve matching task records from the file database and map them to the task list in the mold list area through the association between task ID and area identifier, dynamically refreshing the interface display;

[0127] It supports sorting or filtering query results by task attributes and synchronously updating task status through the aforementioned change management master table;

[0128] The image preview area, linked to the mold list area and the task and resource mapping table, retrieves image data via task ID index and renders part drawings and mold drawings in real time. Specifically, it includes:

[0129] Based on the task ID selected in the mold list area, retrieve the task and resource mapping table to obtain the associated part 3D model file path and mold design drawing storage address;

[0130] It calls the graphics rendering engine to load image resources and generate a high-precision preview view, supporting zoom, rotation and cross-sectional viewing operations.

[0131] When the real-time region identifier field in the task status data changes, the consistency of image resources is verified by version tagging, and the latest version of the design drawings is automatically loaded.

[0132] The template list area of ​​the visual interactive interface module is connected to the task status flow engine, dynamically loading regional task lists based on the enterprise's proprietary process topology. The template list area extracts the real-time regional identifier field from the change management master table, parses the current task quantity and status of the region, and generates a structured dataset containing task IDs, task titles, and execution progress. A tree-structured view is generated based on process type classification tags, marking the real-time task volume and node jump paths for each region, for example, using different colors to distinguish high-priority regions or timed-out tasks. When a user selects a specific region, the system locates the associated task data through the mapping relationship between task IDs and region identifiers, synchronously highlighting the current region and associated nodes, and displaying task details in the sidebar, including creation time, responsible personnel, and operation logs, achieving dynamic linkage between task status and interface elements.

[0133] The quick query area is linked with the mold list area and task status data, integrating an SQL parsing engine to execute cross-database structured query commands. User-inputted query conditions are converted into executable commands for the target database by the SQL parsing engine; for example, natural language filtering conditions are parsed into SQL statements with time ranges or status filters. The system retrieves matching task records from the file database and maps them to the task list in the mold list area through the association between task IDs and region identifiers, dynamically refreshing the interface display. Query results support sorting or filtering by task attributes, such as sorting by priority in descending order or displaying only incomplete tasks. Simultaneously, task status is updated synchronously through the change management master table, triggering real-time updates of the tree view in the mold list area to maintain data consistency.

[0134] The image preview area is linked with the mold list area and the task and resource mapping table. Image data is retrieved via task ID index, and part and mold drawings are rendered in real time. When a user selects a task ID in the mold list area, the system searches the task and resource mapping table to obtain the path to the associated 3D model file of the part and the storage address of the mold design drawing. The graphics rendering engine loads the image resources, generating a high-precision preview view that supports zooming, rotation, and cross-sectional viewing operations, such as using WebGL technology to enable 3D model interaction on the browser side. When the real-time area identifier field in the task status data changes, the system verifies the consistency of image resources through version marking, such as comparing the version number of the design drawing with the latest version associated with the current task area identifier. It automatically loads the latest resources and updates the preview view, avoiding image display lag due to task status migration. Data interaction between functional areas is based on a unified data bus. Task status changes trigger collaborative updates of interface elements, achieving visualization and operational closure of the task management process.

[0135] Specifically, the modular task management system based on dynamic process configuration described in this invention stores the following data in the historical trajectory tracing module:

[0136] Basic task attribute data, including task ID, task title, creator information, and the type of process to which it belongs;

[0137] Real-time area identifier change sequence records the flow path of tasks in the process topology and stores area identifier change records in chronological order, including the current area identifier and historical area identifier sequence;

[0138] A timestamp sequence that marks the time dimension information of task creation time, estimated completion time, actual completion time, and key operation nodes;

[0139] The historical trajectory tracing module constructs a task lifecycle record chain in the following ways:

[0140] The data synchronization mechanism is to use an atomic transaction lock mechanism to incrementally synchronize the real-time area identifier field and operation information to the historical record table when the task status flow engine updates the change management master table, thereby generating an unalterable operation trajectory.

[0141] The index construction rule is to use the task ID as the primary index in the history table to associate the task's basic attributes and the sequence of changes in the region identifier, and use the timestamp as the secondary index to arrange the data records in the order of operation, forming a combined index of task ID and timestamp.

[0142] Forward process backtracking involves retrieving the region identifier change sequence from the historical record table based on the task ID, generating a visual flowchart in timestamp order, and marking the operation time, execution role, and associated operation instructions for each node.

[0143] Reverse operation tracing involves reversing the history of task status changes based on timestamp indexes, locating the predecessor and successor states of specific operation nodes, and extracting associated operation logs and context data for abnormal operation rollback or fault analysis.

[0144] The historical trajectory tracking module stores basic task attribute data, including task ID, task title, creator information, and associated process type. This data is persistently stored in a structured data table, with the task ID serving as a unique identifier linked to the entire task lifecycle. The real-time region identifier change sequence records the task's flow path within the process topology, storing the current region identifier and historical region identifier sequences in chronological order. Incremental storage only records the differences before and after field changes, reducing storage redundancy. The timestamp sequence marks the task creation time, estimated completion time, actual completion time, and time dimension information of key operation nodes, stored in the ISO standard format, supporting cross-timezone time synchronization and calculation.

[0145] The historical trajectory tracking module constructs a complete task lifecycle record chain through a data synchronization mechanism. When the task status transition engine updates the change management master table, the system uses an atomic transaction lock mechanism to incrementally synchronize the real-time region identifier field and operation information to the historical record master table. This atomic transaction lock mechanism employs a two-phase commit protocol. In the pre-commit phase, the target data record is locked and a transaction log is generated. In the formal commit phase, the changed data is written to the historical record master table in batches, simultaneously generating an immutable operation trajectory containing operation type, user role, and timestamp. The transaction log generates a unique digest value using a hash algorithm, which, combined with the timestamp, forms an anti-tamper verification tag, providing technical assurance for data integrity.

[0146] The index construction rules establish a composite index in the historical record table, using the task ID as the primary index and the timestamp as the secondary index. The primary index associates the task's basic attributes with the sequence of region identifier changes, enabling fast retrieval of the complete workflow by task ID. The secondary index arranges data records in chronological order of operation time, supporting filtering of specific operation nodes by time range. The composite index uses a B+ tree structure to optimize query efficiency, allowing for a mix of range queries and exact searches, such as retrieving all region identifier change records for a task within a specified time window, or locating operation context data at a specific time point.

[0147] The forward process backtracking retrieves the region identifier change sequence from the historical record table based on the task ID and generates a visual flowchart in timestamp order. The system extracts basic task attributes, region identifier change records, and timestamp sequences, and uses a graphics rendering engine to generate a flowchart that includes node jump paths, operation times, and executing roles. Flowchart nodes are labeled with operation instruction types, such as "Jump to review node" or "Revert to correction node," and colors are used to distinguish normal operations from abnormal events; for example, red marks nodes that have timed out and not been processed. The visual flowchart supports interactive operation; clicking on a node allows viewing associated operation logs and contextual data.

[0148] Reverse operation tracing is based on timestamp indexing to reverse-parse the task state change history. When an abnormal operation is detected or a rollback is required, the system reverse-traverses the historical record table based on timestamps to locate the operation node that caused the abnormality and extract the predecessor and successor state data. For example, when a task is rolled back due to data conflict, the reverse tracing module retrieves the timestamp and region identifier of the most recent valid state, triggering the task state transition engine to restore it to that state. Related operation logs and context data are restored through transaction logs, including user operation commands, resource change records, and system alarm information, providing a complete data chain for fault analysis. A version marking mechanism verifies data consistency and prevents state errors caused by data version conflicts during the recovery process.

[0149] Specifically, the modular task management system based on dynamic process configuration described in this invention includes the following modular extension interfaces:

[0150] The process extension interface is used to allow the fields of the structured data table to be extended when adding new regional nodes, while maintaining compatibility with existing process topologies;

[0151] The function extension interface is used to embed third-party business modules into the task state transition engine through reserved hook functions;

[0152] The interface extension interface is used to dynamically load new functional components into the visual interactive interface module using a plug-in architecture.

[0153] The modular extension interface's process extension interface is used to expand the fields of the structured data table when adding new regional nodes. This interface uses dynamic table structure management technology to add custom attribute fields, such as "priority" or "urgency," to the original regional process metadata table. The newly added fields are dynamically bound to the enterprise-specific process topology structure via the process template ID, generating a process instance containing the extended fields. The system distinguishes between old and new data modes using version numbers. When loading the process topology structure, it automatically identifies the version number and adapts to the corresponding data table structure, allowing for a smooth transition between old and new nodes. Compatibility between new and existing fields is achieved through preset data conversion rules, such as filling new fields with default values ​​from older versions, preventing process logic interruptions caused by field expansion.

[0154] The functional extension interface embeds third-party business modules into the task state transition engine through reserved hook functions. These hook functions are pre-defined at key nodes in the task state transition, such as triggering permission verification before a region identifier change or triggering data archiving after a change. Third-party business modules connect via a standardized interface protocol, defining input parameters as task ID, region identifier, and operation context, and output parameters as operation instructions or verification results. For example, when integrating a quality inspection module, the system calls this module to perform parameter compliance checks before the task jumps to the final review node; if the check fails, a state rollback is triggered. The interface enables independent deployment of modules through dynamic link libraries or a microservice architecture, ensuring the stability of the core engine while supporting hot loading and unloading to adapt to dynamic adjustments in business processes.

[0155] The interface extension uses a plug-in architecture to dynamically load newly added functional components into the visual interactive interface module. This plug-in architecture is based on a component registration mechanism, defining the resource paths, dependencies, and permission requirements of new components through configuration files. For example, when adding a data analysis panel, the system loads the corresponding front-end component file and registers it in the extended function area of ​​the template list, dynamically binding the data source through the association between task ID and region identifier. Plug-in components share the same data bus with the core interface, responding in real-time to data updates in the change management master table; for example, when task status migrates, the data analysis panel automatically refreshes statistical charts. This architecture isolates the plug-in runtime environment through a sandbox mechanism to prevent resource conflicts between components, while supporting on-demand loading and unloading, optimizing system performance and resource utilization.

[0156] Each extended interface collaborates through data flow and an event-driven mechanism. New fields added to the process extended interface are synchronized to the hook function parameter list of the functional extended interface via the process template ID, driving the logical adaptation of third-party business modules. For example, when a "urgent task" field is added, the functional extended interface calls the emergency task processing module during state transitions to adjust the jump condition threshold. The execution results of the functional extended interface notify the plugin components of the interface extended interface via the event bus, triggering dynamic rendering of interface elements. The display logic of newly added components is bound to the data source; for example, the emergency task highlighting plugin dynamically adjusts the color markers based on the field values ​​of the process extended interface. The standardized data access specifications and event-driven architecture of the modular extended interfaces support the system's dynamic functional expansion without refactoring core modules, adapting to diverse needs across enterprise scenarios.

[0157] The technical solution of this invention is explained as follows:

[0158] Dynamic Process Configuration Model and Algorithm: The dynamic process configuration module dynamically binds enterprise configuration data with regional process metadata through process template IDs, generating an enterprise-specific process topology. The process template ID serves as the core association key, calling pre-configured regional process metadata (including regional identifier, process version number, and category tags) and enterprise configuration data (such as node display rules and role-based permission policies) for dynamic mapping through structured data tables. For example, the two-way binding technology between regional identifiers and node numbers establishes a correspondence between logical nodes and physical operations, and the process version number supports the coexistence of multiple version process instances. When adding a new regional node, the dynamic table structure management algorithm expands the data table fields, marking the old and new data patterns with version numbers, automatically adapting during loading to avoid process logic conflicts. The decoupling design of enterprise configuration data and process definition data allows for independent updates to display rules or business rules, adapting to the deployment needs of different enterprises.

[0159] The task state transition engine employs atomic transaction locks and verification algorithms: Based on an event-driven model, the engine triggers state transitions and ensures data consistency through atomic transaction locks. In cross-region operations, a two-phase commit protocol is used: the pre-commit phase locks the associated region identifier field and verifies preconditions (such as resource allocation status); the formal commit phase batch updates the real-time region identifier field and timestamp sequence, and rolls back to the pre-operation state in case of conflicts. Rollback operation verification is based on dynamic rule-based data algorithms, including rollback threshold verification (such as maximum rollback count) and rollback path validity judgment (such as retrieving a set of valid paths based on the rollback reason). For example, when the rollback reason is "design error," the engine only allows a jump to the correction node; otherwise, it intercepts the operation and generates an exception alarm log.

[0160] Data Linkage and Rendering Algorithms for the Visual Interactive Interface: The visual interactive interface module achieves data linkage through a task-resource mapping table and a cross-database query algorithm. The mold list area, based on the real-time area identifier field of the change management master table, uses a tree-structure generation algorithm to dynamically render the area task list, marking task volume and jump paths. The quick query area integrates an SQL parsing engine, converting user-input natural language conditions into target database query commands. Search results are mapped to the interface via task IDs and refreshed in real time. The image preview area uses a graphics rendering engine (such as WebGL) to load 3D models and design drawings, automatically loading the latest resources through a version tag verification algorithm. For example, when the task status changes, the design drawing version number is compared with the latest version associated with the current area identifier to prevent resource display lag.

[0161] Historical trajectory tracing index construction and synchronization algorithm: The historical trajectory tracing module optimizes data retrieval efficiency through a combined index algorithm. The task ID serves as the primary index, associating the task's basic attributes and the sequence of changes to regional identifiers. Timestamps serve as secondary indexes, arranging records in operation order. A B+ tree structure is used to accelerate range queries (e.g., retrieving operation records within a specific time period). Data synchronization is based on an incremental storage algorithm, recording only differences in field changes. An atomic transaction lock mechanism writes real-time incremental data to the historical record table, generating an immutable operation trajectory containing a hash digest. Forward process backtracking reconstructs the task flow path using a visual flowchart generation algorithm. Reverse tracing uses timestamps to reverse-analyze the operation history, locating abnormal nodes and extracting contextual data (such as operation logs and resource change records).

[0162] The modular extension interface utilizes an event-driven and pluggable algorithm: It dynamically expands through hook functions and a pluggable architecture algorithm. Functional extension interfaces pre-set hooks at key nodes in task state transitions (such as before a region identifier change). Third-party modules connect via standardized interface protocols, inputting parameters including the task ID, region identifier, and operation context, and outputting verification results or operation instructions. For example, the quality inspection module verifies parameter compliance before the final review node, triggering a rollback upon failure. Interface extension interfaces use a sandbox isolation algorithm to dynamically load pluggable components, responding to changes in the master change management table via a data bus. When adding fields to the process extension interface, a version adaptation algorithm ensures compatibility between old and new topologies; for example, old data is automatically populated with default values ​​to avoid process interruptions.

[0163] This invention, specifically implemented using a modular task management system based on dynamic process configuration, addresses the problems of poor cross-enterprise deployment adaptability, unintuitive task status display, and rigid process logic caused by fixed process configurations in existing technologies. It achieves technical optimization through modular design and a dynamic binding mechanism. The dynamic process configuration module constructs a structured data table based on pre-configured regional process metadata and enterprise configuration data, dynamically binding enterprise configuration data to process metadata via process template IDs. Regional process metadata includes a regional identifier, process version number, and process type classification label. Enterprise configuration data includes node display rules bound to the enterprise ID and button visibility rules associated with role permissions. The process template ID serves as the association key, generating an enterprise-specific process topology. For example, binding the "Production Approval" process template to the node display rules of enterprise A creates a process instance adapted to enterprise A. The structured data table reserves extended fields through dynamic table structure management technology. When a new regional node is added, the fields are extended and marked with a version number. During loading, it automatically adapts to the old and new data patterns, supporting rapid deployment in cross-enterprise scenarios.

[0164] The task status transition engine parses the validity of region identifiers based on the enterprise-specific process topology and triggers state transitions through event-driven mechanisms. When a user triggers a task transition operation, the engine extracts node jump conditions from dynamic rule data and matches them with task status parameters, such as verifying whether the number of tasks in the completed region has reached a threshold. If the conditions are met, the real-time region identifier field is updated through an atomic transaction lock mechanism, and a two-phase commit protocol is used to handle data consistency across regions: in the pre-commit phase, associated fields are locked and preconditions are verified; in the formal commit phase, data is updated in batches, and in case of conflicts, the system rolls back to the state before the operation. When a rollback operation is executed, the number of rollbacks and the validity of the path are verified based on the rollback policy configuration, for example, restricting "design error" type rollbacks to only allow jumps to the correction node. Change records are synchronously backed up to the history master table, generating transaction logs containing operation type, timestamp, and user information, providing a data foundation for historical traceability.

[0165] The visual interactive interface module loads the process topology structure to generate a multi-region parallel display interface. The mold list area dynamically renders a region tree view based on the real-time region identifier field in the change management master table, marking the number of tasks and jump paths. The quick query area uses an SQL parsing engine to convert user commands, retrieves task records across databases, and maps them to the task list. The image preview area calls the task-resource mapping table to load 3D models and design drawings, and version marking verifies resource consistency. Modular extension interfaces support functional expansion through standardized data specifications: the process extension interface is compatible with existing topologies when adding fields; the functional extension interface embeds a quality inspection module through hook functions to perform compliance checks before state migration; the interface extension interface uses a plug-in architecture to load the data analysis panel and responds to task state changes through a data bus. Each module collaborates based on event-driven mechanisms. For example, when an urgent task field is added, the functional extension interface adjusts the jump conditions, and the interface plug-in highlights the urgent task, achieving dynamic adaptation of process logic, business rules, and interactive functions, improving operational efficiency and system scalability across enterprise scenarios.

[0166] This invention addresses the technical problem of poor cross-enterprise deployment adaptability in existing systems through a dynamic process configuration module. The dynamic process configuration module dynamically binds enterprise configuration data with regional process source data based on process template IDs, generating an enterprise-specific process topology structure that includes regional identifiers, node relationships, and process category tags. Enterprise configuration data includes node display rules and role-based access control policies. A structured data table decouples this data from the process definition data, allowing enterprises to independently adjust interface display logic or business rules to adapt to the process needs of different organizations. The process template ID supports the coexistence of multiple version process instances. When adding a new regional node, fields are expanded through a dynamic table structure, ensuring compatibility with existing topologies and enabling rapid deployment and flexible adaptation across enterprise scenarios.

[0167] The visual interactive interface module addresses the issue of unintuitive task status display through a multi-region parallel display mechanism. The mold list area dynamically renders a tree-structured view of regions based on the real-time region identifier field in the change management master table, annotating the number of tasks and jump paths. The quick query area integrates an SQL parsing engine, performing cross-database structured searches, mapping query results to the task list, and refreshing the interface in real time. The image preview area calls the task-resource mapping table, loading associated 3D models and design drawings based on the task ID, supporting interactive operations. All zones are linked through a unified data bus; changes in task status trigger collaborative updates of interface elements. For example, when the region identifier field is updated, the latest version of the drawings is automatically loaded, achieving real-time synchronization between task status and resource presentation.

[0168] The modular extension interface addresses the inflexibility of process logic adjustments by adopting standardized data access specifications. The process extension interface allows for the expansion of structured data table fields when adding new regional nodes, achieving a smooth transition between old and new process topologies based on version number markers. The function extension interface embeds third-party business modules through pre-defined hook functions, performing compliance checks or triggering related logic at key nodes during task state migration. The interface extension interface uses a plug-in architecture to dynamically load components, isolating the runtime environment through a sandbox mechanism while sharing a data bus. All interfaces collaborate based on an event-driven mechanism; new fields drive the adaptation of functional module logic, and execution results trigger the rendering of interface components. This supports the dynamic expansion of process rules, business logic, and interactive functions without refactoring the core architecture, meeting the flexible adjustment needs across enterprise scenarios.

Claims

1. A modular task management system based on dynamic process configuration, characterized in that, include: The dynamic process configuration module is used to build a structured data table based on the pre-configured regional process original data and enterprise configuration data. It dynamically binds the enterprise configuration data and process original data through the process template ID, and configures an enterprise-specific process topology structure including regional identifier, next node association relationship and process type classification label. The task status transition engine is connected to the dynamic process configuration module. It receives the enterprise-specific process topology, parses the legality of the current region identifier and the existence of the target node, triggers task status migration based on event-driven mechanism, updates the real-time region identifier field in the task status data through atomic transaction lock mechanism, and synchronizes the updated real-time region identifier field and associated operation instructions to the change management master table. The visual interactive interface module is connected to the task status flow engine and is used to load the process topology to generate an interface for parallel display of multiple regions. Based on the real-time region identifier field in the change management master table, it dynamically renders the region tree structure and its real-time task volume, and integrates cross-database query function and task and resource mapping table to call associated image data. The historical trajectory tracking module is connected to the task status flow engine. Based on the real-time area identifier field and timestamp sequence in the change management master table, it constructs a task lifecycle record chain and stores the area identifier change sequence and operation information. The modular extension interface connects to the dynamic process configuration module and the visual interactive interface module. It is used to extend process nodes, functional components and interface plugins through standardized data access specifications, update the structured data table based on the newly added regional nodes, and dynamically load third-party business modules to the visual interactive interface.

2. The modular task management system based on dynamic process configuration as described in claim 1, characterized in that, The data defined by the dynamic process configuration module includes: Process definition data includes the region identifier, process version number, and process type classification label from the original data of the regional process; Enterprise configuration data, including node display rules bound to the enterprise ID and button visibility rules associated with role permissions; Dynamic rule data, including node jump conditions, fallback strategy configuration, and automatic archiving trigger rules in the dynamic rule configuration; The process template ID dynamically binds the process definition data with the enterprise configuration data to generate an enterprise-specific process instance, and updates the real-time region identifier field in the task status data through the mapping relationship between the region identifier and the task ID.

3. The modular task management system based on dynamic process configuration as described in claim 2, characterized in that, Also includes: The dynamic process configuration module establishes a dynamic mapping mechanism for regional nodes through a two-way binding technology between regional identifiers and node numbers, generating an enterprise-specific process topology structure that includes the mapping relationship between regional identifiers and physical node numbers. When a user triggers a task flow operation, the task status flow engine parses the node number corresponding to the current regional identifier based on the enterprise-specific process topology structure, and determines the target regional identifier and associated operation instructions according to the association relationship of the next node. The task status transition engine submits the target area identifier and operation instructions to the change management master table, updates the real-time area identifier field in the task status data through the atomic transaction lock mechanism, and simultaneously backs up the change records to the history record master table to form an unalterable operation trajectory. When the task status transition engine performs a rollback operation, it verifies whether the number of rollbacks for the current task exceeds the maximum rollback threshold based on the rollback strategy configuration in the dynamic rule data. It also searches for allowed rollback paths in the enterprise-specific process topology according to the rollback reason classification and verifies whether the target area identifier is within the set of legal paths. If the verification passes, the task status data is updated; otherwise, the operation is intercepted and an abnormal alarm log is generated.

4. The modular task management system based on dynamic process configuration as described in claim 3, characterized in that, The task status transition engine executes the following verification rules: Before the task state transition, based on the conditional triggering rules in the dynamic rule data, verify whether the jump condition of the current region identifier meets the preset threshold, including: Extract the node jump conditions associated with the current region identifier from the dynamic rule data and match them with the operation parameters in the task status data; If the jump condition meets the preset threshold, an operation instruction that allows migration is generated; otherwise, an alarm is triggered and the process is terminated. In cross-regional operations, if the task state transition involves updating multiple region identifiers, a two-phase commit protocol is used to handle data consistency in the change management master table, including: Pre-commit phase: Lock all associated region identifier fields and verify whether the status of each region node meets the commit conditions; The formal submission phase involves updating the real-time region identifier field and timestamp sequence in the task status data in batches using an atomic transaction lock mechanism if the pre-submission verification passes; if a conflict exists, the system rolls back to the state before the operation. Before the operation command is executed, the access control model associated with the role permissions dynamically verifies whether the user role has the operation permissions corresponding to the current area identifier, including: Based on the real-time area identifier in the task status data, retrieve the list of allowed operations from the role permission rule base; If the user's role permissions do not match the target operation command, the operation will be intercepted and a permission alert log will be generated.

5. The modular task management system based on dynamic process configuration as described in claim 4, characterized in that, The visual interactive interface module includes: The mold list area, connected to the task status transition engine, dynamically loads the regional task list based on the enterprise-specific process topology and displays the process path relationships, specifically including: Extract the real-time region identifier field from the change management master table, and parse the number and status of tasks in the current region; Generate a tree structure view based on process type classification labels, and label the real-time task volume and node jump path of each area; When a user selects a specific area, the associated task data is located through the mapping relationship between the task ID and the area identifier, and the current area and associated nodes are highlighted simultaneously. The quick query area, linked to the mold list area and task status data, integrates an SQL parsing engine to execute cross-database structured query commands, covering file database association retrieval within the task status data, specifically including: It receives query conditions input by the user and converts them into executable instructions for the target database through an SQL parsing engine; Retrieve matching task records from the file database and map them to the task list in the mold list area through the association between task ID and area identifier, dynamically refreshing the interface display; It supports sorting or filtering query results by task attributes and synchronously updating task status through the aforementioned change management master table; The image preview area, linked to the mold list area and the task and resource mapping table, retrieves image data via task ID index and renders part drawings and mold drawings in real time. Specifically, it includes: Based on the task ID selected in the mold list area, retrieve the task and resource mapping table to obtain the associated part 3D model file path and mold design drawing storage address; It calls the graphics rendering engine to load image resources and generate a high-precision preview view, supporting zoom, rotation and cross-sectional viewing operations. When the real-time region identifier field in the task status data changes, the consistency of image resources is verified by version tagging, and the latest version of the design drawings is automatically loaded.

6. The modular task management system based on dynamic process configuration as described in claim 5, characterized in that, The historical trajectory tracing module stores the following data: Basic task attribute data, including task ID, task title, creator information, and the type of process to which it belongs; Real-time area identifier change sequence records the flow path of tasks in the process topology and stores area identifier change records in chronological order, including the current area identifier and historical area identifier sequence; A timestamp sequence that marks the time dimension information of task creation time, estimated completion time, actual completion time, and key operation nodes; The historical trajectory tracing module constructs a task lifecycle record chain in the following ways: The data synchronization mechanism is to use an atomic transaction lock mechanism to incrementally synchronize the real-time area identifier field and operation information to the historical record table when the task status flow engine updates the change management master table, thereby generating an unalterable operation trajectory. The index construction rule is to use the task ID as the primary index in the history table to associate the task's basic attributes and the sequence of changes in the region identifier, and use the timestamp as the secondary index to arrange the data records in the order of operation, forming a combined index of task ID and timestamp. Forward process backtracking involves retrieving the region identifier change sequence from the historical record table based on the task ID, generating a visual flowchart in timestamp order, and marking the operation time, execution role, and associated operation instructions for each node. Reverse operation tracing involves reversing the history of task status changes based on timestamp indexes, locating the predecessor and successor states of specific operation nodes, and extracting associated operation logs and context data for abnormal operation rollback or fault analysis.

7. The modular task management system based on dynamic process configuration as described in claim 6, characterized in that, The modular extension interface includes: The process extension interface is used to allow the fields of the structured data table to be extended when adding new regional nodes, while maintaining compatibility with existing process topologies; The function extension interface is used to embed third-party business modules into the task state transition engine through reserved hook functions; The interface extension interface is used to dynamically load new functional components into the visual interactive interface module using a plug-in architecture.

Images