Dynamic process management method and device based on Java and medium

Abstract

The invention discloses a Java-based dynamic process management method, Java-based dynamic process management equipment and a medium. The technical problem that a traditional workflow engine has inherent defects in the aspects of dynamics, expansibility and reliability is solved. The method comprises the following steps: receiving a process definition file, loading a plug-in node parser based on a Java SPI (Serial Peripheral Interface) mechanism, and dynamically parsing node logic in the process definition file; splitting the analyzed process definition into sub-tasks, and distributing the sub-tasks to a working node cluster based on a ZooKeeper coordination service; and calling the local cache through the working node to execute the corresponding subtask, and synchronizing the task state to the management layer node through the event bus. Through the method, version switching can be completed without restarting a system, the service iteration efficiency is improved, the task is allocated to the resource idle node according to the load state, the problem of single-point overload is effectively avoided, local cache data is preferentially read, and frequent access to a central database is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of process management, and in particular to a Java-based dynamic process management method, device and medium. BACKGROUND

[0002] The business process management in current enterprise-level applications generally adopts a Java-based workflow engine implementation, however, the traditional scheme has significant defects in dynamic updating, distributed collaboration and performance optimization. Since the process definition is usually pre-compiled to the system in a static manner, any change in business logic requires re-deployment of the engine, resulting in increased system downtime and difficulty in adapting to rapidly iterating business requirements. Especially for long-running process instances, the incompatibility between the new and old definitions after version upgrade often causes data inconsistency problems, which require manual intervention for migration, resulting in high operation and maintenance costs.

[0003] Under a distributed architecture, the task scheduling mechanism of the traditional workflow engine has serious deficiencies. It adopts a fixed-weight load distribution strategy, which cannot real-time perceive node resource fluctuations, resulting in overloading of some work nodes while other nodes are idle, and low overall resource utilization. At the same time, process state queries rely on centralized databases, and frequent IO operations in high-concurrency scenarios become a performance bottleneck, and the response delay of process instances increases exponentially with the load. In addition, cross-system process collaboration mostly uses tightly coupled API calls, lacks transaction compensation mechanisms, and when some services fail, it is difficult to ensure global consistency, significantly increasing the risk of business interruption.

[0004] Existing technologies have weak dynamic optimization capabilities for process paths, only supporting pre-defined routing rules, and cannot intelligently adjust the execution path based on real-time context. For example, in an approval flow scenario, even if some steps lose their execution significance due to changes in conditions, the system still mechanically executes all nodes, resulting in resource waste. Although some schemes attempt to introduce a rule engine, the decision logic is separate from the process engine, requiring the maintenance of two sets of systems, resulting in complex architecture and reduced execution efficiency. SUMMARY

[0005] The embodiments of the present application provide a Java-based dynamic process management method, device and medium to solve the above technical problems.

[0006] In one aspect, the embodiments of the present application provide a Java-based dynamic process management method, comprising: receiving a process definition file and loading a plug-in node parser based on a Java SPI mechanism to dynamically parse the node logic in the process definition file; splitting the parsed process definition into sub-tasks and distributing the sub-tasks to a work node cluster based on a ZooKeeper coordination service; The local cache is invoked by the worker node to execute the corresponding subtask, and the task state is synchronized to the management layer node through the event bus.

[0007] In an implementation manner of the present application, the node logic in the process definition file is dynamically parsed, specifically including: A version change event of the process definition file is listened to, and an update notification is sent to a running process instance through a message queue in a case where the version change is listened to; The process instance is subjected to version compatibility checking to identify a process instance to be updated, and a loading event of the new version of the process definition is listened to; According to a preset transition strategy, a target process instance in running is suspended, and after the loading of the new version of the process definition is completed, the execution of the target process instance is resumed.

[0008] In an implementation manner of the present application, the process instance is subjected to version compatibility checking to identify a process instance to be updated, specifically including: The node ID of the target process instance is compared with the node ID of the new version of the process definition respectively, and the routing path of the target process definition is compared with the routing path of the new version of the process definition; In a case where the downstream node of the running process instance is detected to be inconsistent with the new version of the process definition, a version conflict marker is generated, and based on the version conflict marker, automatic rollback to the last stable version is triggered.

[0009] In an implementation manner of the present application, according to a preset transition strategy, a target process instance in running is suspended, and after the loading of the new version of the process definition is completed, the execution of the target process instance is resumed, specifically including: In a case where the process instance is at a manual approval node, the process instance is continuously executed until the process instance is subjected to version switching after the approval is completed; In a case where the process instance is at an automated service node, the current execution context is saved, and the process instance is subjected to version switching; After the version switching of the process instance is completed, the operation of an unfinished node is rolled back through a distributed transaction compensation mechanism.

[0010] In an implementation manner of the present application, the subtasks are distributed to the worker node cluster based on a ZooKeeper coordination service, specifically including: Each worker node is subjected to real-time monitoring, and based on the monitoring data, the load weight corresponding to each worker node is calculated; the monitoring data includes CPU utilization, memory occupation and task queue length; determining whether the load weight of the worker node exceeds a preset load threshold, and if not, assigning the subtask to the worker node with the lowest load weight among the worker nodes; If the load weight of all worker nodes exceeds the threshold, a new worker node is started to join the worker node cluster, and the new worker node is assigned a corresponding subtask.

[0011] In an implementation manner of the application, the method further includes: receiving a rollback instruction and a target version for a target process instance, and extracting a process definition corresponding to the target version from a preset version library; suspending running of the current process instance, restoring instance data state of the target version to a worker node corresponding to the target process instance, and restarting execution of the target process instance based on the restored worker node.

[0012] In an implementation manner of the application, the task state is synchronized to the management layer node through an event bus, and specifically includes: a worker node encapsulates a task state change corresponding to the target process instance into a DTO object, and publishes the DTO object to the event bus through a REST API; based on a subscription trigger of the management layer node to the event bus, the task state change is synchronized to the management layer node through the event bus, and based on the task state change, a global process instance state library is updated, and a local cache is cleaned up.

[0013] In an implementation manner of the application, a process definition file is received, and a plug-in node parser is loaded based on a Java SPI mechanism, and specifically includes: the process model is parsed to generate standardized process definition data; the process definition is converted into a JSON format, and the process definition in the JSON format is stored to a version control database; when a process instance is started, a corresponding node plug-in is dynamically loaded according to a current process version.

[0014] On the other hand, the application embodiment also provides a Java-based dynamic process management device, which includes: at least one processor; and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the above-described Java-based dynamic process management method.

[0015] On the other hand, an embodiment of the present application further provides a non-volatile computer storage medium storing computer-executable instructions. When the computer-executable instructions are executed, a Java-based dynamic process management method as described above is implemented.

[0016] The embodiments of the present application provide a Java-based dynamic process management method, device, and medium, which have at least the following beneficial effects: Plug-in node parsing is implemented through the Java SPI mechanism, so that modifications to the process definition can take effect in real time, and version switching can be completed without restarting the system, greatly improving business iteration efficiency; combined with the version compatibility check mechanism, it ensures that running process instances can smoothly transition to the new version, avoiding data inconsistency problems caused by definition changes; based on the ZooKeeper coordination service, intelligent allocation of subtasks is achieved, the load status of each working node is dynamically perceived, and tasks are preferentially assigned to resource-free nodes, effectively avoiding single-point overload problems; through multi-level load balancing strategies, the overall resource utilization of the cluster is significantly improved, and the system throughput is improved; using a combination of local cache and event bus, working nodes give priority to reading local cache data when executing tasks, reducing frequent access to the central database; at the same time, asynchronous synchronization of state changes through the event bus ensures data consistency and reduces network communication overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1 A flowchart of a Java-based dynamic process management method provided in an embodiment of the present application; Figure 2 A schematic diagram of the internal structure of a Java-based dynamic process management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0018] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0019] The following describes in detail the technical solutions provided by various embodiments of the present application in conjunction with the accompanying drawings.

[0020] Figure 1A flowchart of a Java-based dynamic flow management method provided by an embodiment of the present application.

[0021] The analysis method related by the embodiments of the present application can be implemented in a terminal device or a server, and the present application does not make special limitations thereon. For the convenience of understanding and description, the following embodiments are described in detail by taking the server as an example.

[0022] It should be noted that the server can be a single device or a system composed of multiple devices, i.e., a distributed server, and the present application does not make specific limitations thereon.

[0023] As shown in the figure, the Java-based dynamic flow management method provided by the embodiments of the present application comprises the following steps. Figure 1 Step 101, receiving a flow definition file and loading a plug-in node parser based on Java SPI mechanism to dynamically parse the node logic in the flow definition file.

[0024] In the embodiment, the system receives the flow definition file through a file listening service or an API interface. It can be understood that the flow definition file can adopt a BPMN2.0 standard format or a self-defined JSON format, which contains node types, routing rules and other metadata.

[0025] For example, the system registers a parser interface such as NodeParser under the META-INF / services directory through Java SPI mechanism. When a new flow definition is detected, the system will scan the SPI configuration file in the META-INF / services directory under the classpath when starting, and dynamically loads the plug-in class that implements the NodeParser interface. Specifically, each plug-in class corresponds to a node type, such as an approval node, a service calling node, etc., and the plug-in jar package is stored in the plug-in warehouse in accordance with the naming specification of "node type-version number". When a flow definition change is detected, the version management module will compare the differences between the new and old definitions, and only reload the plug-in corresponding to the changed node.

[0026] In the embodiment, the dynamic parsing mechanism further refines the processing logic when the flow definition changes, ensuring that the running process instance can be smoothly transitioned to the new version. Through the cooperative work of event listening, compatibility checking and intelligent transition strategy, the scheme solves the problem that the traditional workflow engine needs to be shut down for migration when updating the version.

[0027] ​It can be understood that the system monitors the changes of the process definition file in real time through a file monitoring service (such as Java WatchService) or a configuration center (such as Nacos, Apollo). For example, when it is detected that the process definition file is modified, the version management module generates a structured version change event, which contains metadata such as change type (such as node addition, attribute modification), impact range label, etc. It should be noted that the event is broadcast through the / version-updates topic of the message queue (such as Kafka or RocketMQ), rather than directly operating the running instance, so as to decouple the version change and the instance execution.

[0028] Specifically, after the message consumer service subscribes to the topic, it will filter out the affected process instances. For example, only instances using the old version definition and whose current state may be affected by the change will be sent an update notification, such as instances upstream of the node to be updated. It can be understood that the notification message carries a new-old version difference summary for subsequent compatibility check.

[0029] In this embodiment, the compatibility check module adopts a double verification strategy: static topology comparison and dynamic context analysis. For example, static comparison checks the node ID mapping relationship and routing path consistency of the new and old versions. Specifically, if it is found that the current node of the running instance has been deleted in the new version, or the instance variable does not meet the input constraint of the new version node, it is marked as “conflict state”. It can be understood that dynamic analysis evaluates the instance execution history, for example, skipping the completed but abandoned nodes in the new version.

[0030] It should be noted that when it is detected that the downstream node is incompatible, such as the new version adds a risk assessment node after the approval node, the system will generate a version conflict label and trigger automatic rollback. For example, the rollback operation extracts the original definition at the instance startup from the version library, and restores the execution context to the latest stable state. For non-conflicting changes, such as only optimizing the node description text, the instance is marked as “updateable” state.

[0031] It can be understood that the system provides multiple preset transition strategies, which are dynamically selected according to business scenarios. Specifically, for manual approval type nodes, the “complete the current processing and then update” strategy is adopted to avoid interrupting the user experience halfway through the approval. For example, the system will freeze the approval form data, and after the approver submits, it will switch the version before executing the next automated node.

[0032] In this embodiment, for the service call class node, the "switch immediately after saving context" strategy is adopted. It should be noted that the system serializes the current node input parameters, service call progress and other context information, and deserializes and recovers after the new version plug-in is loaded. It can be understood that after the version switching is completed, the atomicity of the unfinished operation is checked through the distributed transaction compensation mechanism (such as Saga mode), for example, rolling back the service API that has been called but is no longer needed by the new version.

[0033] It can be understood that the loading process of the new version definition adopts an event-driven architecture. Specifically, the plug-in management service publishes the / plugins-loaded event to the event bus after completing the SPI registration of the new version node plug-in. Illustratively, the event contains plug-in checksum, loading timestamp and other metadata to ensure that the plug-in versions loaded by each worker node are consistent. It should be noted that the instance state recovery operation is triggered only after the transition strategy executor subscribes to the event, avoiding system abnormalities caused by inconsistent plug-in versions between nodes.

[0034] In this embodiment, this mechanism is particularly suitable for gray release scenarios. Illustratively, the administrator can first update the plug-in for part of the node cluster, and then publish the / plugins-loaded event globally after the health check. It can be understood that when the running instance recovers and executes, it will preferentially connect to the updated worker node, realizing seamless transition.

[0035] Step 102, split the parsed flow definition into sub-tasks, and distribute the sub-tasks to the worker node cluster based on the ZooKeeper coordination service.

[0036] In this embodiment, the task splitting module analyzes the DAG structure of the flow model and splits the node groups that can be executed in parallel into atomic sub-tasks. It can be understood that each sub-task encapsulates the execution logic, input data specification and subsequent task dependency.

[0037] Specifically, the ZooKeeper coordination service maintains three key paths of / workers storing active node information, / tasks storing tasks to be assigned, and / assignments recording task assignment relationships. It should be noted that when the worker node starts, it creates a temporary node under / workers and periodically updates the load indicators, including CPU, memory usage, etc.

[0038] Illustratively, the task allocator uses a weight algorithm to calculate the suitability of each node. It can be understood that when a new task is generated, the allocator queries the current load of all nodes under / workers, selects the most suitable node, creates a persistent node under / assignments to record the assignment relationship, and notifies the target worker node to pick up the task through the Watcher mechanism.

[0039] In the embodiment, a multi-level load balancing intelligent task scheduling mechanism is adopted. The first layer is a management layer node which performs global load balancing according to CPU, memory, task queue length and other indicators of the worker node. The second layer is a local scheduling strategy based on priority and task type in the worker node.

[0040] When the task execution fails, automatic retry is performed according to the failure type and number of times, and if the multiple retries fail, a compensation process is triggered to ensure business consistency.

[0041] Step 103, calling the local cache through the worker node to execute the corresponding subtask, and synchronizing the task state to the management layer node through the event bus.

[0042] In the embodiment, the worker node will query the local Guava cache before executing the task, and if the process instance context exists, it will be used directly. It should be noted that the local cache is maintained using the least recently used strategy, and the cache expiration time is linked with the process timeout setting.

[0043] Specifically, the state changes generated by task execution are encapsulated as a unified DTO object. For example, the DTO contains process instance ID, task ID, execution result and other fields, which are published to the state-updates topic of the Kafka event bus through the REST API. It can be understood that after the management layer node subscribes to the topic, it will update the global state library and broadcast the cache invalidation instruction.

[0044] It should be noted that this step also involves an exception handling mechanism. Specifically, when the task execution fails, the worker node will capture the exception and generate a compensation operation log, and publish the compensation instruction through a special transaction compensation topic to ensure the atomicity of operations in a distributed environment.

[0045] In the embodiment, the process instance rollback mechanism provides fast recovery capability in abnormal scenarios. This scheme solves the problem that traditional workflow engines are difficult to roll back to the historical version when the process is abnormal, through the cooperative work of version snapshot management, state restoration and consistency verification.

[0046] It can be understood that the system receives the rollback instruction through the management console API or the event bus. For example, the rollback instruction contains two core parameters: target process instance ID and target version number. It should be noted that the version library adopts a hierarchical storage architecture, in which the latest version is stored in the cache (such as Redis), and the historical version is stored in the object storage (such as MinIO). Specifically, when the rollback instruction is received, the version service will first check the local cache, and if it is not hit, it will extract the process definition file of the target version from the persistent storage.

[0047] The version extraction process includes an integrity check step. For example, the system calculates the MD5 checksum of the downloaded file and compares it with the checksum recorded in the version metadata to ensure that the definition file has not been tampered with. It can be understood that this mechanism provides a reliable data basis for subsequent state restoration.

[0048] It can be understood that after the system receives the rollback instruction, it will immediately send a pause signal to the target worker node. Specifically, the pause operation adopts a two-phase commit protocol, first freezes the task queue of the process instance to prevent new task allocation; then waits for the completion or arrival of the safety breakpoint of the currently executing subtask. It should be noted that this design avoids the generation of "half-finished" tasks during the rollback process.

[0049] In this embodiment, the context saving module captures the complete runtime state of the instance. For example, this includes process variable snapshots, task execution logs, service call records, etc. Specifically, these data are serialized into state snapshot files and temporarily stored in a shared file system. It can be understood that the snapshot file adopts an incremental storage strategy, only recording the state difference relative to the base version, significantly reducing the storage space occupation.

[0050] It should be noted that the state restoration process is divided into two stages: data restoration and dependency reconstruction. For example, the data restoration stage re-injects the process variable values in the snapshot file into the execution context of the worker node; the dependency reconstruction stage re-establishes the association between tasks and services. Specifically, for completed approval tasks, the system will retain the approval result but reset the approval state to "to be processed", ensuring that the rollback can trigger the approval process again.

[0051] In this embodiment, the mechanism works in coordination with the distributed transaction compensation mechanism. It can be understood that during the rollback process, if a cross-system service call is detected, the compensation process will be triggered in reverse. For example, for the email notifications that have been sent, the system will automatically send a cancellation email; for the database records that have been modified, an inverse SQL update will be performed.

[0052] It can be understood that when the state restoration is complete, the system will publish an instance restart event to the event bus. Specifically, after receiving this event, the worker node will re-initialize the process engine state machine and continue execution from the rollback point. It should be noted that the version number of the restarted instance will be specially marked, such as adding the suffix _ROLLBACK, to facilitate subsequent monitoring and identification.

[0053] In this embodiment, the system will continuously monitor the running state of the instance after rollback. For example, if an exception occurs again within a preset time, a secondary rollback alarm will be automatically triggered. It can be understood that this mechanism provides additional security for operation and maintenance personnel, ensuring the continuity of critical business processes.

[0054] The above is a method embodiment of the present application. Based on the same inventive concept, the present embodiment also provides a Java-based dynamic flow management device, the structure of which is shown in Figure 2 .

[0055] Figure 2 An internal structure diagram of a Java-based dynamic flow management device provided by the present embodiment is shown in Figure 2 . The device comprises: at least one processor; and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: receive a flow definition file, and load a plug-in node parser based on a Java SPI mechanism to dynamically parse node logic in the flow definition file; split the parsed flow definition into sub-tasks, and distribute the sub-tasks to a worker node cluster based on a ZooKeeper coordination service; invoke a local cache through a worker node to execute corresponding sub-tasks, and synchronize task status to a management layer node through an event bus.

[0056] The present embodiment also provides a non-volatile computer storage medium, which stores computer executable instructions, and the computer executable instructions, when executed, can: receive a flow definition file, and load a plug-in node parser based on a Java SPI mechanism to dynamically parse node logic in the flow definition file; split the parsed flow definition into sub-tasks, and distribute the sub-tasks to a worker node cluster based on a ZooKeeper coordination service; invoke a local cache through a worker node to execute corresponding sub-tasks, and synchronize task status to a management layer node through an event bus.

[0057] Each of the embodiments in the present application is described in a progressive manner, and the same or similar parts of each of the embodiments can be referred to each other. Each of the embodiments focuses on the differences from other embodiments. In particular, the device and medium embodiments are described simply because they are basically similar to the method embodiments, and the relevant parts can be referred to the part of the method embodiment.

[0058] The device and medium provided by the embodiments of the present application are one-to-one corresponding, and therefore the device and medium also have similar beneficial technical effects to the corresponding method. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the device and medium will not be described here again.

[0059] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. In addition, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage, etc.) containing computer-usable program code.

[0060] The present application is described with reference to flowcharts and / or block diagrams of the method, device (system), and computer program product according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus generate a means for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 one or more flows and / or blocks Figure 1 an apparatus that implements the functions specified in one or more flows and / or blocks.

[0061] These computer program instructions can also be stored in a computer-readable memory that can direct the computer or other programmable data processing apparatus to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including instruction apparatus, which implements the functions specified in the flowcharts and / or block diagrams. Figure 1 one or more flows and / or blocks Figure 1 an apparatus that implements the functions specified in one or more flows and / or blocks.

[0062] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, so that a series of operation steps are performed on the computer or other programmable data processing apparatus to produce a computer-implemented process, so that the instructions executed on the computer or other programmable data processing apparatus provide a means for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 one or more flows and / or blocks Figure 1 an apparatus that implements the functions specified in one or more flows and / or blocks.

[0063] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memories.

[0064] Memory can include non-persistent memory, Random Access Memory (RAM), and / or non-volatile memory, such as Read Only Memory (ROM) or flash memory, in computer readable media. Memory is an example of computer readable media.

[0065] Computer readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital versatile disc (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer readable media does not include transitory media, such as modulated data signals and carrier waves.

[0066] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover a non-exclusive inclusion, such that a process, method, article or apparatus that comprises a list of elements does not include only those elements in the list, but can also include other elements not expressly listed or inherent to such process, method, article or apparatus. Without further limitation, an element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.

[0067] The above only is an embodiment of the present application, and is not intended to limit the present application. The present application can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application shall be included in the scope of claims of the present application.

Claims

1. A Java-based dynamic process management method, characterized in that: The method comprises: Receive the process definition file and load the plug-in node parser based on the Java SPI mechanism to dynamically parse the node logic in the process definition file; Split the parsed process definition into subtasks and assign the subtasks to a cluster of worker nodes based on the ZooKeeper coordination service; The local cache is called through the working node to execute the corresponding subtask, and the task status is synchronized to the management node through the event bus.

2. A Java-based dynamic process management method according to claim 1, characterized in that: Dynamically parse the node logic in the process definition file, specifically including: Monitor the version change events of the process definition file, and when a version change is detected, send an update notification to the running process instance through the message queue; Performing version compatibility checks on the process instances to identify the process instances to be updated, and monitoring loading events of the new version of the process definition; According to the preset transition strategy, the running target process instance is suspended, and after monitoring that the loading of the new version of the process definition is completed, the execution of the target process instance is resumed.

3. A Java-based dynamic process management method according to claim 2, characterized in that: Perform a version compatibility check on the process instance to identify the process instance to be updated, specifically including: Compare the node ID of the target process instance with the node ID of the new version of the process definition, and compare the routing path of the target process definition with the routing path of the new version of the process definition; When it is detected that the downstream node of the running process instance is inconsistent with the new version of the process definition, a version conflict marker is generated, and based on the version conflict marker, an automatic rollback to the previous stable version is triggered.

4. A Java-based dynamic process management method according to claim 2, characterized in that: According to the preset transition strategy, the running target process instance is suspended, and after monitoring the completion of loading the new version of the process definition, the target process instance is resumed. Specifically, it includes: When a process instance is at a manual approval node, continue to execute the process instance until the approval is completed and then switch the version of the process instance; When the process instance is in an automation service node, save the current execution context and perform version switching on the process instance; After the process instance version switch is completed, the operations of the unfinished nodes are rolled back through the distributed transaction compensation mechanism.

5. The Java-based dynamic process management method according to claim 1, characterized in that: Distribute the subtasks to the worker node cluster based on the ZooKeeper coordination service, specifically including: Monitor each work node in real time and calculate the load weight corresponding to each work node based on the monitoring data; the monitoring data includes: CPU utilization, memory usage and task queue length; Determine whether the load weight of the working node exceeds the preset load threshold. If not, assign the subtask to the working node with the lowest load weight among all working nodes; If the load weights of all working nodes exceed the threshold, a new working node is started to join the working node cluster, and corresponding subtasks are assigned to the new working node.

6. The Java-based dynamic process management method according to claim 1, characterized in that: The method further comprises: Receive a rollback instruction and a target version for a target process instance, and extract a process definition corresponding to the target version from a preset version library; The current process instance is paused, and the instance data state of the target version is restored to the working node corresponding to the target process instance, so as to restart the execution of the target process instance based on the restored working node.

7. The Java-based dynamic process management method according to claim 1, characterized in that: Synchronize task status to management nodes through the event bus, including: Encapsulate the task status changes corresponding to the target process instance into a DTO object through the working node, and publish the DTO object to the event bus through the REST API; Based on the subscription trigger of the management layer node to the event bus, the task status change is synchronized to the management layer node through the event bus, and according to the task status change, the global process instance state library is updated and the local cache is cleared.

8. The Java-based dynamic process management method according to claim 1, characterized in that: Receives the process definition file and loads the plug-in node parser based on the Java SPI mechanism, including: Analyze the process model and generate standardized process definition data; Convert the process definition into JSON format and store the JSON formatted process definition in the version control database; When the process instance starts, the corresponding node plug-in is dynamically loaded according to the current process version.

9. A Java-based dynamic process management device, characterized in that: The device comprises: at least one processor; and, a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the Java-based dynamic process management method according to any one of claims 1 to 8.

10. A non-volatile computer storage medium storing computer executable instructions, characterized in that: When the computer-executable instructions are executed, a Java-based dynamic process management method according to any one of claims 1 to 8 is implemented.

Images