Workflow engine implementation method based on event traceability and decentralized monitoring

Abstract

The invention relates to the technical field of informatization, in particular to a workflow engine implementation method based on event traceability and decentralized monitoring, which is based on the design of recording node operation and deducing a process state on the basis of an immutable event sequence, thoroughly relieves the constraint of traditional state table storage on dynamic adjustment, and improves the working efficiency. Operation such as node insertion, skipping or rollback can take effect in real time through runtime metadata reconstruction, meanwhile, a completely stored operation event chain naturally supports full-process audit tracing, and a log system does not need to be additionally developed; a power proportion algorithm decomposes distributed node decisions into three layers of logics of role allocation, predefined result verification and secondary monitoring triggering, cross-service consistency is guaranteed through a post weight adjustment and historical behavior voting dual mechanism, and an online voting mechanism dynamically calculates and processes human weights by using event logs, so that the decision accuracy is improved. Therefore, the technical bottlenecks of rigidity, redundancy and weak consistency of the traditional scheme are overcome.

Description

Technical Field

[0001] This invention relates to the field of information technology, specifically to a workflow engine implementation method based on event tracing and decentralized monitoring. Background Technology

[0002] With the deep application of internet technology in enterprise office collaboration, workflow engines, as the core system supporting various approval processes, directly determine the flexibility and reliability of business processing through their architectural design. However, traditional workflow engines have exposed significant shortcomings when dealing with the complex and ever-changing business processes in China: layered architectures, due to excessive module coupling, struggle to support dynamic process adjustments; any node insertion, skipping, or rollback operation requires hard coding, leading to a surge in development and maintenance costs; while microservice deployment improves scalability, communication overhead between cross-service nodes is high, lacking an effective consistency guarantee mechanism, and process state synchronization is prone to deviations; furthermore, existing solutions rely on centralized decision-making models, which can easily cause process stagnation when nodes malfunction. A deeper problem lies in the fundamental contradiction between static process templates and dynamic business requirements—fixed state table storage methods cannot adapt to runtime structural adjustments, and audit and traceability functions often require the additional development of log systems, further increasing system redundancy. Meanwhile, the bloated architecture of mainstream engines (such as Activiti and Camunda) brings heavy dependencies, not only increasing resource consumption but also hindering the hot updating of business rules. These technical bottlenecks collectively make it difficult for traditional workflow engines to meet the needs of modern enterprises for efficient collaboration in terms of flexibility, consistency, and lightweight design. Summary of the Invention

[0003] The technical problem solved by this invention is to provide a workflow engine implementation method based on event tracing and decentralized monitoring to solve the technical problem that traditional workflow engines are unable to meet the needs of modern enterprises for efficient collaboration in terms of flexibility, consistency and lightweightness.

[0004] The basic solution provided by this invention is a workflow engine implementation method based on event sourcing and decentralized monitoring, comprising the following steps:

[0005] S1: Construct a time-based traceability architecture: Define structured metadata, including node relationships and expected result types; define node operations as immutable events, and associate the event structure with the metadata definition; store events in the log in sequence to ensure timeliness; provide a runtime reflection interface to obtain process class objects; deduce the process state by replaying the event sequence; construct a tree-shaped backtracking structure based on the event sequence;

[0006] S2: Runtime dynamic process changes:

[0007] S201: Listen for metadata change events;

[0008] S202: Obtain the runtime class object through the reflection interface;

[0009] S203: Encapsulate node insertion / skip / rollback operations as events and append them to the log;

[0010] S204: Example of process reconstruction based on new event sequence;

[0011] S3: Node Decision: Assign a processor to each node for approval, and obtain the node processing result by statistically analyzing the approval results according to the weighting algorithm. When the node processing result does not meet the expected result, the weighting algorithm is triggered to recalculate the decision result.

[0012] S4: Drives distributed node execution based on decision results, ensuring consistency of state across service processes.

[0013] Furthermore, S203 includes:

[0014] Node insertion operation: Dynamically inserting nodes into class objects through aspect-oriented programming;

[0015] Rollback operation: Only adds new events, and does not modify historical events.

[0016] Furthermore, the approval result of the processor includes pass and fail, and the expected result includes:

[0017] One vote is sufficient: approval by any processor is considered to meet expectations.

[0018] Percentage Pass: Statistically determines whether the percentage of passes has reached the metadata threshold.

[0019] Furthermore, the rollback operation in S2 is only implemented by appending new events, and modification of historical events is prohibited.

[0020] Furthermore, the weighting algorithm in S3 includes:

[0021] Rule A, when nodes are configured with weighted power:

[0022] a1. Initialize the weights of the processors to the average score;

[0023] a2. If the current result matches the expected result, proceed to the next node; otherwise, execute a3.

[0024] a3. Adjust the weights according to the pre-configured positions, organizations or custom rules, store the processors in the priority queue in descending order of weight, perform polling in the priority queue, and dequeue them in descending order of weight for reprocessing until the result matches the expected result;

[0025] Rule B, when the node uses an online voting mechanism:

[0026] b1. Filter historical relevant handlers from the event log;

[0027] b2. Calculate weights dynamically based on operational behavior, adding 1 for acceptance and subtracting 1 for rejection;

[0028] b3. The decision of the aggregate with the highest weight is the final result.

[0029] Furthermore, step S4 includes the following steps:

[0030] S401: Encapsulate the final decision generated by the weighting algorithm into a standardized event. The event includes node ID, handler, timestamp, and decision-based weight value.

[0031] S402: Broadcast the event to all relevant service instances via a lightweight message queue;

[0032] S403: Each service instance derives the latest process status based on the local event log replay mechanism to ensure status consistency.

[0033] Furthermore, it also includes S5: Fault Tolerance and Incentive Execution:

[0034] a1. Fault tolerance mechanism: By configuring a listener to capture node exceptions, at least one of the following operations is performed:

[0035] Timeout handling: Activate a backup handler for stalled nodes;

[0036] Error migration: Migrate the faulty node to a healthy service instance;

[0037] a2. Incentive Module: Dynamically adjusts resource allocation based on the weight of the processor, including:

[0038] Prioritize allocating computing resources to high-weight processing personnel;

[0039] Grant standby user permissions to the user who has participated in the event a threshold number of times.

[0040] Furthermore, the node insertion operation in S203 includes the following steps:

[0041] S2031: Serialize the acquired class object into structured data;

[0042] S2032: Inserting dynamic node objects into existing class objects using aspect-oriented programming;

[0043] S2033: Deserialize the reconstructed data structure and update the metadata information.

[0044] A workflow engine storage medium based on event sourcing and decentralized monitoring employs any of the aforementioned workflow engine implementation methods based on event sourcing and decentralized monitoring.

[0045] The principles and advantages of this invention are as follows: First, this solution is based on the design of recording node operations and deriving process states using immutable event sequences, completely removing the constraints of traditional state table storage on dynamic adjustments. This allows operations such as node insertion, skipping, or rollback to take effect in real time through runtime metadata reconstruction, improving the response speed to business changes. At the same time, the fully preserved operation event chain naturally supports full-process auditing and traceability without the need for additional log system development. Second, the distributed node decision-making is decomposed into three layers of logic—role allocation, predefined result verification, and secondary monitoring triggering—through a weighted algorithm. Cross-service consistency is ensured through a dual mechanism of job weight adjustment and historical behavior voting. The online voting mechanism uses event logs to dynamically calculate the weight of the processor, improving decision accuracy. Finally, the lightweight architecture dynamically modifies process objects through reflection interfaces and AOP aspects, reducing resource consumption and overcoming the technical bottlenecks of rigidity, redundancy, and weak consistency in traditional solutions. Attached Figure Description

[0046] Figure 1 This is a flowchart illustrating the steps of an embodiment of a workflow engine implementation method based on event tracing and decentralized monitoring according to the present invention. Detailed Implementation

[0047] The following detailed description illustrates the specific implementation method:

[0048] The specific implementation process is as follows:

[0049] Example 1

[0050] Example 1 is attached. Figure 1 As shown, a workflow engine implementation method based on event sourcing and decentralized monitoring is proposed. By utilizing the event sourcing architecture design and decentralized monitoring mechanism algorithm, the coupling problem between node code is eliminated, which improves the ability to cope with various complex and ever-changing business processes. At the same time, it also eliminates the dependence on centralized platforms and does not require heavy reliance on fixed templates.

[0051] Specifically, due to the high module coupling and difficulty in handling complex processes in traditional workflow engines, this embodiment adopts an event sourcing architecture design. This solution first constructs a time-based sourcing architecture: defining structured metadata (XML format) including node relationships and expected result types; defining node operations as immutable events, and associating event structures with metadata definitions; storing events sequentially in logs to ensure timeliness; providing a runtime reflection interface for obtaining process class objects; deriving process states by replaying event sequences; and constructing a tree-like backtracking structure based on event sequences.

[0052] This solution utilizes event-driven architecture to eliminate coupling between node modules. It supports dynamic insertion, skipping, and rollback of process nodes, eliminating the need to predefine a fixed process engine template for each modification or addition. This allows it to handle complex and flexible business processes. Furthermore, with this architecture, the entire process supports audit traceability and has a complete historical record, improving the overall security and stability of the business.

[0053] This solution then monitors the dynamic process at runtime and adapts to greater complexity through dynamic node operations. The steps include:

[0054] S201: Listen for metadata change events;

[0055] S202: Obtain the runtime class object through the reflection interface;

[0056] S203: Encapsulate node insertion / skip / rollback operations as events and append them to the log;

[0057] S204: Example of process reconstruction based on new event sequence.

[0058] Specifically, in this embodiment, a listener is created at each node. When the structured metadata between existing process nodes changes, the object-oriented language allows for runtime dynamic manipulation of its own structure and behavior to retrieve the previously running structured elements and serialize them into defined class objects. Then, using aspect-oriented programming, dynamically added node objects are inserted into the original class objects. The structured data structure is then deserialized, and the original operation records are retrieved to update the new metadata information to the current node. The event sourcing mechanism records all node operations and assigns an immutable state event. When a rollback or other secondary operation occurs, the original data cannot be modified; only new records or states can be added. In other words, rollback operations are only implemented by adding new events, prohibiting modification of historical events, thus obtaining a complete process trajectory record. When tracing the process, it is only necessary to construct all processes as a tree structure and then backtrack based on the selected sourcing node or state, either by degenerating into a linked list or maintaining the original structure. Thus, through the event sourcing architecture design, the code logic implementation between nodes and the engine layer is completed, and the state is changed from directly storing the state table to inferring it from the event sequence.

[0059] Existing engine-level execution processes incur significant overhead for inter-service communication and struggle to guarantee consistency across service processes. This solution addresses this by designing a decentralized monitoring mechanism and utilizing its monitoring algorithms to differentiate the roles of each node, such as node information confirmers and node implementers. When results do not meet expectations, a further monitoring algorithm, such as the weighted algorithm in this solution, ensures normal flow between nodes and flexibly determines the next target node to execute.

[0060] Specifically, in S3, node decision-making involves assigning a processor to each node for approval. The approval results are statistically analyzed using a weighted algorithm to obtain the node's processing result. If the node's processing result does not meet the expected outcome, the weighted algorithm is triggered to recalculate the decision result. This embodiment predefines the expected outcome in the structured metadata, including criteria such as "one-vote approval" and "proportional approval." "One-vote approval" means that approval by any processor is considered to meet the expectation; "proportional approval" refers to whether the statistical approval rate reaches a metadata threshold.

[0061] When approval is performed at a process node, a decision result is obtained through a weighted algorithm based on the approval results of all processors. When the decision result is compared with a predefined result, if it does not meet the expected result, the weighted algorithm is triggered again to recalculate the decision result; otherwise, if it meets the expected result, the process proceeds normally to the next node.

[0062] The weighting algorithm in this embodiment includes two rules:

[0063] Rule A, when nodes are configured with weighted power:

[0064] a1. Initialize the weights of the processors to the average score;

[0065] a2. If the current result matches the expected result, proceed to the next node; otherwise, execute a3.

[0066] a3. Adjust the weights according to the pre-configured positions, organizations or custom rules, store the processors in the priority queue in descending order of weight, perform polling in the priority queue, and dequeue them in descending order of weight for reprocessing until the result matches the expected result;

[0067] Rule B, when the node uses an online voting mechanism:

[0068] b1. Filter historical relevant handlers from the event log;

[0069] b2. Calculate weights dynamically based on operational behavior, adding 1 for acceptance and subtracting 1 for rejection;

[0070] b3. The decision of the aggregate with the highest weight is the final result.

[0071] Specifically, in this embodiment, the power weighting configuration rule can be based on factors such as position, organization, and custom rules, and the processing proportion can be manually adjusted. Based on this, when processing the current node for the first time, all processors are placed in a singly linked list, and the linked list is divided into blocks of equal size to store the results processed by each person. The proportion of each result is equally distributed. If the current result matches the predefined result, it flows to the next node. If it does not match the predefined result, according to the configured power weighting rules, such as position and job, which can affect the result, all processors adjust the proportion of the result according to the influencing factors and put it into a set with PriorityQueue as the key and the original operation behavior list as the value. At this time, the processing set is re-circulated internally, maintaining the original operator behavior, popping from the stack in descending order of proportion, and recalculating the new result. Once a new result matches the expected result, it flows directly through.

[0072] In this embodiment, the online voting mechanism involves placing all processors into a singly linked list when processing the current node for the first time. The linked list is then divided into equal-sized blocks to store the results processed by each person, with each result having an equal weight. If the current result matches a predefined result, the process moves to the next node. If it does not match the predefined result, all records of the personnel and operations involved in the previous process are added to a set. The personnel involved at this time are then selected and placed into a new set. The weights are readjusted based on the number of operations and the current operation behavior, such as by incrementing by 1 and decrementing by 1 if rejected. The person with the largest weight is voted on in turn to determine the processing result, thus completing the node transfer.

[0073] S4: Drives distributed node execution based on decision results, ensuring consistency of state across service processes.

[0074] Specifically, in this embodiment, the final decision (such as "pass" or "reject") generated by the weighting algorithm is encapsulated as a standardized event, including node ID, handler, timestamp, and decision-based weight values. This event is broadcast to all relevant service instances via a lightweight message queue (such as RabbitMQ) to ensure that unified decision results are received in real time across service nodes. After receiving the event, each service instance derives the latest process state based on its local event log replay mechanism, avoiding the overhead of centralized state synchronization and thus ensuring consistency of process states across services.

[0075] In addition, this embodiment also includes S5: fault tolerance and stimulus execution:

[0076] a1. Fault tolerance mechanism: By configuring a listener to capture node exceptions, at least one of the following operations is performed:

[0077] Timeout handling: Enable a backup handler for stalled nodes.

[0078] Error transfer: Migrate the faulty node to a healthy service instance.

[0079] By deploying configurable listeners at key nodes (such as contract signing), anomalies such as timeouts and service crashes can be monitored in real time, and fault tolerance can be handled promptly when anomalies occur at the supermarket or node.

[0080] a2. Incentive Module: Dynamically adjusts resource allocation based on the weight of the processor, including:

[0081] Prioritize allocating computing resources to users with high processing weight.

[0082] Grant standby user permissions to the user who has participated in the event a threshold number of times.

[0083] This embodiment includes a weight threshold. When a processor's weight reaches the threshold, a dedicated computing resource pool is automatically allocated. The participation frequency threshold in this embodiment is set to 50 times per month, with participation counts automatically tallied from the event logs. Those reaching the threshold are automatically added to the backup processor registry.

[0084] In summary, this solution firstly, based on the design of recording node operations and deriving process states using immutable event sequences, completely removes the constraints of traditional state table storage on dynamic adjustments. This allows operations such as node insertion, skipping, or rollback to take effect in real time through runtime metadata reconstruction, improving the response speed to business changes. At the same time, the fully preserved operation event chain naturally supports full-process auditing and traceability, eliminating the need for additional log system development. Secondly, by using a weighted algorithm, distributed node decision-making is decomposed into three layers of logic: role allocation, predefined result verification, and secondary monitoring triggering. Cross-service consistency is ensured through a dual mechanism of job weight adjustment and historical behavior voting. The online voting mechanism uses event logs to dynamically calculate the weight of the processor, improving decision accuracy. Finally, by using a lightweight architecture to dynamically modify process objects through reflection interfaces and AOP aspects, resource consumption is reduced, comprehensively overcoming the technical bottlenecks of rigidity, redundancy, and weak consistency in traditional solutions.

[0085] Example 2

[0086] The difference between Example 2 and Example 1 is that Example 2 is a workflow engine storage medium based on event sourcing and decentralized monitoring that applies the above-mentioned workflow engine implementation method based on event sourcing and decentralized monitoring.

[0087] The above are merely embodiments of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A workflow engine implementation method based on event sourcing and decentralized monitoring, characterized in that, Including the following steps: S1: Construct a time-based traceability architecture: Define structured metadata, including node relationships and expected result types; define node operations as immutable events, and associate the event structure with the metadata definition; store events in the log in sequence to ensure timeliness; provide a runtime reflection interface to obtain process class objects; deduce the process state by replaying the event sequence; Construct a tree-like backtracking structure based on event sequences; S2: Runtime dynamic process changes: S201: Listen for metadata change events; S202: Obtain the runtime class object through the reflection interface; S203: Encapsulate node insertion / skip / rollback operations as events and append them to the log; S204: Example of process reconstruction based on new event sequence; S3: Node Decision: Assign a processor to each node for approval, and obtain the node processing result by statistically analyzing the approval results according to the weighting algorithm. When the node processing result does not meet the expected result, the weighting algorithm is triggered to recalculate the decision result. S4: Drives distributed node execution based on decision results, ensuring consistency of state across service processes.

2. The workflow engine implementation method based on event sourcing and decentralized monitoring according to claim 1, characterized in that, S203 includes: Node insertion operation: Dynamically inserting nodes into class objects through aspect-oriented programming; Rollback operation: Only adds new events, and does not modify historical events.

3. The workflow engine implementation method based on event sourcing and decentralized monitoring according to claim 2, characterized in that: The approval result of the processor includes pass and fail, and the expected result includes: One vote is sufficient: approval by any processor is considered to meet expectations. Percentage Pass: Statistically determines whether the percentage of passes has reached the metadata threshold.

4. The workflow engine implementation method based on event sourcing and decentralized monitoring according to claim 3, characterized in that: The rollback operation in S2 is only implemented by adding new events, and modification of historical events is prohibited.

5. The workflow engine implementation method based on event sourcing and decentralized monitoring according to claim 4, characterized in that: The weighting algorithm in S3 includes: Rule A, when nodes are configured with weighted power: a1. Initialize the weights of the processors to the average score; a2. If the current result matches the expected result, proceed to the next node; otherwise, execute a3. a3. Adjust the weights according to the pre-configured positions, organizations or custom rules, store the processors in the priority queue in descending order of weight, perform polling in the priority queue, and dequeue them in descending order of weight for reprocessing until the result matches the expected result; Rule B, when the node uses an online voting mechanism: b1. Filter the historical relevant handlers from the event log; b2. Calculate weights dynamically based on operational behavior, adding 1 for acceptance and subtracting 1 for rejection; b3. The decision of the aggregate with the highest weight is the final result.

6. The workflow engine implementation method based on event sourcing and decentralized monitoring according to claim 5, characterized in that, S4 includes the following steps: S401: Encapsulate the final decision generated by the weighting algorithm as a standardized event. The event includes node ID, handler, timestamp, and decision-based weight value. S402: Broadcast the event to all relevant service instances via a lightweight message queue; S403: Each service instance derives the latest process status based on the local event log replay mechanism to ensure status consistency.

7. The workflow engine implementation method based on event sourcing and decentralized monitoring according to claim 6, characterized in that, Also includes S5: Fault Tolerance and Incentive Execution: a1. Fault tolerance mechanism: By configuring a listener to capture node exceptions, at least one of the following operations is performed: Timeout handling: Activate a backup handler for stalled nodes; Error migration: Migrate the faulty node to a healthy service instance; a2. Incentive Module: Dynamically adjusts resource allocation based on the weight of the processor, including: Prioritize allocating computing resources to high-weight processing personnel; Grant standby user permissions to the user who has participated in the event a threshold number of times.

8. The workflow engine implementation method based on event sourcing and decentralized monitoring according to claim 2, characterized in that, The node insertion operation in S203 includes the following steps: S2031: Serialize the acquired class object into structured data; S2032: Inserting dynamic node objects into existing class objects using aspect-oriented programming; S2033: Deserialize the reconstructed data structure and update the metadata information.

9. A workflow engine storage medium based on event sourcing and decentralized monitoring, characterized in that: The workflow engine implementation method based on event sourcing and decentralized monitoring, as described in any one of claims 1-8, is adopted.

Images