Metadata-based action chain dynamic arrangement and verification method

Abstract

The invention provides an action chain dynamic arrangement and verification method based on metadata, and relates to the technical field of computer software, and the method comprises the steps: constructing an action metadata model which comprises an action identifier, a name, a type, an input parameter, a front dependency relationship and a rear dependency relationship; analyzing the action metadata model based on an action chain arrangement engine to identify and obtain business logic, dynamically constructing an action chain according to the business logic, configuring variable parameters of the action chain through an expression, and performing condition verification of the action chain by adopting a preposed verification mechanism; and the action chain executes corresponding business logic on the input parameters according to the sequence, and outputs an obtained output result to the next action.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computer software, and particularly relates to a metadata-based action chain dynamic arrangement and verification method. BACKGROUND

[0002] With the development of information technology, the complexity of software systems is increasing, especially in large systems such as enterprise resource planning (ERP). Traditional software design patterns have many shortcomings in handling complex business processes and action management, such as code redundancy, high maintenance cost, poor stability, and complex parameter management. Traditional architecture usually relies on hard coding to implement business logic, which means that any changes to business processes require modifications and recompilation of the source code, which not only increases the development workload, but also may cause new errors, reducing the stability and maintainability of the system.

[0003] In addition, in dynamic business scenarios, such as rapid changes in promotional rules, supply chain optimization, and other requirements, traditional software architecture is difficult to quickly respond to these changes, resulting in delayed business response and affecting user experience. At the same time, the collaboration efficiency between different teams is low, because the lack of unified design tools and data transfer mechanisms between modules often relies on manual coordination, further increasing communication costs and integration difficulty. SUMMARY

[0004] The application provides a metadata-based action chain dynamic arrangement and verification method to solve one of the above technical problems.

[0005] The technical solution adopted by the application is:

[0006] The application embodiment provides a metadata-based action chain dynamic arrangement and verification method, which includes:

[0007] An action metadata model is constructed, including action identification, name, type, input parameter, pre-depending relationship, and post-depending relationship;

[0008] An action chain arrangement engine is used to parse the action metadata model to identify the business logic, dynamically construct the action chain according to the business logic, configure the variable parameters of the action chain through expressions, and use a pre-checking mechanism to perform conditional verification of the action chain;

[0009] The action chain executes the corresponding business logic on the input parameters in sequence, and outputs the obtained output results to the next action.

[0010] According to one embodiment of this application, in the step of constructing the action metadata model, the action identifier is a unique string identifier, the action name is used for interface display, and the action type includes one or more combinations of data reading, data processing, data storage, API call, and interface interaction;

[0011] The input parameters can be dynamically obtained through expressions, including but not limited to variable references, arithmetic operations, logical judgments, and function calls.

[0012] The preceding and following dependencies are defined through metadata fields. The preceding dependency represents other actions that must be completed before the current action is executed, and the following dependency represents subsequent actions that need to be triggered after the current action is executed.

[0013] According to one embodiment of this application, the process of the action chain orchestration engine parsing the action metadata model includes:

[0014] Load the corresponding metadata model from the database or configuration file according to the business trigger command;

[0015] The pre- and post-dependencies between actions are analyzed using graph theory algorithms to generate an action execution order table.

[0016] It supports configuring variable parameters through template languages ​​or scripting languages. These variable parameters include static values, context variables, or external data source references.

[0017] Before executing an action, the input parameters are checked for validity according to predefined validation rules. If the validation fails, the current action chain is terminated and an error log is recorded.

[0018] According to one embodiment of this application, the action chain sequentially executes the corresponding business logic steps on the input parameters:

[0019] The output of each action is automatically written to the global context object, and subsequent actions read the required data from the context by variable name;

[0020] If an exception occurs during the execution of the action, a response is made according to a preset exception handling strategy, which is configured through metadata fields.

[0021] The execution path is dynamically selected by the entry condition, which determines whether to execute the action chain of the corresponding branch based on the expression calculation result.

[0022] After each action is completed, it reports its status to the orchestration engine. This status is used to drive the execution decision of subsequent actions or trigger exception handling procedures.

[0023] According to one embodiment of this application, in the step of outputting the output result of the action chain to the next action:

[0024] The output results are transmitted using a unified data structure, which includes status codes, output data, and metadata descriptions.

[0025] Cache frequently accessed output results to reduce the overhead of redundant calculations or external calls;

[0026] It allows the output of one action chain to be used as the input parameter of another action chain, enabling cross-chain data transfer through metadata fields;

[0027] The execution progress, output results, and exception information of the action chain are displayed in real time through a graphical interface. The monitoring data is generated by the orchestration engine's log system.

[0028] According to one embodiment of this application, in the step of constructing the action metadata model, the input parameters support the following configuration methods:

[0029] Define fixed values ​​directly in the metadata;

[0030] Reference data in the global context by variable name;

[0031] Values ​​are dynamically obtained through a predefined data interface, the configuration information of which is contained in the data_source field of the metadata;

[0032] Input parameters are preprocessed using logical operators or function calls.

[0033] According to one embodiment of this application, after the action chain orchestration engine parses the action metadata model, the generated action chain supports the following execution modes:

[0034] Actions are executed sequentially according to their dependencies, with the output of the previous action serving as the input for the next action;

[0035] Actions without dependencies can be executed in parallel, with concurrency managed through thread pools or asynchronous task schedulers;

[0036] Define loop conditions through metadata fields to repeatedly execute specific actions until the conditions are met;

[0037] The execution path can be dynamically selected based on the entry conditions, supporting multi-branch logic.

[0038] According to one embodiment of this application, the pre-verification mechanism of the action chain includes:

[0039] Check whether the input parameters conform to the predefined data type and format;

[0040] The input validity is verified using preset validation rules;

[0041] Ensure that all required parameters provide valid values; trigger an error message and terminate the action chain if any parameter is missing.

[0042] Perform permission verification for sensitive operations, determining whether execution is permitted based on role or user identity.

[0043] A second aspect of this application provides a computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the steps described in the method.

[0044] A third aspect of this application provides an electronic device including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method as described.

[0045] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows:

[0046] This application achieves a complete separation of business logic and code implementation by abstracting business processes into configurable metadata. This allows business personnel to directly adjust metadata configurations without relying on developers, significantly improving response speed and supporting the ability to respond to market demands within minutes. Metadata supports dynamic loading at runtime without requiring service restarts, enabling the system to quickly adapt to market changes and support rapid business iteration. Each action is treated as an independent module, reducing the risk of code modification and supporting on-demand expansion of new features. Simultaneously, standardized descriptions of various elements in the action chain enhance the system's readability and maintainability. Defining complex process logic such as branches, parallelism, and loops through metadata eliminates the need to predefine all process paths, adapting to dynamic business rules and improving the system's adaptability and flexibility. Metadata defines exception handling strategies, improving the system's fault tolerance and reducing the need for manual intervention, thereby enhancing system stability and reliability. By employing the above techniques, the development process is simplified, reducing the additional workload caused by frequent changes, and thus lowering overall development and maintenance costs. Attached Figure Description

[0047] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0048] Figure 1 A flowchart illustrating a method for dynamic orchestration and verification of action chains based on metadata, provided in an embodiment of this application;

[0049] Figure 2This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0050] Figure label:

[0051] 810, Processor; 820, Communication interface; 830, Memory; 840, Communication bus. Detailed Implementation

[0052] To more clearly illustrate the overall concept of this application, a detailed explanation is provided below with reference to the accompanying drawings.

[0053] Many specific details are set forth in the following description to provide a thorough understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below. It should be noted that, unless otherwise specified, the embodiments of this application and the features thereof can be combined with each other.

[0054] In this application, unless otherwise expressly specified and limited, the "above" or "below" of the second feature can mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples.

[0055] Example 1

[0056] like Figure 1 As shown, a method for dynamic orchestration and validation of action chains based on metadata includes:

[0057] Construct an action metadata model, including action identifier, name, type, input parameters, pre-dependencies, and post-dependencies.

[0058] As mentioned above, constructing an action metadata model is a fundamental step in the entire action chain design pattern based on a metadata system. This step involves defining a series of key elements that collectively describe each action in the action chain. Specifically:

[0059] Action Identifier (key): This is a unique string identifier used to distinguish different actions, ensuring that every action in the system can be accurately identified and referenced.

[0060] Label: Provide a user-friendly interface with a label that is easy to understand and use. For example, "User Login Verification" displayed on the user interface.

[0061] Action type: Specifies the specific type of action, such as data reading, data processing, API call, etc. This helps the orchestration engine understand how to perform the action.

[0062] Input parameters (options): Define all the input information required for the action to be executed, including static values, context variables, or references to external data sources. These parameters can be single values ​​or complex object structures.

[0063] Pre-dependencies: Specifies a list of actions that must be completed before the current action can be executed. This dependency ensures that actions are executed in the correct order, guaranteeing the consistency of business logic.

[0064] Post-dependency: In contrast to pre-dependency, it defines the subsequent actions that need to be triggered after the current action is completed, helping to automate the process.

[0065] For example, suppose you are designing an order processing flow on an e-commerce platform, which includes a "check inventory" action. Its metadata model can be defined as follows:

[0066] Action identifier: "checkInventory"

[0067] Name: "Check Inventory"

[0068] Type: "Data Query"

[0069] Input parameter: Product ID (extracted from the product information obtained in the previous step)

[0070] Prerequisite dependency: "fetchProductDetails" (fetch product details first)

[0071] Post-dependency: "processOrder" (process the order if there is sufficient stock)

[0072] In this example, the "Check Inventory" action depends on the result of the "Get Product Details" action, and triggers the "Process Order" action upon its successful completion. This ensures the correctness and efficiency of the order processing flow.

[0073] It should be noted that, in specific implementation scenarios, the above solution can be used to adjust the input parameters at runtime according to actual needs. For example, certain parameter values ​​can be dynamically calculated through expressions, or the latest data can be obtained from external systems in real time.

[0074] In specific implementation scenarios, based on the above solutions, internationalization support can be provided for the name field, so that users in different regions can see the action name displayed in their native language, thereby improving the user experience.

[0075] In specific implementation scenarios, based on the above solutions, permission fields can be added to the metadata to restrict which users or roles can trigger specific actions, thereby enhancing security.

[0076] In specific implementation scenarios, version control can be applied to the metadata of each action based on the above solution, allowing rollback to earlier versions or parallel testing of action chains between new and old versions. This is particularly important for continuous integration and deployment.

[0077] In specific implementation scenarios, based on the above solutions, for frequently used actions, caching strategies or other optimization measures can be specified in the metadata to reduce the number of repeated calculations or external calls and improve overall performance.

[0078] In specific implementation scenarios, in addition to the basic success or failure status, detailed exception handling rules can be defined based on the above solutions, such as the number of retries and timeout periods, to deal with unforeseen situations.

[0079] The action chain orchestration engine parses the action metadata model to identify business logic, dynamically constructs action chains based on the business logic, configures the variable parameters of the action chain through expressions, and uses a pre-validation mechanism to perform condition validation of the action chain.

[0080] As mentioned above, parsing the action metadata model: The action chain orchestration engine first needs to read and parse the defined metadata model to understand the identifier, name, type, input parameters and dependencies of each action.

[0081] Identify business logic: Based on the parsed metadata, the orchestration engine can identify specific business processes and logical sequences, such as which actions need to be executed first and which actions can be executed in parallel.

[0082] Dynamically constructing action chains: Based on the identified business logic, the orchestration engine automatically constructs one or more executable action chains. These action chains can be dynamically adjusted according to actual business needs to adapt to the ever-changing business environment.

[0083] Configure variable parameters via expressions: When building action chains, expressions can be used to dynamically configure variable parameters, allowing the action chains to be flexibly adjusted based on runtime data.

[0084] Pre-validation mechanism: In order to ensure the correctness and effectiveness of the action chain, the orchestration engine will perform pre-validation on the input parameters before executing any action to check whether they meet the preset conditions, such as non-empty validation, format validation, etc.

[0085] For example, suppose we want to design a user registration process for an e-commerce website, which includes the following actions: "verification code verification", "email verification", and "password setting".

[0086] Parse the action metadata model: The orchestration engine reads the relevant metadata of these three actions from the configuration file, including their names, types (all of which are data validation), input parameters (such as verification code, email address, password), and prerequisite dependencies ("verification code validation" must be completed before "email validation").

[0087] Identifying business logic: The orchestration engine determined the correct execution order to be "verification code verification -> email verification -> password setting", while also noting that subsequent operations can only continue after "verification code verification" is successful.

[0088] Dynamically build action chain: Based on the above logic, the orchestration engine builds an action chain consisting of these three actions and sets the corresponding dependencies.

[0089] Configure variable parameters via expressions: For the "verification code verification" action, its input parameter may be an expression used to obtain the current user's verification code input value from the context.

[0090] Pre-validation mechanism: Before executing each action, the orchestration engine checks the validity of the input parameters, such as ensuring that the verification code is not empty and meets the format requirements.

[0091] It should be noted that, in specific implementation scenarios, in addition to simple serial or parallel execution modes, the above solutions can also support more complex logical structures, such as loops and conditional branches. For example, when a user enters the wrong verification code three times consecutively, the system can automatically send a new verification code to the user.

[0092] In specific implementation scenarios, based on the above solutions, performance monitoring tools can be integrated during the execution of the action chain to track the execution time, resource consumption, and other indicators of each action in real time, and optimize the design of the action chain accordingly, such as adjusting the concurrency or priority.

[0093] In specific implementation scenarios, based on the above solutions, the design can take into account the differences between different platforms (such as mobile applications and web terminals) to ensure that the same action chain can run seamlessly on multiple platforms without the need for repeated development.

[0094] In specific implementation scenarios, more security verification mechanisms, such as identity authentication and access control, can be introduced on the basis of the above solutions to ensure that only authorized users can trigger specific action chains and protect the security of sensitive data.

[0095] In specific implementation scenarios, based on the above solutions, support for multiple languages ​​can be provided, allowing prompts and error messages in the action chain to automatically switch according to the user's language preferences, thereby improving the user experience.

[0096] In specific implementation scenarios, version management of the action chain can be implemented based on the above solution, supporting a quick rollback to a stable version when problems are found in a new version, reducing the risks caused by updates.

[0097] The action chain executes the corresponding business logic on the input parameters in sequence and outputs the result to the next action.

[0098] As mentioned above, the core execution step of the action chain design pattern based on metadata is to execute the corresponding business logic on the input parameters in sequence and output the result to the next action. This ensures that each action can be executed correctly in the predetermined order and according to the dependencies, and that its output can be seamlessly passed to subsequent actions, thus forming a coherent business process.

[0099] Sequential execution: According to a predefined action chain structure, each action is executed sequentially. After the current action is completed and produces an output, the output will be used as the input for the next action.

[0100] Business logic execution: Each action is responsible for executing specific business logic, such as data validation, calculation, or API calls. This logic is determined based on the configuration in the metadata model.

[0101] Output delivery: After the current action is completed, its output is recorded and passed to the next action. This is usually achieved through a global context object, allowing data to flow throughout the entire action chain.

[0102] For example, suppose you are designing a user registration system that includes the following three actions: "email verification", "password setting", and "welcome message sending".

[0103] Email verification:

[0104] Input parameter: The email address provided by the user.

[0105] Execution logic: Check if the email address format is correct and confirm that the email address has not been used by other accounts.

[0106] Output: A successful verification flag and the user ID (if verification is successful).

[0107] Password setting:

[0108] Input parameters: The user ID generated in the previous step and the new password set by the user.

[0109] Execution logic: Store the new password and associate it with the user ID, while performing security checks (such as password complexity requirements).

[0110] Output: A message indicating successful password setting and a user information digest.

[0111] Welcome message sent:

[0112] Input parameter: The user information summary generated in the previous step.

[0113] Execution logic: Send a personalized welcome email based on user information.

[0114] Output: Send a status report (success or failure).

[0115] In this example, each action depends on the output of the previous action and passes its own output to the next action, forming a complete user registration process.

[0116] It should be noted that, in specific implementation scenarios, based on the above solutions, for time-consuming actions (such as big data analysis), an asynchronous processing method can be adopted, allowing the action chain to continue executing other tasks while waiting for some operations to complete, thereby improving overall efficiency.

[0117] In specific implementation scenarios, a caching mechanism can be introduced on the basis of the above solutions. For frequently used data or repeatedly executed operations, caching can reduce unnecessary calculations or external calls and improve performance.

[0118] In specific implementation scenarios, based on the above solutions, when an action fails to be executed successfully due to a temporary failure, an automatic retry function or error recovery path can be provided to ensure the continuity and stability of the action chain.

[0119] In specific implementation scenarios, based on the above solution, it is also possible to support data sharing between different action chains, allowing the output of one action chain to be used as the input of another action chain, thereby promoting collaboration between modules.

[0120] In specific implementation scenarios, a real-time feedback mechanism can be added to each action based on the above solution to provide users with immediate status updates (such as progress bar display) and to track the execution of the entire action chain through monitoring tools, so as to facilitate timely detection of problems.

[0121] In specific implementation scenarios, based on the above solutions, in a multi-tenant environment, data isolation for each tenant can be ensured, and the action chain execution environment of different tenants can be distinguished by tenant identifiers, thereby ensuring data security and privacy protection.

[0122] According to one embodiment of this application, in the step of constructing the action metadata model, the action identifier is a unique string identifier, the action name is used for interface display, and the action type includes one or more combinations of data reading, data processing, data storage, API call, and interface interaction;

[0123] The input parameters can be dynamically obtained through expressions, including but not limited to variable references, arithmetic operations, logical judgments, and function calls.

[0124] The preceding and following dependencies are defined through metadata fields. The preceding dependency represents other actions that must be completed before the current action is executed, and the following dependency represents subsequent actions that need to be triggered after the current action is executed.

[0125] As mentioned above, an action identifier is a unique string identifier used to clearly distinguish different actions throughout the system. Each action must have a unique identifier to be accurately referenced and executed within the action chain. For example, in a user login verification process, "loginValidation" can serve as an action identifier.

[0126] Action names are primarily used for interface display, providing a user-friendly and easy-to-understand name for users or developers. For example, using "User Login Verification" as an action name clearly demonstrates the purpose or function of the action on the user interface, making it easy to understand and use.

[0127] Action types define the specific behavior or operation category of an action, including but not limited to data reading, data processing, data storage, API calls, and user interface interactions. These types help the orchestration engine identify how to perform a specific action. For example, "data reading" actions are used to retrieve information from a database or other data sources; "API call" actions are used to communicate with other services; and "user interface interaction" actions are used to interact with user interface elements, such as opening a dialog box or updating a specific area on a page.

[0128] Input parameters refer to all the input information required to execute an action. To increase flexibility, values ​​can be dynamically obtained through expressions. This means that input parameters can not only be fixed static values, but can also be dynamically calculated based on variable references, arithmetic operations, logical judgments, or function calls. For example, an input parameter can be a simple static value such as "default_value:admin", or a complex expression such as "username:{context.user_input}&&trim()", where `{context.user_input}` is a variable obtained from the context, and the `trim()` function removes leading and trailing spaces.

[0129] Pre-dependencies are defined through metadata fields, indicating other actions that must be completed before the current action can be executed. This ensures that actions are executed in the correct order, maintaining the consistency and integrity of business logic. For example, in an order processing flow, the "Inventory Check" action may need to be executed only after the "Product Details Retrieval" action is completed; therefore, a pre-dependency on "Product Details Retrieval" is defined in the metadata of "Inventory Check".

[0130] Dependencies are also defined through metadata fields, indicating the subsequent actions that need to be triggered after the current action is successfully executed. These dependencies help automate processes, ensuring that once an action is completed, related subsequent actions are automatically initiated. For example, after the "order payment confirmation" action is completed, its subsequent dependency can be defined as the "send confirmation email" action. This way, when payment is successfully confirmed, the system will automatically send a confirmation email to the customer.

[0131] According to one embodiment of this application, the process of the action chain orchestration engine parsing the action metadata model includes:

[0132] Load the corresponding metadata model from the database or configuration file according to the business trigger command;

[0133] The pre- and post-dependencies between actions are analyzed using graph theory algorithms to generate an action execution order table.

[0134] It supports configuring variable parameters through template languages ​​or scripting languages. These variable parameters include static values, context variables, or external data source references.

[0135] Before executing an action, the input parameters are checked for validity according to predefined validation rules. If the validation fails, the current action chain is terminated and an error log is recorded.

[0136] As described above, when the system receives a business trigger instruction, the action chain orchestration engine first searches for and loads the corresponding action metadata model from the database or configuration file based on the business identifier or action chain name contained in the instruction. These metadata models are stored in a structured format, containing information such as the identifier, name, type, input parameters, pre-dependencies, and post-dependencies of each action. The loading process ensures that the orchestration engine can obtain complete and accurate action definitions, providing a data foundation for subsequent parsing and execution.

[0137] The orchestration engine performs dependency analysis on the loaded metadata model, identifying pre- and post-dependencies between actions. It then uses graph theory algorithms (such as topological sorting) to process action nodes and their dependent edges, constructing a directed acyclic graph (DAG) and generating an action execution order list. This order list explicitly indicates the execution order of actions, ensuring that dependent actions are executed in the correct logical sequence and preventing process interruptions or data inconsistencies due to incorrect ordering.

[0138] The orchestration engine supports configuring variable parameters in action chains using template languages ​​or scripting languages. These variable parameters can be static values, such as fixed strings or numbers; they can also be context variables, i.e., data dynamically generated and stored in the context environment during action chain execution; or they can be references to external data sources, such as data obtained from database query results, API return values, or other system interfaces. Through an expression parsing mechanism, the engine can dynamically calculate parameter values ​​at runtime, improving the flexibility and adaptability of action chains.

[0139] Before executing each action, the orchestration engine checks the validity of the input parameters for the current action according to predefined validation rules. Validation rules include, but are not limited to, non-empty validation, data type validation, format validation (such as email address format, phone number format), range validation (such as numerical range), and business rule validation (such as password strength requirements). If any parameter fails validation, the engine will immediately terminate the execution of the current action chain to prevent erroneous data from entering subsequent processes, and will record the validation failure information in the error log for subsequent troubleshooting and system monitoring.

[0140] According to one embodiment of this application, the action chain sequentially executes the corresponding business logic steps on the input parameters:

[0141] The output of each action is automatically written to the global context object, and subsequent actions read the required data from the context by variable name;

[0142] If an exception occurs during the execution of the action, a response is made according to a preset exception handling strategy, which is configured through metadata fields.

[0143] The execution path is dynamically selected by the entry condition, which determines whether to execute the action chain of the corresponding branch based on the expression calculation result.

[0144] After each action is completed, it reports its status to the orchestration engine. This status is used to drive the execution decision of subsequent actions or trigger exception handling procedures.

[0145] As described above, during the execution of the action chain, after each action completes its business logic processing, the resulting output is automatically written to a global context object. This context object is valid throughout the entire lifecycle of the action chain and is used to store and transfer shared data between actions. Subsequent actions, when executed, can read the required data from this context using predefined variable names as input parameters for their own execution. This mechanism achieves data decoupling and efficient data transfer between actions, avoiding explicit data transfer operations and improving the coherence and maintainability of the process.

[0146] If an exception occurs during action execution, such as an external service call failure, incorrect data format, or insufficient system resources, the action chain orchestration engine will respond according to pre-configured exception handling policies. These exception handling policies are defined through metadata fields, such as options for "number of retries," "skip," "terminate the action chain," or "redirect to an alternative path." Based on these configurations, the engine determines subsequent behavior, such as automatically retrying the current action, skipping the action and continuing with subsequent actions, or interrupting the entire action chain and entering an error handling process, thereby enhancing the system's fault tolerance and operational stability.

[0147] Action chains support dynamic selection of execution paths based on runtime conditions. This is achieved through entry conditions, which are expressions that can include context variables, constants, logical operators, and function calls. When the process reaches a branch node, the orchestration engine calculates the value of this expression and determines whether the execution condition is met based on the result. If the condition is true, the corresponding branch action chain is activated and execution continues; otherwise, the branch is skipped. This mechanism supports complex process structures such as conditional statements, multi-path branching, and loop control, enabling action chains to adapt to diverse business scenarios.

[0148] After each action is completed, regardless of success or failure, it sends its execution status back to the action chain orchestration engine. The status information includes the execution result (e.g., success, failure, timeout), execution time, output data summary, and possible error codes or exception information. Upon receiving this status, the orchestration engine uses it as a basis for decision-making to control the execution flow of subsequent actions. For example, it may determine whether to continue executing the next action, trigger exception handling mechanisms, record runtime logs, or notify external monitoring systems. This feedback mechanism enables real-time control of the action chain execution process, supporting fine-grained process scheduling and operation and maintenance management.

[0149] According to one embodiment of this application, in the step of outputting the output result of the action chain to the next action:

[0150] The output results are transmitted using a unified data structure, which includes status codes, output data, and metadata descriptions.

[0151] Cache frequently accessed output results to reduce the overhead of redundant calculations or external calls;

[0152] It allows the output of one action chain to be used as the input parameter of another action chain, enabling cross-chain data transfer through metadata fields;

[0153] The execution progress, output results, and exception information of the action chain are displayed in real time through a graphical interface. The monitoring data is generated by the orchestration engine's log system.

[0154] As described above, during the execution of the action chain, after the current action completes its business logic processing, its output is encapsulated according to a unified data structure and passed to the next action. This data structure contains three core components: status codes, output data, and metadata descriptions. Status codes indicate the execution result of the current action, such as success, failure, or timeout; output data is the actual business data generated by the action, such as user information, order number, or verification result; and metadata descriptions provide additional information about the output data, including data type, generation time, and source action identifier. By adopting a unified structure, the consistency of data formats between different actions is ensured, facilitating parsing and processing, and improving the reliability and maintainability of system integration.

[0155] To improve execution efficiency and reduce the overhead of redundant calculations or repeated calls to external services, the system implements a caching mechanism for output results that are frequently accessed by subsequent actions. When the output result of an action is determined to be cacheable, it is temporarily stored in memory or a distributed cache, with appropriate expiration dates and access policies set. When subsequent actions request the same data, they prioritize reading from the cache rather than re-executing the original action or calling external interfaces again. This mechanism effectively reduces system resource consumption and improves the overall response speed of the action chain, making it particularly suitable for high-concurrency scenarios or those involving remote calls.

[0156] The system supports using the output of one action chain as the input parameter of another independent action chain, enabling cross-chain data sharing and workflow linkage. This cross-chain transfer is achieved by configuring reference relationships in metadata fields. For example, defining the "reference source chain ID" and "output field name" in the input parameters of an action chain allows the orchestration engine to automatically identify and load the output of the corresponding action chain during execution. This mechanism enables flexible collaboration between multiple business processes, supports the construction of modular and reusable process units, and enhances the system's composability and scalability.

[0157] The system provides a graphical interface for real-time display of the action chain's execution status, including current progress, output results of each action, and any exceptions. This monitoring function relies on the action chain orchestration engine's built-in logging system, which automatically collects key operational data during each action's execution, such as start time, end time, input / output content, state changes, and error stacks, and pushes this data to the front-end monitoring interface. Users can intuitively understand the entire action chain's operation through visual charts, flowcharts, or log lists, facilitating rapid problem identification, performance bottleneck analysis, or business auditing, thus improving system observability and operational efficiency.

[0158] According to one embodiment of this application, in the step of constructing the action metadata model, the input parameters support the following configuration methods:

[0159] Define fixed values ​​directly in the metadata;

[0160] Reference data in the global context by variable name;

[0161] Values ​​are dynamically obtained through a predefined data interface, the configuration information of which is contained in the data_source field of the metadata;

[0162] Input parameters are preprocessed using logical operators or function calls.

[0163] As mentioned above, the input parameters can be configured in multiple ways during the construction of the action metadata model to meet the flexibility and dynamic requirements of different scenarios. Specifically, these include the following four configuration methods:

[0164] Input parameters can be configured with static, fixed values ​​that are determined during metadata definition and remain unchanged each time the action is executed. For example, in a notification sending action, the "message type" parameter can be directly set to the fixed string "urgent notification". This approach is suitable for parameters that do not change with the execution environment and have definite values; it is simple to configure and highly efficient.

[0165] Input parameters can reference dynamic data stored in the global context object using variable names. The global context persists throughout the action chain and stores data shared between actions. For example, a user ID or order number generated by a previous action can be retrieved as an input parameter in a subsequent action using a variable reference like "${userId}". This approach enables data transfer and context dependencies between actions, supporting continuous execution of the process.

[0166] The values ​​of input parameters can also be dynamically obtained at runtime by calling predefined data interfaces. These interfaces may point to database queries, remote API services, message queues, or other external systems. Related interface configuration information, such as request address, request method, and authentication method, is centrally defined in the `data_source` field of the metadata. When an action is executed, the system automatically initiates a data request based on the configuration of this field and retrieves the returned result as the input parameter. This approach is suitable for scenarios requiring real-time acquisition of external data, enhancing the integration capability between the action chain and external systems.

[0167] During the process of obtaining input parameter values, logical operators (such as AND, OR, and NOT) or built-in functions are supported for calculation and transformation. For example, two context variables can be concatenated, numerical values ​​can be subjected to arithmetic operations, and string processing functions (such as removing spaces and converting case) or date functions (such as formatting and calculating time differences) can be called. These expressions are evaluated by the expression parsing engine before the action is executed, and the final result is used as the actual input parameter. This approach improves the flexibility of parameter configuration and supports complex business logic processing.

[0168] According to one embodiment of this application, after the action chain orchestration engine parses the action metadata model, the generated action chain supports the following execution modes:

[0169] Actions are executed sequentially according to their dependencies, with the output of the previous action serving as the input for the next action;

[0170] Actions without dependencies can be executed in parallel, with concurrency managed through thread pools or asynchronous task schedulers;

[0171] Define loop conditions through metadata fields to repeatedly execute specific actions until the conditions are met;

[0172] The execution path can be dynamically selected based on the entry conditions, supporting multi-branch logic.

[0173] As mentioned above, after parsing the action metadata model, the action chain orchestration engine generates an ordered action chain based on the pre- and post-dependencies between each action. In this mode, actions are executed sequentially according to their dependencies, with the output of the previous action serving as the input parameter for the next. For example, in the user registration process, after the "email verification" action is completed, its verification result (such as the user ID) is passed to the "password setting" action as input. This serial execution mode ensures the consistency and integrity of business logic, avoiding data inconsistencies or process interruptions due to incorrect order.

[0174] When multiple actions are independent of each other, they can be executed in parallel to improve efficiency. The orchestration engine manages concurrently executed tasks through thread pools or asynchronous task schedulers. For example, in order processing, the actions "inventory check" and "payment verification" are independent and can begin execution simultaneously, checking inventory status and verifying payment information respectively. This not only speeds up the overall process but also optimizes system resource utilization, making it particularly suitable for performance improvements in high-concurrency scenarios.

[0175] In some business scenarios, it may be necessary to repeatedly execute an action until a specific condition is met. The orchestration engine allows defining loop conditions through metadata fields. These conditions are typically composed of expressions containing elements such as logical operators, variable references, and function calls. For example, during batch data import, a loop condition can be set to "continue the import operation as long as there are still unprocessed data records." At each loop iteration, the orchestration engine re-evaluates this condition; if the condition is still true, the specified action continues; otherwise, the loop exits. This approach supports complex loop control logic, enhancing the adaptability of the action chain to dynamic business requirements.

[0176] Action chains support dynamic selection of execution paths based on entry conditions, enabling multi-branch logic control. Entry conditions are calculated using expressions and used to determine whether the conditions for executing a specific branch are met. For example, in a user login verification process, the subsequent operation path can be dynamically determined based on the user's account type (regular user or administrator): if the user is an administrator, they are redirected to the administrator interface; if they are a regular user, they are directed to the regular user interface. This mechanism allows action chains to flexibly adjust execution paths based on real-time data and business rules, supporting complex decision logic and personalized user experiences, thus improving the system's flexibility and scalability.

[0177] According to one embodiment of this application, the pre-verification mechanism of the action chain includes:

[0178] Check whether the input parameters conform to the predefined data type and format;

[0179] The input validity is verified using preset validation rules;

[0180] Ensure that all required parameters provide valid values; trigger an error message and terminate the action chain if any parameter is missing.

[0181] Perform permission verification for sensitive operations, determining whether execution is permitted based on role or user identity.

[0182] As mentioned above, before each action is executed, the pre-validation mechanism first checks whether the data type and format of the input parameters are consistent with the predefined requirements in the metadata model. For example, if an input parameter is defined as a date type, the system will verify whether the actual value passed in conforms to the standard date format (such as YYYY-MM-DD). Similarly, for numeric parameters, the system will confirm whether they are in a valid numeric form and may also check whether they are within a specified range. This validation ensures data consistency and correctness, preventing subsequent logical processing failures due to mismatched data types or formats.

[0183] In addition to basic data type and format validation, the pre-validation mechanism also supports the application of more complex business rules to verify the legality of input. These validation rules can be specific conditions set based on specific business needs, such as "password length must be at least 8 characters" or "email address must contain the '@' symbol." The system validates the input parameters one by one according to the pre-configured rule set, and only allows the current action to continue when all rules are satisfied. If any rule fails, the corresponding error handling process is triggered.

[0184] For input parameters marked as required, a pre-validation mechanism specifically checks whether these parameters exist and have valid values. If a required parameter is found to be missing or the provided value is invalid (such as an empty string, a value that does not meet format requirements, etc.), an error message is immediately triggered, and the execution of the current action chain is terminated. This strict check of required parameters helps prevent business logic errors or system anomalies caused by insufficient critical information, ensuring the robustness and integrity of the entire process.

[0185] For actions involving sensitive operations (such as deleting important data or modifying permission settings), the pre-verification mechanism also includes a permission verification step. During this process, the system determines whether a user is authorized to perform the relevant operation based on their role or identity information. For example, only users with administrator privileges can delete user accounts; if a regular user attempts to perform such an operation, the system will reject the request and record the corresponding access control log. This approach enhances system security, prevents unauthorized operations, and protects the security of system resources and data.

[0186] A second aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any of the embodiments of the first aspect above.

[0187] Figure 2 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 2 As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 may call logical instructions in the memory 830 to execute the method in any of the embodiments of the first aspect described above, the method including:

[0188] Construct an action metadata model, including action identifier, name, type, input parameters, pre-dependencies, and post-dependencies;

[0189] The action chain orchestration engine parses the action metadata model to identify business logic, dynamically constructs action chains based on business logic, configures variable parameters of action chains through expressions, and uses a pre-validation mechanism to perform condition validation of action chains.

[0190] The action chain executes the corresponding business logic on the input parameters in sequence and outputs the result to the next action.

[0191] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0192] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program, the computer program being able to be stored on a non-transitory computer-readable storage medium, and when the computer program is executed by a processor, the computer being able to perform the methods provided by the above methods, the method comprising:

[0193] Construct an action metadata model, including action identifier, name, type, input parameters, pre-dependencies, and post-dependencies;

[0194] The action chain orchestration engine parses the action metadata model to identify business logic, dynamically constructs action chains based on business logic, configures variable parameters of action chains through expressions, and uses a pre-validation mechanism to perform condition validation of action chains.

[0195] The action chain executes the corresponding business logic on the input parameters in sequence and outputs the result to the next action.

[0196] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the cigarette box image recognition method provided by the methods described above, the method comprising:

[0197] Construct an action metadata model, including action identifier, name, type, input parameters, pre-dependencies, and post-dependencies;

[0198] The action chain orchestration engine parses the action metadata model to identify business logic, dynamically constructs action chains based on business logic, configures variable parameters of action chains through expressions, and uses a pre-validation mechanism to perform condition validation of action chains.

[0199] The action chain executes the corresponding business logic on the input parameters in sequence and outputs the result to the next action.

[0200] For any parts not mentioned in this application, existing technologies may be used or referenced.

[0201] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0202] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for dynamic orchestration and verification of action chains based on metadata, characterized in that, include: Construct an action metadata model, including action identifier, name, type, input parameters, pre-dependencies, and post-dependencies; The action chain orchestration engine parses the action metadata model to identify business logic, dynamically constructs action chains based on business logic, configures variable parameters of action chains through expressions, and uses a pre-validation mechanism to perform condition validation of action chains. The action chain executes the corresponding business logic on the input parameters in sequence and outputs the result to the next action.

2. The method according to claim 1, characterized in that, In the step of constructing the action metadata model, the action identifier is a unique string identifier, the action name is used for interface display, and the action type includes one or more combinations of data reading, data processing, data storage, API call, and interface interaction; The input parameters can be dynamically obtained through expressions, including but not limited to variable references, arithmetic operations, logical judgments, and function calls. The preceding and following dependencies are defined through metadata fields. The preceding dependency represents other actions that must be completed before the current action is executed, and the following dependency represents subsequent actions that need to be triggered after the current action is executed.

3. The method according to claim 1, characterized in that, The process by which the action chain orchestration engine parses the action metadata model includes: Load the corresponding metadata model from the database or configuration file according to the business trigger command; The pre- and post-dependencies between actions are analyzed using graph theory algorithms to generate an action execution order table. It supports configuring variable parameters through template languages ​​or scripting languages. These variable parameters include static values, context variables, or external data source references. Before executing an action, the input parameters are checked for validity according to predefined validation rules. If the validation fails, the current action chain is terminated and an error log is recorded.

4. The method according to claim 1, characterized in that, The action chain executes the corresponding business logic steps on the input parameters in sequence: The output of each action is automatically written to the global context object, and subsequent actions read the required data from the context by variable name; If an exception occurs during the execution of the action, a response is made according to a preset exception handling strategy, which is configured through metadata fields. The execution path is dynamically selected by the entry condition, which determines whether to execute the action chain of the corresponding branch based on the expression calculation result. After each action is completed, it reports its status to the orchestration engine. This status is used to drive the execution decision of subsequent actions or trigger exception handling procedures.

5. The method according to claim 1, characterized in that, The output of the action chain is then passed to the next action step: The output results are transmitted using a unified data structure, which includes status codes, output data, and metadata descriptions. Cache frequently accessed output results to reduce the overhead of redundant calculations or external calls; It allows the output of one action chain to be used as the input parameter of another action chain, enabling cross-chain data transfer through metadata fields; The execution progress, output results, and exception information of the action chain are displayed in real time through a graphical interface. The monitoring data is generated by the orchestration engine's log system.

6. The method according to claim 1, characterized in that, In the step of constructing the action metadata model, the input parameters support the following configuration methods: Define fixed values ​​directly in the metadata; Reference data in the global context by variable name; Values ​​are dynamically obtained through a predefined data interface, the configuration information of which is contained in the data_source field of the metadata; Input parameters are preprocessed using logical operators or function calls.

7. The method according to claim 1, characterized in that, After parsing the action metadata model, the action chain orchestration engine generates action chains that support the following execution modes: Actions are executed sequentially according to their dependencies, with the output of the previous action serving as the input for the next action; Actions without dependencies can be executed in parallel, with concurrency managed through thread pools or asynchronous task schedulers; Define loop conditions through metadata fields to repeatedly execute specific actions until the conditions are met; The execution path can be dynamically selected based on the entry conditions, supporting multi-branch logic.

8. The method according to claim 1, characterized in that, The pre-verification mechanism of the action chain includes: Check whether the input parameters conform to the predefined data type and format; The input validity is verified using preset validation rules; Ensure that all required parameters provide valid values; trigger an error message and terminate the action chain if any parameter is missing. Perform permission verification for sensitive operations, determining whether execution is permitted based on role or user identity.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1-8.

10. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1-8.

Images