Event-driven three-layer decoupling workflow orchestration method and system

Abstract

The application discloses a three-layer decoupling workflow arrangement method and system based on event driving, and the method comprises the following steps: an event arrangement layer analyzes an event triggering request, creates an event instance, and generates a node instance set; a rule decision layer generates a gateway branch variable and a process starting variable based on an event execution context; a process scheduling layer starts a process instance, locks an external task, and distributes through a message queue; a node executor assembles a request parameter by using parameter analysis DSL, and calls back an execution result, and an event arrangement layer updates a node state and an execution context; and the system controls an abnormal task through a workflow engine lock, a cache distributed lock, a lock renewal, a retry, and a pause termination strategy, so that the decoupling, reliability, and expansibility of the workflow are improved.

Description

Technical Field

[0001] This invention relates to the fields of network application technology and workflow orchestration technology, and in particular to an event-driven three-layer decoupled workflow orchestration method and system. Background Technology

[0002] With the widespread adoption of microservice and event-driven architectures in business systems, business processes such as order processing, resource activation, business approval, message notification, and third-party API calls typically require collaboration among multiple independent service nodes. To achieve sequential control and state transitions between these service nodes, existing systems typically organize business processes using methods such as hard-coding business code, direct triggering via message middleware, or workflow engine scheduling.

[0003] When using hard-coded business logic, the execution order, condition checks, request parameter conversion, exception retries, and status callbacks between business nodes are directly embedded in the business code. When the business process changes, the corresponding business code needs to be modified, and compilation, deployment, and service restart operations must be performed. This approach not only couples business logic with process orchestration logic but also makes it difficult to reuse node execution capabilities across different processes. As the number of business nodes increases or process branches change frequently, this can easily lead to complex code structures, long change cycles, and difficulty in locating operational failures.

[0004] While using message queues to directly drive business interface execution enables asynchronous delivery of business tasks, message queues primarily handle message transmission and typically cannot fully represent process instances, node instances, conditional branches, node execution states, and contextual relationships. Therefore, this approach struggles to uniformly control serial execution, parallel execution, gateway routing, failure retries, execution pauses, and process termination among multiple nodes. Furthermore, when node execution results need to be used as parameters for subsequent node requests, parameter extraction and conversion code must be written separately in each business service, resulting in fragmented parameter passing logic between nodes.

[0005] When using traditional workflow engines, it's typically necessary to configure business service tasks within the process model, or for the process engine to directly call business interfaces. As node types and business rules increase, the process model can easily simultaneously bear the process structure, business judgments, and business call logic, creating strong coupling between event triggering, rule decisions, process scheduling, and business execution. When business rules change, the process model may need to be modified synchronously; when interface call methods change, the service task configuration in the process engine may also need to be adjusted, affecting the independent evolution of the process model and the business execution program.

[0006] Furthermore, for asynchronous nodes executed via external tasks, workflow engines typically set a limited lock duration for these tasks. When a node's execution time exceeds this lock duration, the external task may be reacquired by another executor, leading to duplicate execution of the same business node. Using only workflow engine locks is insufficient for handling lock holder verification, lock renewal, and task recovery after lock expiration in scenarios involving multiple executors and message queue collaboration. Additionally, existing solutions often lack retry, pause, cancellation, and termination mechanisms that simultaneously cover both node and process levels. When a node times out or experiences consecutive failures, it can easily lead to prolonged process blocking, invalid tasks continuously consuming resources, or incorrect execution of business nodes following the abnormal node.

[0007] Therefore, designing a new workflow orchestration method has positive practical significance. Summary of the Invention

[0008] In view of this, the purpose of this invention is to propose an event-driven three-layer decoupled workflow orchestration method and system. This solution sets up event instance and state management, business rule decision-making, and process instance scheduling in mutually independent processing layers, and establishes data connections between the three layers through standardized variables and interfaces. At the same time, it is necessary to uniformly process message distribution of external tasks, dynamic assembly of node parameters, task locking and renewal, execution result callback, and exception policy control to improve the configurability, execution reliability, and scalability of complex microservice workflows.

[0009] To achieve the above-mentioned technical objectives, the technical solution adopted by this invention is as follows: An event-driven, three-layer decoupled workflow orchestration method, comprising: S1, the event orchestration layer receives event triggering requests sent by external systems, performs standardized parsing of the event triggering requests, and generates event instance identifiers and event execution contexts containing event codes, business primary keys, and business parameters; S2, the event orchestration layer loads the corresponding event definition according to the event code. The event definition includes a process model identifier, a rule set identifier, and a node configuration list. It also generates a set of node instances associated with the event instance identifier based on the node configuration list. Each node instance is configured with a node type, task topic, parameter template, timeout threshold, retry strategy, and / or pause / termination strategy. S3, the rule decision layer obtains the corresponding rule set according to the rule set identifier, and executes the rule set based on the event execution context to generate a rule decision result containing gateway branch variables and process start variables; S4, the process scheduling layer loads the corresponding process model according to the process model identifier, starts the process instance based on the process start variable, and writes the gateway branch variable into the process instance, so that the process instance flows to the corresponding external task node according to the gateway branch variable. S5, the process scheduling layer locks the external task corresponding to the external task node, writes the distributed lock associated with the external task into the cache lock module, and encapsulates the external task identifier, process instance identifier, node instance identifier, task topic and lock holder identifier into an external task message and sends it to the message queue. S6, the node executor cluster consumes the external task message, determines the corresponding node executor according to the task topic, and the node executor uses the parameter parsing DSL to parse the parameter template, extracts and assembles the node request parameters from the event execution context, executes the corresponding node action based on the node request parameters, and generates the node execution result; S7, the node executor calls back the node execution result to the event orchestration layer. The event orchestration layer updates the node state of the corresponding node instance and the event execution context according to the node execution result, and sends a task completion instruction to the process scheduling layer when the node action is successfully executed. The process scheduling layer completes the current external task and allows the process instance to continue to flow. S8, during the execution of an external task, when the task lock and cache distributed lock of the external task meet the renewal conditions, the lock holder is verified according to the external task identifier and the lock holder identifier, and the task lock and cache distributed lock are renewed synchronously after the verification is passed.

[0010] Step S8 includes: during the execution of an external task, the process scheduling layer and the event orchestration layer perform lock renewal, task retry, node suspension, process suspension, node cancellation, or process termination processing according to the lock remaining duration, node execution duration, node execution result, and execution count of the external task, and in accordance with the retry policy and pause / termination policy of the corresponding node instance.

[0011] As one possible implementation, step S1 of this solution further includes: The event orchestration layer receives event trigger requests sent by external systems; Extract the trigger source identifier, event code, business primary key, business parameters, and trigger time from the event trigger request; The business parameters are converted into a context object with a preset structure, and the trigger time is converted into a unified time format; Generate an event idempotent key based on the event code, business primary key, and trigger source identifier; Duplicate event validation is performed based on the event idempotent key. If no event instance corresponding to the event idempotent key is found, the event instance identifier is generated and the event execution context is created.

[0012] As one possible implementation, further, in step S2 of this solution, the node types in the node configuration list include HTTP nodes, message nodes, approval nodes, client callback nodes, and gateway nodes; The node executor cluster routes HTTP nodes to HTTP executors, message nodes to message executors, approval nodes to approval executors, and client callback nodes to client callback executors based on the task topic. The process scheduling layer determines the subsequent process branch corresponding to the gateway node based on the gateway branch variable.

[0013] As one possible implementation, further, in step S2 or step S8 of this solution, the retry strategy includes a one-time execution mode, a polling error stop mode, and a polling error continue mode; In the single execution mode, a node action is executed once, and a corresponding pause and termination strategy is triggered when the node action fails to execute. In the polling error stop mode, node actions are executed according to a preset polling interval, and subsequent polling is stopped and a corresponding pause termination strategy is triggered when a polling execution error is detected. In the polling error continuation mode, when a polling execution error is detected, the error result of the current polling is recorded, and subsequent polling continues until the node action is successfully executed or the preset polling limit is reached; As one possible implementation, further, in step S2 or step S8 of this solution, the pause / termination strategy includes a node-level pause strategy, a global pause strategy, a node-level cancellation strategy, and a global termination strategy. The node-level pause policy is used to set the current node instance to a paused state while retaining the process instance and event execution context; The global pause policy is used to set the event instance and process instance to a paused state; The node-level cancellation policy is used to set the current node instance to a cancelled state and record the corresponding cancellation reason; The global termination policy is used to terminate the process instance, set the event instance to a terminated state, and clean up any node instances that have not yet been executed.

[0014] As one possible implementation, step S3 of this solution further includes: The data items to be completed are determined according to the data completion configuration in the rule set, and the completion data is obtained from the corresponding external service according to the data items to be completed. The completed data is merged with the event execution context to form a rule input context; The rule expressions in the rule set are compiled, and the compilation results corresponding to the rule expressions are cached. The compilation result is executed using the rule input context, the hit rule is determined according to the rule priority, and the gateway branch variable and process start variable are generated according to the hit rule.

[0015] As one possible implementation, step S5 of this solution further includes: The process scheduling layer obtains the external tasks to be processed from the workflow engine and calls the external task locking interface of the workflow engine to lock the external tasks according to the lock holder identifier and the preset engine locking duration. Generate a cache lock key based on the external task identifier, node instance identifier, and lock holder identifier; The cache lock key and lock holder identifier are written to the cache lock module through an atomic write operation, and the cache lock duration is set for the cache lock key; After the engine lock and cache lock of the external task are successfully written, the external task message is generated and sent.

[0016] As one possible implementation, further, in step S6 of this solution, the parameter parsing DSL includes: A value-retrieval function used to extract the target value from the event execution context based on the parameter path; A fixed-value function used to request parameters from the node to write preset fixed values; An array extraction function used to extract a set of target fields from an array object; Object field processing functions used to extract target fields from an object and rename the target fields; A string concatenation function used to concatenate fixed characters with dynamically extracted results; When the parameter template contains multiple DSL functions connected by pipe symbols, the multiple DSL functions are executed sequentially according to their arrangement order in the parameter template, and the output of the previous DSL function is used as the input of the next DSL function.

[0017] As one possible implementation, the lock continuation step S8 of this solution further includes: Periodically obtain the engine lock expiration time and cache lock expiration time of the external task; Calculate the remaining duration of the engine lock and cache lock respectively; When any of the remaining time durations is less than the preset lifespan threshold, the current executor is verified as the lock holder of the corresponding external task based on the external task identifier and the lock holder identifier. After the verification is successful, the lock extension interface of the workflow engine is called to extend the lock duration of the engine lock, and the cache lock duration of the cache lock is extended simultaneously.

[0018] Based on the above, this solution also proposes an event-driven three-layer decoupled workflow orchestration system, which includes: an event orchestration layer, a rule decision layer, a process scheduling layer, a message queue, a cache lock module, and a node executor cluster. The event orchestration layer is used to receive and parse event triggering requests, create event instances, load event definitions, generate a set of node instances, and maintain node states and event execution contexts. The rule decision layer is communicatively connected to the event orchestration layer and is used to execute the rule set corresponding to the event definition based on the event execution context, and generate gateway branch variables and process start variables. The process scheduling layer is communicatively connected to the event orchestration layer and the rule decision layer, and is used to start process instances according to the process initiation variables, control the flow of the process instances according to the gateway branch variables, lock the external tasks generated by the process instances, and complete the external tasks. The message queue is communicatively connected to the process scheduling layer and the node executor cluster, respectively, and is used to receive external task messages sent by the process scheduling layer and distribute the external task messages to the node executor cluster. The cache lock module is communicatively connected to the process scheduling layer and the node executor cluster, respectively, and is used to store the distributed lock corresponding to the external task and perform lock holder verification and lock renewal. The node executor cluster is communicatively connected to the event orchestration layer. It is used to determine the node executor based on the task topic in the external task message, assemble the node request parameters using parameter parsing DSL, execute the corresponding node action, and call back the node execution result to the event orchestration layer.

[0019] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art: The present invention separates event reception and status maintenance, business rule calculation, and process instance scheduling by setting up an event orchestration layer, a rule decision layer, and a process scheduling layer. The event orchestration layer creates event instances and generates a set of node instances based on event codes; the rule decision layer generates gateway branch variables and process initiation variables based on the event execution context; and the process scheduling layer starts and controls process instances based on these variables. Therefore, event types, rule expressions, and process models can be adjusted separately, reducing the cascading impact of business rule changes on the event access program and the process scheduling program, and improving the maintainability and independent scalability of the workflow orchestration structure.

[0020] This invention's solution, upon a process instance reaching an external task node, first locks the external task through the workflow engine, then writes a distributed lock corresponding to that external task into the cache lock module. Only when both types of locks are successfully established is the external task message generated and sent to the message queue. During execution, lock holder verification and lock renewal are performed based on the remaining lock duration, ensuring that long-running nodes maintain a locked task state during execution, reducing the possibility of external tasks being repeatedly acquired by other node executors due to lock expiration. Combined with the asynchronous distribution mechanism of the message queue, this also allows for the separation of process scheduling and business node execution, improving task concurrency and fault isolation capabilities.

[0021] This invention routes external tasks to HTTP executors, message executors, approval executors, and client callback executors through task topics. It extracts, transforms, and combines node request parameters from the event execution context and upstream node execution results using a parameter parsing DSL, reducing the need to write separate parameter mapping programs for different nodes. After a node completes execution, the event orchestration layer updates the node status and event execution context uniformly, and the process scheduling layer completes the external task and advances the process. When a node times out, fails to execute, the lock is about to expire, or the execution count exceeds the limit, lock renewal, retry, suspension, cancellation, or termination is performed according to retry and pause / termination policies, thereby improving the recoverability and operational controllability of abnormal workflows. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a simplified implementation flowchart of the event-driven, three-layer decoupled workflow orchestration method of this solution; Figure 2 This is a simplified diagram of the network structure of the three-layer decoupled workflow orchestration system involved in this scheme; Figure 3 This is a schematic diagram of the network structure data transmission of the three-layer decoupled workflow orchestration system involved in this scheme. Detailed Implementation

[0024] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be particularly noted that the following embodiments are for illustrative purposes only and do not limit the scope of the invention. Similarly, the following embodiments are only some, not all, embodiments of the present invention, and all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] This embodiment proposes an event-driven, three-layer decoupled workflow orchestration method, which is based on a three-layer decoupled workflow orchestration system (see reference). Figure 2 As shown in the diagram, the system includes: an event orchestration layer, a rule decision layer, a process scheduling layer, a message queue, a cache lock module, and a node executor cluster; simultaneously, combined with Figure 1 , Figure 3 As shown, the three-layer decoupled workflow orchestration method described in this solution includes: S1, the event orchestration layer receives event triggering requests sent by external systems, performs standardized parsing of the event triggering requests, and generates event instance identifiers and event execution contexts containing event codes, business primary keys, and business parameters; S2, the event orchestration layer loads the corresponding event definition according to the event code. The event definition includes a process model identifier, a rule set identifier, and a node configuration list. It also generates a set of node instances associated with the event instance identifier based on the node configuration list. Each node instance is configured with a node type, task topic, parameter template, timeout threshold, retry strategy, and / or pause / termination strategy. S3, the rule decision layer obtains the corresponding rule set according to the rule set identifier, and executes the rule set based on the event execution context to generate a rule decision result containing gateway branch variables and process start variables; S4, the process scheduling layer loads the corresponding process model according to the process model identifier, starts the process instance based on the process start variable, and writes the gateway branch variable into the process instance, so that the process instance flows to the corresponding external task node according to the gateway branch variable. S5, the process scheduling layer locks the external task corresponding to the external task node, writes the distributed lock associated with the external task into the cache lock module, and encapsulates the external task identifier, process instance identifier, node instance identifier, task topic and lock holder identifier into an external task message and sends it to the message queue. S6, the node executor cluster consumes the external task message, determines the corresponding node executor according to the task topic, and the node executor uses the parameter parsing DSL to parse the parameter template, extracts and assembles the node request parameters from the event execution context, executes the corresponding node action based on the node request parameters, and generates the node execution result; S7, the node executor calls back the node execution result to the event orchestration layer. The event orchestration layer updates the node state of the corresponding node instance and the event execution context according to the node execution result, and sends a task completion instruction to the process scheduling layer when the node action is successfully executed. The process scheduling layer completes the current external task and allows the process instance to continue to flow. S8, during the execution of an external task, when the task lock and cache distributed lock of the external task meet the renewal conditions, the lock holder is verified according to the external task identifier and the lock holder identifier, and the task lock and cache distributed lock are renewed synchronously after the verification is passed.

[0026] In step S8, during the execution of an external task, the process scheduling layer and the event orchestration layer perform lock renewal, task retry, node suspension, process suspension, node cancellation, or process termination processing according to the lock remaining duration, node execution duration, node execution result, and execution count of the external task, and in accordance with the retry strategy and pause / termination strategy of the corresponding node instance.

[0027] Different external systems can send event trigger requests via HTTP interfaces or message queues, but the field names, parameter structures, and time formats used by different trigger sources may differ. If external requests are directly passed to the rule decision layer and process scheduling layer, subsequent processing modules need to adapt to different data formats, which can easily lead to coupling between the event access logic and the rule and process logic.

[0028] Therefore, in this solution, step S1 standardizes and parses the event triggering request to form a unified event execution context and generate an event instance identifier that runs through the subsequent process.

[0029] As one possible implementation, step S1 of this solution further includes: The event orchestration layer receives event trigger requests sent by external systems; Extract the trigger source identifier, event code, business primary key, business parameters, and trigger time from the event trigger request; The business parameters are converted into a context object with a preset structure, and the trigger time is converted into a unified time format; Generate an event idempotent key based on the event code, business primary key, and trigger source identifier; Duplicate event validation is performed based on the event idempotent key. If no event instance corresponding to the event idempotent key is found, the event instance identifier is generated and the event execution context is created.

[0030] As an example, step S1 of this solution includes the following technical details: In this scheme, the event orchestration layer receives event triggering requests sent by external systems and represents the original event triggering request as follows:

[0031] in, This indicates that the original event triggered the request; Indicates event encoding; Indicates the business primary key; Indicates business parameters; Indicates the identifier of the event trigger source; Indicates the event trigger time; This indicates the link tracing identifier.

[0032] When an external system sends an event-triggered request via an HTTP interface, the event orchestration layer extracts the aforementioned fields from the request path, request header, and request body; when an external system sends an event-triggered request via a message queue, the event orchestration layer extracts the aforementioned fields from the message subject, message header, and message body.

[0033] In this solution, the event orchestration layer processes the original event triggering requests through preset standardized functions:

[0034] in, Indicates the initial event execution context; Represents a normalized function for events; This indicates that the original event triggered the request.

[0035] Under the logical definition of this formula: the business parameters, trigger time and source identifier in the original event trigger request may have different formats. Therefore, the external fields are first mapped to internal standard fields by the field mapping rules, and then data type conversion, time format conversion and null value completion are performed to finally form a unified event execution context.

[0036] The initial event execution context includes at least the event code, business primary key, standardized business parameters, trigger source identifier, standardized trigger time, and tracing identifier.

[0037] In this solution, to avoid creating multiple duplicate event instances by external systems repeatedly sending the same event, an idempotent key for the event can be generated based on the event code, business primary key, and trigger source identifier. Its definition is as follows:

[0038] in, Indicates the idempotent key of the event; Represents the hash operation function; Indicates event encoding; Indicates the business primary key; Indicates the identifier of the event trigger source; This indicates a field concatenation operation.

[0039] Under the logical definition of this formula, the event code is used to distinguish the business event type, the business primary key is used to distinguish the business objects corresponding to the same type of event, and the trigger source identifier is used to distinguish the event generating system; by concatenating the three and performing a hash operation, a stable idempotent event key can be formed.

[0040] In this scheme, the event orchestration layer checks whether an unterminated event instance corresponding to the event idempotent key already exists. If not, an event instance identifier is generated. Create an event instance; if it already exists, return the existing event instance or refuse to create it again according to the preset duplicate event handling rules.

[0041] The data output in step S1 of this solution Includes: event instance identifier Event coding Initial event execution context event idempotent key .

[0042] The subsequent step S2 of this solution will use event coding. Query event definitions, identified by event instances. Associate it with subsequently generated node instances and execute the context of the initial event. This serves as the foundational data for rule-based decision-making and node parameter parsing.

[0043] In this solution, if a task is created and executed directly based on the business code after an event is triggered, the node type, task topic, parameter template, retry strategy, and pause / termination strategy will be scattered throughout the business program, making it impossible to flexibly configure for different events.

[0044] Therefore, step S2 of this solution converts the static event definition into a set of runtime node instances corresponding to the current event instance.

[0045] As an example, in step S2 of this solution, the node types in the node configuration list include HTTP nodes, message nodes, approval nodes, client callback nodes, and gateway nodes. The node executor cluster routes HTTP nodes to HTTP executors, message nodes to message executors, approval nodes to approval executors, and client callback nodes to client callback executors based on the task topic. The process scheduling layer determines the subsequent process branch corresponding to the gateway node based on the gateway branch variable.

[0046] As one possible implementation, further, in step S2 of this solution, the retry strategy includes a one-time execution mode, a polling error stop mode, and a polling error continue mode; In the single execution mode, a node action is executed once, and a corresponding pause and termination strategy is triggered when the node action fails to execute. In the polling error stop mode, node actions are executed according to a preset polling interval, and subsequent polling is stopped and a corresponding pause termination strategy is triggered when a polling execution error is detected. In the polling error continuation mode, when a polling execution error is detected, the error result of the current polling is recorded, and subsequent polling continues until the node action is successfully executed or the preset polling limit is reached; As one possible implementation, further, in step S2 of this solution, the pause / termination strategy includes a node-level pause strategy, a global pause strategy, a node-level cancellation strategy, and a global termination strategy; The node-level pause policy is used to set the current node instance to a paused state while retaining the process instance and event execution context; The global pause policy is used to set the event instance and process instance to a paused state; The node-level cancellation policy is used to set the current node instance to a cancelled state and record the corresponding cancellation reason; The global termination policy is used to terminate the process instance, set the event instance to a terminated state, and clean up any node instances that have not yet been executed.

[0047] As a possible implementation example, step S2 of this solution further includes the following technical details: In this scheme, the event orchestration layer uses the event codes output in step S1. The corresponding event definition is:

[0048] in, This represents the event definition corresponding to the event code; This indicates that the event defines a query function; This indicates the event code.

[0049] An event definition can be expressed as:

[0050] in, Indicates process model identifier; Indicates the rule set identifier; This represents the list of node configurations. Indicates a global retry policy; This indicates a global pause / termination strategy.

[0051] The node configuration list is as follows:

[0052] in, Represents the node configuration list; defines Indicates the first Node configuration; Indicates the number of nodes configured.

[0053] In this scheme, each node configuration includes at least node identifier, node type, task topic, parameter template, timeout threshold, node retry policy, and node pause / termination policy.

[0054] In this scheme, the event orchestration layer instantiates the node configurations in the node configuration list, generating node instances, which are defined as follows:

[0055] in, Indicates the first One node instance; This represents the node instantiation function; Indicates the first Node configuration; Indicates the event instance identifier.

[0056] This results in a set of node instances:

[0057] in, Represents a collection of node instances; Define Indicates the first One node instance; Indicates the number of node instances.

[0058] In this scheme, each node instance is associated with an event instance identifier. It is associated with a node instance, and has an independent node instance identifier, initial node state, current execution count, and runtime strategy parameters.

[0059] In this solution, when a node retry policy is configured in the node configuration, the node retry policy is used; when no node retry policy is configured, the global retry policy is inherited, which is defined as follows:

[0060] in, Indicates the first The actual retry strategy used by each node instance; Indicates the first The node retry policy in the configuration of each node; This indicates the global retry policy in the event definition; This indicates that the corresponding policy has not been configured.

[0061] The pause / termination strategy uses the same inheritance mechanism, defined as follows:

[0062] in, Indicates the first The actual pause / termination strategy used by each node instance; Indicates the first The node pause / termination policy in the node configuration; This indicates the global pause / termination strategy in the event definition.

[0063] The data obtained by this scheme through step S2 Includes: event instance identifier Initial event execution context Process model identification Rule set identifier Node instance collection .

[0064] The subsequent step S3 of this solution will be based on the rule set identifier. Load the rule set and execute the context with the initial event. As the basis for rule input; step S4 will be based on the process model identifier. Loading process model.

[0065] Different event instances may require entering different process branches due to variations in business parameters, business object states, and external service data. If the branch conditions are fixed in the business code or process model, each adjustment to the business rules would require modification of the business program or process model. Therefore, step S3 of this solution uses an independent rule decision layer to form gateway branch variables and process initiation variables.

[0066] As an example, step S3 of this solution includes: The data items to be completed are determined according to the data completion configuration in the rule set, and the completion data is obtained from the corresponding external service according to the data items to be completed. The completed data is merged with the event execution context to form a rule input context; The rule expressions in the rule set are compiled, and the compilation results corresponding to the rule expressions are cached. The compilation result is executed using the rule input context, the hit rule is determined according to the rule priority, and the gateway branch variable and process start variable are generated according to the hit rule.

[0067] As one possible implementation, step S3 of this solution further includes the following technical details: In this scheme, the rule decision layer uses the rule set identifier output in step S2. The function for retrieving the rule set is defined as follows:

[0068]

[0069] in, Represents a set of rules; This represents a rule set query function; Indicates the rule set identifier.

[0070] The rule set may include data completion configurations. The rule decision layer obtains completion data from the corresponding external service based on the data completion configuration. It is then merged with the initial event execution context, and its function is defined as:

[0071] in, This indicates the rule input context; Indicates the initial event execution context; This indicates the completion data obtained based on the data completion configuration; This indicates a context merging operation.

[0072] Under the logical definition of this formula, the event triggering request usually only contains the basic business parameters required to trigger the event, while rule judgment may also require data such as user level, resource status, inventory status or service status; therefore, it is necessary to merge the external supplementary data with the initial event execution context to form a complete rule input context.

[0073] When re-evaluating rules during process execution, the output context of completed nodes can also be used. Merge into rule input context Its definition is:

[0074] in, This indicates the output context of historical nodes that have completed node formation.

[0075] In this scheme, the rule set includes several rules defined as follows:

[0076] Among them, the definition Indicates the first Rules; Indicates the number of rules.

[0077] The rule decision-making level on the first The conditional expression of a rule is compiled and the compilation result is cached. The rule is then input into the context and the compilation result is input. It is defined as follows:

[0078] in, Indicates the first The result of a rule is 1 if it is hit and 0 if it is not hit; This represents the function to execute the regular expression; Indicates the first Rules; This indicates the context in which the rule is input.

[0079] When multiple rules are applied simultaneously, the final rule that applies can be determined based on its priority, which is defined as follows:

[0080] in, Indicates the sequence number of the final hit rule; This indicates the index of the variable that maximizes the objective function value; Indicates the first The result of hitting the rule; Indicates the first The priority of the rules; Indicates the number of rules.

[0081] Under the logical definition of this formula, the missed rule satisfies The corresponding selection value is 0; the hit rule is satisfied. The corresponding selection value is equal to its rule priority. Therefore, taking the maximum value of the product determines the rule that has been hit and has the highest priority.

[0082] Generate rule decision results based on the final hit rules:

[0083] in, Indicates the result of rule-based decision-making; Indicates gateway branch variables; This indicates the process initiation variable.

[0084] In this scheme, the gateway branch variable is used for the selection of the gateway branch for subsequent process instances; the process startup variable is used to provide the process model with the event instance identifier, business primary key, and parameters required for process initialization.

[0085] After step S3, the data obtained by this method include: ;in, Indicates the event instance identifier; Indicates process model identifier; Represents a collection of node instances; This indicates the rule input context; Indicates gateway branch variables; This indicates the process initiation variable.

[0086] Among them, the subsequent step S4 is identified according to the process model. Load the process model and set the gateway branch variable. and process initiation variables Write process example.

[0087] The rule decision results generated by the rule decision layer can only represent business judgment results and cannot directly control the execution order of nodes. Therefore, in step S4 of this solution, the process scheduling layer converts the rule decision results into process variables that the workflow engine can recognize and starts the corresponding process instance.

[0088] In this scheme, the process scheduling layer uses the process model identifier output in step S2. The loading process model is defined as follows:

[0089] in, Representing the process model; This indicates the function for loading the process model; This indicates the process model identifier.

[0090] In this solution, the process model includes a start node, external task nodes, a gateway node, an end node, and process connections linking the nodes. External task nodes are configured with task topics, and gateway nodes are configured with branching conditions based on process variables.

[0091] In this scheme, the process scheduling layer merges the gateway branch variable and process start variable generated in step S3, and adds an event instance identifier, which is defined as:

[0092] in, Represents a set of process variables; Indicates the process initiation variable; Indicates gateway branch variables; Indicates the event instance identifier; This indicates a variable set merging operation.

[0093] Under the logical definition of this formula, the process initiation variable is used to complete the process instance initialization, the gateway branch variable is used for gateway routing, and the event instance identifier is used to establish the correspondence between the event instance and the process instance. Therefore, they all need to be written into the process instance.

[0094] In this scheme, the process scheduling layer starts process instances based on the process model and process variables, which is defined as follows:

[0095] in, Represents a process instance; This represents the process instance startup function; Representing the process model; Represents a set of process variables.

[0096] After the process instance is generated, obtain the process instance identifier. And establish a mapping between event instances and process instances, defined as:

[0097] in, This represents the mapping relationship between event instances and process instances; Indicates the event instance identifier; Indicates the process instance identifier; This indicates the process model identifier.

[0098] When a process instance reaches the gateway node, it reads the gateway branch variable from the process variable set. Select the corresponding process branch and transfer it to the external task node.

[0099] After step S4, the data obtained by this method include: ;in, Indicates the event instance identifier; Indicates the process instance identifier; This indicates the mapping relationship between event instances and process instances; Represents a collection of node instances; This indicates the context in which the rule is input.

[0100] After the process instance reaches the external task node, step S5 will be based on the process instance identifier. Retrieve the corresponding external task and based on the node instance set. Locate the node instance corresponding to this external task.

[0101] When multiple executors are running simultaneously, the same external task may be acquired by multiple executors at the same time; for nodes with long execution times, the workflow engine lock may also expire before the node finishes execution. Therefore, step S5 of this solution completes task locking before the external task is sent to the message queue, and applies a second layer of constraint through a cached distributed lock.

[0102] As one possible implementation, step S5 of this solution further includes: The process scheduling layer obtains the external tasks to be processed from the workflow engine and calls the external task locking interface of the workflow engine to lock the external tasks according to the lock holder identifier and the preset engine locking duration. Generate a cache lock key based on the external task identifier, node instance identifier, and lock holder identifier; The cache lock key and lock holder identifier are written to the cache lock module through an atomic write operation, and the cache lock duration is set for the cache lock key; After the engine lock and cache lock of the external task are successfully written, the external task message is generated and sent.

[0103] As an example, step S5 of this solution includes the following technical details: After a process instance enters an external task node, the process scheduling layer obtains the external task to be executed. And call the workflow engine's external task locking interface:

[0104] in, Indicates the first Engine lockout results for an external task; Indicates the function for locking external tasks; Indicates the first An external task; Indicates the lock holder's identity; Indicates the duration of engine lockout.

[0105] A cache lock key is generated based on the external task identifier, node instance identifier, and lock holder identifier, and its definition is:

[0106] in, Indicates the first A cache lock key for an external task; Represents the hash operation function; Indicates the first An external task identifier; Indicates the first Node instance identifier; Indicates the lock holder's identity; This indicates a field concatenation operation.

[0107] The cache lock module establishes a distributed lock through atomic write operations, which is defined as follows:

[0108] in, This indicates the result of writing to the cached distributed lock; This indicates the atomic write function for the cache lock; Indicates the cache lock key; Indicates the lock holder's identity; Indicates the duration of cache lock.

[0109] The conditions under which external tasks are allowed to be sent are:

[0110] in, Indicates the first Does the external task meet the sending conditions? This indicates the engine lock result; This indicates the result of writing to the cached distributed lock; Represents the logical AND operation.

[0111] Only when both the engine lock and the cache lock are successfully established. Only if the result is true will the process scheduling layer generate an external task message.

[0112] In this scheme, external task messages can be represented as:

[0113] in, Indicates the first An external task message; Indicates an external task identifier; Indicates the process instance identifier; Indicates the event instance identifier; Indicates the node instance identifier; Indicate the task topic; Indicates the lock holder's identity; Indicates the lock expiration time.

[0114] The process scheduling layer will receive external task messages. Send to the message queue, and according to the task topic. Configure message routing information.

[0115] After step S5, the data obtained by this method include: ;in, Indicates an external task message; Indicates the cache lock key; Indicates the lock holder's identity; Indicates the lock expiration time; This indicates the context in which the rule is input.

[0116] In the subsequent step S6 of this scheme, the node executor will be selected based on the task topic in the external task message; in step S8, the lock status will be checked and the lock will be renewed based on the cache lock key, the lock holder identifier and the lock expiration time.

[0117] In this solution, different nodes may employ different execution methods such as HTTP calls, message sending, manual approval, or client callbacks. Their request parameters may also come from event initial parameters, rule completion data, or upstream node output. Writing a separate parameter extraction program for each node would result in the node execution program being tightly coupled with the specific business process.

[0118] As an example, in step S6 of this solution, the parameter parsing DSL includes: A value-retrieval function used to extract the target value from the event execution context based on the parameter path; A fixed-value function used to request parameters from the node to write preset fixed values; An array extraction function used to extract a set of target fields from an array object; Object field processing functions used to extract target fields from an object and rename the target fields; A string concatenation function used to concatenate fixed characters with dynamically extracted results; When the parameter template contains multiple DSL functions connected by pipe symbols, the multiple DSL functions are executed sequentially according to their arrangement order in the parameter template, and the output of the previous DSL function is used as the input of the next DSL function.

[0119] As one possible implementation, step S6 of this solution further includes the following technical details: The node executor cluster consumes external task messages from the message queue. Read task topic The node executor is determined through the executor routing function, which is defined as follows:

[0120] in, Indicates the first The node executor corresponding to each external task; This represents the routing function between the task topic and the node executor; Indicates the task topic.

[0121] For example, HTTP task topics are mapped to HTTP executors, message task topics are mapped to message executors, approval task topics are mapped to approval executors, and client callback task topics are mapped to client callback executors.

[0122] In this scheme, the node executor is based on the node instance identifier. Read the parameter template of the corresponding node instance and construct the parameter parsing context:

[0123] in, Indicates the first The parameter parsing context of each node; Indicates the initial event execution context; This represents the completed data obtained in step S3; This indicates the output context of the historical node that has completed the formation of the upstream node; This represents fixed configuration data; This indicates a context merging operation.

[0124] When the first execution node has no upstream output, the historical node outputs the context. Empty; After step S7 of this solution updates the output context of the historical nodes, subsequent nodes can retrieve the updated context from the previous steps. Extract parameters from it.

[0125] Regarding the parsing of DSL parameters, this scheme assumes that the DSL expression for a certain target field in the parameter template is derived from... If functions are connected by a pipe symbol, they are parsed according to the following recursive relationship:

[0126]

[0127]

[0128] in, This represents the initial input to the DSL function chain; Indicates the first The parameter parsing context of each node; Indicates the first Intermediate results after the execution of a DSL function; Indicates the first function in the function chain One DSL function; Indicates the DSL function number; This indicates the total number of DSL functions. No. The result after executing each DSL function; Indicates the first The first of the node request parameters Each field value.

[0129] Under the definition logic of this formula, the output of the function preceding the pipe symbol serves as the input of the function following it. Therefore, the entire DSL expression can be represented as a sequential composition of multiple functions. Starting from the parameter parsing context, each DSL function is executed in turn, and finally the target field value is obtained.

[0130] After performing the above parsing on all fields in the parameter template, the node request parameters are generated:

[0131] in, Indicates the first Node request parameters for each node; definition Indicates the first The node of the first Values ​​of each parameter field; Indicates the first The number of parameter fields for each node.

[0132] In terms of executing node actions, the node executor Based on node request parameters Execute the corresponding node action:

[0133] in, Indicates the first The execution results of each node; This indicates the function to execute the node's action; Indicates a node executor; This represents the node request parameters.

[0134] In this scheme, the node execution results include execution status, response data, error code, error message, execution start time, and execution end time.

[0135] After step S6, the data obtained by this scheme include: ;in, Indicates an external task identifier; Indicates the node instance identifier; Indicates the process instance identifier; Indicates the execution result of the node; Indicates the lock holder's identity; This indicates the cache lock key.

[0136] In the subsequent step S7 of this scheme, the node status and event execution context will be updated according to the node execution result; when the node execution fails, times out, or the lock is about to expire, step S8 will use the above parameters to perform exception control.

[0137] In this solution, if the node executor directly operates the workflow engine after completing the business action, it will cause coupling between the node executor and the process scheduling layer; if the node executor only returns the business result without updating the event execution context, subsequent nodes will not be able to reference the output of the previous node. Therefore, in step S7 of this solution, the event orchestration layer uniformly receives callbacks, maintains node states and event execution contexts, and then the process scheduling layer completes the external tasks.

[0138] Regarding the generation and reception of node callbacks, the node executor in this scheme forms node callback data based on the node execution results generated in step S6:

[0139] in, Indicates the first Node callback data for each node; Indicates an external task identifier; Indicates the node instance identifier; Indicates the process instance identifier; Indicates the execution status of the node; This represents the node's response data; Indicates node error information; Indicates the node execution end time.

[0140] The event orchestration layer queries the node instance based on the node instance identifier and verifies whether the node instance belongs to the current event instance.

[0141] Regarding updating node status, this solution transitions node status based on the current node status and the node execution status:

[0142] in, Indicates the node state after callback processing; Indicates the node state before callback processing; This indicates the node execution status returned by the node executor; This represents the node state transition function.

[0143] For example, when the current node status is in execution and the node execution status is successful, the node status is updated to execution successful; when the node execution status is failed, it is updated to pending retry or execution failed based on the retry judgment in the subsequent step S8; when the client callback node has not yet received a response from the third party, it can be updated to waiting for callback status.

[0144] Regarding updating the event execution context, when a node executes successfully or produces output data that can be used by subsequent nodes, the node response data is written to the historical node output context:

[0145] in, This indicates the updated output context of the historical node; This indicates the output context of the historical nodes before the update; Indicates the first The node identifier of each node; Indicates the first Response data from each node; This indicates a context merging operation.

[0146] The updated event execution context is as follows:

[0147] in, Indicates the updated event execution context; Indicates the initial event execution context; Indicates that the rules complete the data; This indicates the updated output context of the historical node.

[0148] When this solution executes subsequent nodes, it uses the updated event execution context as the basis for the new parameter parsing context.

[0149] Regarding the completion of external tasks, when a node's execution status is successful, the event orchestration layer sends a task completion instruction to the process scheduling layer:

[0150] in, Indicates the first The task completion instructions corresponding to each node; Indicates an external task identifier; Indicates the process instance identifier; Indicates the node instance identifier; Indicates the lock holder's identity; This indicates the updated event execution context.

[0151] The process scheduling layer calls the workflow engine's task completion interface based on the external task identifier and lock holder identifier, enabling the process instance to proceed to the next node. If the next node is an external task node, then step S5 is re-entered; if the process reaches the end node, then the process instance and event instance are updated to the completed state.

[0152] The data obtained by this scheme through step S7 include: ;in, Indicates the updated node state; Indicates the updated event execution context; This indicates that the task has been completed.

[0153] When the node execution result does not meet the task completion conditions, the updated node status and corresponding execution information are passed to the subsequent step S8, which determines whether to retry, pause, cancel, or terminate.

[0154] During node execution, issues such as prolonged execution time, failed business calls, exceeding the execution limit, or requiring manual intervention may arise. Without unified exception control, problems such as expired task locks, repeated execution of the same node, prolonged node blocking, or continued abnormal process flow may occur.

[0155] As an example, the lock continuation step S8 in this scheme includes: Periodically obtain the engine lock expiration time and cache lock expiration time of the external task; Calculate the remaining duration of the engine lock and cache lock respectively; When any of the remaining time durations is less than the preset lifespan threshold, the current executor is verified as the lock holder of the corresponding external task based on the external task identifier and the lock holder identifier. After the verification is successful, the lock extension interface of the workflow engine is called to extend the lock duration of the engine lock, and the cache lock duration of the cache lock is extended simultaneously.

[0156] As one possible implementation, step S8 of this solution further includes the following technical details: Regarding lock remaining duration detection and renewal, the process scheduling layer or lock renewal task periodically obtains the expiration time of external task locks and calculates the lock remaining duration, which is defined as:

[0157] in, Indicates the first The remaining lock duration for each external task; Indicates the first The lock expiration time for an external task; Indicates the current system time.

[0158] When the remaining lock duration is not greater than the lock life extension threshold, life extension is triggered:

[0159] in, Indicates the first The lock continuation flag for an external task; when the value is 1, lock continuation is performed. Indicates the remaining lock duration; This indicates the preset lock life extension threshold.

[0160] Before performing the life extension, based on the cache lock key Read the lock holder and compare it with the lock holder identifier in the external task message. Compare the locks. If they match, call the workflow engine lock extension interface and simultaneously extend the validity period of the cached distributed lock.

[0161] Regarding node execution timeout determination, this solution calculates the node's execution time based on the node's start time and current time, defined as follows:

[0162] in, Indicates the first The execution time of each node; Indicates the current system time; Indicates the first The execution start time of each node.

[0163] The node timeout flag is:

[0164] in, Indicates the first Timeout flags for each node; Indicates the first The execution time of each node; Indicates the first The timeout threshold configured for each node.

[0165] When the timeout flag is 1, the node pause, process pause, node cancellation, or process termination action is determined according to the pause / termination policy corresponding to the node instance.

[0166] Regarding node retry judgment, this scheme sets the first... The number of times each node has been executed is currently [number]. The maximum number of executions allowed is The retry permission flag is then set to:

[0167] in, Indicates the first Does each node allow retries? Indicates the first The execution status of each node; Indicates an execution failure status; Indicates the first The current number of times each node has been executed; Indicates the first The maximum number of times a node is allowed to execute; Represents the logical AND operation.

[0168] When retries are allowed, the next execution time is calculated based on the polling interval configured for the node:

[0169] in, Indicates the first The next retry time for each node; Indicates the current system time; Indicates the first The retry interval configured for each node.

[0170] The event orchestration layer updates the node status to pending retry, and after the next retry time arrives, it regenerates the external task message or re-delivers the existing task message, causing the process to return to step S5.

[0171] For the single-execution mode, if the first execution fails, the polling will not be redeployed; for the polling error stop mode, the subsequent polling will stop after the current polling fails; for the polling error continue mode, the current polling failure result will be recorded and the remaining polling will continue to be executed until it succeeds or the maximum number of polling attempts is reached.

[0172] Regarding the selection of pause / termination actions, the exception control action is selected based on the scope of the pause / termination strategy, the triggering conditions, and the action type:

[0173] in, Indicates that for the first An exception control action executed by a node or corresponding process instance; This indicates the function for selecting the pause / termination strategy; Indicates the scope of the strategy, including node-level and global-level; This indicates the policy trigger conditions, including execution timeout, exceeding the maximum number of execution failures, and manual intervention; Indicates the type of strategy action, including pause, cancel, and terminate.

[0174] When the node pause action is selected, only the current node instance is set to the paused state while the event execution context is preserved; when the process pause action is selected, both the event instance and the process instance are set to the paused state; when the node cancel action is selected, the current node instance is set to the canceled state and the cancellation reason is recorded; when the process terminate action is selected, the process instance is terminated and any node instances that have not yet been executed are set to the canceled or unexecuted cleanup state.

[0175] After exception handling, update the node status or process status, which is defined as follows: In addition, exception handling logs or compensation logs are generated. .

[0176] Through step S8, this solution outputs data. And execute the closed loop, output data include: ;in, Indicates abnormal control actions; Indicates the node status or process status after exception handling; Indicates the time for the next retry; This indicates an exception handling log or a compensation log.

[0177] When the exception control action is lock continuation, the node continues to execute step S6; when the exception control action is retry, the process returns to step S5 to resubmit the task; when the exception control action is continue execution, the process completes the external task through step S7 and enters the next node; when the exception control action is pause, cancel, or terminate, the process stops flowing until a recovery instruction is received or the process terminates.

[0178] Combination Figure 2 , Figure 3 As shown above, this solution also proposes an event-driven three-layer decoupled workflow orchestration system, which includes: an event orchestration layer, a rule decision layer, a process scheduling layer, a message queue, a cache lock module, and a node executor cluster. The event orchestration layer is used to receive and parse event triggering requests, create event instances, load event definitions, generate a set of node instances, and maintain node states and event execution contexts. The rule decision layer is communicatively connected to the event orchestration layer and is used to execute the rule set corresponding to the event definition based on the event execution context, and generate gateway branch variables and process start variables. The process scheduling layer is communicatively connected to the event orchestration layer and the rule decision layer, and is used to start process instances according to the process initiation variables, control the flow of the process instances according to the gateway branch variables, lock the external tasks generated by the process instances, and complete the external tasks. The message queue is communicatively connected to the process scheduling layer and the node executor cluster, respectively, and is used to receive external task messages sent by the process scheduling layer and distribute the external task messages to the node executor cluster. The cache lock module is communicatively connected to the process scheduling layer and the node executor cluster, respectively, and is used to store the distributed lock corresponding to the external task and perform lock holder verification and lock renewal. The node executor cluster is communicatively connected to the event orchestration layer. It is used to determine the node executor based on the task topic in the external task message, assemble the node request parameters using parameter parsing DSL, execute the corresponding node action, and call back the node execution result to the event orchestration layer.

[0179] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A three-layer decoupled workflow orchestration method based on event-driven principles, characterized in that, include: S1, the event orchestration layer receives event triggering requests sent by external systems, performs standardized parsing of the event triggering requests, and generates event instance identifiers and event execution contexts containing event codes, business primary keys, and business parameters; S2, the event orchestration layer loads the corresponding event definition according to the event code. The event definition includes a process model identifier, a rule set identifier, and a node configuration list. It also generates a set of node instances associated with the event instance identifier based on the node configuration list. Each node instance is configured with a node type, task topic, parameter template, timeout threshold, retry strategy, and / or pause / termination strategy. S3, the rule decision layer obtains the corresponding rule set according to the rule set identifier, and executes the rule set based on the event execution context to generate a rule decision result containing gateway branch variables and process start variables; S4, the process scheduling layer loads the corresponding process model according to the process model identifier, starts the process instance based on the process start variable, and writes the gateway branch variable into the process instance, so that the process instance flows to the corresponding external task node according to the gateway branch variable. S5, the process scheduling layer locks the external task corresponding to the external task node, writes the distributed lock associated with the external task into the cache lock module, and encapsulates the external task identifier, process instance identifier, node instance identifier, task topic and lock holder identifier into an external task message and sends it to the message queue. S6, the node executor cluster consumes the external task message, determines the corresponding node executor according to the task topic, and the node executor uses the parameter parsing DSL to parse the parameter template, extracts and assembles the node request parameters from the event execution context, executes the corresponding node action based on the node request parameters, and generates the node execution result; S7, the node executor calls back the node execution result to the event orchestration layer. The event orchestration layer updates the node state of the corresponding node instance and the event execution context according to the node execution result, and sends a task completion instruction to the process scheduling layer when the node action is successfully executed. The process scheduling layer completes the current external task and allows the process instance to continue to flow. S8, during the execution of an external task, when the task lock and cache distributed lock of the external task meet the renewal conditions, the lock holder is verified according to the external task identifier and the lock holder identifier, and the task lock and cache distributed lock are renewed synchronously after the verification is passed.

2. The event-driven, three-layer decoupled workflow orchestration method as described in claim 1, characterized in that, Step S8 includes: During the execution of an external task, the process scheduling layer and the event orchestration layer perform lock renewal, task retry, node suspension, process suspension, node cancellation, or process termination processing according to the lock remaining duration, node execution duration, node execution result, and execution count of the external task, and in accordance with the retry policy and pause / termination policy of the corresponding node instance.

3. The event-driven, three-layer decoupled workflow orchestration method as described in claim 1, characterized in that, Step S1 includes: The event orchestration layer receives event trigger requests sent by external systems; Extract the trigger source identifier, event code, business primary key, business parameters, and trigger time from the event trigger request; The business parameters are converted into a context object with a preset structure, and the trigger time is converted into a unified time format; Generate an event idempotent key based on the event code, business primary key, and trigger source identifier; Duplicate event validation is performed based on the event idempotent key. If no event instance corresponding to the event idempotent key is found, the event instance identifier is generated and the event execution context is created.

4. The event-driven, three-layer decoupled workflow orchestration method as described in claim 1, characterized in that, In step S2, the node types in the node configuration list include HTTP nodes, message nodes, approval nodes, client callback nodes, and gateway nodes; The node executor cluster routes HTTP nodes to HTTP executors, message nodes to message executors, approval nodes to approval executors, and client callback nodes to client callback executors based on the task topic. The process scheduling layer determines the subsequent process branch corresponding to the gateway node based on the gateway branch variable.

5. The event-driven, three-layer decoupled workflow orchestration method as described in claim 1, characterized in that, In step S2 or step S8, the retry strategy includes a one-time execution mode, a polling error stop mode, and a polling error continue mode; In the single execution mode, a node action is executed once, and a corresponding pause and termination strategy is triggered when the node action fails to execute. In the polling error stop mode, node actions are executed according to a preset polling interval, and subsequent polling is stopped and a corresponding pause termination strategy is triggered when a polling execution error is detected. In the polling error continuation mode, when a polling execution error is detected, the error result of the current polling is recorded, and subsequent polling continues until the node action is successfully executed or the preset polling limit is reached; In step S2 or step S8, the pause / termination strategy includes a node-level pause strategy, a global pause strategy, a node-level cancellation strategy, and a global termination strategy. The node-level pause policy is used to set the current node instance to a paused state while retaining the process instance and event execution context; The global pause policy is used to set the event instance and process instance to a paused state; The node-level cancellation policy is used to set the current node instance to a cancelled state and record the corresponding cancellation reason; The global termination policy is used to terminate the process instance, set the event instance to a terminated state, and clean up any node instances that have not yet been executed.

6. The event-driven, three-layer decoupled workflow orchestration method as described in claim 1, characterized in that, Step S3 includes: The data items to be completed are determined according to the data completion configuration in the rule set, and the completion data is obtained from the corresponding external service according to the data items to be completed. The completed data is merged with the event execution context to form a rule input context; The rule expressions in the rule set are compiled, and the compilation results corresponding to the rule expressions are cached. The compilation result is executed using the rule input context, the hit rule is determined according to the rule priority, and the gateway branch variable and process start variable are generated according to the hit rule.

7. The event-driven, three-layer decoupled workflow orchestration method as described in claim 1, characterized in that, Step S5 includes: The process scheduling layer obtains the external tasks to be processed from the workflow engine and calls the external task locking interface of the workflow engine to lock the external tasks according to the lock holder identifier and the preset engine locking duration. Generate a cache lock key based on the external task identifier, node instance identifier, and lock holder identifier; The cache lock key and lock holder identifier are written to the cache lock module through an atomic write operation, and the cache lock duration is set for the cache lock key; After the engine lock and cache lock of the external task are successfully written, the external task message is generated and sent.

8. The event-driven, three-layer decoupled workflow orchestration method as described in claim 1, characterized in that, In step S6, the parameter parsing DSL includes: A value-retrieval function used to extract the target value from the event execution context based on the parameter path; A fixed-value function used to request parameters from the node to write preset fixed values; An array extraction function used to extract a set of target fields from an array object; Object field processing functions used to extract target fields from an object and rename the target fields; A string concatenation function used to concatenate fixed characters with dynamically extracted results; When the parameter template contains multiple DSL functions connected by pipe symbols, the multiple DSL functions are executed sequentially according to their arrangement order in the parameter template, and the output of the previous DSL function is used as the input of the next DSL function.

9. The event-driven, three-layer decoupled workflow orchestration method as described in claim 2, characterized in that, The lock continuation in step S8 includes: Periodically obtain the engine lock expiration time and cache lock expiration time of the external task; Calculate the remaining duration of the engine lock and cache lock respectively; When any of the remaining time durations is less than the preset lifespan threshold, the current executor is verified as the lock holder of the corresponding external task based on the external task identifier and the lock holder identifier. After the verification is successful, the lock extension interface of the workflow engine is called to extend the lock duration of the engine lock, and the cache lock duration of the cache lock is extended simultaneously.

10. An event-driven, three-layer decoupled workflow orchestration system, characterized in that, It includes: an event orchestration layer, a rule decision layer, a process scheduling layer, a message queue, a cache lock module, and a node executor cluster; The event orchestration layer is used to receive and parse event triggering requests, create event instances, load event definitions, generate a set of node instances, and maintain node states and event execution contexts. The rule decision layer is communicatively connected to the event orchestration layer and is used to execute the rule set corresponding to the event definition based on the event execution context, and generate gateway branch variables and process start variables. The process scheduling layer is communicatively connected to the event orchestration layer and the rule decision layer, and is used to start process instances according to the process start variables, control the flow of the process instances according to the gateway branch variables, lock the external tasks generated by the process instances, and complete the external tasks. The message queue is communicatively connected to the process scheduling layer and the node executor cluster, respectively, and is used to receive external task messages sent by the process scheduling layer and distribute the external task messages to the node executor cluster. The cache lock module is communicatively connected to the process scheduling layer and the node executor cluster, respectively, and is used to store the distributed lock corresponding to the external task and perform lock holder verification and lock renewal. The node executor cluster is communicatively connected to the event orchestration layer. It is used to determine the node executor based on the task topic in the external task message, assemble the node request parameters using parameter parsing DSL, execute the corresponding node action, and call back the node execution result to the event orchestration layer.

Images