Intelligent treatment center-based atomic action scheduling method and device, computer device, and medium

Abstract

The application relates to an atomic action scheduling method and device based on an intelligent processing center, computer equipment and a medium. The method comprises the following steps: in response to a service processing request, corresponding target action chain configuration information is determined from a preset action chain configuration library according to the service processing request; the target action chain configuration information comprises a plurality of atomic action identifiers and at least one conditional trigger rule; based on service data in the service processing request, the conditional trigger rule in the target action chain configuration information is analyzed to determine a target atomic action identifier and an execution sequence, and an execution plan is generated; and service logic corresponding to each target atomic action identifier is executed according to the execution plan to complete a service processing operation. The application can standardize and decouple processing actions, and can intelligently arrange and reliably execute the processing actions.

Description

Technical Field

[0001] This application relates to the field of business scheduling technology, and in particular to an atomic action scheduling method, apparatus, computer equipment and medium based on an intelligent processing center. Background Technology

[0002] In modern internet and financial business systems, risk control and business processing are core aspects of ensuring secure and stable operations. Such systems typically need to execute a series of specific actions based on real-time strategy analysis results (such as identifying fraudulent transactions, abnormal logins, or approved credit checks), such as intercepting transactions, freezing accounts, adjusting credit limits, sending user notifications, updating blacklists, or modifying user tags.

[0003] In existing business processing systems (such as risk control and transaction processing), complex business processes are typically executed using two traditional models: First, specific processing actions (such as freezing accounts, sending notifications, and updating credit limits) are directly written into the main logic code of the business strategy in hard-coded form, forming a fixed action call chain; second, action sequences are defined by writing or configuring scripts.

[0004] These methods can meet the needs when the business is simple, but as the business scenarios continue to increase, the rules change frequently and the system scale expands, their inherent defects become increasingly prominent. These methods have at least the following shortcomings: (1) The handling logic is highly coupled with the core business strategy. Any addition, deletion, modification or order adjustment of any action requires modification of the source code and redeployment, resulting in long iteration cycles, high maintenance costs and easy errors; (2) The granularity of the actions is coarse and the reusability is poor. Similar logic cannot be shared in different scenarios, resulting in development duplication and waste of resources; (3) The execution process lacks a unified and intelligent scheduling center, making it difficult to support dynamic branch judgment based on real-time data, parallel execution or flexible dependency management. Summary of the Invention

[0005] To address the aforementioned shortcomings or deficiencies, this application provides an atomic action scheduling method, apparatus, computer equipment, and medium based on an intelligent processing center.

[0006] This application provides an atomic action scheduling method based on an intelligent processing center according to a first aspect, the method comprising: In response to a business processing request, the corresponding target action chain configuration information is determined from a pre-configured action chain configuration library based on the business processing request; the target action chain configuration information includes multiple atomic action identifiers and at least one conditional triggering rule; Based on the business data in the business processing request, the condition triggering rules in the target action chain configuration information are parsed to determine the target atomic action identifier and its execution order, and an execution plan is generated; The business logic corresponding to each target atomic action identifier is executed according to the execution plan to complete the business processing operation.

[0007] In some embodiments, the method further includes: The system receives user-inputted action chain definition information through a pre-defined action chain configuration interface. The action chain definition information includes atomic action identifier sequences, descriptions of dependencies between atomic actions, conditional trigger rule configuration information, version number, and canary release strategy information. The corresponding action chain configuration information is generated based on the action chain definition information; the action chain configuration information includes the action chain identifier, condition triggering rules, grayscale ratio, version number, and effective time; Action chain configuration information is stored in the action chain configuration library as configuration files.

[0008] In some embodiments, based on the business data in the business processing request, the conditional triggering rules in the target action chain configuration information are parsed to determine the target atomic action identifier and its execution order, and an execution plan is generated, including: The logical dependencies between multiple atomic action identifiers are determined based on the target action chain configuration information. Determine the valid execution path in the logical dependency relationship based on the conditional triggering rules in the business data and target action chain configuration information; Determine the atomic action identifiers to be executed and their execution order based on the valid execution path; record the atomic action identifiers to be executed as the target atomic action identifiers; Create a corresponding action instance for the target atomic action identifier. The action instance includes the action instance identifier and the instance input parameter information determined based on the business data. An execution plan is generated based on the execution order and action instances.

[0009] In some embodiments, the method further includes: Define the business logic unit that implements the predefined interface as an atomic action; Standardized action registration information is created for each atomic action; the action registration information includes atomic action identifier, action type, input parameter structure information, output parameter structure information, action execution logic entry information, action compensation logic entry information, and retry logic configuration information; Each action registration information is stored in a specified data table to form an atomic action registry.

[0010] In some embodiments, the execution plan includes multiple action instances and the target atomic action identifier, action instance identifier, instance input parameter information, and execution control information associated with each action instance; Execute the business logic corresponding to each target atomic action identifier according to the execution plan, including: The target atomic action identifier is used to query the pre-set atomic action registry, and the retrieved action registration information is recorded as the target action registration information. Execute the corresponding business logic based on the target action registration information.

[0011] In some embodiments, the corresponding business logic is executed based on the target action registration information, including: Based on the action execution logic entry information in the target action registration information, determine the corresponding business logic processor; The business logic processor is invoked based on the instance input parameter information of the action instance.

[0012] In some embodiments, executing corresponding business logic based on the target action registration information further includes: Use an action lifecycle table to record the execution status of action instances; When an anomaly is detected in an action instance, the corresponding action compensation logic or retry logic is executed based on the action compensation logic entry information and retry logic configuration information in the target action registration information related to the action instance.

[0013] According to a second aspect, this application provides an atomic action scheduling device based on an intelligent processing center, the device comprising: The action chain determination module is used to respond to a business processing request and determine the corresponding target action chain configuration information from a pre-set action chain configuration library based on the business processing request; the target action chain configuration information includes multiple atomic action identifiers and at least one conditional triggering rule; The execution plan generation module is used to parse the conditional triggering rules in the target action chain configuration information based on the business data in the business processing request, in order to determine the target atomic action identifier and its execution order, and generate an execution plan. The execution module is used to execute the business logic corresponding to each target atomic action identifier according to the execution plan in order to complete the business processing operation.

[0014] According to a third aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the atomic action scheduling methods based on an intelligent processing center in the above embodiments.

[0015] According to a fourth aspect, this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executed, implements any of the atomic action scheduling methods based on an intelligent processing center described above.

[0016] This application standardizes and decouples processing actions, enabling intelligent orchestration and reliable execution. Specifically, firstly, by using a pre-built action chain configuration library, the business processing logic, previously hard-coded into the program, is externalized into independently manageable configuration data. This directly allows changes to business rules to take effect without modifying or redeploying the application code; simply updating the configuration library is sufficient. This decouples business logic from the execution system, significantly improving system maintainability and the agility of strategy iteration. Secondly, upon receiving a business processing request, an execution plan is dynamically generated, introducing a dynamic decision-making layer. The system no longer mechanically executes fixed processes but performs logical calculations based on the real-time context data (business data) of each request, dynamically determining the optimal or compliant execution path. This endows the system with the ability to handle complex conditional branches and dynamic dependencies, greatly enhancing the flexibility and intelligence of the processing flow and enabling it to cope with diverse business scenarios. Finally, scheduling is centered around the execution plan, which is a structured and unambiguous set of task instructions that ensures the accuracy and consistency of action execution. Furthermore, the entire process, from receiving requests to generating plans and then executing actions, forms a standardized and automated closed loop. This overcomes the shortcomings of traditional methods, such as scattered scheduling logic and difficulty in unified control of the execution process, thereby improving the reliability and overall efficiency of the system. Attached Figure Description

[0017] Figure 1 This is a flowchart of an atomic action scheduling method based on an intelligent processing center in one or more embodiments of this application; Figure 2 This is a flowchart illustrating the configuration of action chains in one or more embodiments of this application; Figure 3 This is a schematic diagram of the action chain configuration interface in one or more embodiments of this application; Figure 4 This is a flowchart illustrating the registration process of atomic actions in one or more embodiments of this application; Figure 5 This is a schematic diagram of the structure of an atomic action scheduling device based on an intelligent processing center in one or more embodiments of this application; Figure 6 This is a schematic diagram of the internal structure of a computer device according to one or more embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the described embodiments are merely some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0020] In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0021] To address the shortcomings or defects of related technologies, this application provides an atomic action scheduling method based on an intelligent processing center. This method can standardize and decouple processing actions, and intelligently orchestrate and reliably execute them. Specifically, firstly, by using a pre-built action chain configuration library, the business processing logic originally hard-coded in the program is externalized into independently manageable configuration data. This directly enables changes to business rules to take effect without modifying or redeploying the application code; only the configuration library needs to be updated. This decouples business logic from the execution system, significantly improving the system's maintainability and the agility of strategy iteration. Secondly, upon receiving a business processing request, an execution plan is dynamically generated, introducing a dynamic decision-making layer. The system no longer mechanically executes fixed processes but can perform logical calculations based on the real-time context data (business data) of each request, dynamically determining the optimal or compliant execution path. This endows the system with the ability to handle complex conditional branches and dynamic dependencies, greatly enhancing the flexibility and intelligence of the processing process and enabling it to cope with diverse business scenarios. Finally, scheduling is centered around the execution plan, which is a structured and unambiguous set of task instructions that ensures the accuracy and consistency of action execution. Furthermore, the entire process, from receiving requests to generating plans and then executing actions, forms a standardized and automated closed loop. This overcomes the shortcomings of traditional methods, such as scattered scheduling logic and difficulty in unified control of the execution process, thereby improving the reliability and overall efficiency of the system.

[0022] In some exemplary embodiments of this application, such as Figure 1 As shown, the method includes steps S110 to S130, and each step is described in detail below.

[0023] S110: In response to a business processing request, determine the corresponding target action chain configuration information from the pre-set action chain configuration library according to the business processing request. The target action chain configuration information includes multiple atomic action identifiers and at least one condition triggering rule.

[0024] A business processing request refers to an event or instruction generated by an external system (such as a risk control decision engine or a scheduled task) that requires the intelligent processing center to execute a series of business operations. The request includes a business scenario identifier and business data. For example, a credit approval event has the scenario identifier CREDIT_APPROVED and the business data {“userId”:“U123”,“creditLimit”:15000}.

[0025] The action chain configuration library (or simply configuration library) is a persistent storage system that stores templates for all business scenario handling processes (i.e., action chain configuration information). Specifically, it can be a database or a configuration center.

[0026] The target action chain configuration information refers to a specific processing flow template retrieved from the action chain configuration library that matches the current business processing request. Specifically, it is structured configuration data (such as configuration files in JSON or YAML format).

[0027] An atomic action identifier is a string or code used in the system to uniquely identify a minimal executable business operation. For example, CREATE_ACCOUNT means "open an account", and ADD_TO_VIP_LIST means "add to the VIP list".

[0028] A conditional trigger rule is a logical expression defined in an action chain to control process branches. It can be calculated based on business data, and the result is a Boolean value. For example, the conditional trigger rule $creditLimit>=10000 means "when the credit limit is greater than or equal to 10,000 yuan".

[0029] For example, in this step, the intelligent processing center receives a "credit approval approved" event from the risk control engine as a business processing request. The processing center parses the request and extracts the business scenario identifier, such as CREDIT_APPROVED. Subsequently, it queries the action chain configuration library using this business scenario identifier as the key. The configuration library contains action chain configuration information with the number FLOW_POST_APPROVAL. The processing center uses this action chain configuration information as the target action chain configuration information for this processing. This configuration information specifies all atomic action identifiers (such as CREATE_ACCOUNT, ADD_TO_LIST) that may be involved in this scenario, as well as the conditional triggering rules connecting these atomic actions.

[0030] This step extracts business logic from the code by using a pre-built action chain configuration library and manages it as queryable configuration information, thus decoupling business rules from the execution system. When business processes need to be changed, only the template in the configuration library needs to be modified, without rewriting or restarting the application code, thereby greatly improving the system's maintainability and the agility of business response.

[0031] S120: Based on the business data in the business processing request, parse the condition triggering rules in the target action chain configuration information to determine the target atomic action identifier and its execution order, and generate an execution plan.

[0032] Business data refers to the specific parameter information (such as creditLimit:15000) carried in the business processing request that is related to the current request.

[0033] The target atomic action identifier is a set of atomic action identifiers that are actually required to be executed in this request, selected from multiple atomic action identifiers contained in the action chain configuration information after parsing the conditional triggering rules.

[0034] An execution plan is a dynamically generated, immutable list of tasks containing explicit execution instructions for this business processing request.

[0035] For example, in this step, the processing center extracts business data from the business processing request and reads the conditions and dependencies defined in the target action chain configuration information. First, it calculates the result of the condition triggering rule, where $creditLimit>=10000, indicating a true result. Based on this result, the processing center determines that the process will follow the "high-credit" branch, thereby filtering out the target atomic action identifier sequence, such as [CREATE_ACCOUNT, ADD_TO_VIP_LIST, UPDATE_USER_TAG] and its execution order, thus generating an execution plan.

[0036] This step introduces a dynamic decision-making and instantiation process, enabling the processing center to flexibly determine the execution path based on the real-time context of each business processing request, rather than executing a fixed script. This significantly enhances the system's flexibility (intelligence) in handling complex, multi-branch business logic. Furthermore, the execution plan generated in this step is a standardized instruction set, laying the foundation for stable and reliable execution and making the entire scheduling decision-making process traceable.

[0037] S130: Execute the business logic corresponding to each target atomic action identifier according to the execution plan to complete the business processing operation.

[0038] Business logic refers to the specific code, function, or service interface that implements the functionality represented by the atomic action identifier. For example, the business logic corresponding to the CREATE_ACCOUNT identifier might be a specific RPC interface that calls the account service.

[0039] The processing center can determine the business logic corresponding to each target atomic action identifier based on the execution plan, and execute the business logic to complete the business processing operation.

[0040] This step strictly follows the execution plan to carry out business processing operations, achieving centralized and standardized control of the execution process and avoiding the chaos caused by the scattered calling logic in traditional methods.

[0041] In some embodiments, such as Figure 2 As shown, this method also includes steps S210-S230, which are described in detail below.

[0042] S210: Receive action chain definition information input by the user through the preset action chain configuration interface.

[0043] Action chain definition information includes atomic action identifier sequence, dependency description information between atomic actions, condition trigger rule configuration information, version number, and canary release strategy information.

[0044] Action chain configuration information includes action chain identifier, conditional triggering rules, grayscale ratio, version number, and effective time.

[0045] Action chain configuration interfaces refer to the visual interfaces or application programming interfaces provided by the intelligent processing center system to business personnel or configuration administrators for creating and editing action chains. Examples include a web configuration platform or a dedicated RESTful API.

[0046] Action chain definition information refers to the set of raw data that users input through the configuration interface to describe a complete business process.

[0047] An atomic action identifier sequence refers to a user-defined list of atomic action identifiers arranged in order of business logic. For example, ["CREATE_ACCOUNT", "ADD_TO_LIST", "UPDATE_USER_TAG"].

[0048] Dependency description information refers to user-defined constraints that describe the execution order of atomic actions. For example, specifying that "UPDATE_USER_TAG must be executed after CREATE_ACCOUNT succeeds".

[0049] Conditional trigger rule configuration information refers to branch rules defined by the user in the form of logical expressions. For example, configuring a condition as "$creditLimit>=10000" and associating it with different subsequent actions.

[0050] The version number refers to the version identifier that the user specifies for this configuration, used to distinguish and manage different iterations of the same action chain, such as "V1.0" and "V2.1".

[0051] A canary release strategy refers to a user-defined policy that controls how a new version's configuration gradually replaces the old version. For example, {"Canary Release Ratio": 5%, "Effective Condition": "User ID ending in 0-4"}.

[0052] For example, in this step, the business personnel log in to the action chain configuration interface (such as a web management backend) provided by the processing center. In the interface, the business personnel name the new process "Credit Approval Post-Process V2" and specify the version number as "2.0". Then, from the atomic action library provided by the system, they construct a sequence of atomic action identifiers by dragging or selecting. They draw lines between two actions to define dependency description information and configure conditional triggering rule information (such as credit limit conditions) at a decision point. Finally, they select a canary release strategy in the release settings, setting it to apply to 5% of users first. After completing the editing, they click "Save," and the processing center receives this complete action chain definition information.

[0053] This step provides users with an intuitive configuration interface, transforming complex process orchestration into the definition of structured data. This significantly lowers the barrier for business personnel to participate in technical configuration, improving configuration efficiency and accuracy. Simultaneously, it supports the input of version numbers and canary deployment strategies, laying the foundation for safe and smooth business changes in the future.

[0054] S220: Generate corresponding action chain configuration information based on action chain definition information.

[0055] Action chain configuration information refers to the internal configuration data structure generated by the system after standardizing and serializing the action chain definition information input by the user, which can be directly read and parsed by the scheduling engine.

[0056] An action chain identifier is a unique identifier assigned by the system to each action chain configuration information. It is usually associated with the user-defined action chain name and version number and is used for precise retrieval in the system, such as FLOW_CREDIT_POST_V2.

[0057] The grayscale ratio refers to the numerical value extracted from the grayscale release strategy information that determines the proportion of traffic allocation.

[0058] The effective time refers to the point in time when the configuration information begins to formally process requests, either automatically generated by the system or specified by the user.

[0059] For example, in this step, after the processing center system receives the action chain definition information submitted by the user, the background service initiates the configuration compilation process. First, the processing center verifies the validity of the action identifier and the rationality of the dependencies. Upon successful verification, a globally unique action chain identifier (FLOW_CREDIT_POST_V2) is automatically generated. Next, the processing center converts the user-input conditional trigger rule configuration information into an expression format executable by its internal engine. Simultaneously, it extracts the grayscale ratio from the grayscale release strategy information and records the current time or the user-specified effective time. Finally, all information is assembled and serialized into a structured configuration object, which is the final action chain configuration information.

[0060] This step transforms and enhances user-friendly configuration data into machine-executable configuration data. The automated generation and verification process reduces the possibility of human error, ensuring the standardization and completeness of the configuration information.

[0061] S230: Store action chain configuration information in the action chain configuration library as a configuration file.

[0062] Configuration file format refers to the persistent storage format of action chain configuration information, such as JSON, YAML, or XML files. The characteristics of this type of configuration file are clear structure, easy to read, and easy to compare versions.

[0063] An action chain configuration repository is a versioned storage system used to centrally store and manage all action chain configuration information, such as a Git repository, configuration center (such as Apollo, Nacos), or database.

[0064] For example, in this step, the processing center serializes the action chain configuration information object generated in step S220 into a string according to a predetermined format (such as JSON) to form a configuration file. Then, this configuration file, along with its action chain identifier, version number, and other metadata, is submitted to the action chain configuration repository. The configuration repository management system performs version control; the new configuration file is stored as a new version (V2.0), coexisting with the old version (V1.0). After successful storage, the processing center marks the status of the configuration information as "awaiting gray-scale" or "effective" based on the effective time and gray-scale ratio of the configuration.

[0065] This step centralizes and version-codes action chain configuration information in a configuration repository, enabling unified management and historical traceability of configuration assets. Every configuration change is recorded, supporting rapid rollback. Furthermore, the configuration file format simplifies configuration migration, backup, and approval. In addition, combining version and canary release information enables configuration-state management of business processing logic, supporting hot updates, canary releases, and rapid rollback capabilities, significantly improving the security and agility of system changes.

[0066] like Figure 3 The image shows a schematic diagram of the action chain configuration interface, which displays the configured action chains.

[0067] In some embodiments, based on the business data in the business processing request, the conditional triggering rules in the target action chain configuration information are parsed to determine the target atomic action identifier and its execution order, and an execution plan is generated, including: (1) Determine the logical dependencies between multiple atomic action identifiers based on the target action chain configuration information.

[0068] Logical dependencies refer to the predefined execution order constraints between atomic actions in an action chain configuration. Logical dependencies describe which actions must be completed before other actions, and can be represented in the form of directed edges or a list of preconditions.

[0069] In this step, the processing center parses the target action chain configuration information and extracts the atomic action execution flow model defined within it. This model explicitly or implicitly contains logical dependencies. For example, the action chain configuration information might indicate that action B depends on the successful completion of action A through the "dependsOn" field, or it might implicitly imply serial dependencies through a list of steps. The processing center can then transform these relationships into a directed acyclic graph data structure, where each node is an atomic action identifier, and each directed edge indicates the dependencies between atomic actions. For example, an edge from action A to action B indicates that action B depends on action A.

[0070] This step transforms the sequential and parallel constraints in the business process diagram into a graph model that can be accurately calculated and processed by a computer, laying the data structure foundation for subsequent path analysis and scheduling, and enabling the system to understand and process complex business process topologies.

[0071] (2) Determine the effective execution path in the logical dependency relationship based on the condition triggering rules in the business data and target action chain configuration information.

[0072] An effective execution path refers to the one or more paths that are activated and actually need to be executed from the complete logical dependency graph after the conditional triggering rules are calculated using the current business data. It is essentially a subgraph obtained by pruning the original graph.

[0073] In this step, the processing center can use business data (such as user credit limits) as context to calculate the logical expression for each condition-triggered rule in the action chain configuration information. For example, for the rule "$creditLimit>= 10000", if the current credit limit is 15000, the result is true. Based on the calculation results of all rules, the system traverses the logical dependency graph: for conditional branch nodes, only outgoing edges with true conditions are retained; for unconditional nodes, all outgoing edges are retained. Finally, one or more connected paths from the start node to the end node are obtained, i.e., the effective execution paths.

[0074] This step enables dynamic process decision-making based on real-time data. The system (i.e., the processing center) no longer executes fixed scripts, but instead plans an optimal or compliant execution route in real time based on the specific circumstances of each request, greatly improving the flexibility and adaptability of the processing flow to cope with complex business rules.

[0075] (3) Determine the atomic action identifiers to be executed and their execution order based on the effective execution path; record the atomic action identifiers to be executed as the target atomic action identifiers.

[0076] Execution order refers to the order in which atomic actions are executed, determined by the topology of the valid execution path. For nodes in a graph without sequential constraints, their order can be parallel.

[0077] The target atomic action identifier refers to the action identifier of the atomic action that ultimately needs to be executed in this round of requests.

[0078] In this step, the processing center performs topological sorting on the effective execution paths (a directed acyclic graph), which yields a linear or parallel sequence of atomic action identifiers, i.e., the execution order. Simultaneously, all atomic action identifiers in this sequence are collected, forming the set of atomic action identifiers to be executed, and this set is recorded as the target atomic action identifier for this scheduling.

[0079] This step transforms the graph-based path into a well-defined, actionable sequence of tasks. This crucial step bridges the gap between the preceding and following steps, translating the intelligent decision-making result (the effective path) into a work list (task sequence) that the execution engine can directly understand, providing precise input for subsequent task instantiation.

[0080] (4) Create a corresponding action instance for the target atomic action identifier. The action instance includes the action instance identifier and the instance input parameter information determined according to the business data.

[0081] An action instance refers to a specific execution task of an atomic action within a particular business request. It is the runtime manifestation of an atomic action template.

[0082] An action instance identifier is a globally unique identifier (such as a UUID) generated for each action instance, used to track the lifecycle of that instance throughout the system.

[0083] Instance input parameter information refers to the specific input parameter values ​​required for the execution of this instance, generated based on the input parameter structure information in the business data and related atomic action registration information.

[0084] In this step, for each target atomic action identifier in the target atomic action identifier list, the processing center performs the following operations: First, generate a unique action instance identifier (e.g., instance_001). Next, based on the input parameter structure information in the action registration information related to the target atomic action identifier (which can be obtained from the atomic action registry), specific parameter values ​​are extracted, transformed, or mapped from the business data to form instance input parameter information (for example, for the "open an account" action, the input parameter is {"userId": "U123"}). Finally, the target atomic action identifier, action instance identifier, and instance input parameter information are encapsulated into an action instance object.

[0085] This step completes the instantiation process from abstract actions to concrete executable tasks. By generating unique identifiers and binding real-time parameters, each execution is made independent, traceable, and context-complete. This provides the necessary data support for subsequent precise invocation, independent monitoring, and failure retries.

[0086] (5) Generate an execution plan based on the execution order and action instances.

[0087] In this step, the processing center can organize all currently created action instances into an ordered list (or a graph structure that preserves dependencies) according to the determined execution order. This structure is the final execution plan. This plan typically also includes metadata about the plan, such as the plan ID, generation timestamp, and associated business request ID.

[0088] This step produces the final result of scheduling: a definite, unambiguous, and immediately executable work instruction. The execution plan ensures that the execution engine strictly follows the preset logic and parameters, achieving efficient and reliable decoupling between decision-making and execution.

[0089] In some embodiments, such as Figure 4 As shown, this method also includes steps S310-S330, and each step is described in detail below.

[0090] S310: Define the business logic unit that implements the predefined interface as an atomic action.

[0091] A predefined interface refers to a programming interface specification (such as a JavaInterface or a function with a specific signature convention) uniformly defined and provided by the intelligent processing center system. It specifies the methods that any business logic must implement in order to become a system-schedulable atomic action, such as an interface containing the execute(Context context) and rollback(Context context) methods.

[0092] A business logic unit refers to an independent code module that already exists in the system and is used to complete a specific business function. For example, a Java class that is responsible for calling a remote service to open an account, a function that sends an SMS message, or a stored procedure that updates the database.

[0093] In this step, when developers implement a specific business function (such as "user credit limit adjustment"), they create a new class (e.g., AdjustCreditLimitAction). For this function to be recognized and scheduled by the processing center, this class must implement the predefined interface provided by the processing center (e.g., the AtomicAction interface) and complete the specific logic of the core methods defined in the interface (e.g., execute and rollback). Once this class is written, compiled, and deployed to the system classpath, the processing center treats it as an atomic action. For example, after implementing the execute method (which includes the logic of calling the credit limit system RPC), the AdjustCreditLimitAction class is defined as an atomic action marked ADJUST_CREDIT_LIMIT.

[0094] This step, by mandating the implementation of a predefined interface, provides a unified abstraction layer and execution contract for all heterogeneous business functions (such as local functions and remote calls). This standardizes and normalizes business logic, enabling the system to manage and schedule diverse business operations in a consistent manner, laying the foundation for building a unified scheduling platform.

[0095] S320: Creates standardized action registration information for each atomic action.

[0096] Action registration information refers to a structured data object that describes all the metadata of an atomic action. Action registration information includes atomic action identifier, action type, input parameter structure information, output parameter structure information, action execution logic entry information, action compensation logic entry information, and retry logic configuration information.

[0097] Action type is a classification of the nature of atomic action business, such as "account operation", "notification", "list management", "data reporting", etc., which is used to assist in management and statistics.

[0098] Input parameter structure information refers to the constraints, such as the name, type, and whether it is required, of the input parameters needed to execute related atomic actions, defined in schema form. For example, JSONSchema can be used to describe {“userId”:“string”,“amount”:“number”}.

[0099] Output parameter structure information refers to the standard output structure after the execution of related atomic actions defined in the form of a pattern, such as {"success":"boolean","data":"object","message":"string"}.

[0100] The action execution logic entry point information is an identifier pointing to the specific business logic unit that implements the predefined interface. In Java applications, this is usually a fully qualified class name (such as com.abc.action.AdjustCreditLimitAction); in a microservice architecture, it may be a service name or an API endpoint URL.

[0101] The action compensation logic entry information is an identifier pointing to the rollback or compensation logic implementation unit corresponding to the relevant atomic action, and its format is the same as the execution logic entry information.

[0102] Retry logic configuration information is used to define the retry strategy when related atomic actions fail. It typically includes the maximum number of retries, retry interval (such as fixed interval or exponential backoff), and the exception type that triggers the retries.

[0103] In this step, when the processing center initiates or detects a new action, it automatically scans the classpath to find all classes that implement the predefined interface. For each such class, the processing center reads its annotations or associated configuration files to extract or generate its action registration information. For example, it obtains the atomic action identifier and action type from the `@Action(id="ADJUST_LIMIT", type="ACCOUNT")` annotation; generates input / output parameter structure information from the `@Param` annotation; uses the class name itself as the entry point for the action execution logic; and reads retry logic configuration information from the `@RetryPolicy` annotation. Subsequently, the module populates this information into a standard structure (such as a POJO or JSON object), completing the creation of the action registration information.

[0104] This step creates complete, self-describing metadata for each atomic action. The input and output parameter structures enable the processing center to perform parameter verification and binding during action orchestration; the execution logic entry point and compensation entry point information of the atomic action provide precise call location; and the retry strategy provides a basis for fault tolerance. This allows for refined, declarative management of business actions, transforming them from a piece of code into a standardized component within the system that can be clearly understood, configured, and controlled.

[0105] S330: Store the registration information for each action in a specified data table to form an atomic action registry.

[0106] A specified data table refers to a relational database table or document collection in a system database (such as MySQL) or key-value store that is specifically designed to persistently store action registration information.

[0107] The atomic action registry is a collection and index of all registered action registration information in memory and persistent storage.

[0108] In this step, the processing center serializes (e.g., converts to a JSON string) the action registration information created for each atomic action in the previous steps, and then persists (e.g., via insert or update) it to a designated table in the database. This table uses the atomic action identifier as the primary key. Simultaneously, the processing center maintains a cached index of all registration information in system memory (e.g., a ConcurrentHashMap) to provide high-performance queries. This unified action metadata repository, comprised of persistent storage and memory caching, is the atomic action registry. During the processing center's operation, the execution engine can query this table to locate the specific business logic implementation.

[0109] This step establishes a system-level atomic action capability center (registry) through centralized and persistent storage. This enables newly launched atomic actions to be automatically discovered and loaded by the system (hot registration), and also allows for unified management of action metadata changes; ensuring that abstract action identifiers can be accurately mapped to specific code implementations.

[0110] In some embodiments, the execution plan includes multiple action instances and, for each action instance, a target atomic action identifier, an action instance identifier, instance input parameter information, and execution control information. The execution plan is used to execute the business logic corresponding to each target atomic action identifier, including: (1) Query the preset atomic action registry based on the target atomic action identifier, and record the found action registration information as the target action registration information.

[0111] In this step, the target action registration information refers to the action registration information uniquely corresponding to the target atomic action identifier, which is retrieved from the atomic action registry based on the identifier of the target atomic action to be executed.

[0112] In this step, the processing center uses the execution engine to process each action instance in the execution plan sequentially. For each action instance, the execution engine reads its associated target atomic action identifier (e.g., "CREATE_ACCOUNT"). The engine then uses this identifier as the key to query the atomic action registry. The atomic action registry performs a matching lookup in its memory cache or persistent storage, returning the complete metadata object corresponding to that identifier, i.e., the target action registration information. This information contains all execution elements of the action, such as the execution entry point, parameter format, retry strategy, etc.

[0113] This step establishes a mapping from abstract action identifiers to specific execution tasks by performing a centralized query before action execution. This achieves complete decoupling between scheduling logic and business implementation logic. The execution engine doesn't need to concern itself with the specific implementation of "CREATE_ACCOUNT"; it only needs to retrieve the relevant target action registration information based on the action identifier and execute the action according to the specific information in the registration information. This greatly improves the system's modularity and maintainability. When the implementation code of an atomic action changes or is even replaced, only its registration information in the registry needs to be updated, without modifying the scheduling engine itself.

[0114] (2) Execute the corresponding business logic based on the target action registration information.

[0115] In this step, business logic refers to the specific, executable code unit or service interface pointed to by the action execution logic entry information in the target action registration information.

[0116] In this step, after obtaining the target action registration information, the execution engine extracts the action execution logic entry point information (e.g., the fully qualified name of a Java class, com.xx.service.AccountService). Next, the execution engine uses reflection, a service factory, or dynamic proxies to locate and instantiate the actual business logic processor object based on this entry point information. Then, the execution engine retrieves the instance input parameter information from the current action instance and adapts and validates it according to the input parameter structure defined in the target action registration information. Finally, the execution engine calls the execution method of the business logic processor, passing in the adapted parameters, thereby completing the actual execution of this atomic action. The call result (such as success, failure, or output data) will be recorded and fed back to the status monitoring and compensation module of the processing center.

[0117] This step ensures the accuracy (accurate location via entry point information) and reliability (guaranteeing the call contract through parameter format adaptation) of action execution through a standardized, registration-based execution mechanism. This standardized execution mode enables the system to drive hundreds or thousands of different backend services or functions securely and efficiently in a unified manner, achieving standardization and automation of the execution process and providing a solid foundation for stable system operation and large-scale expansion. Simultaneously, since all calls pass through this unified path, it also provides a unified approach for subsequent end-to-end monitoring, consistency assurance, and fault diagnosis.

[0118] In some embodiments, the corresponding business logic is executed based on the target action registration information, including: (1) Determine the corresponding business logic processor based on the action execution logic entry information in the target action registration information.

[0119] A business logic processor is an object instance that is dynamically located, loaded, or created by the system at runtime based on the action execution logic entry information, and is capable of actually executing business logic. It encapsulates specific business operations, such as calling RPC services or executing database transactions.

[0120] In this step, the execution engine parses the target action registration information and extracts the action execution logic entry point information. The processing center then uses appropriate technical means to determine the processor based on the format and conventions of the information extracted by the execution engine. For example: If the entry information is a Java class name, the processing center uses reflection to load the class through Class.forName() and call its constructor or obtain its instance through the dependency injection container. This instance is the business logic processor. If the entry information is a REST API address, the processing center will create an HTTP client proxy configured with that address as the business logic processor.

[0121] For example, the processing center can maintain a processor factory or service catalog, and use the entry information as a key to directly obtain pre-generated processor instances from the processor factory or service catalog.

[0122] This step enables the crucial transformation from static configuration information to dynamic executable objects. Specifically, by standardizing entry point information parsing, this step allows the processing center to adapt and integrate various technical implementations (such as local classes, remote services, and function computation) in a unified manner, greatly enhancing the system's inclusiveness and scalability. Simultaneously, standardizing the processor acquisition process isolates the specific implementation technologies of business logic, ensuring the stability and simplicity of the execution engine's core logic.

[0123] (2) Call the business logic processor based on the instance input parameter information of the action instance.

[0124] In this step, after obtaining the business logic processor object, the execution engine retrieves its instance input parameter information from the currently processed action instance and converts this information into the calling format expected by the business logic processor (e.g., mapping a JSON object to a list of parameters for a Java method). Subsequently, the execution engine calls the core execution method of the business logic processor (such as the `execute` method), passing in the converted parameters. This call process sets a timeout and handles exceptions. After the call is complete, the execution result returned by the business logic processor is received and recorded by the execution engine.

[0125] This step completes the final physical execution of atomic actions, ensuring that each scheduling accurately delivers specific data to the specific business code, guaranteeing the correctness of business processing and data consistency. The standardized calling process makes the execution process controllable and observable, providing a unified entry point for subsequent monitoring, measurement, and performance analysis. As a stable scheduling framework, the execution engine interacts with the ever-changing business logic through clear interfaces and parameter contracts, achieving a high degree of decoupling between the framework and the business logic.

[0126] In some embodiments, executing corresponding business logic based on the target action registration information further includes: (1) Use the action lifecycle table to record the execution status of action instances.

[0127] The action lifecycle table is a persistent storage table (usually located in the database) maintained by the processing center to track the state changes of all action instances from creation to termination. Each record corresponds to an action instance, and core fields include instance_id (action instance identifier), status (current status), and timestamp (status update time).

[0128] In this step, before the execution engine begins processing an action instance, the status monitoring and compensation module of the handling center inserts a record into the action lifecycle table, marked with a status of PENDING. When the business logic processor is invoked, the status is updated to RUNNING. After the call completes, if the call is successful, the status is updated to SUCCESS; if the call fails or an exception occurs, the status is updated to FAILED. If a compensation operation is subsequently triggered and successfully executed, the status is further updated to COMPENSATED. Each status change is recorded with a precise timestamp.

[0129] This step establishes a continuous digital profile for each action instance, enabling global, real-time, and visualized monitoring of the distributed, asynchronous execution process. It not only allows operations personnel to clearly understand the progress of the entire handling request but also provides the most direct and reliable decision-making basis (i.e., state-driven) for the handling center to automatically identify anomalies and trigger subsequent processes (such as retries and compensation), fundamentally improving the system's observability and maintainability.

[0130] (2) When an abnormality is detected in an action instance, the corresponding action compensation logic or retry logic is executed according to the action compensation logic entry information and retry logic configuration information in the target action registration information related to the action instance.

[0131] In this step, when the execution engine catches a call exception or finds the status to be FAILED by querying the lifecycle table, the status monitoring and compensation module of the handling center first checks the retry logic configuration information in the target action registration information. If the current number of failures does not exceed the maximum number of retries and the exception type meets the retry conditions, the status monitoring and compensation module will wait for the configured interval and then re-trigger the execution of the action instance (the status may be reset from FAILED to PENDING). If the retries exhaust the attempts and still fail, or the retry conditions are not met, the module reads the action compensation logic entry information. Based on this information, the handling center uses a method similar to obtaining the business logic processor to locate and call the action compensation logic, such as a method or service that implements a rollback operation, to restore business consistency as much as possible. After the compensation is executed, the status in the lifecycle table is updated to COMPENSATED.

[0132] This step internalizes fault tolerance and recovery mechanisms into the core capabilities of the system, rather than relying on external manual intervention. Through predefined retry strategies, the handling center can automatically respond to temporary failures (such as network jitter), increasing the probability of successful handling and system resilience. Furthermore, standardized compensation logic calls provide transactional guarantees for business operations with side effects. In the event of unrecoverable errors, automated cleanup and rollback can significantly reduce the risk of business disruption and the probability of data inconsistency.

[0133] It should be noted that, unless otherwise explicitly stated herein, the execution order of the steps included in the atomic action scheduling method based on the intelligent processing center provided in any of the above embodiments is not strictly limited, and these steps can be executed in other orders. Moreover, at least some of these steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0134] Based on the same inventive concept, this application also provides an atomic action scheduling device based on an intelligent processing center. In some embodiments, such as Figure 5 As shown, the atomic action scheduling device based on the intelligent processing center includes the following modules: The action chain determination module 110 is used to respond to a business processing request and determine the corresponding target action chain configuration information from a pre-set action chain configuration library according to the business processing request; the target action chain configuration information includes multiple atomic action identifiers and at least one conditional triggering rule; The execution plan generation module 120 is used to parse the condition triggering rules in the target action chain configuration information based on the business data in the business processing request, so as to determine the target atomic action identifier and its execution order, and generate an execution plan; The execution module 130 is used to execute the business logic corresponding to each target atomic action identifier according to the execution plan in order to complete the business processing operation.

[0135] In some embodiments, the device further includes an action chain configuration module. The action chain configuration module is configured to: receive action chain definition information input by a user through a preset action chain configuration interface; the action chain definition information includes an atomic action identifier sequence, dependency description information between atomic actions, conditional trigger rule configuration information, version number, and canary release strategy information; generate corresponding action chain configuration information based on the action chain definition information; the action chain configuration information includes an action chain identifier, conditional trigger rule, canary release ratio, version number, and effective time; and store the action chain configuration information in an action chain configuration library in the form of a configuration file.

[0136] In some embodiments, the execution plan generation module 120 is configured to: determine the logical dependencies between multiple atomic action identifiers based on the target action chain configuration information; determine the valid execution path in the logical dependencies according to the business data and the condition triggering rules in the target action chain configuration information; determine the atomic action identifiers to be executed and their execution order according to the valid execution path; record the atomic action identifiers to be executed as target atomic action identifiers; create corresponding action instances for the target atomic action identifiers, the action instances including action instance identifiers and instance input parameter information determined according to the business data; and generate an execution plan according to the execution order and action instances.

[0137] In some embodiments, the apparatus further includes an atomic action registration module. The atomic action registration module is used to define business logic units implementing predetermined interfaces as atomic actions; create standardized action registration information for each atomic action; the action registration information includes an atomic action identifier, action type, input parameter structure information, output parameter structure information, action execution logic entry information, action compensation logic entry information, and retry logic configuration information; and store each action registration information in a specified data table to form an atomic action registry.

[0138] In some embodiments, the execution plan includes multiple action instances and a target atomic action identifier, an action instance identifier, instance input parameter information, and execution control information associated with each action instance. The execution module 130 is used to query a pre-set atomic action registry based on the target atomic action identifier, record the retrieved action registration information as target action registration information, and execute corresponding business logic based on the target action registration information.

[0139] In some embodiments, the execution module 130 is specifically used to determine the corresponding business logic processor based on the action execution logic entry information in the target action registration information; and to call the business logic processor based on the instance input parameter information of the action instance.

[0140] In some embodiments, the execution module 130 is further configured to record the execution status of an action instance using an action lifecycle table; when an abnormality is detected in an action instance, to execute the corresponding action compensation logic or retry logic according to the action compensation logic entry information and retry logic configuration information in the target action registration information related to the action instance.

[0141] Specific limitations regarding the atomic action scheduling device based on the intelligent processing center can be found in the limitations of the atomic action scheduling method based on the intelligent processing center mentioned above, and will not be repeated here. Each module in the aforementioned atomic action scheduling device based on the intelligent processing center can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0142] This application also provides a computer device. In some embodiments, the computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement the atomic action scheduling method based on the intelligent processing center provided in any of the above embodiments.

[0143] In some embodiments, the internal structure diagram of a computer device may be as follows: Figure 6 As shown. The computer device includes a processor, memory, and network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores action chain configuration information, atomic action registration information, and other data; the specific stored data may also be as defined in the above method embodiments. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements an atomic action scheduling method based on an intelligent processing center.

[0144] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0145] This application also provides a computer-readable storage medium, in some embodiments of which a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, it implements the atomic action scheduling method based on the intelligent processing center provided in any of the above embodiments.

[0146] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0147] Those skilled in the art will understand that implementing all or part of the processes in the above method embodiments can be accomplished by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink, DRAM (SLDRAM), memory bus, direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0148] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0149] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. An atomic action scheduling method based on an intelligent processing center, characterized in that, The method includes: In response to a business processing request, the corresponding target action chain configuration information is determined from a pre-set action chain configuration library based on the business processing request; the target action chain configuration information includes multiple atomic action identifiers and at least one conditional triggering rule; Based on the business data in the business processing request, the condition triggering rules in the target action chain configuration information are parsed to determine the target atomic action identifier and its execution order, and an execution plan is generated; According to the execution plan, the business logic corresponding to each of the target atomic action identifiers is executed to complete the business processing operation.

2. The method according to claim 1, characterized in that, The method further includes: The system receives action chain definition information input by the user through a preset action chain configuration interface. The action chain definition information includes atomic action identifier sequence, dependency relationship description information between atomic actions, condition trigger rule configuration information, version number, and canary release strategy information. Based on the action chain definition information, corresponding action chain configuration information is generated; the action chain configuration information includes action chain identifier, conditional triggering rules, grayscale ratio, version number, and effective time; The action chain configuration information is stored in the action chain configuration library in the form of configuration files.

3. The method according to claim 1, characterized in that, The step of parsing the conditional triggering rules in the target action chain configuration information based on the business data in the business processing request to determine the target atomic action identifier and its execution order, and generating an execution plan, includes: The logical dependencies between the multiple atomic action identifiers are determined based on the target action chain configuration information. The effective execution path in the logical dependency relationship is determined based on the business data and the condition triggering rules in the target action chain configuration information. The atomic action identifiers to be executed and their execution order are determined based on the effective execution path; the atomic action identifiers to be executed are recorded as target atomic action identifiers; Create a corresponding action instance for the target atomic action identifier, wherein the action instance includes an action instance identifier and instance input parameter information determined according to the business data; An execution plan is generated based on the execution order and the action instance.

4. The method according to claim 1, characterized in that, The method further includes: Define the business logic unit that implements the predefined interface as an atomic action; Standardized action registration information is created for each atomic action; the action registration information includes atomic action identifier, action type, input parameter structure information, output parameter structure information, action execution logic entry information, action compensation logic entry information, and retry logic configuration information; The registration information for each action is stored in a designated data table to form an atomic action registry.

5. The method according to claim 4, characterized in that, The execution plan includes multiple action instances and the target atomic action identifier, action instance identifier, instance input parameter information and execution control information associated with each action instance; The step of executing the business logic corresponding to each of the target atomic action identifiers according to the execution plan includes: The target atomic action identifier is used to query the preset atomic action registry, and the retrieved action registration information is recorded as the target action registration information. Execute the corresponding business logic based on the target action registration information.

6. The method according to claim 5, characterized in that, The step of executing the corresponding business logic based on the target action registration information includes: Based on the action execution logic entry information in the target action registration information, determine the corresponding business logic processor; The business logic processor is invoked based on the instance input parameter information of the action instance.

7. The method according to claim 5, characterized in that, The step of executing the corresponding business logic based on the target action registration information further includes: The execution status of the action instance is recorded using an action lifecycle table; When an anomaly is detected in the action instance, the corresponding action compensation logic or retry logic is executed according to the action compensation logic entry information and retry logic configuration information in the target action registration information related to the action instance.

8. An atomic action scheduling device based on an intelligent processing center, characterized in that, The device includes: The action chain determination module is used to respond to a business processing request and determine the corresponding target action chain configuration information from a pre-set action chain configuration library according to the business processing request; the target action chain configuration information includes multiple atomic action identifiers and at least one conditional triggering rule; The execution plan generation module is used to parse the condition triggering rules in the target action chain configuration information based on the business data in the business processing request, so as to determine the target atomic action identifier and its execution order, and generate an execution plan; The execution module is used to execute the business logic corresponding to each of the target atomic action identifiers according to the execution plan, so as to complete the business processing operation.

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

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 7.

Images