Business processing method, electronic equipment, storage medium and program product

Abstract

The invention provides a business processing method, electronic equipment, a storage medium and a program product, and relates to the technical field of computers. The method comprises the steps that first configuration information corresponding to a service is acquired, the service comprises a plurality of first steps, and the first configuration information comprises a first dependency relationship among a plurality of first tasks in each first step; determining task information of a to-be-added second task, the task information being used for indicating a target step to which the second task belongs and a second dependency relationship between the second task and a plurality of first tasks in the target step; according to the target step and the second dependency relationship, updating the first dependency relationship in the first configuration information to obtain second configuration information; and processing the service according to the second configuration information. Through the method, when the second task needs to be newly added, the service can be adjusted without modifying the code corresponding to the online service, so that the service can be flexibly adjusted when the task is newly added, and the adjustment cost of the service is reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a business processing method, electronic device, storage medium, and program product. Background Technology

[0002] In the field of computer technology, task scheduling is the core support for automated business processing, which can improve the efficiency and reliability of business processing.

[0003] Currently, the task scheduling system uses a "linear serial" logic for multiple tasks in the business: tasks are arranged in a fixed order to form an execution chain, and the next task is started after the previous task is completed.

[0004] However, when the business needs to add new tasks and the execution order of the new tasks is between the two existing tasks, it is necessary to directly modify the code of the already launched tasks to embed the new tasks, which results in high adjustment costs for the business. Summary of the Invention

[0005] This application provides a business processing method, electronic device, storage medium, and program product to reduce the adjustment costs of business processes.

[0006] In a first aspect, embodiments of this application provide a business processing method, including:

[0007] Obtain the first configuration information corresponding to the business. The business includes multiple first steps, and the first configuration information includes the first dependency relationship between multiple first tasks in each first step.

[0008] Determine the task information of the second task to be added. The task information is used to indicate the target step to which the second task belongs, and the second dependency relationship between the second task and multiple first tasks in the target step.

[0009] Based on the target steps and the second dependency, the first dependency in the first configuration information is updated to obtain the second configuration information;

[0010] The service is processed based on the second configuration information.

[0011] In some embodiments, the first dependency in the first configuration information is updated according to the target step and the second dependency to obtain the second configuration information, including:

[0012] Based on the target steps and the second dependency, determine the subsequent dependent tasks of the second task. The subsequent dependent tasks depend on the output context of the second task when they are executed.

[0013] In the first configuration information, the input context of the subsequent dependent task is configured as the output context of the second task to obtain the second configuration information.

[0014] In some embodiments, processing of services based on the second configuration information includes:

[0015] Based on the second configuration information, a dependency topology graph is constructed, which indicates the execution order and execution status of multiple first steps, as well as the execution order and execution status of each task in the first step.

[0016] Based on the dependency topology graph, the business logic is processed.

[0017] In some embodiments, processing of business operations based on a dependency topology graph includes:

[0018] Based on the dependency topology graph, determine the second step as executable, and based on the second step, determine the queue of steps to be executed.

[0019] Based on the queue of steps to be executed and the dependency topology, the second step corresponding to the business is processed.

[0020] In some embodiments, for any second step; based on the queue of steps to be executed and the dependency topology, the second step corresponding to the business is processed, including:

[0021] Remove the third step from the queue of steps to be executed. The third step is the second step at the head of the queue of steps to be executed.

[0022] Execute the third step. After the third step is completed, update the execution status of the third step in the dependency topology graph to "completed" and check whether the subsequent dependent steps of the third step still depend on other conditions.

[0023] If no other conditions are required, the execution status of the subsequent dependent steps of the third step is updated to executable, and the subsequent dependent steps of the third step are added to the queue of steps to be executed.

[0024] In some embodiments, performing the third step includes:

[0025] Based on the dependency topology diagram and the third step, determine the third task that is executable in the third step, and determine the queue of tasks to be executed based on the third task.

[0026] For any third task;

[0027] Remove the fourth task from the queue of tasks to be executed. The fourth task is the third task at the head of the queue.

[0028] Determine the input context for the fourth task;

[0029] Based on the input context of the fourth task, execute the fourth task, obtain the output context of the fourth task, update the execution status of the fourth task in the dependency topology graph to completed, and check whether the subsequent dependent tasks of the fourth task still depend on other conditions.

[0030] If no other conditions are required, the execution status of the fourth task's subsequent dependent tasks will be updated to executable, and the fourth task's subsequent dependent tasks will be added to the queue of tasks to be executed.

[0031] In some embodiments, the order of elements in the queue of steps to be executed and / or the queue of tasks to be executed is determined based on a preset scheduling strategy; the scheduling strategy includes at least one of the following: the priority of the steps or tasks, and the creation time of the steps or tasks.

[0032] Secondly, embodiments of this application provide a business processing apparatus, including:

[0033] The acquisition module is used to acquire the first configuration information corresponding to the business. The business includes multiple first steps, and the first configuration information includes the first dependency relationship between multiple first tasks in each first step.

[0034] The determination module is used to determine the task information of the second task to be added. The task information is used to indicate the target step to which the second task belongs, and the second dependency relationship between the second task and multiple first tasks in the target step.

[0035] The update module is used to update the first dependency in the first configuration information according to the target step and the second dependency to obtain the second configuration information;

[0036] The processing module is used to process the business based on the second configuration information.

[0037] In some embodiments, the update module is specifically used for:

[0038] Based on the target steps and the second dependency, determine the subsequent dependent tasks of the second task. The subsequent dependent tasks depend on the output context of the second task when they are executed.

[0039] In the first configuration information, the input context of the subsequent dependent task is configured as the output context of the second task to obtain the second configuration information.

[0040] In some embodiments, the processing module is specifically used for:

[0041] Based on the second configuration information, a dependency topology graph is constructed, which indicates the execution order and execution status of multiple first steps, as well as the execution order and execution status of each task in the first step.

[0042] Based on the dependency topology graph, the business logic is processed.

[0043] In some embodiments, the processing module is specifically used for:

[0044] Based on the dependency topology graph, determine the second step as executable, and based on the second step, determine the queue of steps to be executed.

[0045] Based on the queue of steps to be executed and the dependency topology, the second step corresponding to the business is processed.

[0046] In some embodiments, for any second step; the processing module is specifically used for:

[0047] Remove the third step from the queue of steps to be executed. The third step is the second step at the head of the queue of steps to be executed.

[0048] Execute the third step. After the third step is completed, update the execution status of the third step in the dependency topology graph to "completed" and check whether the subsequent dependent steps of the third step still depend on other conditions.

[0049] If no other conditions are required, the execution status of the subsequent dependent steps of the third step is updated to executable, and the subsequent dependent steps of the third step are added to the queue of steps to be executed.

[0050] In some embodiments, the processing module is specifically used for:

[0051] Based on the dependency topology diagram and the third step, determine the third task that is executable in the third step, and determine the queue of tasks to be executed based on the third task.

[0052] For any third task;

[0053] Remove the fourth task from the queue of tasks to be executed. The fourth task is the third task at the head of the queue.

[0054] Determine the input context for the fourth task;

[0055] Based on the input context of the fourth task, execute the fourth task, obtain the output context of the fourth task, update the execution status of the fourth task in the dependency topology graph to completed, and check whether the subsequent dependent tasks of the fourth task still depend on other conditions.

[0056] If no other conditions are required, the execution status of the fourth task's subsequent dependent tasks will be updated to executable, and the fourth task's subsequent dependent tasks will be added to the queue of tasks to be executed.

[0057] In some embodiments, the order of elements in the queue of steps to be executed and / or the queue of tasks to be executed is determined based on a preset scheduling strategy; the scheduling strategy includes at least one of the following: the priority of the steps or tasks, and the creation time of the steps or tasks.

[0058] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0059] The memory stores instructions that the computer executes;

[0060] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0061] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0062] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0063] The present application provides a business processing method, electronic device, storage medium, and program product. The method includes: obtaining first configuration information corresponding to a business, where the business includes multiple first steps, and the first configuration information includes first dependencies between multiple first tasks in each first step; determining task information for a second task to be added, where the task information indicates the target step to which the second task belongs, and a second dependency between the second task and multiple first tasks in the target step; updating the first dependencies in the first configuration information according to the target step and the second dependencies to obtain second configuration information; and processing the business according to the second configuration information. In this method, only the target step to which the newly added second task belongs and its second dependencies with the existing first tasks within that step need to be clearly defined. Based on this, the dependencies in the first configuration information can be accurately updated to generate the second configuration information. Subsequent business processing can then be directly performed based on the updated second configuration information, achieving flexible adjustment of the business when adding a new task and reducing the cost of business adjustment. Attached Figure Description

[0064] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0065] Figure 1 A flowchart illustrating a business processing method provided in an embodiment of this application;

[0066] Figure 2 A flowchart illustrating a method for processing business data, provided as an embodiment of this application;

[0067] Figure 3 A flowchart illustrating a step-processing method provided in an embodiment of this application;

[0068] Figure 4 This is a schematic diagram of the structure of a service processing device provided in an embodiment of this application;

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

[0070] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0071] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. 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.

[0072] The collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0073] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0074] In the field of computer technology, task scheduling is the core support for automated business processing, which can improve the efficiency and reliability of business processing.

[0075] Currently, the task scheduling system uses a "linear serial" logic for multiple tasks in the business: tasks are arranged in a fixed order to form an execution chain, and the next task is started after the previous task is completed.

[0076] However, when the business needs to add new tasks and the execution order of the new tasks is between the two existing tasks, it is necessary to directly modify the code of the already launched tasks to embed the new tasks, which results in high adjustment costs for the business.

[0077] In this embodiment, first configuration information corresponding to a service is obtained. The service includes multiple first steps, and the first configuration information includes first dependencies between multiple first tasks in each first step. Task information for a second task to be added is determined. This task information indicates the target step to which the second task belongs, and the second dependencies between the second task and multiple first tasks in the target step. Based on the target step and the second dependencies, the first dependencies in the first configuration information are updated to obtain second configuration information. The service is then processed based on the second configuration information. In this method, by pre-defining the dependencies between tasks within each step of the service and managing them in the form of configuration information, when a second task needs to be added, there is no need to modify the already deployed task code. Only the target step to which the second task belongs and its second dependencies with the original first tasks within that step need to be clearly defined. Based on this, the dependencies in the initial first configuration information can be accurately updated to generate the second configuration information. Subsequent service processing is then directly based on the updated second configuration information. This effectively avoids the problem of modifying deployed code when adding intermediate tasks under a "linear serial" logic, achieving flexible and low-intrusive adjustments to the service execution chain when adding tasks, significantly reducing the adjustment cost of the service.

[0078] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0079] Figure 1 This is a flowchart illustrating a business processing method provided in an embodiment of this application, such as... Figure 1 As shown, the method includes:

[0080] S101. Obtain the first configuration information corresponding to the service, wherein the service includes multiple first steps, and the first configuration information includes the first dependency relationship between multiple first tasks in each first step.

[0081] In some embodiments, the first configuration information corresponding to the service may further include: feature information of the service, feature information of each first step in the service, and feature information of each first task in each first step.

[0082] Optionally, the characteristic information of the service may include one or more of the following: service ID, service description, one or more node groups that execute the service, one or more nodes that execute the service, and service activation flag.

[0083] The business ID is a unique identifier for that business.

[0084] A business description is descriptive text that describes the function or purpose of the business in natural language.

[0085] When the service's characteristic information includes a node group that executes the service, the service is processed through the nodes within that node group; when the service's characteristic information includes a node that executes the service, the service is processed through that node; when the service's characteristic information does not include a node group or a node that executes the service, all nodes in the cluster can process the service.

[0086] Obtaining the first configuration information corresponding to a service can involve obtaining the first configuration information corresponding to multiple services. The service activation flag indicates whether the service is executable. For example, when the service activation flag is 1, it indicates that the service is executable; when the service activation flag is 0, it indicates that the service is not executable.

[0087] In some embodiments, when multiple services exist, the characteristic information of the services may also include service priority.

[0088] Optionally, the characteristic information of the first step includes one or more of the following: the business ID of the business to which it belongs, the step ID, the step description, the step activation flag, the step priority, and one or more preceding dependent steps.

[0089] Pre-dependency steps are used to indicate the dependencies between multiple first steps. Specifically, pre-dependency steps indicate the execution order of multiple first steps. A first step is eligible to be executed only after all its pre-dependency steps have been executed.

[0090] It should be noted that the meanings of step ID, step description, step activation flag, and step priority are similar to those of business ID, business description, business activation flag, and business priority, and will not be repeated here.

[0091] Optionally, the characteristic information of the first task may include one or more of the following: the business ID of the business to which it belongs, the step ID of the step to which it belongs, the task ID, the task description, the task activation flag, the task priority, one or more prerequisite dependent tasks, the task execution program, the task execution method, the optional parameters of the task execution method, and the maximum number of retries.

[0092] The task executor is the entity that implements the specific logic of the task. For example, in an object-oriented programming environment, the executor can be an instance of a specific class or a Bean identifier in a Spring application.

[0093] A task execution method is a specific operation or function that is actually called in the task execution program to complete the core logic of the task.

[0094] The optional parameters of the task execution method are used to provide static configuration information for calling the task execution method.

[0095] The maximum number of retries is the maximum number of times a task will be automatically retried after it fails. Specifically, if a task fails but the maximum number of retry attempts has not yet been reached, the task's execution status will be set to "waiting for redo," and it will be added back to the task queue in subsequent processing. If the maximum number of retry attempts has been reached or exceeded when the task fails, the task's execution status will be set to "finally failed," potentially causing the failure of its associated steps or business logic. The setting of the maximum number of retries is typically related to the idempotency of the task operation, ensuring that repeated execution during retries does not negatively impact the business logic.

[0096] Pre-dependency tasks are used to indicate the primary dependencies between multiple first tasks; specifically, they indicate the execution order of these first tasks. A first task is only eligible to be executed after all its pre-dependency tasks have been completed.

[0097] The following provides an illustrative example of the first dependencies between multiple first tasks in each first step:

[0098] In the first step A, which includes first task A1, first task A2, and first task A3, first task A1 does not include any prerequisite dependent tasks, first task A2's prerequisite dependent task is first task A1, and first task A3's prerequisite dependent tasks include first task A1 and first task A2, then the first dependency relationship between the first tasks in the first step A indicates that the execution of first task A1 does not depend on any other task in this step, while the execution of first task A2 requires the successful completion of first task A as a prerequisite. At the same time, the execution of first task A3 may be configured to wait for both first task A1 and first task A2 to be successfully completed before it can begin.

[0099] S102. Determine the task information of the second task to be added, wherein the task information is used to indicate the target step to which the second task belongs, and the second dependency relationship between the second task and multiple first tasks in the target step.

[0100] Optionally, the task information of the second task includes the characteristic information of the second task and one or more subsequent dependent tasks of the second task, wherein the characteristic information of the second task includes: the step ID of the target step to which the second task belongs, the task ID of the second task, the task description, the task activation flag, the task priority, one or more preceding dependent tasks, the task execution program, the task execution method, the optional parameters of the task execution method, and the maximum number of retries.

[0101] The second dependency is indicated by preceding and following dependent tasks, defining the execution order between the second task and one or more first tasks in the target step. For example, the second dependency can specify that the second task can only begin execution after one or more of its preceding dependent tasks have been completed, and that one or more of its following dependent tasks can only begin execution after the second task has been completed.

[0102] It should be noted that the characteristic information in the task information, such as the task execution program and execution method, has the same or similar meaning as the characteristic information of the first task, and will not be repeated here.

[0103] S103. Based on the target steps and the second dependency, update the first dependency in the first configuration information to obtain the second configuration information.

[0104] In some embodiments, during the processing of a business function, each task in each step of the business process is associated with its own context information during execution for data transfer between tasks. This context information includes input context and output context. When a task's feature information includes preceding dependent tasks, the input context of that task is the output context of its preceding dependent tasks.

[0105] In some embodiments, the first dependency in the first configuration information is updated according to the target step and the second dependency to obtain the second configuration information, including:

[0106] Based on the target step and the second dependency, determine the subsequent dependent tasks of the second task, wherein the subsequent dependent tasks of the second task depend on the output context of the second task during execution.

[0107] In the first configuration information, the input context of the subsequent dependent task of the second task is configured as the output context of the second task, thus obtaining the second configuration information.

[0108] The subsequent dependent tasks of the second task depend on the output context of the second task during execution. This can be understood as the input context of the subsequent dependent tasks of the second task being the output context of the second task.

[0109] The following is an example of updating the first dependency in the first configuration information according to the target step and the second dependency to obtain the second configuration information:

[0110] The target step B includes tasks B1, B2 and B3. Task B1 does not include any prerequisite tasks. Task B2's prerequisite task is task B1. Task B3's prerequisite tasks include both task B1 and task B2.

[0111] If the second dependency relationship indicates that the preceding dependency of the second task C is task B1 and the following dependency of the second task C is task B2, then according to the target step and the second dependency relationship, the following dependency of the second task can be determined to be task B2. In the first configuration information, the input context of task B2 is configured as the output context of the second task to obtain the second configuration information.

[0112] Configuring the input context of task B2 as the output context of the second task also means updating the preceding dependent task in the feature information of task B to the second task C.

[0113] S104. Process the service according to the second configuration information.

[0114] In some embodiments, before processing the service according to the second configuration information, the process may include: determining whether the triggering conditions of the service are met; if the triggering conditions of the service are met, instantiating the service according to the second configuration information, and creating a service instance of the service, step instances of each step in the service, and task instances of each task in each step. Then, processing the service according to the second configuration information involves: processing the service instance of the service, the step instances of each step in the service, and the task instances of each task in each step according to the second configuration information.

[0115] To determine whether the triggering conditions for a service are met, one can scan the triggering carrier corresponding to the service to determine whether the triggering conditions for the service are met.

[0116] The triggering carriers for the business include, but are not limited to: file directories, a record in a database table that meets the matching conditions, or other structured data carriers that can carry business triggering information.

[0117] The business triggering information carried in the trigger carrier depends on the business requirements and may include key data such as the business execution date, associated file path, and processing parameters. This information is used to construct the initial context of the business instance.

[0118] The initial context construction process includes parsing the business trigger information in the trigger carrier and converting it into key-value pairs. This initial context will be persisted to the business instance table as the global data environment for subsequent task instance execution. The initial context remains read-only throughout the business instance's lifecycle to ensure data consistency during business processing.

[0119] The following examples, 1A and 1B, illustrate how scanning the trigger carrier corresponding to this service can determine whether the service's triggering conditions are met:

[0120] Example 1A: Monitor a specified file directory. When a file with a filename matching a specified pattern is detected in the file directory, determine if the trigger condition for the business is met.

[0121] Example 1B: Poll the database table and determine if the trigger condition for the business logic is met when the data corresponding to the STATUS field of the database table changes to NEW.

[0122] In some embodiments, to ensure the uniqueness of the trigger carrier in a cluster environment, the carrier identifier of the trigger carrier usually includes a unique serial number generated by mechanisms such as UUID and database sequence.

[0123] It is understandable that when the business activation flag indicates that the business is executable, the business is instantiated according to the second configuration information, and a business instance of the business, step instances of each step in the business, and task instances of each task in each step are created; when the business activation flag indicates that the business is not executable, a business instance of the business, step instances of each step in the business, and task instances of each task in each step are not created.

[0124] Instantiating this business logic can be understood as creating a record in the business instance table to save the initial context; creating step instances for steps that are executable (indicated by the step activation flag); and creating task instances for tasks that are executable (indicated by the task activation flag). Through the instantiation process, static configuration information is transformed into executable runtime objects.

[0125] In some embodiments, for multiple services, the service instances corresponding to the multiple services can be sorted according to a preset scheduling strategy, and the sorted service instances can be added to the queue of services to be executed in sequence; the service instance at the head of the queue of services to be executed is determined as the currently executed service instance; the locking flag of the currently executed service instance is configured to be executing to prevent other nodes in the cluster from repeatedly executing the service.

[0126] The following examples, 2A, 2B, and 2C, illustrate how to sort service instances corresponding to multiple services according to a preset scheduling strategy:

[0127] Example 2A sorts multiple business instances based on the priority of the business they correspond to.

[0128] Specifically, higher-priority business instances (e.g., instances with larger priority values) will be ranked before lower-priority business instances.

[0129] Example 2B sorts multiple business instances based on their creation time.

[0130] Specifically, business instances created earlier will be prioritized over business instances created later, following the principle of first-come, first-served.

[0131] Example 2C sorts multiple business instances based on the priority of the business corresponding to the business instance and when the business instance was created.

[0132] Specifically: First, the business priorities corresponding to the business instances are compared. Business instances with higher priorities (e.g., instances with larger priority values) will be ranked before business instances with lower priorities. Second, for multiple business instances with the same priority, their creation times are compared. Business instances created earlier will be ranked before business instances created later, following the principle of first-come, first-served.

[0133] For example, when the locking flag of a service instance is 0, it indicates that the service has not been executed; when the locking flag of a service instance is 1, it indicates that the service is being executed or has been executed.

[0134] In some embodiments, there is no dependency between multiple services, but the output of one service can be one of the conditions triggered by another service. For example, the output of service A is file A, and the triggering carrier for service B is file directory B. When file A is detected in file directory B, it is determined that the triggering condition of service B is met.

[0135] In some embodiments, each step in the business process may have no or one or more preceding dependent jobs, but there cannot be circular dependencies. A circular dependency is, for example, job A's preceding dependent job is job B, and job B's preceding dependent job is job A.

[0136] In some embodiments, each task in the steps may have no or one or more preceding dependent tasks, but there must be no circular dependencies.

[0137] In this embodiment, first configuration information corresponding to a service is obtained. The service includes multiple first steps, and the first configuration information includes first dependencies between multiple first tasks in each first step. Task information of a second task to be added is determined. The task information is used to indicate the target step to which the second task belongs, and the second dependencies between the second task and multiple first tasks in the target step. The first dependencies in the first configuration information are updated according to the target step and the second dependencies to obtain second configuration information. The service is processed according to the second configuration information. In the above method, by pre-defining the dependencies between tasks within each step of the business process and managing them in the form of configuration information, when a second task needs to be added, there is no need to modify the code of the already deployed task. It is only necessary to clarify the target step to which the second task belongs and its second dependency relationship with the original first task within that step. Based on this, the dependency relationship in the initial first configuration information can be accurately updated to generate the second configuration information. Subsequently, business processing can be carried out directly based on the updated second configuration information. This effectively avoids the problem of modifying the deployed code when adding intermediate tasks under the "linear serial" logic. It realizes flexible and low-intrusion adjustment of the business execution chain when adding tasks, which greatly reduces the adjustment cost of the business. At the same time, it ensures the stability and scalability of business processing and further improves the adaptability efficiency of the task scheduling system to business changes.

[0138] Below, in Figure 1 Based on the implementation examples, combined with Figure 2 Further explanation is provided regarding the processing of services based on the second configuration information.

[0139] Figure 2 A flowchart illustrating a method for processing business operations provided in this application embodiment is shown below. Figure 2 As shown, the method includes:

[0140] S201. Based on the second configuration information, construct a dependency topology graph, wherein the dependency topology graph indicates the execution order and execution status of multiple first steps, as well as the execution order and execution status of each task in the first step.

[0141] In some embodiments, a dependency topology graph is constructed based on the second configuration information, including:

[0142] Parse the second configuration information to obtain the feature information of all steps included in the business, as well as the feature information of all tasks included in each step;

[0143] Based on the feature information of all steps included in the business and the feature information of all tasks included in each step, the dependencies between steps and the dependencies between tasks are determined.

[0144] Based on the dependencies between steps, a topological graph of the step hierarchy is constructed, where each step is represented as a topological node, and the dependencies between steps are represented as directed edges connecting these topological nodes.

[0145] For each step, based on the dependencies between tasks within that step, a sub-topology graph of the task hierarchy for that step is constructed, where each task is represented as a topology node, and the dependencies between tasks are represented as directed edges connecting these topology nodes.

[0146] Associate the topology graph at the step level with the sub-topology graph at the task level of each step to form a complete dependency topology graph that covers both the step and task levels.

[0147] Based on the dependency topology graph, initialize the execution state of each step topology node and each task topology node in the dependency topology graph.

[0148] The dependencies between steps are represented as directed edges connecting these topological nodes. This can be understood as follows: the prerequisite task of step D1 is step D2, which is represented as a directed edge from the topological node corresponding to step D2 to the topological node corresponding to step D1.

[0149] The following describes the execution status of each step's topology node and each task's topology node in the dependency topology graph, based on the initialization process:

[0150] When there are no other steps or nodes pointing to a step or node in the dependency topology graph, the execution state of that step or node is initialized to executable in the dependency topology graph.

[0151] When a step or node has other steps or nodes pointing to it in the dependency topology graph, the execution state of that step or node is initialized to non-executable in the dependency topology graph.

[0152] In some embodiments, the dependency topology graph also includes the execution status of the service, which includes executable, non-executable, processing, waiting to be redone, completed, and failed.

[0153] For any given service, after starting to execute the service, update the execution status of the service to "processing"; if the execution time of the service is too long, update the execution status of the service to "waiting to be redone"; after the service is completed, update the execution status of the service to "completed"; if the execution of the service encounters an error, update the execution status of the service to "failed".

[0154] When available resources are limited, in order to prevent the business from running indefinitely, when the execution time of the business exceeds the preset time, the execution status of the business will be updated to "waiting to be redone", and resources will be released to execute other businesses.

[0155] It should be noted that the execution status of the steps is similar to the execution status of the business logic, and will not be elaborated on here.

[0156] In some embodiments, the execution status of a task includes executable, non-executable, in process, waiting to be redone, completed, and failed.

[0157] For any given task, after starting the task, update the task's execution status to "Processing"; if the task encounters an error and the maximum number of retries has not been reached, update the task's execution status to "Waiting to be redone"; after the task is completed, update the task's execution status to "Completed"; if the task encounters an error and the maximum number of retries has not been reached, update the task's execution status to "Failed".

[0158] S202. Process the business logic based on the dependency topology diagram.

[0159] In some embodiments, processing of business operations based on a dependency topology graph includes:

[0160] Based on the dependency topology graph, determine the second step as executable, and based on the second step, determine the queue of steps to be executed.

[0161] Based on the queue of steps to be executed and the dependency topology, the second step corresponding to the business is processed.

[0162] When there are multiple second steps, the queue of steps to be executed is determined according to the second steps. This may include: sorting the second steps according to a preset scheduling strategy, and adding the sorted second steps to the queue of steps to be executed in sequence.

[0163] In the specific implementation process, according to the preset scheduling strategy, the step instances corresponding to the second step are sorted, and the sorted step instances corresponding to the second step are added to the queue of steps to be executed in sequence.

[0164] It should be noted that the process of sorting the step instances corresponding to the second step according to the preset scheduling strategy is similar to the process of sorting multiple business instances according to the preset scheduling strategy, and will not be described again here.

[0165] In some embodiments, the second step corresponding to the business logic is processed according to the queue of steps to be executed and the dependency topology graph. Specifically, the second step at the head of the queue is taken as the current step to be executed. Then, this current step is executed. After the step is completed, the dependency topology graph is updated: the execution status of the topology node corresponding to the currently executed step is marked as completed, and all subsequent dependent steps (i.e., steps in the dependency relationship where this step is a preceding dependent step) are checked. For each subsequent dependent step, it is determined whether there are any other incomplete preceding dependent steps. If all preceding dependent steps of a certain subsequent dependent step are completed, the execution status of the topology node of that subsequent dependent step is updated to executable, and it is added to the end of the queue of steps to be executed. Finally, the above process is repeated to continue taking steps from the updated queue of steps to be executed for execution.

[0166] In this embodiment, a dependency topology graph is constructed based on the second configuration information. The dependency topology graph indicates the execution order and status of multiple first steps, as well as the execution order and status of each task within each first step. The business is then processed based on the dependency topology graph. In the above method, by constructing a dependency topology graph based on the second configuration information, the execution order and status of multiple first steps included in the business, as well as the execution order and status of different tasks within each first step, are presented in an intuitive topology graph format, facilitating more efficient automated processing of the business.

[0167] The following, based on any of the above embodiments, combined with Figure 3 For any second step, further explanation is given on how to process the corresponding second step of the business based on the queue of steps to be executed and the dependency topology graph.

[0168] Figure 3 A flowchart illustrating a step-processing method provided in an embodiment of this application is shown below. Figure 3 As shown, the method includes:

[0169] S301. Delete the third step from the queue of steps to be executed, where the third step is the second step at the head of the queue of steps to be executed.

[0170] Deleting the third step from the queue of steps to be executed can be understood as retrieving and removing the third step from the queue. At this point, the execution status of the third step in the dependency topology graph is updated to "processing". This operation ensures that, in a clustered environment, the same step instance will not be processed repeatedly by multiple scheduling threads, thus guaranteeing the uniqueness and consistency of step execution.

[0171] S302. Execute the third step. After the third step is completed, update the execution status of the third step in the dependency topology graph to "completed" and check whether the subsequent dependent steps of the third step still depend on other conditions.

[0172] In some embodiments, performing the third step includes:

[0173] Based on the dependency topology diagram and the third step, determine the third task that is executable in the third step, and determine the queue of tasks to be executed based on the third task.

[0174] For any third task;

[0175] Remove the fourth task from the queue of tasks to be executed. The fourth task is the third task at the head of the queue.

[0176] Determine the input context for the fourth task;

[0177] Based on the input context of the fourth task, execute the fourth task, obtain the output context of the fourth task, update the execution status of the fourth task in the dependency topology graph to completed, and check whether the subsequent dependent tasks of the fourth task still depend on other conditions.

[0178] If no other conditions are required, the execution status of the fourth task's subsequent dependent tasks will be updated to executable, and the fourth task's subsequent dependent tasks will be added to the queue of tasks to be executed.

[0179] When all tasks in the third step of the dependency topology graph have been successfully executed, update the execution status of the third step in the dependency topology graph to "completed".

[0180] When there are multiple third tasks, the queue of tasks to be executed is determined based on the third tasks. This may include: sorting the multiple third tasks according to a preset scheduling strategy, and adding the sorted tasks to the queue of tasks to be executed in sequence.

[0181] In the specific implementation process, according to the preset scheduling strategy, the task instances corresponding to multiple third tasks are sorted, and the sorted task instances corresponding to multiple third tasks are added to the queue of tasks to be executed in sequence.

[0182] It should be noted that the process of sorting task instances corresponding to multiple third tasks according to the preset scheduling strategy is similar to the process of sorting multiple business instances according to the preset scheduling strategy, and will not be described again here.

[0183] Specifically, task instances corresponding to multiple third tasks can be sorted based on the maximum number of retries. Specifically, task instances with a lower maximum number of retries will be ranked before task instances with a higher maximum number of retries.

[0184] In some embodiments, if the fourth task is not configured with a preceding dependent task, its input context directly uses the initial context of its business instance; if the fourth task is configured with a preceding dependent task, its input context is derived from the output context of one or more of its specified preceding dependent tasks.

[0185] The fourth task is executed by calling the task execution program and task execution method of the fourth task.

[0186] Checking whether the subsequent dependent tasks of the fourth task still depend on other conditions can be done by: determining whether the subsequent dependent tasks of the fourth task have other unfinished preceding dependent tasks, or determining whether the subsequent dependent tasks of the fourth task have an execution arrival time.

[0187] S303. If no other conditions are required, update the execution status of the subsequent dependent steps of the third step to executable, and add the subsequent dependent steps of the third step to the queue of steps to be executed.

[0188] When all steps in the dependency topology graph have been executed successfully, update the execution status of the business in the dependency topology graph to "completed".

[0189] The processing flow based on the dependency topology graph described in steps S301 to S303 above can achieve efficient scheduling through an event-driven collaboration mechanism. The core of this mechanism is the interaction of three information flows: "completion events are passed from bottom to top", "ready events are passed from bottom to top", and "resources to be run are passed from top to bottom".

[0190] The bottom-up propagation of completion events means that when a lower-level execution unit (such as a task) finishes processing, a completion event is generated. This event is propagated upwards to its parent unit (such as a step). Upon receiving the event, the parent unit updates its internal state and checks dependencies. If all its lower-level units have completed, it also becomes complete and continues to trigger a new completion event to the next higher level. This mechanism ensures that changes in business state can be propagated and confirmed from the bottom up, layer by layer, ultimately enabling the top-level scheduler to accurately perceive the completion of the entire business or a large step.

[0191] The bottom-up propagation of ready events means that when an underlying resource (such as an execution thread) becomes available, a ready event signal is emitted. This signal propagates upwards along the execution hierarchy, inquiring in turn whether there are any pending work items at the next higher level. This bottom-up event propagation is equivalent to a continuous "I can work" signal, driving the scheduling process.

[0192] The process of passing resources down from top to bottom is the response process for ready events: When an upper-level scheduler (such as a step scheduler) receives a ready event from a lower-level scheduler, and it does indeed have lower-level units (such as tasks) ready to be executed, it will pass the execution permissions and specific execution resources (such as task instances) down to the lower-level executor (such as a task executor) that issued the ready event. This process ensures that once resources are available, pending work items can be allocated and executed in a timely manner.

[0193] By combining these three event flows, the system constructs an efficient and decoupled scheduling loop: ready events drive resource allocation, resource allocation leads to task execution, task execution generates completion events, and completion events may in turn trigger new ready events and resource allocation requests. This design enables the scheduling of batch tasks or business processes to operate adaptively, making full and effective use of system resources and proceeding in an orderly manner strictly according to the configured dependencies.

[0194] In this embodiment, for any second step, the third step is deleted from the queue of steps to be executed. The third step is the second step at the head of the queue of steps to be executed. The third step is executed. After the third step is executed, the execution status of the third step in the dependency topology graph is updated to "completed". It is then checked whether the subsequent dependent steps of the third step still depend on other conditions. If no other conditions are needed, the execution status of the subsequent dependent steps of the third step is updated to "executable". The subsequent dependent steps of the third step are then added to the queue of steps to be executed. In the above method, the third step is processed by taking it out of the queue of steps to be executed and deleting the head of the queue. Its execution status in the dependency topology graph is updated synchronously to ensure execution uniqueness. After completion, the conditions of subsequent dependent steps are checked. Only when no other conditions are required are subsequent dependent steps set as executable and added to the queue. This processing method based on the linkage between queue and topology graph status not only ensures the orderliness and consistency of step execution, but also dynamically drives the flow of subsequent steps according to the dependency relationship, avoiding the chaos or duplication of step execution. This allows the business processing flow to advance efficiently while strictly following the dependency logic, improving the reliability and continuity of business processing.

[0195] Figure 4 This is a schematic diagram of the structure of a service processing device provided in an embodiment of this application, as shown below. Figure 4 As shown, the service processing device 40 provided in this embodiment includes:

[0196] The acquisition module 401 is used to acquire the first configuration information corresponding to the business. The business includes multiple first steps, and the first configuration information includes the first dependency relationship between multiple first tasks in each first step.

[0197] The determination module 402 is used to determine the task information of the second task to be added. The task information is used to indicate the target step to which the second task belongs, and the second dependency relationship between the second task and multiple first tasks in the target step.

[0198] The update module 403 is used to update the first dependency in the first configuration information according to the target step and the second dependency to obtain the second configuration information;

[0199] Processing module 404 is used to process the service according to the second configuration information.

[0200] The business processing device 40 provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0201] In some embodiments, the update module 403 is specifically used for:

[0202] Based on the target steps and the second dependency, determine the subsequent dependent tasks of the second task. The subsequent dependent tasks depend on the output context of the second task when they are executed.

[0203] In the first configuration information, the input context of the subsequent dependent task is configured as the output context of the second task to obtain the second configuration information.

[0204] In some embodiments, the processing module 404 is specifically used for:

[0205] Based on the second configuration information, a dependency topology graph is constructed, which indicates the execution order and execution status of multiple first steps, as well as the execution order and execution status of each task in the first step.

[0206] Based on the dependency topology graph, the business logic is processed.

[0207] In some embodiments, the processing module 404 is specifically used for:

[0208] Based on the dependency topology graph, determine the second step as executable, and based on the second step, determine the queue of steps to be executed.

[0209] Based on the queue of steps to be executed and the dependency topology, the second step corresponding to the business is processed.

[0210] In some embodiments, for any second step; the processing module 404 is specifically used for:

[0211] Remove the third step from the queue of steps to be executed. The third step is the second step at the head of the queue of steps to be executed.

[0212] Execute the third step. After the third step is completed, update the execution status of the third step in the dependency topology graph to "completed" and check whether the subsequent dependent steps of the third step still depend on other conditions.

[0213] If no other conditions are required, the execution status of the subsequent dependent steps of the third step is updated to executable, and the subsequent dependent steps of the third step are added to the queue of steps to be executed.

[0214] In some embodiments, the processing module 404 is specifically used for:

[0215] Based on the dependency topology diagram and the third step, determine the third task that is executable in the third step, and determine the queue of tasks to be executed based on the third task.

[0216] For any third task;

[0217] Remove the fourth task from the queue of tasks to be executed. The fourth task is the third task at the head of the queue.

[0218] Determine the input context for the fourth task;

[0219] Based on the input context of the fourth task, execute the fourth task, obtain the output context of the fourth task, update the execution status of the fourth task in the dependency topology graph to completed, and check whether the subsequent dependent tasks of the fourth task still depend on other conditions.

[0220] If no other conditions are required, the execution status of the fourth task's subsequent dependent tasks will be updated to executable, and the fourth task's subsequent dependent tasks will be added to the queue of tasks to be executed.

[0221] In some embodiments, the order of elements in the queue of steps to be executed and / or the queue of tasks to be executed is determined based on a preset scheduling strategy; the scheduling strategy includes at least one of the following: the priority of the steps or tasks, and the creation time of the steps or tasks.

[0222] The business processing device 40 provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0223] Figure 5This is a schematic diagram of an electronic device provided in an embodiment of this application. The electronic device can be replaced with other terminal devices that perform the above-described method embodiments. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. The processor 501 and the memory 502 are connected via a bus 503.

[0224] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0225] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0226] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0227] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0228] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0229] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0230] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0231] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0232] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0233] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0234] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0235] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0237] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0238] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A business processing method, characterized in that, include: Obtain first configuration information corresponding to the service, wherein the service includes multiple first steps, and the first configuration information includes first dependencies between multiple first tasks in each first step; Determine the task information of the second task to be added, wherein the task information is used to indicate the target step to which the second task belongs, and the second dependency relationship between the second task and multiple first tasks in the target step; Based on the target step and the second dependency, the first dependency in the first configuration information is updated to obtain the second configuration information; The service is processed according to the second configuration information.

2. The method according to claim 1, characterized in that, The step of updating the first dependency in the first configuration information according to the target step and the second dependency to obtain the second configuration information includes: Based on the target step and the second dependency relationship, determine the subsequent dependent tasks of the second task, wherein the subsequent dependent tasks depend on the output context of the second task when they are executed; In the first configuration information, the input context of the subsequent dependent task is configured as the output context of the second task to obtain the second configuration information.

3. The method according to claim 2, characterized in that, The step of processing the service according to the second configuration information includes: Based on the second configuration information, a dependency topology graph is constructed, which indicates the execution order and execution status of the plurality of first steps, as well as the execution order and execution status of each task in the first step; The service is processed according to the dependency topology graph.

4. The method according to claim 3, characterized in that, The step of processing the service according to the dependency topology graph includes: Based on the dependency topology graph, determine the second step as executable, and based on the second step, determine the queue of steps to be executed; Based on the queue of steps to be executed and the dependency topology graph, the second step corresponding to the business is processed.

5. The method according to claim 4, characterized in that, For any second step; based on the queue of steps to be executed and the dependency topology graph, process the second step corresponding to the business, including: The third step is deleted from the queue of steps to be executed. The third step is the second step at the head of the queue of steps to be executed. Execute the third step. After the third step is completed, update the execution status of the third step in the dependency topology graph to "completed" and check whether the subsequent dependent steps of the third step still depend on other conditions. If no other conditions are required, the execution status of the subsequent dependent steps of the third step is updated to executable, and the subsequent dependent steps of the third step are added to the queue of steps to be executed.

6. The method according to claim 5, characterized in that, Performing the third step includes: Based on the dependency topology diagram and the third step, determine the third task that is executable in the third step, and determine the queue of tasks to be executed based on the third task. For any third task; The fourth task is removed from the queue of tasks to be executed. The fourth task is the third task at the head of the queue. Determine the input context for the fourth task; Based on the input context of the fourth task, the fourth task is executed to obtain the output context of the fourth task. The execution status of the fourth task in the dependency topology graph is updated to completed, and it is checked whether the subsequent dependent tasks of the fourth task still depend on other conditions. If no other conditions are required, the execution status of the subsequent dependent tasks of the fourth task is updated to executable, and the subsequent dependent tasks of the fourth task are added to the queue of tasks to be executed.

7. The method according to any one of claims 4-6, characterized in that, The order of elements in the queue of steps to be executed and / or the queue of tasks to be executed is determined based on a preset scheduling strategy; the scheduling strategy includes at least one of the following: the priority of the steps or tasks, and the creation time of the steps or tasks.

8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images