Business process engine system based on micro-service architecture

Abstract

The invention discloses a business process engine system based on a micro-service architecture, and belongs to the technical field of business process engines. The business process engine system based on the micro-service architecture comprises a process design module, a process execution engine module, a task management module, a service communication module and an exception handling module. The method solves the problems that in the prior art, abnormities cannot be processed in time, and flow lag or management confusion is easily caused, the micro-service architecture and the business flow engine system are combined, a huge business flow can be split into independent micro-services according to functions, the iteration period is greatly shortened, the fast changing business requirements are met, and the method is suitable for large-scale popularization and application. The method is advantaged in that resource waste is avoided, cascade paralysis is avoided through a fusing mechanism, continuous operation of a core process is guaranteed, health state indexes of micro-services are continuously acquired, real-time alarm is triggered during abnormity, operation and maintenance personnel are helped to rapidly intervene, and operation efficiency of a business process engine is improved.

Description

Technical Field

[0001] This invention relates to the field of business process engine technology, specifically a business process engine system based on a microservice architecture. Background Technology

[0002] Business process management systems (BPMs) are widely used across various industries, and are especially indispensable for research and development activities in the engineering field. For example, product design and manufacturing processes are far more complex than ordinary business processes. These require BPMs to not only support common change management but also manage intermediate data generated during process execution and monitor the process in real time. Furthermore, they must meet the needs of complex research and development task iterations and dynamic task decomposition. The business process engine is the core driving force behind these functions; it not only provides the logic for handling these functions but also determines the accuracy and efficiency of process execution.

[0003] Chinese Patent Publication No. CN112734360B discloses an end-to-end business process management method, apparatus, device, and storage medium. The method includes: upon receiving a business process processing instruction from a first device, determining a business process scenario and a business process objective based on the instruction; determining business process decision engine data based on the business process scenario and objective; executing the process corresponding to the business process decision engine data to output the target scheduling data of the business process processing instruction to a second device. This method can automate the entire business process, improving the efficiency and security of business processing.

[0004] In actual use, the aforementioned patents do not meet the existing needs because the business processes are not only numerous but also complex in type. If anomalies occur during process execution and cannot be handled in a timely manner, it can easily lead to process delays or management chaos. Therefore, we propose a business process engine system based on a microservice architecture. Summary of the Invention

[0005] The purpose of this invention is to provide a business process engine system based on a microservice architecture. By combining a microservice architecture with a business process engine system, large business processes can be functionally broken down into independent microservices, significantly shortening the iteration cycle, adapting to rapidly changing business needs, avoiding resource waste, limiting rule engine crashes to localized areas, preventing cascading paralysis through circuit breakers, ensuring the continuous operation of core processes, and continuously collecting health status indicators of each microservice. Real-time alarms are triggered when services crash, interfaces time out, or dependent resources are abnormal, helping operations and maintenance personnel to intervene quickly, improving the operating efficiency of the business process engine, and solving the problems mentioned in the background technology.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a business process engine system based on a microservice architecture, comprising:

[0007] The process design module provides a visual tool for defining processes, including process structure, node logic, and flow rules.

[0008] The process execution engine module is used for distributed process instance management, creating and executing processes. It uses the Drools engine to dynamically determine the flow conditions when the process nodes are executed, and determines the flow conditions based on the judgment results.

[0009] The task management module is used to automatically distinguish tasks in the process and automatically execute the corresponding tasks after the distinction is completed. It includes operation log audit tracking function.

[0010] The service communication module is used to enable the interaction between the process engine and each microserver through the REST gateway, as well as the collaborative calls between microservices;

[0011] The exception handling module is used to capture and automatically recover from exceptions in the microservice environment, and automatically execute predefined process node compensation logic.

[0012] Preferably, the process design module specifically includes:

[0013] The visualization unit is used to set process nodes in different formats and display them visually. Process nodes include start, end, task, gateway, and connection rules.

[0014] Define management units to convert process nodes of different formats into process definitions that the engine can execute, and to create, publish, take offline, and roll back the converted process definitions.

[0015] The verification unit is used to verify the legality, logical integrity, and rationality of the process before it is released.

[0016] Preferably, the process execution engine module specifically includes:

[0017] The process engine unit is used for distributed process instance management, including task allocation strategy, countersigning / or signing mechanism, historical version control and rollback function;

[0018] The process creation unit is used for the creation, execution, status management and node scheduling of process instances, driving the process to flow according to the definition;

[0019] The node scheduling unit is used to trigger node execution according to the process definition order, process gateway logic, and persistently store process instance status and node execution records.

[0020] The rule engine unit is used to dynamically determine the flow conditions when the process node is executed using the Drools engine, and to determine the flow conditions based on the judgment results.

[0021] Preferably, the exception handling module specifically includes:

[0022] The retry unit is used to automatically retry service calls that fail temporarily, including configuring the number of retries and exponential backoff;

[0023] The circuit breaker unit is used to trigger a circuit breaker when the failure frequency of a microservice is too high, and at the same time provides a degradation strategy.

[0024] An exception capture unit is used to capture exceptions during process execution and to manually intervene or automatically recover the process when an exception occurs.

[0025] The process compensation unit is used to automatically execute predefined process node compensation logic for failed process nodes.

[0026] Preferably, the task management module specifically includes:

[0027] The task differentiation unit is used to distinguish between automatic tasks and manual tasks, and sets the execution logic of the tasks based on the differentiation results;

[0028] The task integration unit is used to connect with user systems, providing task lists, to-do reminders, and task processing interfaces.

[0029] Preferably, the service communication module specifically includes:

[0030] Obtain the available instance address of the target microservice through the service registry, and select a specific instance based on the load balancing strategy.

[0031] Send a request to the microservice via REST, carrying parameters extracted from the process context, encapsulate the request parameters into a message, and send it to the specified message queue. The microservice receives the message, processes it, and sends a callback message to the engine after processing.

[0032] Receive the results returned by the microservice, write the results into the process context, and advance to the next node;

[0033] The engine listens for callback messages, confirms that the microservice has finished processing, updates the process context, and continues execution. If the microservice call times out, it retryes according to the preset strategy.

[0034] Preferably, the method further includes a monitoring and tracking module, specifically comprising:

[0035] The process monitoring unit is used to continuously collect health status indicators of each microservice and receive the number of process instances, status distribution, and average time in real time.

[0036] The node monitoring unit is used to record the number of executions, success rate, and average time consumption of each server node, and to identify the bottleneck nodes of the server.

[0037] The distributed tracing unit is used to integrate distributed tracing tools, record the link logs of process calls to each microserver, and quickly locate cross-service problems;

[0038] The alarm mechanism unit is used to configure alarm rules and notify maintenance personnel via SMS when an alarm rule is triggered.

[0039] Preferably, the monitoring and tracking module further includes an access control security module, specifically including:

[0040] The identity authentication unit is used to interface with the unified identity authentication service to verify the legitimacy of the user's identity;

[0041] The data security unit is used to de-identify, store, and transmit sensitive data in the process, and HTTPS encryption is used during communication.

[0042] Preferably, the monitoring and tracking module further includes:

[0043] The load sensing unit is used for:

[0044] The health status indicators of each microservice are continuously collected by the process monitoring unit; among them, the health status indicators include at least: CPU utilization, memory usage, task queue waiting length, and historical average processing time of tasks.

[0045] Based on the health status indicators of each microservice, a comprehensive load score is calculated for each microservice, using the following formula:

[0046]

[0047] Where S is the overall load score of any microservice, U cpu To determine the CPU utilization of the corresponding microservice, U mem To determine the memory usage of the corresponding microservice, L queue T represents the task queue waiting length for the corresponding microservice. avg To correspond to the historical average processing time of microservice tasks, L max T is the preset maximum tolerable queue length. base The preset baseline processing time is α, β, γ and δ are preset weighting coefficients, and α+β+γ+δ=1;

[0048] When the overall load score of any microservice exceeds the preset score threshold, the corresponding microservice will be classified as an overloaded microservice.

[0049] When the ratio of the number of overloaded microservices to the total number of all microservices exceeds a preset threshold, new microservices are automatically deployed to the system.

[0050] Preferably, the access control security module further includes:

[0051] The log security hardening unit is used for:

[0052] The process of obtaining records from the distributed tracing unit involves calling the link logs of each microserver; the link logs include at least: service node IP, call time, input parameters, and return status code;

[0053] Aggregate link logs according to a preset time window and generate a Merkle tree;

[0054] The root hash of the generated Merkle tree is signed together with the timestamp and then concatenated to obtain the evidence message;

[0055] The evidence storage message is sequentially processed with elliptic curve signature and quantum-resistant signature to obtain a double-signed evidence storage message; the elliptic curve signature is completed using the system private key, and the quantum-resistant signature is completed using the system secondary private key;

[0056] Broadcast the double-signature notarization message to the permissioned blockchain network, triggering the smart contract in the permissioned blockchain network to put the double-signature notarization message on the chain;

[0057] Obtain the on-chain certificate of the double-signature stored message returned by the permissioned blockchain network;

[0058] The on-chain credentials are stored in the system's local database.

[0059] Compared with the prior art, the beneficial effects of the present invention are:

[0060] This invention combines a microservice architecture with a business process engine system, enabling the functional decomposition of large business processes into independent microservices. This results in smaller code size, clearer logic, and significantly improved development and maintenance efficiency. Different services can be developed, tested, and deployed in parallel by independent small teams. Modifying a single node does not require global redeployment, greatly shortening the iteration cycle, adapting to rapidly changing business needs, avoiding resource waste, and limiting rule engine crashes to localized areas. Circuit breaking mechanisms prevent cascading failures and ensure the continuous operation of core processes. By continuously collecting health status indicators of each microservice, real-time alarms are triggered when services crash, interfaces time out, or dependent resources are abnormal, helping operations personnel to intervene quickly and improving the operational efficiency of the business process engine.

[0061] It can dynamically and accurately monitor the operational status of microservices, promptly identifying and addressing potential overload issues. Through in-depth analysis of multi-dimensional health indicators, it can proactively identify performance bottlenecks and potential risks in the system, preventing overload during operation. When the proportion of overloaded microservices reaches a set threshold, the system automatically deploys new microservices for load balancing, effectively distributing the pressure on existing microservices and preventing excessive load on a single microservice from impacting the stability of the entire system. Furthermore, this automated scaling mechanism not only improves the system's responsiveness and processing capabilities but also ensures the continuous and stable operation of services in high-concurrency and complex environments, significantly enhancing system reliability and scalability, and providing more efficient technical support for enterprises and applications.

[0062] By combining elliptic curve signatures and quantum-resistant signatures, a high level of security is provided, ensuring that log data not only possesses traditional encryption protection but also resistance to quantum computing attacks. The use of blockchain ensures the immutability and long-term validity of the logs, making the entire system more reliable in the face of security challenges and significantly improving system security and compliance. Furthermore, the blockchain's on-chain mechanism enhances auditing and traceability capabilities, effectively addressing potential future security risks and legal compliance requirements. Attached Figure Description

[0063] Figure 1 This is a schematic diagram of the business process engine system module based on microservice architecture of the present invention;

[0064] Figure 2 This is a flowchart of the business process engine system based on microservice architecture of the present invention. Detailed Implementation

[0065] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0066] To address the issues arising from the large number and complexity of business processes in practical applications of existing technologies, and the inability to promptly handle anomalies during process execution, which can easily lead to process delays or management chaos, please refer to [the relevant documentation / reference]. Figures 1-2 This embodiment provides the following technical solution:

[0067] Example 1: A business process engine system based on a microservice architecture, comprising:

[0068] The process design module provides a visual tool for defining processes, including process structure, node logic, and flow rules. It includes functions such as node editing, form binding, and variable mapping, allowing users to define process steps through a graphical interface.

[0069] The process execution engine module is used for distributed process instance management, creating and executing processes. It uses the Drools engine to dynamically determine the flow conditions when the process nodes are executed, and determines the flow conditions based on the judgment results.

[0070] The task management module is used to automatically distinguish tasks in the process and automatically execute the corresponding tasks after the distinction is completed. It includes operation log audit tracking function.

[0071] The service communication module is used to enable the interaction between the process engine and each microserver through the REST gateway, as well as the collaborative calls between microservices;

[0072] The exception handling module is used to capture and automatically recover from exceptions in the microservice environment, and automatically execute predefined process node compensation logic.

[0073] The process design module specifically includes:

[0074] The visualization unit is used to set process nodes in different formats and display them visually. Process nodes include start, end, task, gateway, and connection rules.

[0075] Define management units to convert process nodes of different formats into process definitions that the engine can execute, and create, publish, take offline and roll back the converted process definitions to avoid conflicts between multiple versions of the process.

[0076] The verification unit is used to verify the legality, logical integrity, and rationality of the process before it is released.

[0077] The process execution engine module specifically includes:

[0078] The process engine unit is used for distributed process instance management, including task allocation strategies (fixed personnel / roles / expressions), countersigning / or signing mechanisms, historical version control, and rollback functions.

[0079] The process creation unit is used for the creation, operation, status management and node scheduling of process instances, driving the process to flow according to the definition, including creating process instances based on process definitions, maintaining instance status, namely running, paused, terminated and completed status, and recording instance context, such as variables and parameters.

[0080] The node scheduling unit is used to trigger node execution according to the process definition order, such as calling microservices, assigning manual tasks, and handling gateway logic, such as branch selection for parallel gateways and exclusive gateways. It also persistently stores the process instance status and node execution records to support recovery after failure.

[0081] The rule engine unit is used to dynamically determine the flow conditions when the process node is executed using the Drools engine, and determine the flow conditions based on the judgment results, including approval rule configuration and condition jump. It achieves decoupling of business logic and process through rule templates.

[0082] The exception handling module specifically includes:

[0083] The retry unit is used to automatically retry service calls that fail temporarily, including configuring the number of retries and exponential backoff;

[0084] The circuit breaker unit is used to trigger a circuit breaker when the failure frequency of a microservice is too high, so as to avoid cascading failures. It also provides degradation strategies, such as returning the default value or skipping non-core nodes.

[0085] The exception capture unit is used to capture exceptions during process execution, such as service timeouts and parameter errors, and to manually intervene when exceptions occur, such as the administrator forcing a retry, continuing after modifying parameters, or automatically restoring the process, such as restarting the process instance.

[0086] The process compensation unit is used to automatically execute predefined process node compensation logic for failed process nodes.

[0087] It is mainly used to deal with uncertainties in microservice environments, such as service downtime or network fluctuations, and to ensure process stability.

[0088] The task management module specifically includes:

[0089] The task differentiation unit is used to distinguish between automatic tasks and manual tasks. Automatic tasks include calling microservice interfaces, while manual tasks include approval and data entry. The execution logic of the task is set according to the differentiation result. The execution logic includes creating tasks, assigning tasks by role, user group or rule, claiming tasks, executing tasks, and completing / terminating tasks. It supports task priority (high / medium / low), timeout reminders and automatic reassignment, as well as dependencies, such as task B can only be executed after task A is completed.

[0090] The task integration unit is used to connect with user systems, providing task lists, to-do reminders, and task processing interfaces.

[0091] The service communication module specifically includes:

[0092] Obtain the available instance address of the target microservice through the service registry, and select the specific instance by combining the load balancing strategy (such as round-robin, weight).

[0093] Send a request to the microservice via REST, carrying parameters extracted from the process context, encapsulate the request parameters into a message, and send it to the specified message queue. The microservice receives the message, processes it, and sends a callback message to the engine after processing.

[0094] Receive the results returned by the microservice, write the results into the process context, and advance to the next node;

[0095] The engine listens for callback messages, confirms that the microservice has finished processing, updates the process context, and continues execution. If the microservice call times out, it retryes according to a preset strategy, such as a maximum of 3 times with a 10-second interval, to ensure that the microservice does not execute repeatedly when it receives the message repeatedly, thus avoiding repeated triggering of process nodes.

[0096] Working principle: When using it, according to Figure 1 and Figure 2 :

[0097] S1: Set up process nodes in different formats and visualize them, convert process nodes in different formats into process definitions that the engine can execute, and create, publish, take offline and roll back the converted process definitions. Before the process is published, verify the legality, logical integrity and rationality of the process.

[0098] S2: After verification, distributed process instance management is performed, and process instances are created, run, managed in status and scheduled. At the same time, the process is driven to flow according to the definition.

[0099] S3: Trigger node execution according to the process definition order, process gateway logic during execution, and persistently store the process instance status and node execution records. After storage, use the Drools engine to dynamically determine the flow conditions when the process node is executed, and determine the flow conditions based on the judgment result.

[0100] S4: Based on the flow conditions, distinguish between automatic tasks and manual tasks, set the execution logic of the tasks according to the distinction results, and interface with the user system;

[0101] S5: Utilizes a REST gateway to enable interaction between the workflow engine and various microservers. After the interaction is completed, tasks are flowed according to the execution logic, and exception detection and handling are performed during the flow process.

[0102] Example 2: In this example, the business process engine system based on a microservice architecture further includes a monitoring and tracing module, which specifically includes:

[0103] Monitor process execution status and microservice call chains for troubleshooting and performance optimization.

[0104] The process monitoring unit is used to continuously collect health status indicators of each microservice and receive the number of process instances, status distribution (running / completed / abnormal) and average time in real time. It supports filtering by process definition and time range.

[0105] The node monitoring unit is used to record the number of executions, success rate, and average time of each server node, and to identify bottleneck nodes of the server, such as a microservice call that takes too long.

[0106] The distributed tracing unit is used to integrate distributed tracing tools, such as Zipkin and Jaeger, to record the link logs of process calls to each microserver, including call order, time consumption and status, to quickly locate cross-service problems;

[0107] The alarm mechanism unit is used to configure alarm rules, such as when the process anomaly rate exceeds 5% or the node time exceeds 10 minutes, the operation and maintenance personnel will be notified via SMS when the alarm rule is triggered.

[0108] Working Principle: The system sets up and visualizes process nodes in different formats, converts these nodes into executable process definitions, and creates, publishes, decommissions, and rolls back the converted definitions. Before publication, it verifies the process's legality, logical integrity, and rationality. After verification, it manages distributed process instances, creating, running, managing their status, and scheduling nodes, while driving the process to flow according to its definition. Nodes are triggered in the order defined by the process, handling gateway logic during execution and persistently storing process instance status and node execution records. Once stored, the Drools engine dynamically executes the process nodes. The system determines the flow conditions based on the judgment results; it distinguishes between automatic and manual tasks based on the flow conditions, sets the execution logic of the tasks according to the distinction results, and interfaces with the user system; it uses a REST gateway to realize the interaction between the process engine and each microserver, and after the interaction is completed, it flows the tasks according to the execution logic, and performs anomaly detection and handling during the flow process; it configures alarm rules, and after the handling is completed, it receives the number of process instances, status distribution, and average time consumption in real time, and records the execution count, success rate, and average time consumption of each server node, identifies the bottleneck nodes of the server, and notifies the operation and maintenance personnel via SMS if the process anomaly rate exceeds 5% or the node consumption exceeds 10 minutes.

[0109] Example 3: In this example, the monitoring and tracking module also includes an access control security module, specifically including:

[0110] The identity authentication unit is used to interface with the unified identity authentication service to verify the legitimacy of the user's identity;

[0111] The data security unit is used to de-identify, store, and transmit sensitive data in the process, and HTTPS encryption is used during communication.

[0112] Working Principle: The system sets up and visualizes process nodes in different formats, converts these nodes into executable process definitions, and creates, publishes, decommissions, and rolls back the converted definitions. Before publication, it verifies the legality, logical integrity, and rationality of the process. After verification, it manages distributed process instances, creating, running, managing their status, and scheduling nodes, while driving the process to flow according to its definition. Nodes are triggered in the order defined by the process; during execution, gateway logic is processed, and process instance status and node execution records are persistently stored. After storage, the Drools engine dynamically determines the flow conditions during process node execution, and determines the flow conditions based on the judgment results. The system then differentiates processes based on these flow conditions. The system categorizes tasks into automated and manual tasks, sets execution logic based on the distinction, and interfaces with user systems. A REST gateway facilitates interaction between the process engine and various microservers. After interaction, tasks are routed according to the execution logic, with anomaly detection and handling implemented during the route. User identity is verified during the integration process; upon successful verification, alarm rules are configured. The system receives real-time data on the number of process instances, status distribution, and average latency. Sensitive data within the process is anonymized for storage and transmission. HTTPS encryption is used during communication, and the system records the execution count, success rate, and average latency of each server node. Bottleneck nodes are identified; if the process anomaly rate exceeds 5% or node latency exceeds 10 minutes, maintenance personnel are notified via SMS.

[0113] In summary, the microservice-based business process engine system of this invention, by combining microservice architecture with a business process engine system, can functionally decompose large business processes into independent microservices, such as process definition, task scheduling, and approval nodes. Each service focuses on a single business domain, with small code size and clear logic, significantly improving development and maintenance efficiency. Different services can be developed, tested, and deployed in parallel by independent small teams. Modifying a single node does not require global redeployment, greatly shortening the iteration cycle, adapting to rapidly changing business needs, avoiding resource waste, and limiting rule engine crashes to local areas. Circuit breaking mechanisms prevent cascading paralysis and ensure the continuous operation of core processes. By continuously collecting health status indicators of each microservice, real-time alarms are triggered when services crash, interfaces time out, or dependent resources, such as caches and message queues, are abnormal, helping operations and maintenance personnel to intervene quickly. When the business process engine is executing, if a node is stuck due to a service failure, the tracing module can immediately mark the abnormal node and associate it with the corresponding service call records to clarify whether the failure is due to the service itself or inter-service communication problems, avoiding the black box nature of the process.

[0114] Example 4: The monitoring and tracking module further includes:

[0115] The load sensing unit is used for:

[0116] The health status indicators of each microservice are continuously collected by the process monitoring unit; among them, the health status indicators include at least: CPU utilization, memory usage, task queue waiting length, and historical average processing time of tasks.

[0117] Based on the health status indicators of each microservice, a comprehensive load score is calculated for each microservice, using the following formula:

[0118]

[0119] Where s is the overall load score of any microservice, U cpu To determine the CPU utilization of the corresponding microservice, U mem To determine the memory usage of the corresponding microservice, L queue T represents the task queue waiting length for the corresponding microservice. avg To correspond to the historical average processing time of microservice tasks, L max T is the preset maximum tolerable queue length. base The preset baseline processing time is α, β, γ and δ are preset weighting coefficients, and α+β+γ+δ=1;

[0120] When the overall load score of any microservice exceeds the preset score threshold, the corresponding microservice will be classified as an overloaded microservice.

[0121] When the ratio of the number of overloaded microservices to the total number of all microservices exceeds a preset threshold, new microservices are automatically deployed to the system.

[0122] The working principle and beneficial effects of the above technical solution are as follows:

[0123] The real-time monitoring and evaluation mechanism based on load-aware units aims to ensure the efficient operation and automated scaling of microservice systems. By continuously collecting health status indicators of each microservice, including CPU utilization, memory usage, task queue wait length, and average historical task processing time, the system can comprehensively reflect the load status of each microservice. The comprehensive load score calculation formula is based on weighted coefficients of α, β, γ, and δ, comprehensively assessing the stress level of each microservice according to the priority of different health indicators. Specifically, CPU utilization and memory usage are key factors directly affecting microservice performance, while task queue wait length and average processing time reflect the bottlenecks in microservice processing capacity. Through weight adjustment, the importance of each indicator can be flexibly configured according to actual business needs, ensuring the accuracy of system evaluation. When the comprehensive load score of a microservice exceeds a preset threshold, the system marks it as an overloaded microservice, thereby triggering a resource adjustment mechanism to ensure real-time adjustment and optimization of microservice load.

[0124] This invention enables dynamic and precise monitoring of microservice operation status, timely detection and response to potential overload issues. Through in-depth analysis of multi-dimensional health indicators, performance bottlenecks and potential risks in the system can be identified in advance, preventing overload during system operation. When the proportion of overloaded microservices reaches a set threshold, the system automatically deploys new microservices for load balancing, effectively distributing the pressure on existing microservices and preventing excessive load on a single microservice from affecting the stability of the entire system. Furthermore, this automated scaling mechanism not only improves the system's responsiveness and processing capabilities but also ensures the continuous and stable operation of services in high-concurrency and complex environments, greatly enhancing system reliability and scalability, and providing more efficient technical support for enterprises or applications.

[0125] Example 5: The permission security module further includes:

[0126] The log security hardening unit is used for:

[0127] The process of obtaining records from the distributed tracing unit involves calling the link logs of each microserver; the link logs include at least: service node IP, call time, input parameters, and return status code;

[0128] Aggregate link logs according to a preset time window and generate a Merkle tree;

[0129] The root hash of the generated Merkle tree is signed together with the timestamp and then concatenated to obtain the evidence message;

[0130] The evidence storage message is sequentially processed with elliptic curve signature and quantum-resistant signature to obtain a double-signed evidence storage message; the elliptic curve signature is completed using the system private key, and the quantum-resistant signature is completed using the system secondary private key;

[0131] Broadcast the double-signature notarization message to the permissioned blockchain network, triggering the smart contract in the permissioned blockchain network to put the double-signature notarization message on the chain;

[0132] Obtain the on-chain certificate of the double-signature stored message returned by the permissioned blockchain network;

[0133] The on-chain credentials are stored in the system's local database.

[0134] The working principle and beneficial effects of the above technical solution are as follows:

[0135] The log security enhancement unit achieves comprehensive protection and authentication of microservice link logs in the distributed system. The specific process first acquires the microservice link logs recorded by the distributed tracing unit, including key data such as service node IPs, call times, input parameters, and return status codes. Based on a set time window, the link logs are aggregated and a Merkle tree structure is generated. The Merkle tree is an efficient data structure that ensures the consistency and integrity of log data. Next, a signature is generated using a combination of a timestamp and the Merkle tree root hash to ensure the immutability of log data at a specific point in time. To enhance security, the signature message undergoes both elliptic curve signing and quantum-resistant signing. Elliptic curve signing uses the system's private key, while quantum-resistant signing uses the system's secondary private key. The dual-signature signature message is then broadcast to a permissioned blockchain network, triggering a smart contract to upload the message to the blockchain.

[0136] Throughout the process, blockchain technology is used to ensure the logs' tamper-proof nature and auditability. Once uploaded to the blockchain, the system obtains an on-chain certificate from the blockchain network, proving that the log data has been successfully recorded and has legal validity. Finally, the on-chain certificate is stored in the system's local database, forming a trusted and traceable log record.

[0137] This invention, by combining elliptic curve signatures and quantum-resistant signature technologies, provides a high level of security, ensuring that log data not only possesses traditional encryption protection but also resistance to quantum computing attacks. The use of blockchain ensures the immutability and long-term validity of the logs, making the entire system more reliable in the face of security challenges and significantly improving system security and compliance. Furthermore, the blockchain's on-chain mechanism enhances auditing and traceability capabilities, effectively addressing potential future security risks and legal compliance requirements.

[0138] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "include," "contain," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0139] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention.

Claims

1. A business process engine system based on a microservice architecture, characterized in that, include: The process design module provides a visual tool for defining processes, including process structure, node logic, and flow rules. The process execution engine module is used for distributed process instance management, creating and executing processes. It uses the Drools engine to dynamically determine the flow conditions when the process nodes are executed, and determines the flow conditions based on the judgment results. The task management module is used to automatically distinguish tasks in the process and automatically execute the corresponding tasks after the distinction is completed. It includes operation log audit tracking function. The service communication module is used to enable the interaction between the process engine and each microserver through the REST gateway, as well as the collaborative calls between microservices; The exception handling module is used to capture and automatically recover from exceptions in the microservice environment, and automatically execute predefined process node compensation logic.

2. The business process engine system based on microservice architecture according to claim 1, characterized in that, The process design module specifically includes: The visualization unit is used to set process nodes in different formats and display them visually. Process nodes include start, end, task, gateway, and connection rules. Define management units to convert process nodes of different formats into process definitions that the engine can execute, and to create, publish, take offline, and roll back the converted process definitions; The verification unit is used to verify the legality, logical integrity, and rationality of the process before it is released.

3. The business process engine system based on microservice architecture according to claim 1, characterized in that, The process execution engine module specifically includes: The process engine unit is used for distributed process instance management, including task allocation strategy, countersigning / or signing mechanism, historical version control and rollback function; The process creation unit is used for the creation, execution, status management and node scheduling of process instances, driving the process to flow according to the definition; The node scheduling unit is used to trigger node execution according to the process definition order, process gateway logic, and persistently store process instance status and node execution records. The rule engine unit is used to dynamically determine the flow conditions when the process node is executed using the Drools engine, and to determine the flow conditions based on the judgment results.

4. The business process engine system based on microservice architecture according to claim 1, characterized in that, The exception handling module specifically includes: The retry unit is used to automatically retry service calls that fail temporarily, including configuring the number of retries and exponential backoff; The circuit breaker unit is used to trigger a circuit breaker when the failure frequency of a microservice is too high, and at the same time provides a degradation strategy; An exception capture unit is used to capture exceptions during process execution and to manually intervene or automatically recover the process when an exception occurs. The process compensation unit is used to automatically execute predefined process node compensation logic for failed process nodes.

5. The business process engine system based on microservice architecture according to claim 1, characterized in that, The task management module specifically includes: The task differentiation unit is used to distinguish between automatic tasks and manual tasks, and sets the execution logic of the tasks based on the differentiation results; The task integration unit is used to connect with user systems, providing task lists, to-do reminders, and task processing interfaces.

6. The business process engine system based on microservice architecture according to claim 1, characterized in that, The service communication module specifically includes: Obtain the available instance address of the target microservice through the service registry, and select a specific instance based on the load balancing strategy. Send a request to the microservice via REST, carrying parameters extracted from the process context, encapsulate the request parameters into a message, and send it to the specified message queue. The microservice receives the message, processes it, and sends a callback message to the engine after processing. Receive the results returned by the microservice, write the results into the process context, and advance to the next node; The engine listens for callback messages, confirms that the microservice has finished processing, updates the process context, and continues execution. If the microservice call times out, it retryes according to the preset strategy.

7. The business process engine system based on microservice architecture according to claim 1, characterized in that, It also includes a monitoring and tracking module, which specifically includes: The process monitoring unit is used to continuously collect health status indicators of each microservice and receive the number of process instances, status distribution, and average time in real time. The node monitoring unit is used to record the number of executions, success rate, and average time consumption of each server node, and to identify the bottleneck nodes of the server. The distributed tracing unit is used to integrate distributed tracing tools, record the link logs of process calls to each microserver, and quickly locate cross-service problems; The alarm mechanism unit is used to configure alarm rules and notify maintenance personnel via SMS when an alarm rule is triggered.

8. The business process engine system based on microservice architecture according to claim 7, characterized in that, The monitoring and tracking module also includes an access control and security module, specifically comprising: The identity authentication unit is used to interface with the unified identity authentication service to verify the legitimacy of the user's identity; The data security unit is used to de-identify, store, and transmit sensitive data in the process, and HTTPS encryption is used during communication.

9. The business process engine system based on microservice architecture according to claim 7, characterized in that, The monitoring and tracking module also includes: The load sensing unit is used for: The health status indicators of each microservice are continuously collected by the process monitoring unit; among them, the health status indicators include at least: CPU utilization, memory usage, task queue waiting length, and historical average processing time of tasks. Based on the health status indicators of each microservice, a comprehensive load score is calculated for each microservice, using the following formula: Where S is the overall load score of any microservice, U cpu To determine the CPU utilization of the corresponding microservice, U mem To determine the memory usage of the corresponding microservice, L queue T represents the task queue waiting length for the corresponding microservice. avg To correspond to the historical average processing time of microservice tasks, L max T is the preset maximum tolerable queue length. base The preset baseline processing time is α, β, γ and δ are preset weighting coefficients, and α+β+γ+δ=1; When the overall load score of any microservice exceeds the preset score threshold, the corresponding microservice will be classified as an overloaded microservice. When the ratio of the number of overloaded microservices to the total number of all microservices exceeds a preset threshold, new microservices are automatically deployed to the system.

10. The business process engine system based on microservice architecture according to claim 8, characterized in that, The access security module also includes: The log security hardening unit is used for: The process of obtaining records from the distributed tracing unit involves calling the link logs of each microserver; the link logs include at least: service node IP, call time, input parameters, and return status code; Aggregate link logs according to a preset time window and generate a Merkle tree; The root hash of the generated Merkle tree is signed together with the timestamp and then concatenated to obtain the evidence message; The evidence storage message is sequentially processed with elliptic curve signature and quantum-resistant signature to obtain a double-signed evidence storage message; the elliptic curve signature is completed using the system private key, and the quantum-resistant signature is completed using the system secondary private key; Broadcast the double-signature notarization message to the permissioned blockchain network, triggering the smart contract in the permissioned blockchain network to put the double-signature notarization message on the chain; Obtain the on-chain certificate of the double-signature stored message returned by the permissioned blockchain network; The on-chain credentials are stored in the system's local database.

Images