Task orchestration method, apparatus, device, medium, and program product

Abstract

The embodiment of the present application discloses a task scheduling method, device, equipment, medium and program product, wherein the task scheduling method comprises the following steps: determining a task plan chain corresponding to a to-be-processed task; the task plan chain comprises at least two subtasks corresponding to the to-be-processed task and an execution order of the at least two subtasks; determining an atomic script corresponding to each subtask in the at least two subtasks in a preset script library; the atomic script is a preset minimum execution unit of a database language; executing the atomic script corresponding to each subtask according to the task plan chain in sequence, and obtaining data corresponding to each subtask in a database.

Description

Technical Field

[0001] This application belongs to the field of database processing technology, and in particular relates to a task orchestration method, apparatus, device, medium and program product. Background Technology

[0002] Currently, all database-related computational logic is hard-coded into Java source files. When the business rules corresponding to task processing change—for example, adjusting calculation formulas, adding calculation dimensions, or modifying thresholds—the source code must be modified, recompiled, repackaged, and then fully deployed to update the task. This tightly coupled design pattern prevents the system from supporting hot updates or dynamic configurations. Even minor adjustments to business logic within a task require triggering the entire software development lifecycle, significantly reducing the system's responsiveness and agility, making it difficult to adapt to application scenarios with frequent changes in business rules. Summary of the Invention

[0003] This application provides a task orchestration method, apparatus, device, medium, and program product.

[0004] This application provides a task orchestration method, the method comprising: Determine the task plan chain corresponding to the task to be processed; the task plan chain includes at least two subtasks corresponding to the task to be processed and the execution order of the at least two subtasks; In a preset script library, determine the atomic script corresponding to each of the at least two subtasks; the atomic script is a preset minimum execution unit of the database language. The atomic scripts corresponding to each subtask are executed sequentially according to the task schedule chain, and the data corresponding to each subtask is retrieved from the database.

[0005] This application provides a task orchestration apparatus, the apparatus comprising: A processing module is used to determine the task plan chain corresponding to the task to be processed; the task plan chain includes at least two sub-tasks corresponding to the task to be processed and the execution order of the at least two sub-tasks; The determination module is used to determine the atomic script corresponding to each of the at least two subtasks from a preset script library; the atomic script is a preset database language minimum execution unit. The execution module is used to execute the atomic scripts corresponding to each subtask in sequence according to the task plan chain, and to retrieve the data corresponding to each subtask from the database.

[0006] This application provides an electronic device, which includes a processor and a memory for storing computer programs capable of running on the processor; wherein, The processor is used to run the computer program to perform any task orchestration method.

[0007] This application provides a computer storage medium storing a computer program that, when executed by a processor, implements any task orchestration method.

[0008] This application provides a computer program product, including a computer program that, when executed by a processor, implements any task orchestration method.

[0009] This application provides a task orchestration method, apparatus, device, medium, and program product. By pre-setting atomic scripts in a pre-defined script library, a task plan chain for the task to be processed is determined. Based on the task plan chain, the atomic script corresponding to each subtask is directly determined in the pre-defined script library. By executing the atomic scripts of each subtask sequentially according to the task plan chain, the processing of each subtask in the task to be processed can be achieved based on the execution of the atomic scripts. It can be seen that by decomposing the task to be processed into subtasks for execution, the logic originally coupled to the stored procedure can be decomposed. When a subtask in the task to be processed changes, such as when a business rule changes, only the corresponding atomic script needs to be modified, without redeploying the entire source code. This improves the system's response speed and agility, reduces the development cycle, and is more suitable for task processing scenarios with frequent changes in business rules. Attached Figure Description

[0010] Figure 1 This is a flowchart of a task orchestration method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a method for determining a task plan chain based on a task template, provided in an embodiment of this application. Figure 3 This is a schematic diagram of a task state machine provided in an embodiment of this application; Figure 4 This is a flowchart of another task orchestration method provided in an embodiment of this application; Figure 5 This is a schematic diagram of an orchestration system provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a task orchestration device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] Assets Under Management (AUM) is a common key metric for measuring business scale in the economics and management field. Employee performance evaluation and customer asset calculation are important scenarios in AUM management systems, often involving complex calculations of massive amounts of data. Traditional implementations heavily rely on database stored procedures. For example, in an employee asset portfolio management system, AUM performance evaluation and performance scoring of employees need to be performed based on multiple indicators such as account opening, compliance, and transaction metrics. Currently, related businesses involve hundreds of indicators, which are categorized into primary, secondary, and other levels based on business value. Furthermore, different branches have regional and resource differences, requiring personalized settings for the conversion coefficients of each indicator. In traditional solutions, these calculation logics are typically encapsulated in a large Oracle database stored procedure and executed all at once within the database.

[0013] In traditional stored procedure-based computational solutions, developers hardcode all computational logic (such as compliance score calculation and performance bonus rules) into the stored procedure code within the database. For complex computational scenarios, this stored procedure code typically reaches hundreds of lines. The application layer calls the stored procedure name and input parameters, the database engine loads the entire process, executes it all at once, and returns the processing result. The code logic in this implementation is usually strongly bound to the syntax of a specific database, such as Oracle's Procedural Language (PL) or Structured Query Language (SQL).

[0014] It can be seen that the above-mentioned stored procedure-based calculation scheme has the following drawbacks: Since most current domestic databases do not support or fully support Oracle's PL / SQL syntax, existing stored procedures cannot be directly migrated, requiring rewriting the database language code, resulting in extremely high transformation costs. Furthermore, this method directly consumes the database server's Central Processing Unit (CPU) and memory resources within the stored procedure. During large-scale task processing (such as calculating employee performance), it is highly susceptible to database memory overflow (OOM) or table locking, affecting the stable operation of the core transaction system. In addition, when business rules are tightly coupled within the stored procedure, it leads to poor readability of the stored code and difficulties in compilation and debugging. Changes in task-related parameters require rewriting the code, resulting in a long processing cycle.

[0015] It can be seen that due to the differences in the indicators selected by different employees (such as investment advisors and private finance staff) and different branches, the personalized calculation logic of each branch leads to significant differences in the scoring logic. Traditional solutions are difficult to dynamically combine various logics, and usually require writing independent code for each processing sequence, resulting in low reusability.

[0016] In traditional Java-based full-scale computation logic implementations, business rules, data processing flows, and calculation formulas are typically embedded entirely within the Java application code. This process directly writes the computation logic within the method bodies of Java classes, using compiler checks to ensure its correctness. In practice, strategy or factory patterns are often used to organize different computation branches. For example, different implementation classes are defined for different business scenarios, providing unified computation services through interfaces. The data flow process is entirely handled by Java's collection framework, streaming application programming interfaces (APIs), and custom entity classes. After obtaining raw data from the data source, all transformation, aggregation, and computation operations are completed in memory, and the results are ultimately persisted or returned to the caller.

[0017] As can be seen, while implementing all computational logic based on Java code offers advantages in compilation security and execution efficiency, this approach still suffers from the following drawbacks when dealing with complex business scenarios: 1. Rigid business logic and poor scalability: All computational logic is hard-coded into Java source files. When business rules change, such as adjusting calculation formulas, adding calculation dimensions, or modifying threshold conditions, the source code must be modified and recompiled before full deployment. This tightly coupled design pattern cannot support hot updates or dynamic configurations. Even minor adjustments to business logic require triggering the entire software development lifecycle, significantly reducing system responsiveness and agility, making it difficult to adapt to application scenarios with frequent changes in business rules. 2. High code complexity and huge maintenance costs: AUM calculations typically involve a large number of metrics. The metrics and calculation formulas selected for assessment by different branches vary, and the calculations for each branch's assessment scheme are personalized and highly complex, resulting in verbose Java code. This highly coupled logical structure makes the code extremely difficult to read and maintain. Developers need to spend a lot of effort to trace the code path when troubleshooting calculation errors or understanding business processes. Furthermore, the logic of different computing scenarios is intertwined, and modifying one piece of logic may affect other business branches, increasing the difficulty of test coverage and quality assurance. 3. Insufficient reusability and generality: This solution deeply binds the computing logic to specific technical implementation details (such as data source type, interface protocol, etc.), making it difficult for the computing module to be reused independently outside the current system. If the same computing capabilities need to be reused in other business scenarios or systems, the relevant code must be copied and adapted. At the same time, the hard-coded logic cannot support dynamic rule combinations or user-defined computing requirements, limiting the system's generality and flexibility, and failing to meet the differentiated computing needs of multiple scenarios and users.

[0018] To overcome the problems existing in related technologies, embodiments of this application provide a task orchestration method, apparatus, device, medium, and program product. Through distributed task orchestration computing, task processing and computation logic are decoupled from the database, achieving high-performance and highly flexible database computing through a combination of scripting and queuing.

[0019] The embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the embodiments provided herein are merely illustrative of the embodiments of this application and are not intended to limit the embodiments of this application. Furthermore, the embodiments provided below are some embodiments for implementing this application, and not all embodiments for implementing this application. Unless otherwise specified, the technical solutions described in the embodiments of this application can be implemented in any combination.

[0020] It should be noted that, in the embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a method or apparatus that includes a list of elements includes not only the elements expressly described, but also other elements not expressly listed, or elements inherent to implementing the method or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of other related elements in the method or apparatus that includes that element (e.g., steps in the method or units / modules in the apparatus; for example, units / modules in the apparatus may be portions of circuitry, processors, programs, or software, etc.).

[0021] The task orchestration method provided in this application includes a series of steps, but the task orchestration method provided in this application is not limited to the steps described. Similarly, the task orchestration device provided in this application includes a series of modules, but the device provided in this application is not limited to the modules explicitly described, but may also include modules that need to be set for obtaining relevant information or processing based on information.

[0022] Figure 1 A flowchart of a task orchestration method is shown. This method can be applied to orchestration systems and can use a domestically developed database as the underlying storage. This domestically developed database is responsible for persistent data storage and basic SQL querying. Domestically developed databases include, but are not limited to, PostgreSQL-compatible databases, DM, Kingbase, OceanBase, etc. Figure 1 As shown in the embodiments of this application, the task orchestration method includes: Step 101: Determine the task schedule chain corresponding to the task to be processed.

[0023] The task schedule chain includes at least two subtasks corresponding to the task to be processed and the execution order of the at least two subtasks.

[0024] In this embodiment, the task to be processed can be split based on a preset splitting template, task processing dimensions, etc., to obtain at least two sub-tasks. The at least two sub-tasks are then arranged according to a preset order or causal relationship between the sub-tasks to obtain a task plan chain for the task to be processed. For example, for task A, the decomposed task plan chain can be "sub-task 1 - sub-task 2 - sub-task n", and the task is executed using the sub-tasks in the task plan chain as units.

[0025] For example, before determining the task schedule chain, the processing objective of the task to be processed can be determined. Based on the processing objective, the corresponding processing dimensions are determined, and the task to be processed is broken down into at least two subtasks. Then, the attributes and causal relationships of each subtask in the at least two subtasks can be determined. Based on the attributes and causal relationships of each subtask, each subtask is sorted to determine the execution order of each subtask, thus obtaining the task schedule chain corresponding to the task to be processed.

[0026] To obtain a complete task plan chain, in some embodiments, determining the task plan chain corresponding to the task to be processed includes: determining a task template for the task to be processed based on the task to be processed; the task template is used to determine one or more of the following: the processing dimension of the task to be processed, the task indicators of the task to be processed, the processing target corresponding to the task to be processed, and the correction coefficient corresponding to the task to be processed; determining at least two sub-tasks corresponding to the task to be processed and the execution order of the at least two sub-tasks according to the task template; and determining the task plan chain corresponding to the task to be processed based on the at least two sub-tasks corresponding to the task to be processed and the execution order of the at least two sub-tasks.

[0027] In practical applications, task templates can be preset, and the tasks to be processed can be broken down using these templates to determine the task plan chain. Specifically, a task template can include one or more of the following: dimension layer, indicator layer, target layer, and coefficient layer; a task template can also include a template layer. The template layer includes the main model of the task to be processed, which can be used to identify the task type and comprehensively schedule the dimension layer, indicator layer, target layer, coefficient layer, etc.

[0028] Specifically, the dimension layer is used to predefine the processing dimensions of the task to be processed. For example, when the task is a business assessment task, the dimension layer is used to determine the assessment dimensions, such as business results and business capabilities. The indicator layer is used to predefine the various task indicators, their weights, and scoring standards for the task to be processed. For example, when the task is a business assessment task, the indicator layer is used to determine the various assessment indicators, their weights, and the scoring standards. The target layer is used to configure the processing target of the task to be processed, i.e., to determine the target value of the task. For example, it can determine the target value for different job levels and positions. When the task is a business assessment task, the number of business users corresponding to job level A and position B can be determined as an assessment indicator, with a target value of 10,000. When the target value is reached, such as the number of new business users being greater than or equal to 10,000, a corresponding score can be obtained. The coefficient layer is used to adjust various parameters and indicators based on actual conditions and regional differences, determining the adjustment coefficients for each indicator corresponding to the task to be processed.

[0029] For example, when the orchestration system is running, the configuration loading component of the orchestration system can split the task to be processed in the order of "template-dimension-metric-goal" to obtain at least two sub-tasks and build a task plan chain.

[0030] Based on the method given in this embodiment, Figure 2 A schematic diagram of a method for determining a task plan chain based on a task template is shown. The model and configuration layers in the orchestration system can send tasks to be processed to the task template configurator, where the task template configurator can define task templates. Figure 2 The document illustrates the definable elements of a task template, including template master information, dimension definitions, metric definitions, segment definitions, target definitions, correction coefficients, and execution strategies. The template master information defines the task template's processing cycle, processing scope, and the sequence type of the task plan chain (e.g., sequential sequence, parallel sequence, conditional sequence). Specifically, dimension definitions define the processing dimensions of the task, including dimension identifiers, weights of different dimensions, and constraints between dimensions. Metric definitions define the task metrics, including metric identifiers, which metrics are mandatory, the corresponding scoring methods, and metric weights. Segment definitions define the segmented scoring standards for different metric ranges. Target definitions define the processing objectives of the task. Correction coefficients define the correction coefficients for the task, including those for different regions and different sets. Execution strategies allow for customization of the task's execution strategy, including the number of retries upon failure, task timeout policies, and concurrency strategies.

[0031] Next, the task to be processed can be structured based on one or more of the above task templates. Through template validation and versioning, the structured processing result of the task to be processed is verified and the version representation is determined, generating an executable task plan chain. Finally, the output task plan chain contains the execution steps of at least two ordered subtasks. Each subtask's corresponding steps can include one or more of the following: step identifier (ID), corresponding atomic script ID, step IDs that the current step depends on (i.e., step IDs that have a causal relationship with the current step), output result reference relationships, rollback and retry strategies, etc.

[0032] It can be seen that by determining the task plan chain corresponding to the task to be processed, the task to be processed can be split into at least two ordered sub-tasks. In practical applications, the splitting method of the task to be processed can be determined based on actual needs, task objectives, etc., and the execution order or execution method of each sub-task can be determined.

[0033] Step 102: Determine the atomic scripts corresponding to each subtask in at least two subtasks from the preset script library.

[0034] Among them, atomic scripts are the minimum execution units of the database language.

[0035] In this embodiment, the orchestration system includes a preset script library, which stores independent SQL fragments, i.e., atomic scripts. Specifically, the preset script library may include template scripts, step scripts, parameterized fragments, and version information. The preset script library can support script rollback and canary implementation. Script rollback can restore a modified atomic script to its state before the change if the script fails to execute. Canary implementation can make the updated atomic script only effective for preset users or under preset conditions.

[0036] Each atomic script in the pre-defined script library is used to implement a pre-defined function. For example, atomic script 1 is responsible for calculating the "compliance score," atomic script 2 is responsible for calculating the "account opening score," and atomic script n is responsible for calculating the "investment advisor performance," etc. By setting up the pre-defined script library, the orchestration system front-end or configuration center can no longer implement data processing or business logic by writing stored procedures. Furthermore, by combining it with a visual configuration interface, it can directly execute tasks to be processed without writing code.

[0037] During the construction of the pre-defined script library, general logic for task processing or database processing (such as compliance processing logic) and personalized logic (such as specific rules for investment advisors) can be atomically processed and split into independent scripts for storage, resulting in atomic scripts in the pre-defined script library. Simultaneously, metadata tags corresponding to each atomic script can be recorded, and the function of the atomic script can be determined based on these metadata tags to enable its invocation. After determining the atomic script corresponding to each subtask, the orchestration system can maintain the mapping relationship between each subtask and the target atomic script.

[0038] Step 130: Execute the atomic scripts corresponding to each subtask in sequence according to the task schedule chain, and retrieve the data corresponding to each subtask from the database.

[0039] After selecting the atomic scripts corresponding to subtasks from the preset script library, the atomic scripts corresponding to each subtask can be executed sequentially based on the order of each subtask in the task schedule chain and the mapping relationship between each subtask and the atomic script. Data for each subtask is retrieved from the database, and the execution result for each subtask is obtained, ultimately yielding the execution result of the task to be processed. Based on the above example, when the task schedule chain is "Subtask 1 - Subtask 2 - Subtask n", the execution order of the atomic scripts can be obtained as: "Subtask 1 (execute atomic script 1) - Subtask 2 (execute atomic script 2) - Subtask n (execute atomic script n)".

[0040] In practical applications, the orchestration system's computation engine can break down task processing into standard pipeline nodes according to the execution order of each subtask. It loads the atomic scripts corresponding to each subtask sequentially according to the task schedule chain; for example, it loads atomic script 1 corresponding to subtask 1 first. The computation engine enables pipelined computation of multi-source data fusion, supporting different sequences and allowing for the reuse of a unified architecture across various scenarios such as investment consulting, retail, and institutional applications. In specific applications, only the scenario data and indicator configurations need to be replaced.

[0041] Specifically, the computing engine can send the atomic scripts of subtasks to the domestic IT database for execution. Based on these atomic scripts, the domestic IT database only needs to handle simple SQL queries, without handling complex logical calculations. After executing the atomic script of a subtask, the orchestration system can update its current execution status, such as marking "Subtask 1 completed," and store the execution result of Subtask 1. Then, based on the task schedule chain, the atomic script corresponding to the next subtask of Subtask 1 can be retrieved and executed.

[0042] After all the atomic scripts corresponding to the subtasks of the pending task have been executed, the execution results of each subtask can be summarized to obtain the execution result of the pending task.

[0043] This application provides a task orchestration method that improves database execution efficiency by breaking down complex database processing logic into independent atomic scripts and storing them as a pre-defined script library. By determining the task schedule chain for the tasks to be processed and executing the atomic scripts of each subtask sequentially based on the task schedule chain, the pressure on the database CPU and storage is reduced. This application manages subtasks through task schedule chains, shifting processing pressure from the database layer to the application layer, reducing the risk of database memory overflow and facilitating large-scale asynchronous computing. By executing the atomic scripts corresponding to the task schedule chain, when adjustments to the task processing logic are needed, only the atomic scripts of the corresponding sub-steps need to be modified, eliminating the need to redeploy the entire source code, reducing the development cycle, and effectively improving task processing speed.

[0044] In practical applications, steps 101 to 103 can be implemented based on a processor, which can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor.

[0045] To ensure consistency of the results of the tasks to be processed, in some embodiments, before determining the task plan chain corresponding to the task to be processed, the method further includes: determining a unique identifier for the task to be processed; the execution of the atomic scripts corresponding to each subtask in sequence according to the task plan chain includes: determining whether there are conflicting subtasks that are currently being executed, waiting to be executed, or have been completed, based on the unique identifier of the task to be processed; a conflicting subtask represents the subtask corresponding to the unique identifier; if there are no conflicting subtasks, the atomic scripts corresponding to each subtask are executed in sequence according to the task plan chain.

[0046] In some embodiments, when conflicting subtasks exist, the above method further includes instructing the pending task to wait for execution or to report an error.

[0047] When determining the task to be processed, a unique identifier for that task can be identified. Then, based on the above embodiments, after identifying at least two subtasks of the task to be processed, the unique identifier of the task to be processed can be used as the unique identifier for each subtask, or as the unique identifier for the task plan chain. To further distinguish subtasks within the same task to be processed, a subtask identifier for each subtask can also be determined. Based on the unique identifier and subtask identifier for each subtask, the relationship between subtasks can be determined, and each subtask can be effectively identified. In this way, during task execution, it is possible to determine which subtasks belong to the same task plan chain, which helps to obtain the result of the task to be processed based on the result of each subtask.

[0048] In order to prevent duplicate processing of the same task when determining the unique identifier of the task to be processed and executing the subtasks of the task to be processed, in this embodiment, before executing each subtask, it can be determined whether there are conflicting subtasks, that is, whether there are currently the same subtasks being executed. Especially when the task plan chain is executed sequentially, it can be determined whether conflicting subtasks are stored first, and then it can be determined whether to execute the subtasks in the task plan chain.

[0049] For example, in a sequentially executed task schedule chain, before executing subtask 2, it is determined whether the unique identifier corresponding to the currently executing subtask 1 is consistent with the unique identifier corresponding to subtask 2. Alternatively, it is determined whether the unique identifier corresponding to subtask 3 waiting to be executed in the current message queue is consistent with the unique identifier of subtask 2; or, it can be determined from the processing results of the subtasks that there exists a processing result for a subtask that is consistent with the unique identifier corresponding to subtask 2. When any of the above situations exist, such as a subtask corresponding to a currently executing unique identifier, or a subtask corresponding to a unique identifier waiting to be executed in the message queue, the task to be processed (i.e., the subtask of the task to be processed) can be instructed to wait for execution. Alternatively, when there are processing results for the same subtask, the subtask of the task to be processed can be instructed to wait for execution, or the next subtask can be executed, or an error can be reported.

[0050] When there are no conflicting subtasks, the subtasks of the pending task can be executed in sequence.

[0051] Specifically, the unique identifier of a task to be processed can be determined based on one or more of the following: task identifier, task content, task cycle, application scenario, and task affiliation. Before the orchestration system's computing engine calculates each subtask sequentially, an idempotency check can be performed based on the unique identifier of the task to be processed. If no conflicting subtasks are found, the subtasks to be executed can continue to be executed sequentially.

[0052] In practical applications, idempotency can be determined at the initial stage of task creation to avoid duplicate creation of task schedule chains. In some embodiments, before determining the task schedule chain corresponding to the task to be processed, the method further includes: determining a unique identifier for the task to be processed; determining, based on the unique identifier, whether there is currently an executing task corresponding to the unique identifier; determining the task schedule chain corresponding to the task to be processed includes: determining the task schedule chain corresponding to the task to be processed when there is currently no executing task corresponding to the unique identifier.

[0053] Before creating a task schedule chain, a unique identifier for a task to be processed can be determined based on one or more of the following: task identifier, task content, task cycle, application scenario, and task affiliation. In this embodiment, the method for determining the unique identifier of each task to be processed is consistent. For example, in practical applications, the unique identifier of a task to be processed can be determined uniformly based on the task identifier, task content, task cycle, application scenario, and task affiliation to ensure that the unique identifier of the same task is consistent.

[0054] Subsequently, it can be determined whether there is an ongoing task that matches the unique identifier of the task to be processed. For example, it can be determined whether there is a conflicting subtask based on the method described in the above embodiments. If a conflicting subtask exists, it is assumed that the same task is currently being processed or has been completed. In this case, the task schedule chain for the task to be processed will not be created, that is, the task to be processed will not be executed.

[0055] If there is no currently processing task corresponding to the unique identifier, i.e. there are no conflicting subtasks, a task schedule chain of pending tasks can be created and the pending tasks can be executed.

[0056] For example, upon receiving a task request, the model and configuration layers of an orchestration system first verify the task's unique identifier and then perform idempotency checks based on this identifier. If a task corresponding to the unique identifier already exists and is being processed, the model and configuration layers can refuse to create a duplicate task or task schedule chain. If no task corresponding to the unique identifier exists and is being processed, the model and configuration layers create the task and task schedule chain corresponding to the unique identifier.

[0057] Furthermore, in some embodiments, the above-mentioned execution of the atomic scripts corresponding to each subtask according to the task schedule chain and the acquisition of data corresponding to each subtask from the database includes: determining the first subtask to be executed among at least two subtasks according to the task schedule chain; reading the task context corresponding to the task to be processed, executing the atomic scripts corresponding to the first subtask based on the task context, and acquiring the first data corresponding to the first subtask from the database; the task context includes at least one or more of the following: the subtask identifier of the completed subtask, the subtask identifier of the first subtask, and an intermediate result table; the intermediate result table is used to record the execution results of the completed subtasks.

[0058] After obtaining the first data corresponding to the first subtask, in some embodiments, the above method further includes: obtaining the first execution result corresponding to the first subtask based on the first data; and recording the first execution result in an intermediate result table.

[0059] In some embodiments, the task context may further include a snapshot of each subtask, the execution status of the task schedule chain, and an identifier of the execution result of each subtask. The task context may also include the task batch to which the pending task belongs. In the event of execution failure of a pending task, the task context may also record the reason for the failure. Based on the task context, the association between pending tasks and their execution results can be preserved, and task processing traceability can be supported according to time sequence, the affiliation of pending tasks, etc.

[0060] Based on the method described in the above embodiments, after determining the unique identifier and the task plan chain for creating the task to be processed, a global task ID and a result ID corresponding to the task to be processed can be created, and the task status record table (TSCENE_STATUS) and the intermediate result table (TSCENE_DONE_RESULT) can be initialized. The global task ID identifies the global execution result corresponding to the task to be processed, and the result ID identifies the execution result of each subtask in the task to be processed. The task status record table can be used to record the generated task plan chain and its execution status, including the task processing status of the task to be processed, the number of executions, etc. The task status record table can also record the subtask identifiers of completed subtasks and the subtask identifiers of currently pending subtasks (such as the first subtask). The intermediate result table is used to record the execution result of each subtask of the task to be processed and the identifier of each subtask's execution result. The intermediate result table can also record relevant remarks about the task to be processed, the number of rows of recorded data, the task processing duration, the task processing batch number, and snapshots corresponding to each subtask, etc. The snapshot for each subtask may include a snapshot of the atomic script for each subtask, as well as a snapshot of the input parameters for each subtask.

[0061] The intermediate result table and task status record table can be passed based on the task context of the task to be processed. The task status record table enables queuing, retries, failure write-back, and progress queries for each subtask within the task to be processed.

[0062] After processing and obtaining the execution results of the subtasks, these results can be recorded in an intermediate result table. Specifically, after determining the first subtask to be executed based on the task schedule chain, the task context recorded in the orchestration system can be obtained. Based on the subtask identifiers of completed subtasks within the task context, the execution results of those completed subtasks can be retrieved, and the first subtask can be executed based on these results. Alternatively, when the first subtask has a causal relationship with already completed subtasks, and the first subtask depends on the execution results of the completed subtasks, the execution results of the corresponding completed subtasks can be obtained from the intermediate result table of the task context. The first subtask can be any subtask among the tasks to be processed.

[0063] In practical applications, after generating task schedule chains, the orchestration system can add these chains to a message queue, achieving asynchronous decoupling between task orchestration and the computation engine. The orchestration system can be configured with a queue management module. This module can trigger a backpressure mechanism based on factors such as database server memory usage, thread pool load, database connection pool load, and task priority, preventing memory thrashing and database errors caused by concentrated task processing.

[0064] Then, following the execution order of each subtask in the task schedule chain, the task context is read first to determine the execution status of the first subtask, the first subtask is bound to the corresponding atomic script, the atomic script corresponding to the first subtask is executed, the first execution result of the first subtask is obtained, the first execution result is verified, and if the verification passes, the first execution result is recorded in the intermediate result table.

[0065] During the execution of the first subtask, the identifier of the atomic script corresponding to the first subtask can be determined first. Based on this identifier, the atomic script corresponding to the first subtask is loaded, and the task context is input. The atomic script corresponding to the first subtask is executed based on the task context to obtain the first execution result, which is recorded in the intermediate result table. Afterward, the subtask identifier of the currently pending subtask can be updated, and the subtask identifiers of completed subtasks and pending subtask identifiers in the task context can also be updated.

[0066] In some embodiments, the method further includes: after each of the at least two subtasks has been executed, obtaining the execution result of each of the at least two subtasks based on an intermediate result table; and obtaining the execution result of the task to be processed based on the execution result of each subtask.

[0067] In this embodiment, after all subtasks of the task to be processed have been executed, the computing engine can aggregate the execution results of all subtasks to obtain the execution result of the task to be processed, and write all results into the result table or trigger a notification of completion. Specifically, after each subtask in at least two subtasks has been executed, the computing engine can call back the execution result of each subtask and update the task status record table and intermediate result table to record the completion time, processing time, number of lines executed, and abnormal situations of the task to be processed.

[0068] After obtaining the execution result of the task to be processed, in some embodiments, the above method further includes: after the execution of the atomic script corresponding to each subtask is completed, calling back the execution information and execution result of the task to be processed.

[0069] After the pending tasks are completed, the orchestration system can persistently store the execution results of each subtask and the pending task, and retrieve the execution information of the pending task. This execution information may include the unique identifier of the pending task, the task batch, and the task template identifier. It can establish associations between the unique identifier of the pending task, the execution result ID, the task batch, and the task template identifier, achieving end-to-end traceability.

[0070] In this embodiment, the orchestration system can also provide progress query interfaces and result query interfaces, supporting queries on task execution status and failure reasons based on task attribution information, processing cycle, application scenario type, etc., meeting auditing, recalculation, and supervision requirements. Through version management, historical templates and results can be retained in parallel, ensuring that the execution results of the same task can be reproduced based on the same version configuration and batch processing parameters. By introducing version management, the version value can be verified and incremented when updating the execution status, effectively controlling repeated task execution and concurrency conflicts. Alternatively, the repeated execution and concurrency conflicts can be controlled by introducing execution counts (e.g., the DO_TIMES field).

[0071] For example, in practical applications, the orchestration system can support multi-source data fusion when processing tasks. The input data for the task to be processed can come from task indicator detail tables, task organization statistics tables, customer dimension tables, external coefficient tables, etc. When executing relevant rules based on the task to be processed, the orchestration system can first complete the target value conversion of the processing target, then perform segmented scoring, and finally perform weight aggregation to form a hierarchical calculation of indicator score, dimension score, and total score. When scoring based on the task to be processed, the scoring function can support various segmentation rules, such as: scoring by interval, setting upper and lower limits for scores, segmenting by percentage, setting a zero score line, and mapping scores to standard scores, etc. Weight aggregation can also support flexible combinations, allowing simultaneous setting of weights at the dimension level and weights at the specific indicator level. These rules can all be defined through the configuration of the orchestration system without modifying the core code of the calculation engine. If the rules need to be adjusted, only the configuration template and atomic script version need to be updated, which can effectively reduce the risk of script updates.

[0072] In some embodiments, the above-mentioned execution of the atomic scripts corresponding to each subtask in sequence according to the task schedule chain includes: adding the task schedule chain to the message queue, and executing the atomic scripts corresponding to each subtask in sequence based on the message queue and the task schedule chain.

[0073] In this embodiment, after determining the task schedule chain, the computing engine can query the corresponding task schedule chain based on the unique identifier of the task to be processed. Then, the computing engine can encapsulate the task schedule chain into a message and add the encapsulated message to a message queue. The computing engine retrieves the task schedule chain from the message queue and executes the atomic scripts corresponding to each subtask sequentially based on the task schedule chain.

[0074] In the event that a subtask fails to execute, in some embodiments, the method further includes: if the second subtask fails to process, determining whether the second subtask needs to be re-executed; the second subtask is any one of at least two subtasks; if it is determined that the second subtask needs to be re-executed, adding the second subtask to a retry queue, and re-executing the second subtask based on the retry queue.

[0075] In this embodiment, when any subtask fails to execute, such as the second subtask failing to process, the orchestration system can record the reason for the failure of the second subtask. Since the orchestration system can save the execution results of completed subtasks based on the intermediate result table, it can re-run the process based on the second subtask, avoiding the need to reprocess the entire task to be processed.

[0076] If the second subtask fails, the reason for the failure can be determined. If the reason for the failure is due to preset conditions, the second subtask can be re-executed. These preset conditions may include, but are not limited to, any of the following: network latency, database unavailability, database lockout, server failure, etc. The orchestration system can add the second subtask to the retry queue for re-execution if it determines that the reason for the failure is due to preset conditions.

[0077] When the reason for the failure of the second subtask is not within the preset conditions, such as when the orchestration system recognizes the input data or instructions of the task to be processed as incorrect, cannot recognize them, fails permission verification, has insufficient storage space, or has a program logic error, an error message can be returned to confirm that the second subtask will not be re-executed.

[0078] For example, after a second subtask fails, the orchestration system can return a corresponding identifier code. If the failure is due to preset conditions, the orchestration system returns a retry code, the second subtask enters the retry queue, and the number of execution attempts can be increased to ensure successful execution. If the failure does not meet the preset conditions, the orchestration system returns a failure code, the second subtask is marked as failed, and the failure reason is recorded. During subtask execution, the orchestration system can also return identifier codes based on different processing stages. For example, it can return an acceptance code when a subtask is accepted and an execution code when a subtask is executed. Based on the identifier codes returned by the orchestration system, the current task's execution status can be further determined, effectively advancing the orchestration system to the next step.

[0079] In practical applications, orchestration systems may include task state machines. Figure 3 A schematic diagram of a task state machine is shown, wherein the task state machine includes the following states: created, queued, executing, partial execution failure, failed, execution successful, paused, retrying, etc. Figure 3As shown, in conjunction with the method given in the above embodiments, a task to be processed is created after the idempotency determination is passed. After the task to be processed is created, the task state machine is in the created state. Then, by determining the task plan chain of the task to be processed, the task state machine can be further driven. Specifically, the task plan chain of the task to be processed is added to the message queue, and the task state machine is in the queued state. When the computing engine executes the atomic script, the task state machine is in the executing state. After determining that all subtasks have been successfully executed, the task state machine is in the successfully executed state. If it is determined that any subtask has failed and cannot be re-executed, for example, if the reason for the failure meets a preset condition, the task state machine is in the partially failed state. If it is determined that a subtask has failed and meets a preset condition, the task state machine is in the retrying state. When the task to be processed is paused, the task state machine is in the paused state. Based on the method given in the above embodiments, in concurrent scenarios, the task state can be updated by updating atomic statements, ensuring that the same task is only advanced by one worker node, thereby avoiding duplicate consumption and state overwriting issues.

[0080] To prevent the task from being continuously processed and executed, in some embodiments, before re-executing the second subtask based on the retry queue, the method further includes: determining the number of times the second subtask will be re-executed; the number of re-executions being greater than a threshold; the re-execution of the second subtask based on the retry queue includes: re-executing the second subtask based on the retry queue and the number of times the second subtask will be re-executed.

[0081] The orchestration system can control the number of times the second subtask is re-executed by setting an execution count field, thus avoiding infinite execution. If the number of times the second subtask has been processed exceeds the re-execution limit, the second subtask can be manually processed.

[0082] Based on the method given in the above embodiments, Figure 4 Another task orchestration method is presented, including: Step 401: Submit the task.

[0083] Submit tasks to be processed to the orchestration system.

[0084] Step 402: Perform idempotency determination.

[0085] If the idempotency determination is passed, proceed to step 403; otherwise, do not create a pending task, or do not create a task schedule chain for the pending task.

[0086] Step 403: Generate a task schedule chain.

[0087] Step 404: Add to queue.

[0088] Add the task schedule chain to the message queue.

[0089] Step 405: Perform flow control processing.

[0090] Throttling is performed based on information such as application server and database memory usage, thread pool load, database connection pool load, and task priority, triggering a backpressure mechanism to avoid memory thrashing and database errors caused by concentrated task processing.

[0091] Step 406: Retrieve tasks from the work node.

[0092] The computing engine retrieves subtasks from the message queue.

[0093] Step 407: Read the task context.

[0094] Step 408: Load the atomic script and bind parameters.

[0095] Based on the subtask to be executed, load the corresponding atomic script and bind the relevant parameters.

[0096] Step 409: Execute the SQL and write the intermediate results.

[0097] If the atomic script executes successfully, the subtask execution result is written to the intermediate result table. Then, step 410 is executed; if the atomic script fails to execute, step 414 is executed.

[0098] Step 410: Update step status and task context.

[0099] Step 411: Determine if there is a next step.

[0100] Determine if there are any remaining subtasks to be executed; if there are, proceed to step 407; otherwise, proceed to step 412.

[0101] Step 412: Callback engine update.

[0102] Step 413: Output the results.

[0103] After all subtasks of the pending task have been executed, output the execution result. Task execution ends.

[0104] Step 414: Rollback of exception handling steps.

[0105] Roll back to the subtask that failed to execute.

[0106] Step 415: Determine if it is possible to retry.

[0107] If the failed subtask can be re-executed, proceed to step 404; otherwise, proceed to step 416.

[0108] Step 416: Mark failure and write back the reason.

[0109] Figure 5 A schematic diagram of an orchestration system is shown, such as Figure 5 As shown, the orchestration system comprises an access layer, an orchestration control layer, a model and configuration layer, a computation execution layer, and a data and audit layer. The access layer can configure templates, generating task templates that include one or more of the following: processing dimensions, task metrics, processing objectives, and correction coefficients. The access layer can also trigger computations, query processing progress, and provide a result query interface. The processing dimensions, metrics, weight settings, segmentation rules, and target values ​​corresponding to the tasks to be processed can serve as input data for the access layer.

[0110] The orchestration control layer is used to implement task orchestration. Specifically, the task orchestrator in the orchestration control layer can distribute tasks to be processed, determine task processing policies through policy routers, and generate and update task state record tables through state machine managers to record the various processing states of tasks to be processed in the orchestration system, thereby assisting in the implementation of disconnection resumption and audit traceability functions. The state machine manager can include the aforementioned task state machines. The idempotency and concurrency controller performs idempotency determination on tasks to be processed to ensure that tasks are not executed repeatedly. At the same time, it can control the concurrent processing of various subtasks of the task to be processed based on the relationship between subtasks.

[0111] The model and configuration layer generates tasks to be processed based on the input data from the access layer. For example, it generates unique identifiers for tasks based on key features such as institutional level and investment advisor sequence. Task templates are used to configure the splitting and processing of tasks, and a unified indicator model loader is used to configure various processing indicators for each task. The unified indicator model loader drives task template generation and uses the idempotency determination result of the unique identifier of the task to control the creation of tasks and task plan chains, helping to form task plan chains containing multiple ordered steps.

[0112] The computation execution layer receives processing policies generated by the policy router and various processing metrics configured by the unified metric model loader via a pluggable computing engine, generating a task plan chain. The distributed executor then calls corresponding atomic scripts from a pre-defined script library based on the task plan chain, adding tasks to be processed to a message queue or internal task queue. Computation worker nodes then process the atomic scripts of each subtask in the message queue or internal task queue sequentially according to the task plan chain, retrieving the necessary data for task processing from the domestic IT innovation database. Simultaneously, the distributed executor can also combine the task context in the context manager to obtain the execution result of each subtask, storing the result in an intermediate result table.

[0113] In the orchestration system, the model and configuration layers can call the computation execution layer via HyperText Transfer Protocol (HTTP) and remote procedure call (gRPC). Through asynchronous gRPC calls to external computing services, tasks can be triggered and executed, with the service returning status acknowledgments. The computation execution layer can asynchronously distribute execution units (atomic scripts) to computation worker nodes via message queues or internal task queues. The computation worker nodes access the domestically developed database via Java Database Connectivity (JDBC), execute atomic scripts, and write the results to an intermediate result table. The computation worker nodes execute in a loop, following the sequence of reading task context, parameter binding, atomic script execution, intermediate result persistence, and status write-back, until the task schedule chain ends. After computation, a callback mechanism writes back the task status. After the computation worker nodes complete execution, callbacks can update the task status and result snapshots, thus achieving cross-step consistency, breakpoint resumption, and end-to-end traceability.

[0114] This application presents an integrated task orchestration method that features a unified indicator model, asynchronous task orchestration across scenarios, a pluggable computing engine, and traceable results. This method is applicable to complex performance evaluation processes and utilizes a domestically developed database as the underlying storage to achieve unified task orchestration. By externalizing the database processing logic into standard SQL scripts (i.e., atomic scripts), it eliminates dependence on specific database procedural languages. The method described in this application allows for dynamic adjustment of task indicators, weights, and scoring standards through front-end configuration of new rules. Compared to traditional stored procedure execution methods, this application divides the processing logic into multiple atomic scripts for step-by-step execution, reducing the pressure on the database CPU and storage. By managing computational tasks through queues, the computational burden is shifted from the database layer to the application layer, effectively reducing the risk of memory overflow and ensuring concurrent processing of large-scale asynchronous computations. This application combines configurable modeling with an engine-based computation mode to achieve complete and standardized computation and scoring of multi-source indicator data on a unified pipeline, enabling reusable computational logic and flexible combinations of scoring rules for different organizations and employee sequences.

[0115] In summary, based on the methods described in the above embodiments, by utilizing asynchronous queues and a horizontally scalable computing execution engine, the system's stability and resource utilization can be improved through smooth processing when dealing with sudden fluctuations in traffic or load. Even when facing computing tasks involving hundreds of millions of data points, database memory overflow will not occur, ensuring the stability of the core transaction database. By utilizing script atomicity and orchestration technology, the logic originally coupled to the stored process has been decomposed. When business rules change (such as adjustments to compliance indicators), only the corresponding atomic scripts need to be modified, without redeploying the entire computing package. It is also compatible with any domestically developed database that supports standard SQL, reducing the writing of repetitive code. Through templates and atomic script configuration interfaces, deployment efficiency and system stability can be improved, reducing the online deployment cycle for rule changes from 14 days to 1 hour.

[0116] Those skilled in the art will understand that the order in which the steps are written in the above-described method of the specific implementation does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic. The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

[0117] Based on the task orchestration method proposed in the aforementioned embodiments Figure 6 A schematic diagram of a task orchestration device is shown, such as Figure 6 As shown, the task orchestration device includes: The processing module 601 is used to determine the task plan chain corresponding to the task to be processed; the task plan chain includes at least two subtasks corresponding to the task to be processed and the execution order of the at least two subtasks.

[0118] The determination module 602 is used to determine the atomic script corresponding to each of the at least two subtasks in the preset script library; the atomic script is the preset smallest execution unit of the database language.

[0119] The execution module 603 is used to execute the atomic scripts corresponding to each subtask in sequence according to the task schedule chain and retrieve the data corresponding to each subtask from the database.

[0120] In practical applications, the processing module 601, the determining module 602, and the execution module 603 can be implemented based on a processor and a communication device.

[0121] In some embodiments, the processing module 601 is specifically used to determine a task template for the task to be processed based on the task to be processed; the task template is used to determine one or more of the following: the processing dimension of the task to be processed, the task indicators of the task to be processed, the processing target corresponding to the task to be processed, and the correction coefficient corresponding to the task to be processed; determine at least two sub-tasks corresponding to the task to be processed and the execution order of the at least two sub-tasks according to the task template; and determine the task plan chain corresponding to the task to be processed based on the at least two sub-tasks corresponding to the task to be processed and the execution order of the at least two sub-tasks.

[0122] In some embodiments, before determining the task schedule chain corresponding to the task to be processed, the processing module 601 is further configured to determine the unique identifier of the task to be processed; the execution module 603 is specifically configured to determine, based on the unique identifier of the task to be processed, whether there are currently any conflicting subtasks that are being executed, waiting to be executed, or have been completed; the conflicting subtasks represent the subtasks corresponding to the unique identifier; if there are currently no conflicting subtasks, the atomic scripts corresponding to each subtask are executed sequentially according to the task schedule chain.

[0123] In some embodiments, the execution module 603 is further configured to instruct the pending task to wait for execution or report an error when there are conflicting subtasks.

[0124] In some embodiments, the execution module 603 is specifically used to determine the first subtask to be executed in at least two subtasks according to the task schedule chain; read the task context corresponding to the task to be processed, execute the atomic script corresponding to the first subtask based on the task context, and obtain the first data corresponding to the first subtask from the database; the task context includes at least one or more of the following: the subtask identifier of the completed subtask, the subtask identifier of the first subtask, and an intermediate result table; the intermediate result table is used to record the execution results of the completed subtasks.

[0125] In some embodiments, the execution module 603 is further configured to obtain a first execution result corresponding to the first subtask based on the first data; and record the first execution result in an intermediate result table.

[0126] In some embodiments, the execution module 603 is further configured to, after each of the at least two subtasks has been executed, obtain the execution result of each of the at least two subtasks based on the intermediate result table; and obtain the execution result of the task to be processed based on the execution result of each subtask.

[0127] In some embodiments, before determining the task schedule chain corresponding to the task to be processed, the processing module 601 is further configured to determine the unique identifier of the task to be processed; based on the unique identifier of the task to be processed, determine whether there is currently an executing task corresponding to the unique identifier; specifically, the processing module 601 is configured to determine the task schedule chain corresponding to the task to be processed when there is currently no executing task corresponding to the unique identifier.

[0128] In some embodiments, the execution module 603 is specifically used to add the task schedule chain to the message queue, and execute the atomic script corresponding to each subtask in sequence based on the message queue and the task schedule chain.

[0129] In some embodiments, the execution module 603 is further configured to determine whether the second subtask needs to be re-executed if the second subtask processing fails; the second subtask is any one of at least two subtasks; if it is determined that the second subtask needs to be re-executed, the second subtask is added to the retry queue, and the second subtask is re-executed based on the retry queue.

[0130] In some embodiments, before re-executing the second subtask based on the retry queue, the execution module 603 is further configured to determine the number of times the second subtask will be re-executed; if the number of re-executions is greater than the number threshold, the execution module 603 is specifically configured to re-execute the second subtask based on the retry queue and the number of times the second subtask will be re-executed.

[0131] In some embodiments, the execution module 603 is further configured to call back and output the execution information and execution result of the task to be processed after the atomic script corresponding to each subtask has been executed.

[0132] It should be noted that the descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0133] It should be noted that, in the embodiments of this application, if the above-described methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the prior art, 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 terminal, server, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0134] This application also provides an electronic device. Figure 7 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application, as shown below. Figure 7 As shown, the electronic device 70 may include: Memory 701 is used to store executable instructions.

[0135] The processor 702 is used to implement any of the above-described task orchestration methods when executing executable instructions stored in the memory 701.

[0136] The processor 702 mentioned above can be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor.

[0137] The aforementioned computer-readable storage medium or memory 701 may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM), etc.; it may also be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0138] This application embodiment further provides a computer storage medium storing computer-executable instructions, which are used to implement any of the task orchestration methods provided in the above embodiments.

[0139] Correspondingly, this application embodiment further provides a computer program product, the computer program product including computer executable instructions, which are used to implement any of the task orchestration methods provided in the above embodiments.

[0140] In some embodiments, the functions or modules of the apparatus provided in this application can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0141] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0142] The methods disclosed in the various method embodiments provided in this application can be arbitrarily combined to obtain new method embodiments without conflict.

[0143] The features disclosed in the various product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0144] The features disclosed in the various method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0145] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0146] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of protection of this application, and these forms are all within the protection scope of this application.

Claims

1. A task orchestration method, characterized in that, The method includes: Determine the task plan chain corresponding to the task to be processed; the task plan chain includes at least two subtasks corresponding to the task to be processed and the execution order of the at least two subtasks; In a preset script library, determine the atomic script corresponding to each of the at least two subtasks; the atomic script is a preset minimum execution unit of the database language. The atomic scripts corresponding to each subtask are executed sequentially according to the task schedule chain, and the data corresponding to each subtask is retrieved from the database.

2. The method according to claim 1, characterized in that, The process of determining the task schedule chain corresponding to the task to be processed includes: The task template for the task to be processed is determined based on the task to be processed; the task template is used to determine one or more of the following: the processing dimension of the task to be processed, the task index of the task to be processed, the processing target corresponding to the task to be processed, and the correction coefficient corresponding to the task to be processed. Based on the task template, at least two subtasks corresponding to the task to be processed are determined, as well as the execution order of the at least two subtasks; Based on at least two subtasks corresponding to the task to be processed, and the execution order of the at least two subtasks, the task plan chain corresponding to the task to be processed is determined.

3. The method according to claim 1, characterized in that, Before determining the task schedule chain corresponding to the task to be processed, the method further includes: Determine a unique identifier for the task to be processed; The step of executing the atomic scripts corresponding to each subtask sequentially according to the task schedule chain includes: Based on the unique identifier of the task to be processed, determine whether there are any conflicting subtasks that are currently being executed, waiting to be executed, or have been completed; the conflicting subtasks refer to the subtasks corresponding to the unique identifier. If there are no conflicting subtasks, the atomic scripts corresponding to each subtask are executed sequentially according to the task schedule chain.

4. The method according to claim 3, characterized in that, The method further includes: If the conflicting subtasks exist, instruct the pending task to wait for execution or report an error.

5. The method according to claim 1, characterized in that, The step of executing the atomic scripts corresponding to each subtask sequentially according to the task schedule chain and retrieving the data corresponding to each subtask from the database includes: The first subtask to be executed is determined from the at least two subtasks according to the task planning chain; Read the task context corresponding to the task to be processed, execute the atomic script corresponding to the first subtask based on the task context, and obtain the first data corresponding to the first subtask from the database; the task context includes at least one or more of the following: the subtask identifier of the completed subtask, the subtask identifier of the first subtask, and an intermediate result table; the intermediate result table is used to record the execution results of the completed subtask.

6. The method according to claim 5, characterized in that, The method further includes: Based on the first data, the first execution result corresponding to the first subtask is obtained; The first execution result is recorded in the intermediate result table.

7. The method according to claim 5 or 6, characterized in that, The method further includes: After each of the at least two subtasks has been executed, the execution result of each of the at least two subtasks is obtained based on the intermediate result table; The execution result of the task to be processed is obtained based on the execution result of each subtask.

8. The method according to claim 5, characterized in that, The task context also includes: a snapshot corresponding to each subtask, the execution status of the task plan chain, and an identifier of the execution result of each subtask.

9. The method according to claim 1, characterized in that, Before determining the task schedule chain corresponding to the task to be processed, the method further includes: Determine a unique identifier for the task to be processed; Based on the unique identifier of the task to be processed, determine whether there is currently an executing task corresponding to the unique identifier; The process of determining the task schedule chain corresponding to the task to be processed includes: If there is no currently executing task corresponding to the unique identifier, determine the task schedule chain corresponding to the task to be processed.

10. The method according to claim 1, characterized in that, The step of executing the atomic scripts corresponding to each subtask sequentially according to the task schedule chain includes: The task schedule chain is added to the message queue, and the atomic scripts corresponding to each subtask are executed sequentially based on the message queue and the task schedule chain.

11. The method according to claim 1, characterized in that, The method further includes: If the second subtask fails, determine whether the second subtask needs to be re-executed; the second subtask is any one of the at least two subtasks. If it is determined that the second subtask needs to be re-executed, the second subtask is added to the retry queue, and the second subtask is re-executed based on the retry queue.

12. The method according to claim 11, characterized in that, Before re-executing the second subtask based on the retry queue, the method further includes: Determine the number of times the second subtask will be re-executed; the number of re-executions is greater than a threshold. The step of re-executing the second subtask based on the retry queue includes: Based on the retry queue and the number of times the second subtask has been re-executed, the second subtask is re-executed.

13. The method according to claim 1, characterized in that, The method further includes: After the atomic script corresponding to each subtask is executed, the execution information and execution result of the task to be processed are called back.

14. A task scheduling device, characterized in that, The device includes: A processing module is used to determine the task plan chain corresponding to the task to be processed; the task plan chain includes at least two sub-tasks corresponding to the task to be processed and the execution order of the at least two sub-tasks; The determination module is used to determine the atomic script corresponding to each of the at least two subtasks from a preset script library; the atomic script is a preset database language minimum execution unit. The execution module is used to execute the atomic scripts corresponding to each subtask in sequence according to the task plan chain, and to retrieve the data corresponding to each subtask from the database.

15. An electronic device, characterized in that, The electronic device includes a processor and a memory for storing computer programs capable of running on the processor; wherein, The processor is used to run the computer program to perform the method according to any one of claims 1 to 13.

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

17. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 13.

Images