Server-free workflow engine implementation method based on event arrangement

Abstract

The invention discloses a server-free workflow engine implementation method based on event orchestration, which relates to the technical field of server-free computing, and comprises the following steps: continuously monitoring a predefined event source; when an event is received, matching is performed according to a preset event triggering rule; if the event matching is successful, starting a corresponding predefined workflow according to an event triggering rule; mapping each task in the workflow to a server-free function according to the workflow definition, and triggering the server-free function to execute according to an event; recording the execution state of the workflow, updating the state, and performing flow control and error processing according to the execution state information. According to the method, the real-time response capability is improved, the execution efficiency is enhanced, and the reliability of process control and error processing is ensured, so that the requirements of an automatic complex business process are better met.

Description

Technical Field

[0001] The present invention relates to the field of serverless computing technology, and more specifically to a method for implementing a serverless workflow engine based on event orchestration. Background Art

[0002] In the existing serverless workflow engine technology field, although the serverless architecture has received widespread attention and application due to its high efficiency and flexibility, it still has many limitations in actual business scenarios. Traditional serverless workflow engines mainly face the following problems:

[0003] First, many existing workflow engines lack an effective event-driven mechanism, which means they rely mainly on scheduled tasks or require external manual triggers to execute specific processes. This model cannot meet high-real-time business scenarios because they cannot respond to changes in external events in a timely manner, thus affecting the overall performance of the system and user experience.

[0004] Secondly, most workflow engines on the market are relatively complex in workflow definition, usually requiring code or specific text formats to describe process logic. Although this approach provides powerful customization capabilities, it undoubtedly increases the difficulty of learning and using for users with non-technical backgrounds, hindering wider popularization and application.

[0005] Furthermore, some serverless workflow engines do not provide intuitive visual orchestration tools, which means that users must interact directly with the underlying logic. This not only increases the time cost of defining workflows, but also reduces their ease of use and convenience of subsequent maintenance.

[0006] Finally, some existing workflow engines also have deficiencies in state management, lacking effective methods to record and track the execution status of workflows, which makes process control, error diagnosis, and recovery extremely difficult.

[0007] In order to solve the above problems, the present invention proposes an improved serverless workflow engine solution, which aims to improve the real-time response capability of the system, simplify process definition, enhance execution efficiency, and ensure the reliability of process control and error handling by integrating event-driven, visual orchestration, serverless execution, and state management functions, so as to better meet the needs of automating complex business processes. Summary of the invention

[0008] In view of this, the present invention provides a method for implementing a serverless workflow engine based on event orchestration, which combines event-driven mechanism, visual workflow orchestration, serverless function execution and a complete state management mechanism to realize a serverless workflow engine based on event orchestration, overcomes the shortcomings of the prior art, can more effectively meet users' needs for serverless workflow engines, and provides a more convenient, efficient and reliable tool for building automated solutions for complex business processes.

[0009] In order to achieve the above object, the present invention adopts the following technical solution:

[0010] A method for implementing a serverless workflow engine based on event orchestration, comprising:

[0011] Continuously monitor predefined event sources;

[0012] When an event is received, it is matched according to the preset event trigger rules;

[0013] If the event matches successfully, the corresponding predefined workflow is started according to the event triggering rules;

[0014] Map each task in the workflow to a serverless function according to the workflow definition, and trigger the execution of the serverless function based on events;

[0015] Record the execution status of the workflow and update the status, and perform process control and error handling based on the execution status information.

[0016] Preferably, the engine monitors predefined event sources through a message queue library or an event bus service, specifically including three event sources:

[0017] Message queue: publish events to the queue, the engine subscribes to the queue and listens to events;

[0018] Database changes: Use triggers and monitoring mechanisms to trigger events when database data changes;

[0019] API call: Use Webhook or other API methods to trigger events when the API is called.

[0020] Preferably, the event triggering rule includes the following information:

[0021] Event type: matches events of a specific type;

[0022] Event data content: matches specific fields or values ​​in the event data content;

[0023] Event occurrence time: matches the specific time range in which the event occurred;

[0024] Workflow ID: Matches the unique identifier of the workflow associated with the event.

[0025] Preferably, starting a corresponding predefined workflow according to the event triggering rule specifically includes:

[0026] Get the corresponding workflow definition according to the workflow ID in the event trigger rule;

[0027] Create a workflow instance according to the workflow definition and set the initial state of the workflow instance;

[0028] Use the workflow engine library or custom logic to start a workflow instance and begin executing tasks in the workflow.

[0029] Preferably, each task in the workflow is mapped to a serverless function according to the workflow definition, and the serverless function is executed according to the event triggering, specifically including:

[0030] The engine associates each task in the workflow with a serverless function;

[0031] Get the function name related to the current task ID from the storage mechanism;

[0032] Call the corresponding serverless function according to the function name;

[0033] The engine passes the parameters required for the task to the serverless function.

[0034] Preferably, the engine associates each task in the workflow with a serverless function, wherein the association is predefined or dynamically configured at runtime.

[0035] Preferably, the method further includes defining workflow and event triggering rules through a user interface, wherein defining the workflow specifically includes:

[0036] In the workflow arrangement interface, click or drag to add the required task nodes to the workflow canvas. Task nodes represent tasks in the workflow. Each task node includes task name, task type, and execution condition.

[0037] Add a state node to the workflow canvas, where the state node represents each state of the workflow, and each state node includes a state name and a state description;

[0038] The task nodes and state nodes are connected by connecting lines to indicate the execution order and logical relationship of the workflow. The types of connecting lines include sequential execution, parallel execution and conditional branching, and the connection name and connection conditions are set;

[0039] Set the properties of task nodes, status nodes and connecting lines through the property panel;

[0040] After completing the workflow definition on the graphical interface, the engine will parse the graphical workflow definition into executable code or configuration information:

[0041] Parse the task node into task name, task type, and execution condition information, and map it to the corresponding serverless function;

[0042] Parse the state node into state name and state description, and map them to the state management mechanism in the workflow engine;

[0043] Parse the connection lines into connection types and connection conditions, and map them to the process control logic in the workflow engine.

[0044] Preferably, recording the execution status of the workflow and updating the status specifically includes:

[0045] 1) Predefine the various states that each task may have in the workflow, including:

[0046] Initial state: the task has not started yet;

[0047] Executing state: the task is being executed;

[0048] Success status: the task is executed successfully;

[0049] Failed state: task execution failed;

[0050] Waiting state: The task waits for other tasks to complete or meet certain conditions;

[0051] 2) Store the execution status of the workflow. The status information includes: workflow ID, task ID, current status, execution time and error information;

[0052] 3) During the workflow execution, the engine updates the task status according to the task execution results:

[0053] Get status information: According to the workflow ID and task ID, get the current status information of the corresponding task from the storage mechanism;

[0054] Update status information: Update the status according to the current status information of the task.

[0055] Preferably, the process control specifically includes:

[0056] Obtain the definition information of the corresponding workflow from the storage mechanism according to the workflow ID;

[0057] Determine which tasks have been completed, which tasks are being executed, and which tasks need to wait based on the workflow execution status;

[0058] Determine the next task to be performed based on the workflow definition and the execution status of the above tasks;

[0059] Based on the determined next task, the corresponding serverless function is called to execute the task.

[0060] Preferably, error handling specifically includes:

[0061] Determine whether an error occurs based on the execution status;

[0062] If an error occurs, select an appropriate error handling strategy based on the error type and error message.

[0063] It can be seen from the above technical solutions that, compared with the prior art, the present invention discloses a method for implementing a serverless workflow engine based on event orchestration, which has the following effects:

[0064] 1) Improve the flexibility of workflows: By introducing an event-driven mechanism, the execution of workflows is associated with events, so that workflows can trigger different execution processes based on different events, thereby improving the flexibility of workflows and meeting the needs of various complex business scenarios.

[0065] 2) Simplify workflow definition and management: Provide a visual workflow orchestration interface that allows users to define workflows in a graphical way, reducing the learning cost of workflow definition, improving the ease of use and maintainability of workflows, and making it easy for non-technical personnel to use.

[0066] 3) Improve workflow efficiency and scalability: Taking advantage of serverless computing, each task in the workflow is mapped to a serverless function to automate the execution of the workflow, improve workflow efficiency and scalability, and reduce operation and maintenance costs.

[0067] 4) Improve the reliability and controllability of workflows: Provide a workflow status management mechanism to record the execution status of the workflow, and perform process control and error handling based on the status information, thereby improving the reliability and controllability of the workflow and ensuring the normal execution of the workflow. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0069] Figure 1 A flow chart of a method for implementing a serverless workflow engine based on event orchestration provided by the present invention.

[0070] Figure 2 A flow chart of a method for implementing a serverless workflow engine based on event orchestration in another embodiment provided by the present invention. DETAILED DESCRIPTION

[0071] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0072] The embodiment of the present invention discloses a method for implementing a serverless workflow engine based on event orchestration, such as Figure 1 As shown, including:

[0073] Continuously monitor predefined event sources;

[0074] When an event is received, it is matched according to the preset event trigger rules;

[0075] If the event matches successfully, the corresponding predefined workflow is started according to the event triggering rules;

[0076] Map each task in the workflow to a serverless function according to the workflow definition, and trigger the execution of the serverless function based on events;

[0077] Record the execution status of the workflow and update the status, and perform process control and error handling based on the execution status information.

[0078] The core innovation of the present invention is to combine the event-driven mechanism with the serverless workflow engine. By binding the workflow with events, real-time response to events is achieved, the flexibility of the workflow is improved, and business scenarios with high real-time requirements are met.

[0079] In this embodiment, an event-driven mechanism is provided:

[0080] Associate the execution of workflows with events and trigger the execution of workflows based on events. By binding workflows to events, real-time response to events is achieved, the flexibility of workflows is improved, and business scenarios with high real-time requirements are met. By listening to events, matching event triggering rules, starting workflows, executing workflow tasks, and updating workflow status, real-time response to events is achieved, the flexibility of workflows is improved, and business scenarios with high real-time requirements are met.

[0081] The event-driven mechanism is written in Java, and uses Spring Cloud Stream and Apache Kafka message queue libraries to implement event monitoring and processing. It implements high-throughput, distributed, and scalable message queues for event publishing and subscription.

[0082] The specific implementation process is as follows:

[0083] 1) Event monitoring: The engine monitors predefined event sources through the message queue library or event bus service, and selects the appropriate event source according to business needs. There are three types of event sources:

[0084] Message queue: Publish events to the queue, and the engine subscribes to the queue and listens to events.

[0085] Database changes: Use triggers and monitoring mechanisms to trigger events when database data changes.

[0086] API call: Use Webhook or other API methods to trigger events when the API is called.

[0087] The above event data format includes the following information:

[0088] Event Type: Defines the type of event, such as order creation, payment success, inventory change, etc.

[0089] Event data content: defines the data content contained in the event, such as order number, payment amount, product name, etc.

[0090] Event time: Define the specific time when the event occurred.

[0091] 2) Event matching: The engine will use the rule engine or custom logic to match the event triggering rules. Specifically, when using the rule engine, the event triggering rules are defined as rules, and the rule engine is used to match events; when using custom logic code, matching is performed according to the event triggering rules.

[0092] The event triggering rules include the following information:

[0093] Event type: matches events of a specific type. For example, it may include "order submission event", "data update event", etc. When an event is received, the engine compares its type with the predefined event type. If the event type is exactly the same as the event type specified in the rule, the event type is considered to be matched successfully. For example, if the event triggering rule is specified as "order submission event", then the event type matching condition is met only when the received event is indeed the event generated when the user submits an order.

[0094] Event data content: Match specific fields or values ​​in the event data content to determine the key fields contained in the event data. Specific field value matching: For example, for the "order submission event", the key fields are "order amount", "product category", "user ID", etc. In the event triggering rules, specify the specific values ​​or value ranges of these fields for matching. For example, the rules specify "order amount is greater than 300 yuan", "product category is electronic products", "user ID belongs to a specific user group", etc. When the corresponding field value in the event data meets the conditions specified in the rule, the event data content matches successfully. Complex data structure matching: For example, JSON format or object structure, a deeper hierarchical matching is required. For example, for event data containing multiple nested objects, the rule requires that a field in a specific nested object meets specific conditions. Use data parsing and rule matching algorithms to handle complex data structure matching.

[0095] Event occurrence time: matches the specific time range when the event occurs. In the event triggering rule, set the time range when the event occurs. For example, "the event occurs between 9:00 and 18:00 every day" and "the event occurs within a specific date range". When the engine receives an event, it obtains the timestamp of the event and compares it with the time range set in the rule. If the event occurs within the specified time range, the time match is successful. Periodic time matching: set periodic time matching rules, such as events that occur every Monday, "events that occur on the last day of each month", etc. The engine will determine whether the event meets this periodic time matching condition based on the system time and date information.

[0096] Workflow ID: A unique identifier that matches the workflow associated with the event. In the event triggering rule, the workflow ID associated with the event is specified. When the event reaches the engine, the engine extracts the information associated with the workflow in the event and compares it with the workflow specified in the rule. If the two are consistent, the workflow ID is considered to be matched successfully, and the engine will start the corresponding workflow.

[0097] 3) Workflow start: The engine will use the workflow engine library or custom logic to start the workflow. Specifically:

[0098] Get workflow definition: Get the corresponding workflow definition from the repository based on the workflow ID in the event trigger rule.

[0099] Create a workflow instance: Create a workflow instance based on the workflow definition and set the initial state of the workflow instance.

[0100] Start a workflow: Use the workflow engine library or custom logic to start a workflow instance and begin executing tasks in the workflow.

[0101] 4) Workflow execution: The engine uses a serverless function call library or custom logic to execute tasks in the workflow. Specifically:

[0102] Task mapping: In the workflow definition, map each task to the corresponding serverless function.

[0103] Function call: Use the serverless function call library or custom logic to call the corresponding serverless function according to the task mapping relationship.

[0104] Pass event data: Pass event data as parameters to the serverless function so that the function can process based on the event data.

[0105] 5) Status update: The engine uses a database or other storage mechanism to record the execution status of the workflow.

[0106] Status recording: Use a database or other storage mechanism to record the execution status of the workflow instance, such as task execution results, error information, etc.

[0107] State management: Perform process control based on the execution state of the workflow instance, such as:

[0108] Task execution order: Determine the next task to be executed based on the status information.

[0109] Error handling: Determine whether an error occurs based on status information and execute the corresponding error handling logic.

[0110] Workflow end: Determine whether the workflow has been completed based on the status information and end the workflow instance.

[0111] In this embodiment, a visual workflow arrangement is provided:

[0112] Provides a visual interface that allows users to define workflows in a graphical way, including tasks, states, connections, etc., to simplify workflow definition and management. Through the visual interface, the learning cost of workflow definition is reduced, the usability and maintainability of workflows are improved, and non-technical personnel can also use it easily. Visual workflow orchestration realizes intuitive definition and management of workflows through steps such as graphical interface design, workflow definition parsing, and workflow execution, which reduces the learning cost of workflow definition, improves the usability and maintainability of workflows, and makes it easy for non-technical personnel to use it.

[0113] Among them, the graphical canvas interface provides a user-friendly graphical interface, including elements such as task nodes, status nodes, connection lines and property panels, which makes it easy for users to define workflows intuitively.

[0114] Specifically, Figure 2As shown, before event monitoring, the workflow and event triggering rules are defined through the user interface, wherein the workflow definition specifically includes:

[0115] 1) Task nodes: In the workflow arrangement interface, click or drag to add the required task nodes (such as data collection, data processing, data analysis, etc.) to the workflow canvas. Task nodes represent each task in the workflow. Each task node contains attributes such as task name, task type, and execution conditions.

[0116] State node: Add state nodes (such as start, end, wait, execute, etc.) to the workflow canvas. State nodes represent the various states of the workflow. Each state node contains attributes such as state name and state description.

[0117] Connection line: connects the task node and the status node to indicate the execution order and logical relationship of the workflow. The connection line can be of the sequential execution, parallel execution, conditional branch and other types, and contains properties such as connection name and connection condition.

[0118] Property panel: Provides a property panel for setting the properties of task nodes, state nodes, and connection lines. Users can modify task name, task type, execution conditions, state name, state description, connection name, connection conditions, and other information through the property panel.

[0119] 2) Workflow definition parsing: After the user defines the workflow on the graphical interface, the engine will parse the graphical workflow definition into executable code or configuration information.

[0120] The parsing process needs to parse each element in the graphical interface (task node, status node, connection line) and their attribute information into corresponding code or configuration information. For example:

[0121] Task node: Parsed into task name, task type, execution conditions and other information, and mapped to the corresponding serverless function.

[0122] State node: parsed into state name, state description and other information, and mapped to the state management mechanism in the workflow engine.

[0123] Connection line: Parsed into connection type, connection condition and other information, and mapped to the process control logic in the workflow engine.

[0124] After completing the above-mentioned visual workflow orchestration, the engine listens to the event, matches the time trigger rule and starts the workflow, and uses the workflow engine library or custom logic to start each task in the workflow. The engine will execute each task in the workflow according to the parsed workflow definition. Among them, using the workflow engine library: start each task in the workflow according to the parsed workflow definition. Custom logic: according to the specifications provided by the canvas component library, make custom logic definitions, and start each task in the workflow according to the parsed workflow definition. The workflow engine library provides basic elements such as task nodes, state nodes, and connecting lines, but in actual applications, different business scenarios require specific processing logic, which cannot be fully satisfied by existing standardized elements. For example, data processing in the meteorological field requires interaction with relevant industry algorithms, and these situations require custom logic.

[0125] Custom component library: When users define custom logic, they need to follow the specifications provided by the canvas component library. For example, the custom logic code must correctly read and process the attribute information of task nodes, state nodes, and connection lines.

[0126] Workflow definition: Custom logic executes each task in the workflow according to the parsed workflow definition. For example, the task node performs data collection, and the user extends this data collection task through custom logic and performs custom processing on the task.

[0127] Input and output: Input is the parameters, event data or other external data sources from the task node. The output meets the requirements of the subsequent task node or state node in the workflow. For example, the input of the data processing logic is the data collection result in a specific format, and the output should be a data format that meets the requirements of the next task node after processing.

[0128] Error handling: Custom logic has clear error handling information. If an error occurs during the execution of custom logic, the error message will be displayed and the corresponding processing will be carried out according to the workflow status management mechanism.

[0129] Execution process: The engine will execute each task in sequence according to the task order and logical relationship in the workflow definition. The execution of each task will trigger the corresponding serverless function and update the workflow status according to the execution result of the function.

[0130] In this embodiment, a serverless function execution process is provided:

[0131] Map each task in the workflow to a serverless function, trigger the function execution based on events, and realize the automated execution of the workflow. Take advantage of serverless computing to realize the automated execution of workflows, improve efficiency and scalability, and reduce operation and maintenance costs. Through the steps of task mapping, function calling, parameter passing, and result processing, the automated execution of workflows is realized, which improves efficiency and scalability and reduces operation and maintenance costs.

[0132] The specific algorithm implementation details are as follows:

[0133] 1) Task mapping: The engine uses a database or other storage mechanism to store the mapping relationship between tasks and serverless functions. The engine associates each task in the workflow with a serverless function. This association is predefined and can also be dynamically configured at runtime.

[0134] Task ID: Each task has a unique identifier called a task ID.

[0135] Function name: Every serverless function has a unique name.

[0136] Storing mapping relationships: The engine uses a database or other storage mechanism to store the mapping relationship between task IDs and function names.

[0137] Dynamic configuration: The engine allows users to dynamically configure the mapping relationship between tasks and functions at runtime, such as through a visual interface or API interface.

[0138] 2) Function call: The engine uses the serverless function call library or custom logic to call the serverless function. That is, when the engine needs to execute a task, it will find the corresponding serverless function according to the task mapping relationship and call the function. Specifically:

[0139] Get the function name: Get the function name associated with the current task ID from the storage mechanism. Use the serverless function call library: Call the corresponding serverless function according to the function name. Custom logic: If you use custom logic, call the corresponding serverless function according to the function name. Asynchronous call: In order to improve the execution efficiency of the workflow, the engine usually uses asynchronous method to call the serverless function.

[0140] 3) Parameter passing: The engine will pass the parameters required for task execution to the serverless function. These parameters include task input data, workflow status information, etc.

[0141] Parameter type: supports multiple parameter types, such as string, number, Boolean, array, object, etc.

[0142] Parameter format: Use JSON format to pass parameters to serverless functions.

[0143] Parameter content: Task input data: such as order information, user information, etc.

[0144] Workflow status information: such as the execution status of the current workflow, the list of executed tasks, etc.

[0145] 4) Result processing: The engine receives the execution results of the serverless function and updates the workflow status based on the results to perform the next step of process control.

[0146] Result format: Use JSON data format to receive the execution results of the serverless function and update the workflow status based on the results.

[0147] The results include:

[0148] Success flag: Indicates whether the function is executed successfully.

[0149] Error message: If the function fails, it contains the error message.

[0150] Output data: the result data of function execution.

[0151] Status update: Update the workflow status according to the function execution result, such as:

[0152] Success: If the function is executed successfully, the workflow status is updated to "Completed".

[0153] Failure: If the function fails to execute, the workflow status is updated to "failure" and the error information is recorded.

[0154] Continue execution: If the function is executed successfully but the workflow has not yet completed, continue to execute the next task according to the workflow definition.

[0155] In this embodiment, a state management mechanism is provided:

[0156] Provides workflow status management mechanism, records the execution status of workflow, and performs process control and error handling based on the status information. By recording the execution status of workflow, process control and error handling are implemented, improving the reliability and controllability of workflow.

[0157] Through the steps of state definition, state storage, state update, process control and error handling, the workflow execution state is recorded and managed, which improves the reliability and controllability of the workflow. The specific implementation is as follows:

[0158] 1) State definition: define the various states that each task may have in the workflow, such as:

[0159] Initial state: The task has not started yet.

[0160] Executing state: The task is being executed.

[0161] Success status: The task is executed successfully.

[0162] Failed status: The task execution failed.

[0163] Waiting state: The task waits for other tasks to complete or for a certain condition to be met.

[0164] 2) State storage: Use a database or other storage mechanism to store the execution status of the workflow. The state information includes:

[0165] Workflow ID: A unique ID that identifies the workflow.

[0166] Task ID: A unique ID that identifies each task.

[0167] Current status: records the current status of each task, such as initial status, executing status, successful status, failed status, waiting status, etc.

[0168] Execution time: Record the execution time of each task, such as start time, end time, etc.

[0169] Error message: record the error message when the task fails to execute.

[0170] 3) Status update: When the workflow is executed, the engine will update the status of the task according to the execution result of the task. Specifically:

[0171] Get status information: According to the workflow ID and task ID, get the current status information of the corresponding task from the storage mechanism.

[0172] Update status information: Update the current status information of the task according to the execution result of the task, such as:

[0173] Success: If the task is successfully executed, the task status is updated to "Success Status".

[0174] Failure: If the task execution fails, the task status is updated to "failed status" and the error information is recorded.

[0175] Waiting: If a task needs to wait for other tasks to complete or meet certain conditions, the task status is updated to "Waiting Status".

[0176] Update method: Use cache, database operation library and custom logic to update state information.

[0177] 4) Process control: The engine will decide which task to execute next based on the workflow definition and current status information.

[0178] Get workflow definition: Get the definition information of the corresponding workflow from the storage mechanism based on the workflow ID.

[0179] Analyze status information: Based on the current status information, determine which tasks have been completed, which tasks are being executed, and which tasks need to wait.

[0180] Determine the next task: Determine the next task to be performed based on the workflow definition and current status information.

[0181] Execute the next task: Based on the determined next task, call the corresponding serverless function to execute the task.

[0182] Process control method: Provides workflow engine library and custom logic to implement process control.

[0183] 5) Error handling: The engine will perform corresponding error handling based on the task execution status and error information. Specifically:

[0184] Error detection: Determine whether an error occurs based on the execution status of the task.

[0185] Error handling strategy: Select an appropriate error handling strategy based on the error type and error message, such as:

[0186] Retry execution: Try to re-execute the failed task.

[0187] Notify user: Notify the user of error information.

[0188] Stop Workflow: If the error cannot be resolved, stop the entire workflow.

[0189] Error handling method: Use custom logic to implement error handling.

[0190] The present invention creatively combines event-driven mechanism, visual workflow arrangement, serverless function execution and perfect state management mechanism to realize a serverless workflow engine based on event arrangement. The serverless workflow engine of the present invention helps enterprises realize various business processes, improve efficiency, reduce costs, increase flexibility and improve reliability.

[0191] Embodiment 1: Applying the present invention to order processing:

[0192] Users define an order processing workflow through a visual interface, including the following tasks:

[0193] Receive order information: Define "Receive order information" as the start task of the workflow in the canvas. Drag and drop a module for receiving order information to the workflow editing area. Set input parameters for this task, including: basic information fields of the order, order number, product details, customer information, etc. Configure the connection between this task and the subsequent task "Check inventory" to indicate that inventory check will be triggered after receiving order information.

[0194] Check Inventory: Drag and drop the "Check Inventory" task module in the canvas and connect it to the "Receive Order Information" task. Through the serverless function, the function logic is to query the inventory system to obtain the inventory quantity based on the received order item details. Set the function's input parameter to the item details data passed from the "Receive Order Information" task. Define the output of the task, such as the flag for whether the inventory is sufficient and the specific inventory quantity.

[0195] Generate order: Add the "Generate order" task module to the canvas and connect it to the "Check inventory" task. The corresponding serverless function is responsible for creating a new order record in the order system based on the received order information. The function input is the complete order information after being processed by the previous task. The output is a sign of success or failure of order generation.

[0196] Notify users: Drag and drop the "Notify users" task module into the workflow and connect it to other tasks. The serverless function is responsible for notifying users of the order status through SMS, email, or in-app push based on the order status and user contact information. The input includes order status information and user contact information. The output is a record of whether the notification was sent successfully or failed.

[0197] Process payment: Add the "Process payment" task module in the visual interface and connect it to the previous task. The serverless function integrates with the payment system to process payment based on the order amount and user payment method. The input is information such as order amount and payment method. The output is the result of payment success or failure.

[0198] Shipping: Add the "Shipping" task module to the workflow and connect it with other tasks. The serverless function is responsible for triggering the shipping process, such as notifying the warehouse to perform the shipping operation and updating the order status to shipped. The input is the order information and shipping address, etc. The output is the status of successful or failed shipping.

[0199] Set event trigger rules: When new order information is received, the order processing workflow is triggered. Integrate with the order receiving channel. When new order information is received, the system will capture this event. The event-driven mechanism recognizes that this is an event that needs to start the order processing workflow based on the trigger rules set by the user.

[0200] The workflow engine starts the order processing workflow according to the event triggering rules and executes each task. After the event is triggered, the workflow engine starts the order processing workflow. First, the "Receive Order Information" task is executed to obtain the details of the order. Then, according to the connection relationship of the workflow, the order information is passed to the "Check Inventory" task. The serverless function of the "Check Inventory" task is triggered to query the inventory system and return the result of whether the inventory is sufficient. If the inventory is sufficient, the workflow continues to execute the "Generate Order" task and create an order record. Then the "Notify User", "Process Payment" and "Shipment" tasks are executed in sequence, and the serverless function of each task will perform corresponding operations based on the input parameters.

[0201] The workflow engine records the execution status of each task and performs process control and error handling based on the status information. For example, if the inventory is insufficient, the engine will notify the user and stop the workflow. During the execution of each task, the workflow engine will record the execution status of the task, such as "completed", "failed", and "waiting". For the "check inventory" task, if the inventory is insufficient, the engine will mark the status of the task as "failed", notify the user according to the process control rules, and stop the workflow. For other tasks, if the execution is successful, it will be marked as "completed"; if an error occurs, such as payment failure, delivery failure, etc., the task status will also be marked as "failed" accordingly. When an error occurs, the workflow engine adopts different processing strategies according to the error type. For example, if the payment fails due to a temporary network problem, the engine sets a retry mechanism to retry the payment after a certain time interval. If the inventory is insufficient, the engine sends a notification to the user to inform the inventory status and provides some options, such as waiting for the inventory to be replenished before processing the order or canceling the order. The workflow engine monitors and optimizes the process based on the status information. For example, by analyzing indicators such as the time and success rate of task execution, bottlenecks or problems in the process can be found for optimization and improvement.

[0202] Embodiment 2: Applying the present invention to the marketing activity process:

[0203] Users define a marketing campaign workflow through a visual interface, including the following tasks:

[0204] Create a marketing campaign: In the visual interface, define "Create a marketing campaign" as the start task of the workflow. Set input parameters for this task, such as the campaign name, campaign time range, target audience, and other information. Configure the connection between this task and the subsequent task "Send Coupons", indicating that coupons may be sent after the campaign is created.

[0205] Send coupons: Add the "Send coupons" task module in the visual interface and connect it to the "Create marketing campaign" task. The corresponding serverless function is responsible for sending coupons to users based on the campaign rules and target audience. The function input can be information such as the target user list and coupon type. Define the output of the task, such as the number of users to whom the coupons were successfully sent.

[0206] Push ads: Drag and drop the "Push ads" task module into the workflow and connect it to the previous task. The serverless function is responsible for pushing ad content to specific channels according to the requirements of the marketing campaign. The input includes information such as ad content and push channels. The output is the status feedback of ad push.

[0207] Analyze activity results: Add the "Analyze activity results" task module to the workflow and connect it with other tasks. The serverless function is responsible for collecting and analyzing activity-related data, such as coupon collection rate, ad click-through rate, sales conversion, etc. The input is various data sources generated during the activity. The output is an activity effect analysis report.

[0208] Set event trigger rules: When a user successfully registers or purchases a product, the marketing activity workflow is triggered. The workflow is integrated with the user registration system and the product purchase system. When an event of a user successfully registering or purchasing a product occurs, the system will capture this event. The event-driven mechanism will identify the events that need to start the marketing activity workflow based on the trigger rules set by the user.

[0209] The workflow engine starts the marketing activity workflow according to the event triggering rules and executes each task. The "Create Marketing Activity" task is executed to create a marketing activity record according to the parameters pre-set by the user. Then, based on the connection relationship of the workflow, it is determined whether the "Send Coupon" task needs to be executed. If the system detects that the user has already received the coupon, the task is skipped. If the "Send Coupon" task is not skipped, the serverless function of the task is triggered to send coupons to eligible users. Then the "Push Advertisement" task is executed, and the serverless function pushes advertisements to specific channels according to the activity requirements. Finally, the "Analyze Activity Results" task is executed, and the serverless function collects and analyzes activity data and generates an activity results analysis report.

[0210] The workflow engine records the execution status of each task and performs process control and error handling based on the status information. For example, if the user has already received the coupon, the engine will skip the task of sending the coupon. During the execution of each task, the workflow engine records the execution status of the task. For example, for the "Send Coupon" task, if the coupon is sent successfully, it is marked as "Completed"; if the sending fails, it is marked as "Failed" and the reason for the failure is recorded. For the "Analyze Activity Effect" task, if data collection and analysis are carried out smoothly, it is marked as "Completed"; if there are problems such as missing data or analysis errors, it is marked as "Failed". When an error occurs, the workflow engine adopts different processing strategies according to the error type. For example, if the failure to send the coupon is due to a network problem, the engine sets a retry mechanism and tries to send it again after a certain time interval. If there is missing data in the task of analyzing activity effects, the engine tries to obtain data from other data sources or notifies the administrator to enter the data manually. The workflow engine monitors and optimizes the process based on the status information. For example, by analyzing indicators such as the time and success rate of task execution, bottlenecks or problems in the process can be found for optimization and improvement. If you find that a task takes too long to execute, consider optimizing the serverless function for that task or adjusting the execution order of the tasks.

[0211] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0212] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for implementing a serverless workflow engine based on event orchestration, characterized in that: include: Continuously monitor predefined event sources; When an event is received, it is matched according to the preset event trigger rules; If the event matches successfully, the corresponding predefined workflow is started according to the event triggering rules; Map each task in the workflow to a serverless function according to the workflow definition, and trigger the execution of the serverless function based on events; Record the execution status of the workflow and update the status, and perform process control and error handling based on the execution status information.

2. According to the method for implementing a serverless workflow engine based on event orchestration according to claim 1, it is characterized in that: The engine listens to predefined event sources through the message queue library or event bus service, including three types of event sources: Message queue: publish events to the queue, the engine subscribes to the queue and listens to events; Database changes: Use triggers and monitoring mechanisms to trigger events when database data changes; API call: Use Webhook or other API methods to trigger events when the API is called.

3. The method for implementing a serverless workflow engine based on event orchestration according to claim 1, characterized in that: Event triggering rules, including the following information: Event type: matches events of a specific type; Event data content: matches specific fields or values ​​in the event data content; Event occurrence time: matches the specific time range in which the event occurred; Workflow ID: Matches the unique identifier of the workflow associated with the event.

4. The method for implementing a serverless workflow engine based on event orchestration according to claim 3, characterized in that: The corresponding predefined workflow is started according to the event triggering rules, including: Get the corresponding workflow definition according to the workflow ID in the event trigger rule; Create a workflow instance according to the workflow definition and set the initial state of the workflow instance; Use the workflow engine library or custom logic to start a workflow instance and begin executing tasks in the workflow.

5. The method for implementing a serverless workflow engine based on event orchestration according to claim 1, characterized in that: Map each task in the workflow to a serverless function according to the workflow definition, and trigger the execution of the serverless function based on events, including: The engine associates each task in the workflow with a serverless function; Get the function name related to the current task ID from the storage mechanism; Call the corresponding serverless function according to the function name; The engine passes the parameters required for the task to the serverless function.

6. The method for implementing a serverless workflow engine based on event orchestration according to claim 5, characterized in that: The engine associates each task in the workflow with a serverless function, where the association is pre-defined or dynamically configured at runtime.

7. The method for implementing a serverless workflow engine based on event orchestration according to claim 1, characterized in that: It also includes defining workflows and event triggering rules through the user interface, where defining workflows specifically includes: In the workflow arrangement interface, click or drag to add the required task nodes to the workflow canvas. Task nodes represent tasks in the workflow. Each task node includes task name, task type, and execution condition. Add a state node to the workflow canvas, where the state node represents each state of the workflow, and each state node includes a state name and a state description; The task nodes and state nodes are connected by connecting lines to indicate the execution order and logical relationship of the workflow. The types of connecting lines include sequential execution, parallel execution and conditional branching, and the connection name and connection conditions are set; Set the properties of task nodes, status nodes and connecting lines through the property panel; After completing the workflow definition on the graphical interface, the engine will parse the graphical workflow definition into executable code or configuration information: Parse the task node into task name, task type, and execution condition information, and map it to the corresponding serverless function; Parse the state node into state name and state description, and map them to the state management mechanism in the workflow engine; Parse the connection lines into connection types and connection conditions, and map them to the process control logic in the workflow engine.

8. The method for implementing a serverless workflow engine based on event orchestration according to claim 1, characterized in that: Record the execution status of the workflow and update the status, including: 1) Predefine the various states that each task may have in the workflow, including: Initial state: the task has not yet started execution; Executing state: the task is being executed; Success status: the task is executed successfully; Failed state: task execution failed; Waiting state: The task waits for other tasks to complete or meet certain conditions; 2) Store the execution status of the workflow. The status information includes: workflow ID, task ID, current status, execution time and error information; 3) During the workflow execution, the engine updates the task status according to the task execution results: Get status information: According to the workflow ID and task ID, get the current status information of the corresponding task from the storage mechanism; Update status information: Update the status according to the current status information of the task.

9. The method for implementing a serverless workflow engine based on event orchestration according to claim 1, characterized in that: Process control specifically includes: Obtain the definition information of the corresponding workflow from the storage mechanism according to the workflow ID; Determine which tasks have been completed, which tasks are being executed, and which tasks need to wait based on the workflow execution status; Determine the next task to be performed based on the workflow definition and the execution status of the above tasks; Based on the determined next task, the corresponding serverless function is called to execute the task.

10. The method for implementing a serverless workflow engine based on event orchestration according to claim 1, characterized in that: Error handling specifically includes: Determine whether an error occurs based on the execution status; If an error occurs, select an appropriate error handling strategy based on the error type and error message.

Images