Workflow orchestration method and apparatus, server, storage medium, and program product

Abstract

A workflow orchestration method and apparatus, a server, a storage medium, and a program product. The method comprises: determining the priority of each workflow among one or more workflows; and determining the execution sequence of the one or more workflows on the basis of the priority of each workflow among the one or more workflows.

Description

A workflow orchestration method and apparatus, server, storage medium, and program product.

[0001] Cross-references to related applications

[0002] This application is based on and claims priority to Chinese Patent Application No. 202411918505.6, filed on December 24, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of network management technology, and in particular to a workflow orchestration method and apparatus, server, storage medium, and program product. Background Technology

[0004] In current DevOps process management, while existing solutions have improved R&D and operational efficiency to some extent, certain shortcomings remain. When multiple workflows run simultaneously, more important workflows may be blocked by less important ones, leading to a decrease in R&D and operational efficiency. The root cause is that existing solutions cannot accurately calculate workflow priorities, resulting in issues with the workflow execution order. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a workflow orchestration method and apparatus, a server, a computer storage medium, and a computer program product.

[0006] The workflow orchestration methods provided in this application include:

[0007] Determine the priority of each workflow in one or more workflows;

[0008] The execution order of the one or more workflows is determined based on the priority of each workflow in the one or more workflows.

[0009] The workflow orchestration apparatus provided in this application includes:

[0010] The determining unit is configured to determine the priority of each workflow in one or more workflows; and to determine the execution order of the one or more workflows based on the priority of each workflow in the one or more workflows.

[0011] The server provided in this application includes a processor and a memory, the memory being used to store computer programs, and the processor being used to call and run the computer programs stored in the memory to execute the workflow orchestration method described above.

[0012] The computer-readable storage medium provided in this application is used to store a computer program that causes a computer to perform the workflow orchestration method described above.

[0013] The computer program product provided in this application includes computer program instructions that cause a computer to execute the workflow orchestration method described above.

[0014] The technical solution of this application proposes a method for accurately calculating workflow priorities, which can ensure that the workflow execution order is optimal and improve R&D and operational efficiency. Attached Figure Description

[0015] Figure 1 is a schematic diagram of the integrated R&D and operation business process for communication network operation and management;

[0016] Figure 2 is a physical architecture diagram of the integrated R&D and operation platform for communication operation management;

[0017] Figure 3 is a flowchart illustrating the workflow orchestration method provided in an embodiment of this application.

[0018] Figure 4 is a schematic diagram of the workflow orchestration method provided in the embodiments of this application (II).

[0019] Figure 5 is a schematic diagram of the structural composition of the workflow orchestration device provided in an embodiment of this application;

[0020] Figure 6 is a schematic structural diagram of a server provided in an embodiment of this application. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0022] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0023] It should also be noted that the terms "first, second, and third" used in the embodiments of this application are only used to distinguish similar objects and do not represent a specific order of objects. It is understood that "first, second, and third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0024] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship. It should also be understood that the term "correspondence" mentioned in the embodiments of this application can indicate a direct or indirect correspondence between two objects, or it can indicate an association between them.

[0025] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application will be described below.

[0026] (I) Demand Scenarios

[0027] 1. NF Devops

[0028] In the field of Network Functions Virtualization (NFV), a typical telecommunications application scenario involves network equipment vendors providing virtualized network function components, or Virtual Network Functions (VNFs). Within the NFV systems and network infrastructure of telecommunications operators, operators procure and utilize VNFs from different vendors to compose and provide network services. The virtualization and software-defined nature of NFV technology places demands on rapid updates, iterations, and delivery for these application scenarios. The practice of Development and Operations (DevOps) technology helps achieve these requirements. Through continuous integration / delivery pipelines, small incremental releases of VNFs and VNF components (VNFCs) can be rapidly facilitated. Each VNF vendor has its own DevOps delivery pipeline and internal processes. Telecommunications operators have internal standards and process requirements for VNF verification, deployment, and operation, necessitating the establishment of a cross-organizational VNF joint DevOps delivery pipeline.

[0029] 2. OSS DevOps

[0030] In the communication network infrastructure of telecom operators, operators procure and use network elements from different equipment vendors to assemble and provide network services. In the field of Operations Support System (OSS) technology, traditional mobile network equipment vendors (wireless, core, transmission, etc.) provide both network element software and vendor management systems (i.e., Operations and Maintenance Centers, OMCs). These OMCs interface with network management system integrators, who provide independent professional workbenches and cross-professional integrated management system functional components. This enables Fault Configuration Accounting Performance and Security (FCAPS) management of network elements. With the cloudification and virtualization of Network Functions (NFs) themselves, OMCs have also simultaneously achieved virtualization and software implementation. This places demands on rapid updates, iterations, and delivery for the above application scenarios. The practice of DevOps technology helps achieve these requirements; through continuous integration / delivery pipelines, small incremental releases of OMCs can be rapidly facilitated. Each VNF vendor can reuse its own NF development and operation integrated (DevOps) delivery pipeline and its internal processes. However, telecom operators need to effectively organize the standards and processes for the verification, deployment, and operation of OMC by equipment vendors and network management integrators. This requires the establishment of a cross-organizational OMC joint development and operation integrated (DevOps) delivery pipeline.

[0031] (II) Roles and Responsibilities

[0032] The roles and responsibilities involved in the integrated R&D and operation business process for communication network operation and management are shown in Table 1.

[0033] Table 1: Roles and Responsibilities Involved in the Integrated R&D and Operations Business Process

[0034] The systems and responsibilities involved in the integrated R&D and operation business process for communication network operation and management are shown in Table 2.

[0035] Table 2: Systems and Responsibilities Involved in the Integrated R&D and Operations Business Process

[0036] (III) Business Process

[0037] Figure 1 shows the integrated R&D and operation business process for communication network operation and management. The operator first initiates the integrated R&D and operation business process for communication network operation and management and puts forward product requirements to the supplier.

[0038] When a supplier receives a product requirement from an operator, it analyzes the requirement and initiates the R&D and operation process for the newly released product. When the supplier receives feedback on anomalies related to the current product, it analyzes and locates the problem, completes the iterative requirement analysis, and initiates the R&D and operation iteration process for the new version of the product.

[0039] Based on the requirements analysis results, the supplier-side integrated R&D and operations system designs, develops, builds, tests, and releases artifacts, outputting them to the artifact repository. Subsequently, depending on whether the operator has subscribed to the artifact, the supplier-side integrated R&D and operations system sends artifact update notifications to the operator-side integrated R&D and operations system.

[0040] After receiving a product update notification, the operator-side integrated R&D and operations system first retrieves the corresponding product from the product repository, and then performs the following processing steps on the product:

[0041] 1. Model training phase (optional): The operator-side R&D and operation integrated system performs model training or model retraining on intelligent component products based on business scenario requirements or operational feedback;

[0042] 2. Testing Phase: The operator-side integrated R&D and operation system deploys artifacts to the simulation environment for pre-deployment verification testing;

[0043] 3. Deployment Phase: The operator-side integrated R&D and operation system is deployed to the production environment;

[0044] 4. Operation Phase: The operator-side integrated R&D and operation system subscribes to and collects operational data of deployed products from the production environment;

[0045] 5. Data Feedback Stage: The operator-side integrated R&D and operation system feeds back the product's testing and operation data and necessary auxiliary information to the supplier-side integrated R&D and operation system for iterative optimization of the supplier's products.

[0046] If the product delivery process between the supplier-side R&D and operations integrated system and the operator-side R&D and operations integrated system is implemented through a network, then this network must be physically isolated from the data communication network (DCN).

[0047] (iv) Target Architecture

[0048] The physical architecture of the integrated R&D and operation platform for communication operation management is shown in Figure 2. The physical entities include the DevOps server, artifact building subsystem, and artifact testing and release subsystem of the supplier-side integrated R&D and operation system, and the DevOps server, model training subsystem, artifact testing subsystem, artifact deployment subsystem, and artifact operation monitoring subsystem of the operator-side integrated R&D and operation system, which work together to complete the task.

[0049] The physical entities of the supplier-side integrated R&D and operations system include:

[0050] 1. DevOps server: It should support the workflow management function on the supplier side, realize the workflow control and execution of the product on the supplier side, and deliver the product to the operator's integrated R&D and operation system;

[0051] 2. Artifact Construction Subsystem: It should support requirements / fault analysis and artifact construction functions to enable the development and iteration of supplier artifacts;

[0052] 3. Product Testing and Release Subsystem: It should support test deployment and product release functions, realize product testing and verification, and store products that pass the test in the supplier's product library.

[0053] The physical entities of the operator-side integrated R&D and operation system include:

[0054] 1. DevOps server: It should support the workflow management function on the operator side, receive the delivered products from the supplier, and realize the control and management of the products in the process on the operator side;

[0055] 2. Model Training Subsystem (Optional): Should support model training functions to enable model training and retraining;

[0056] 3. Product Testing Subsystem: It should support automatic testing functions, interface with the simulation environment to manage and execute product testing for different suppliers, and feed back test results to the DevOps server;

[0057] 4. Product Deployment Subsystem: It should support integrated deployment functionality, enabling the integrated deployment of supplier products into the production or simulation environment;

[0058] 5. Product Operation Monitoring Subsystem: It should support operation monitoring functions, connect to the production environment to collect product operation data, complete the data processing flow and feed it back to the supplier's R&D and operation integrated system; collect model training data and feed it back to the model training subsystem.

[0059] The interfaces between physical entities are as follows: The X1 interface between the DevOps server of the operator-side integrated R&D and operations system and the operator-side integrated R&D and operations management system enables process management for integrated R&D and operations in the operator's communication operations management system; the X2 interface between the operator-side integrated R&D and operations system and the supplier-side integrated R&D and operations system enables product delivery and feedback of anomaly information; the Q1 interface between the product testing subsystem of the operator-side integrated R&D and operations system and the simulation environment enables product testing execution and management in the simulation environment; the Q2 interface between the product deployment subsystem of the operator-side integrated R&D and operations system and the production environment enables integrated product deployment; and the Q3 interface between the product operation monitoring subsystem of the operator-side integrated R&D and operations system and the production environment enables product operation data collection, processing, and feedback.

[0060] While some solutions in current DevOps process management have improved the efficiency of software development and operations to some extent, certain shortcomings remain. First, existing workflow management systems lack flexible management based on workflow priorities, failing to respond in real-time to changing business needs and environmental conditions. This results in critical tasks being unable to be processed promptly under resource conflicts and time constraints, delaying the overall project delivery cycle. Furthermore, dependencies between workflows are often not effectively managed. For example, when multiple workflows run concurrently, important tasks may be blocked by lower-priority tasks, leading to inefficient resource utilization and slow response times. Current priority management mechanisms are typically based on static parameters, failing to consider real-time monitoring data and dynamically adjust priorities, thus reducing operational efficiency.

[0061] To address this, the technical solution of this application embodiment is proposed. This application embodiment proposes a workflow priority-based integrated DevOps management method for communication networks (also referred to herein as a workflow orchestration method), aiming to improve the flexibility and efficiency of workflow management. This workflow orchestration method designs a priority formula, calculates parameters such as business level and creation time, and considers the dependencies between workflows to form a flexible priority ranking algorithm that adapts to the needs of complex and dynamic environments. Secondly, a dynamic priority adjustment mechanism is introduced, which intelligently calculates and adjusts the priority of workflows based on real-time monitoring data and the dependencies between workflows, ensuring that workflows corresponding to critical tasks are executed first and effectively preventing workflow congestion. Through the workflow orchestration method of this application embodiment, workflow management and feedback processes can be enhanced, improving the efficiency of DevOps process management and the automation and intelligence level of the system.

[0062] It should be noted that the "workflow orchestration method" described in the embodiments of this application may be replaced by other alternative descriptions, such as: workflow management method, priority-based workflow orchestration / management method, priority-based DevOps workflow orchestration / management method, priority-based communication network DevOps management method, etc.

[0063] Figure 3 is a flowchart illustrating the workflow orchestration method provided in this embodiment of the application. As shown in Figure 3, the workflow orchestration method in this embodiment includes the following steps (it should be noted that the execution subject in the following steps is the operator-side integrated R&D and operation system by default, specifically the DevOps server in the operator-side integrated R&D and operation system, and the management system described in the following steps specifically refers to the operator-side integrated R&D and operation management system):

[0064] Step 301: Determine the priority of each workflow in one or more workflows.

[0065] Step 302: Determine the execution order of one or more workflows based on the priority of each workflow in one or more workflows.

[0066] In this embodiment of the application, determining the priority of each workflow in one or more workflows includes:

[0067] For each workflow in one or more workflows, the priority of that workflow is calculated based on priority calculation parameters; wherein the priority calculation parameters include one or more of the following:

[0068] The first parameter represents the business level of the workflow.

[0069] The second parameter characterizes the dependencies in the workflow;

[0070] The third parameter characterizes the abnormal state of the workflow;

[0071] The fourth parameter characterizes the blocking state of the workflow.

[0072] In some implementations, the first parameter may also be called the service level parameter. The second parameter may also be called the dependency parameter. The third parameter may also be called the abnormal state parameter (or abnormal parameter). The fourth parameter may also be called the blocking state parameter (or blocking parameter).

[0073] In some implementations, the first parameter can be denoted as BL, representing Business Level. The second parameter can be denoted as DR, representing Dependency Relationship. The third parameter can be denoted as EX, representing Exception. The fourth parameter can be denoted as BD, representing Blockage.

[0074] In some implementations, the priority calculation of the workflow based on the workflow priority calculation parameters includes at least one of the following schemes:

[0075] Option 1: Calculate the priority of the workflow based on the first parameter and the first weight, where the first weight is the weight of the business level.

[0076] For workflows without dependencies, Option 1 can be used to calculate the workflow's priority. Here, "no dependencies" means that the execution of the workflow does not depend on other workflows, and the workflow is not depended on by other workflows.

[0077] In some implementations, the priority of workflow i is calculated using the following formula: P i =w1*BL i (1)

[0078] Among them, P i Represents the priority value of workflow i; BL i The business level value of workflow i (i.e., the value of the first parameter) represents the importance of workflow i to the business. For example, it can be divided into three business level values: high (3), medium (2), and low (1). w1 represents the weight of the business level (i.e., the first weight), which is used to measure the degree of influence of the business on the priority.

[0079] Option 2: Calculate the priority of the workflow based on the first parameter, first weight, second parameter, and second weight of the workflow. The first weight is the weight of the business level, and the second weight is the weight of the dependency relationship.

[0080] For workflows with dependencies, or workflow dependencies that have been updated, Scheme 2 can be used to calculate the priority of the workflow. Here, workflow dependencies mean that the execution of the workflow depends on other workflows, and / or the workflow is depended on by other workflows.

[0081] For example, in one scenario, it is necessary to create m (m is a positive integer) workflows and arrange the execution order of these m workflows. Among these m workflows, there are workflows with dependencies. For the workflows with dependencies, the priority of the workflow can be calculated using Scheme 2.

[0082] For example, in another scenario, if k (k is a positive integer) workflows have already been created and their order arranged, and a new workflow (let's call it workflow i) needs to be created and its execution order arranged, if workflow i has dependencies on j (j is a positive integer less than or equal to k) of the k workflows, then Scheme Two is used to calculate the priority of workflow i. Furthermore, because the introduction of workflow i updates the dependencies of the already created j workflows, the workflow of each of the j workflows needs to be recalculated according to Scheme Two, and the priority of each of the j workflows needs to be adjusted based on the recalculation results. This avoids deadlocks and other problems caused by the execution order of workflows.

[0083] For workflows with dependencies, compared to formula (1) above, the priority calculation formula for this workflow needs to add a DR parameter (i.e., the second parameter), indicating whether the execution of this workflow depends on or is depended upon by other workflows. The system records and maintains the dependencies of all workflows (including direct and indirect dependencies), and calculates the value of the DR parameter based on the dependencies. The DR parameter value of the workflow at the top of the dependency relationship will be higher.

[0084] In some implementations, for workflow i with dependencies, the priority of workflow i is calculated using the following formula: P i RD =w1*BL w +w2*DR i (2)

[0085] Among them, P i RD Represents the priority value of workflow i; BL i The business level value of workflow i (i.e., the value of the first parameter) represents the importance of workflow i to the business. For example, it can be divided into three business level values: high (3), medium (2), and low (1); w1 represents the weight of the business level (i.e., the first weight), which is used to measure the degree of influence of the business on the priority; DR i w2 represents the dependency value of workflow i (i.e., the value of the second parameter), indicating whether the execution of workflow i is dependent on or depends on other workflows; w2 represents the weight of the dependency (i.e., the second weight), which is used to reflect the impact of the dependency on the priority.

[0086] In some implementations, the dependency value (i.e., the value of the second parameter) can be determined in the following way:

[0087] Determine the total number of dependencies for each workflow in one or more workflows, where the total number of dependencies refers to the total number of workflows that a workflow depends on; sort the execution order of one or more workflows based on the total number of dependencies for each workflow in one or more workflows; check if there is a workflow in the sort that is preceding the workflow and depends on the workflow; if so, adjust the workflow to precede the workflow that is preceding the workflow and depends on the workflow; determine the value of the second parameter for each workflow in one or more workflows based on the sorting of one or more workflows.

[0088] For example, assuming the number of workflows to be executed in parallel is m (m is a positive integer), the execution order of these m workflows is sorted according to the total number of dependencies (TotalDependents) of each workflow. If there are workflows with the same total number of dependencies, they are sorted according to business priority and / or creation time. It is checked whether there is a workflow (denoted as workflow j) that precedes a certain workflow (let's call it workflow i) and depends on workflow i; if so, workflow i is moved before workflow j. It should be noted that if multiple workflows precede workflow i and depend on it, workflow i is moved to the front of these multiple workflows. The dependency value of each workflow is calculated based on the execution order of the m workflows with dependencies.

[0089] In some implementations, the dependency value of workflow i is calculated using the following formula:

[0090] Among them, DR i Z represents the dependency value of workflow i; Z represents the range of values ​​for the dependency parameter (DR); m represents the number of workflows in the workflow set (i.e., the number of workflows that need to be executed in parallel); n represents the rank of workflow i in the execution order of the workflow set.

[0091] Option 3: Calculate the priority of the workflow based on the first parameter, first weight, second parameter, second weight, and at least one of the following: third parameter, third weight, fourth parameter, and fourth weight. The first weight is the weight of the business level, the second weight is the weight of the dependency relationship, the third weight is the weight of the abnormal state, and the fourth weight is the weight of the blocked state.

[0092] In the event of workflow anomalies and / or blockages, Option 3 can be used to calculate the priority of the workflow.

[0093] For example, during workflow execution, the workflow priority can be recalculated and dynamically adjusted based on actual workflow conditions (such as exceptions or blockages) without manual intervention. This dynamic adjustment mechanism makes priority adjustment more flexible and can cope with complex operating environments and uncertainties.

[0094] For workflows with anomalies and / or blockages, the priority calculation formula for the workflow needs to be supplemented with an anomaly parameter (i.e., the third parameter) and / or a blockage parameter (i.e., the fourth parameter) compared to the above formula (2).

[0095] In some implementations, for workflow i that experiences anomalies and blockages, the priority of workflow i is calculated using the following formula: P i EXBD =w1*BL i +w2*DR i +w3*EX i +w4*BD i (4-1)

[0096] Among them, P i EXBD Represents the priority value of workflow i; BL i The business level value of workflow i (i.e., the value of the first parameter) represents the importance of workflow i to the business. For example, it can be divided into three business level values: high (3), medium (2), and low (1); w1 represents the weight of the business level (i.e., the first weight), which is used to measure the degree of influence of the business on the priority; DR i w1 represents the dependency value of workflow i (i.e., the value of the second parameter), indicating whether the execution of workflow i is dependent on or depends on other workflows; w2 represents the weight of the dependency (i.e., the second weight), used to reflect the impact of the dependency on priority; EX i This represents the abnormal status value of workflow i (i.e., the value of the third parameter). This abnormal status value is a binary value (0 or 1) used to indicate whether an abnormality has occurred in the workflow. For example, an abnormal status value of 1 indicates that the workflow has an abnormality, and an abnormal status value of 0 indicates that the workflow is normal. In other words, if workflow i has an abnormality, then EX... i =1, if workflow i does not experience any abnormalities, then EX i =0, this parameter can be used to increase the priority of abnormal workflows; w3 represents the weight of the abnormal state (i.e., the third weight), which is usually set to a higher value to prioritize abnormal workflows; BD iThis represents the blocking status value of workflow i (i.e., the value of the fourth parameter). This blocking status value is a binary value (0 or 1) used to indicate whether the workflow is blocked (whether it is blocking other workflows, or whether it is blocked by other workflows). For example, a blocking status value of 1 represents that the workflow is blocked, and a blocking status value of 0 represents that the workflow is not blocked. In other words, if workflow i is blocked, then BD... i =1, if workflow i is unblocked, then BD i =0, this parameter can be used to increase the priority of blocked workflows; w4 represents the weight of the blocked state (i.e., the fourth weight), when it is necessary to prioritize blocked workflows, a higher weight can be assigned to them.

[0097] In some implementations, for workflow i with abnormal conditions, the priority of workflow i is calculated using the following formula: P i EXBD =w1*BL i +w2*DR i +w3*EX i (4-2)

[0098] The meaning of each parameter in formula (4-2) can be referred to the description in formula (4-1) above.

[0099] In some implementations, for workflow i that experiences congestion, the priority of workflow i is calculated using the following formula: P i EXBD =w1*BL i +w2*DR i +w4*BD i (4-3)

[0100] The meaning of each parameter in formula (4-3) can be referred to the description in formula (4-1) above.

[0101] It should be noted that when dynamically adjusting the priority of workflow i, it is necessary to ensure that the priority of workflow i is still constrained by dependencies.

[0102] It should be noted that DR in the above formulas (4-1), (4-2), and (4-3) i The calculation method can be referred to the description of the aforementioned formula (3).

[0103] In some implementations, for Scheme 2 and / or Scheme 3 above, the business level value of workflow i can be the business level value of workflow i itself, or the business level value of workflow i can be the average business level of all workflows.

[0104] In some implementations, the formula for calculating the average service level is as follows:

[0105] Among them, BL w Represents the average business level; BL i represents the business level value of workflow i; m represents the number of workflows in the workflow set (i.e., the number of workflows that need to be executed in parallel).

[0106] It should be noted that the above-mentioned options 1, 2, and 3 can be implemented independently or in combination.

[0107] It should be noted that the priority calculation parameters are not limited to the first, second, third, and fourth parameters mentioned above. There can be more or fewer parameters. For example, priority calculation parameters can also include the number of iterations, resource utilization, etc.

[0108] In some implementations, if the priority calculation parameters of the workflow are updated, the priority of the workflow is recalculated based on the updated priority calculation parameters; wherein the reasons for updating the priority calculation parameters include at least one of the following: the business level of the workflow is updated; the dependencies of the workflow are updated; the abnormal state of the workflow is updated; the blocking state of the workflow is updated.

[0109] In some implementations, if at least two workflows in one or more workflows have equal priority, the execution order of the at least two workflows is determined based on their creation time. The workflow created earlier is executed first. However, this is not a limitation; the execution order of the at least two workflows can also be determined based on other factors (such as the number of workflow iterations, resource utilization, etc.).

[0110] The technical solution of this application embodiment proposes a priority processing flow for workflows, including:

[0111] 1. Basic workflow priority processing flow (i.e., the above-mentioned scheme 1): In terms of workflow priority calculation, the technical solution of this application embodiment introduces a flexible priority orchestration mechanism based on business level, which enables the system to reasonably arrange the execution order of workflows, ensure that key workflows are executed first in the workflow set, and avoid the blocking and resource waste of low-priority workflows.

[0112] 2. Workflow processing when dependencies exist (i.e., Scheme 2 above): Based on the basic workflow priority processing flow, a flexible priority orchestration / adjustment mechanism based on dependencies is added to avoid execution order deadlock caused by dependencies.

[0113] 3. Dynamically Adjustable Workflow Process (i.e., Solution 3 above): By introducing a real-time monitoring and feedback mechanism, the system can dynamically adjust the workflow priority based on the workflow's execution status and / or abnormal status. This mechanism can respond promptly to environmental changes during execution, improving task processing efficiency and resource utilization.

[0114] In this embodiment, the functionality of the first interface has been enhanced. The first interface is the interface between the operator-side integrated R&D and operation system (specifically, the DevOps server within the operator-side integrated R&D and operation system) and the operator-side integrated R&D and operation management system (hereinafter referred to as the management system). The first interface can be described in other alternative ways, such as the X1 interface.

[0115] In some implementations, the first interface includes workflow management and information feedback functions (i.e., workflow feedback functions).

[0116] In some implementations, a first message is received from the management system via a first interface, and / or a second message is sent to the management system; wherein the first message is used for workflow management, and the second message is used for workflow feedback.

[0117] Here, the first message is used for workflow management and is implemented based on the workflow management function of the first interface. The second message is used for workflow feedback and is implemented based on the information feedback function of the first interface.

[0118] In some implementations, the first message sent by the receiving management system includes:

[0119] Receive a workflow creation message sent by the management system. The workflow creation message carries at least one of the following parameters: workflow name, operator identifier, workflow type, processes included in the workflow, priority calculation parameters, and dynamic priority adjustment strategy.

[0120] The method further includes: sending a workflow creation response message to the management system, the workflow creation response message carrying at least one of the following parameters: the workflow identifier, the workflow priority, the current execution ranking of the workflow, and the creation result.

[0121] In some implementations, the first message sent by the receiving management system includes:

[0122] Receive update workflow messages sent by the management system. The update workflow message carries at least one of the following parameters: workflow identifier, update content, updated workflow type, processes included in the updated workflow, updated priority calculation parameters, and updated dynamic priority adjustment strategy.

[0123] The method further includes: sending an update workflow response message to the management system, the update workflow response message carrying at least one of the following parameters: updated workflow identifier, updated workflow priority, updated workflow current execution ranking, and update result status.

[0124] In some implementations, the first message sent by the receiving management system includes:

[0125] Receive a delete workflow message sent by the management system. The delete workflow message carries the following parameters: workflow identifier;

[0126] The method further includes: sending a delete workflow response message to the management system, wherein the delete workflow response message carries at least one of the following parameters: the identifier of the deleted workflow and the deletion result status.

[0127] In some implementations, the first message sent by the receiving management system includes:

[0128] Receive a query workflow message sent by the management system. The query workflow message carries at least one of the following parameters: workflow identifier, first query parameter, and second query parameter; the first query parameter represents the current priority of the query workflow, and the second query parameter represents the historical adjustment record of the query workflow priority.

[0129] The method further includes: sending a query workflow response message to the management system, the query workflow response message carrying at least one of the following parameters: workflow identifier, current status of the workflow, currently executing process of the workflow, current priority of the workflow, historical adjustment record of workflow priority, and current execution ranking of the workflow.

[0130] In some implementations, sending the second message to the management system includes:

[0131] Send workflow feedback messages to the management system. The workflow feedback messages carry at least one of the following parameters: workflow identifier, feedback problem description, information file retrieval address, reason for priority adjustment, and feedback timestamp.

[0132] In this embodiment of the application, the interface functions of the X1 interface include workflow management function and information feedback function (i.e., workflow feedback function).

[0133] (a) Workflow management functions include CRUD operations on workflows, specifically including:

[0134] 1. Create Workflow: Supports creating new workflows, including defining each stage of the process (such as testing, deployment, monitoring, etc.) and their order and logical relationships; supports priority calculation parameters for workflows, including priority calculation parameters such as business level, dependency relationship, resource utilization, and number of iterations.

[0135] 2. Update Workflow: Supports configuration modification of existing workflows, including adding or deleting new steps or stages, and modifying workflow priority calculation parameters.

[0136] 3. Delete workflow: Supports deleting unnecessary or completed workflows.

[0137] 4. Query workflow status: Supports querying the current status and execution progress of a specific workflow; supports querying the priority of a specific workflow.

[0138] (ii) The workflow feedback function supports feeding back the execution results (such as test results, deployment status, etc.) and current priority of the workflow to the management system, so as to facilitate subsequent decision-making and process adjustment.

[0139] To implement the above-mentioned interface functions, this application embodiment also provides an interface information model for the X1 interface.

[0140] (i) For workflow management functions, the corresponding interface information model includes at least one of the following:

[0141] 1. Create a workflow process

[0142] The workflow creation function is a workflow management feature, and its interface access method is: POST / v1 / devops / workflows; its interface parameters are defined as shown in Table 3 below:

[0143] Table 3 Parameter definitions for creating a workflow

[0144] 2. Update Workflow Process

[0145] The update workflow is a workflow management function, and its interface access method is: POST / v1 / devops / workflows / {workflowId}; its interface parameters are defined as shown in Table 4 below:

[0146] Table 4 Parameter Definitions for the Update Workflow

[0147] 3. Delete Workflow Process

[0148] Deleting a workflow is a workflow management function, and its interface access method is: DELETE / v1 / devops / workflows / {workflowId}; its interface parameters are defined as shown in Table 5 below:

[0149] Table 5 Parameter Definitions for Deleting a Workflow

[0150] 4. Query Workflow Process

[0151] The workflow query function is a workflow management feature. Its interface access method is: GET / v1 / devops / workflows / {workflowId}; its interface parameters are defined as shown in Table 6 below.

[0152] Table 6 Parameter Definitions for Query Workflow

[0153] (ii) For the information feedback function, the corresponding interface information model includes the following:

[0154] 1. Workflow Feedback

[0155] Workflow feedback, as an information feedback function, is accessed via the interface method: POST / v1 / devopsMS / workflows / feedback; its interface parameters are defined as shown in Table 7 below:

[0156] Table 7 Parameter Definitions for Workflow Feedback

[0157] The technical solution of this application embodiment, by designing a workflow priority calculation method and using this method to define DevOps interactive workflows and management interface functions and information models, enables the creation, updating, and deletion of DevOps workflows that support priority setting, conflict detection, optimized scheduling, and workflow feedback, thus achieving efficient management of concurrent workflows. This comprehensively improves the efficiency and flexibility of DevOps concurrent workflow management, enabling dynamic adjustment of workflows to cope with rapidly changing business needs and complex work scenarios, rationally arranging the execution order of workflows, and enhancing the system's automation and intelligence levels.

[0158] Figure 4 is a schematic flowchart of the workflow orchestration method provided in this embodiment of the application. As shown in Figure 4, the workflow orchestration method in this embodiment of the application includes the following steps:

[0159] Step 401: Process creation.

[0160] The operator-side integrated R&D and operation management system (also referred to as the management system) first pre-creates and configures workflows and confirms relevant priority calculation parameters, including setting the business level and dependencies of the workflow. Workflow configuration covers one or more steps such as artifact reception, training, testing, deployment, and monitoring, and lays the foundation for dynamically adjusting priorities in subsequent processes.

[0161] Step 402: Workflow prioritization.

[0162] After the workflow is created, the DevOps server of the operator's integrated R&D and operation system calculates the basic priority (also known as the initial priority) of each workflow based on the priority calculation parameters mentioned above, according to the "basic workflow priority processing flow" described above, and determines the execution order of the workflows according to the priority sorting. If the priorities are equal, the execution order of the workflows is determined according to the workflow creation time (workflows created earlier are executed first).

[0163] After calculating the priority of each workflow, the DevOps server checks whether the workflow has dependencies on other workflows (e.g., it depends on the completion of other workflows or is depended on by other workflows). If there are dependencies, the priority of the workflows with dependencies is recalculated according to the "workflow processing flow when there are dependencies" described above.

[0164] The DevOps server also dynamically adjusts workflow priorities based on real-time monitoring and workflow progress, according to the "dynamically adjusted workflow processing flow" described above. The DevOps server confirms the execution order of concurrent workflows, ensuring that high-priority workflows are executed first. The real-time monitoring system (i.e., the artifact operation monitoring subsystem in Figure 2) dynamically tracks workflow progress and system status. If anomalies or blockages occur (for example, if an anomaly occurs after some workflows are executed, their priority needs to be dynamically increased; if a workflow being executed is found to be blocking other workflows, its priority can be adjusted immediately), then anomaly and blockage status handling is performed, that is, the workflow priority is recalculated according to the "dynamically adjusted workflow processing flow" described above.

[0165] The DevOps server feeds back the priority information / priority adjustment information of each workflow to the management system.

[0166] Step 403: Product Subscription.

[0167] The DevOps server of the operator-side integrated R&D and operations system proactively subscribes to specific types of artifacts from the supplier-side integrated R&D and operations system based on pre-set process requirements. This subscription to the supplier artifact library assigns a specific vendor artifact type, version, or service to each workflow, such as a VNF upgrade process.

[0168] When a supplier releases a new product, the supplier-side system will notify the operator-side R&D and operations integrated system through a product update notification. The operator-side R&D and operations integrated system will then obtain the latest product information and version.

[0169] Step 404: Product Receiving and Execution Process.

[0170] When the operator-side integrated R&D and operations system receives the product notification, the DevOps server of the operator-side integrated R&D and operations system executes relevant operations according to the workflow pre-set by the management system.

[0171] This step specifically includes the following steps:

[0172] Step 4.1: Product Testing:

[0173] The artifact testing subsystem of the operator-side integrated R&D and operations system performs artifact testing according to the workflow configuration. If the test passes, the next step is executed. If the test fails or an abnormal state occurs, the DevOps server of the operator-side integrated R&D and operations system provides feedback on the abnormal information in real time and triggers a dynamic priority adjustment mechanism to increase the priority of the workflow.

[0174] Step 4.2: Product Deployment:

[0175] The artifact deployment subsystem of the operator-side integrated R&D and operation system executes artifact deployment according to the workflow configuration. If the deployment is successful, the next step is executed; if the deployment fails, an exception message is reported to the management system, and the priority of the workflow is adjusted through the exception handling mechanism.

[0176] Step 405: Process Feedback and Monitoring.

[0177] The operator-side integrated R&D and operations management system continuously monitors process progress macroscopically through the X1 interface, obtaining the process execution status (such as test passed, deployment completed, etc.) summarized by the DevOps server. If any abnormal feedback information is received or occurs at any stage of the DevOps server, it will report the abnormal information to the management system.

[0178] Step 406: Process Update.

[0179] Based on feedback from the DevOps server or user needs, the carrier-side integrated R&D and operations management system can update workflow configurations and related priority calculation parameters. Update operations include, but are not limited to: adjusting business levels and modifying dependencies.

[0180] Step 407: Process terminated.

[0181] When the management system receives a user request or, based on feedback from the DevOps server, decides to terminate a workflow, it sends a delete command via the X1 interface. This operation safely terminates the workflow and releases related resources.

[0182] The technical solution of this application proposes a workflow priority management method for integrated research and development of communication networks. First, a workflow priority calculation scheme is designed, introducing a flexible priority sorting mechanism and dynamic adjustment mechanism based on a weighted formula. By comprehensively considering parameters such as business level and dependencies, it ensures the priority execution of critical tasks in the workflow, enabling real-time response to environmental changes, thereby improving task processing efficiency and reducing resource waste. Second, this application proposes a DevOps workflow management process based on priority calculation, ensuring that workflow priority management runs through the entire lifecycle of each DevOps workflow, accurately reflecting and timely adjusting workflow priorities at different stages. Finally, based on the priority-based DevOps workflow management process, the interface functions and corresponding information models are defined for the workflow management interface X1, enabling the creation, updating, and deletion of DevOps workflows and workflow feedback, achieving efficient management of concurrent workflows.

[0183] The technical solutions of this application embodiment are illustrated below with specific application examples. In the following application examples, the testing and deployment workflow for an NS implementing fault detection functionality will be illustrated. Workflow A is "functional testing of a temporary version of the NS delivered by the vendor to resolve targeted issues," and workflow B is "deployment of the target version of the NS delivered by the operator." These two workflows are dependent on each other; that is, the execution of workflow B must occur after workflow A has been successfully completed.

[0184] Application Example 1

[0185] This application example demonstrates workflow management with dependencies. In this example, workflow A and workflow B are dependent on each other; that is, workflow B must be executed after workflow A has successfully completed. The specific execution steps of this application example are as follows (it should be noted that the subject of execution in the following steps defaults to the operator-side integrated R&D and operations system, and the management system described in the following steps specifically refers to the operator-side integrated R&D and operations management system):

[0186] 1. Create workflow A

[0187] Specifically, the system receives a "Create Workflow" message for workflow A from the management system. Referring to Table 8 below, the interface access method for this message is: POST / v1 / devops / workflows. This message carries the following parameters: workflow name (workflowName), operator ID (operatorId), workflow type (workflowType), steps included in the workflow (steps), priority calculation parameters (priorityCalculationParams), and dynamic priority adjustment strategy (dynamicPriorityAdjustment). The workflow contains two steps, each further including: step name (step name), execution order (sequence), and step description (description). The priority calculation parameters further include: business level (businessLevel) and dependency relationship (dependencyRelation). The dependency relationship further includes: the identifier of the dependent workflow (dependentWorkflowId) and the identifiers of other workflows that depend on the current workflow (dependencyWorkflowId).

[0188] Table 8. Creation Workflow Messages for Workflow A

[0189] The parameters carried in the aforementioned workflow creation message define the test workflow configuration and priority calculation parameters for the temporary version of the vendor-delivered solution for targeted problem debugging and verification. Workflow A is created based on the parameters carried in the aforementioned workflow creation message, and priority is calculated using the basic workflow priority calculation formula P. A BL =w1*BL A The priority of workflow A is calculated; specifically, the business level BL of workflow A is... A =3, assuming the weight of the business level is w1=1, then: P A BL =w1*BL A =3.

[0190] After successfully creating workflow A, a workflow creation response message is sent to the management system. This workflow creation response message carries at least one of the following parameters: the created workflow identifier (workflowId=001), the created workflow priority (priority=3), the current execution order of the created workflow (executionOrder=1), and the creation result (status=success).

[0191] 2. Create workflow B

[0192] Specifically, the system receives a "Create Workflow" message for workflow B from the management system. Referring to Table 9 below, the interface access method for this message is: POST / v1 / devops / workflows. This message carries the following parameters: workflow name (workflowName), operator ID (operatorId), workflow type (workflowType), steps included in the workflow (steps), priority calculation parameters (priorityCalculationParams), and dynamic priority adjustment strategy (dynamicPriorityAdjustment). Each of the three steps in the workflow further includes: step name (step name), execution order (sequence), and step description (description). The priority calculation parameters further include: business level (businessLevel) and dependency relationship (dependencyRelation). The dependency relationship further includes: the identifier of the dependent workflow (dependentWorkflowId) and the identifiers of other workflows that depend on the current workflow (dependencyWorkflowId).

[0193] Table 9: Workflow B Creation Workflow Messages

[0194] The parameters carried in the above workflow creation message define the target version NS deployment workflow configuration and priority calculation parameters delivered by the vendor. Based on the parameters carried in the above workflow creation message, workflow B is created. Since the priority calculation parameter (dependentWorkflowId: 001) for workflow B specifies that workflow B depends on workflow A, the priority of workflow B needs to be calculated according to the workflow dependencies, and the priority of workflow A needs to be recalculated (see the following section on workflow priority orchestration for details).

[0195] 3. Workflow Prioritization

[0196] Calculate the total number of dependencies of workflow A, TotalDependents[A] = 1, and calculate the total number of dependencies of workflow B, TotalDependents[B] = 0;

[0197] The execution order of workflows can be determined based on the total number of dependencies of workflows A and B: workflow A is executed first, and workflow B is executed second.

[0198] The dependency parameter (DR) is set to a value range of 0-3. Based on the current workflow execution order, the dependency parameter value RD for workflow A is obtained. A =3, and the dependency parameter RD of workflow B. B =1.5.

[0199] Recalculate the business level (BL) for workflow A and workflow B. A =BL B = (3+3) / 2 = 3.

[0200] Assuming that the business priority weights of workflows A and B are both w1 = 0.5, and the dependency weights are both w2 = 0.5, recalculate the priority of workflow A: P A RD =w1*BL A +w2*RD A =0.5*3+0.5*3=3;

[0201] Calculate the priority of workflow B: P B RD =w1*BL B +w2*RD B =0.5*3+0.5*1.5=2.25.

[0202] After successfully creating workflow B, a workflow creation response message is sent to the management system. This workflow creation response message carries at least one of the following parameters: the created workflow identifier (workflowId=002), the created workflow priority (priority=2.25), the current execution ranking of the created workflow (executionOrder=2), and the creation result (status=success).

[0203] 4. Execute workflow A

[0204] After priority-based detection and control, workflow A has a higher priority than workflow B, and workflow A is executed first. Workflow A performs targeted problem debugging and verification according to the step sequence and monitors the task execution status in real time.

[0205] 5. Workflow A execution result feedback

[0206] Specifically, a workflow feedback message for workflow A is sent to the management system. Referring to Table 10 below, the interface access method for the workflow feedback message is: POST / v1 / devopsMS / workflows / feedback. This workflow feedback message carries the following parameters: workflowId, problemDescription, informationLocation, priorityAdjustmentReason, and feedbackTimestamp. Through this workflow feedback message, the test results and feedback status of workflow A can be returned to the management system, including whether the test was successful or not and any problems found.

[0207] Table 10 Workflow Feedback Messages for Workflow A

[0208] 6. Execute workflow B

[0209] After confirming the successful completion of Workflow A, Workflow B will begin execution. During the execution of Workflow B, the target version testing and deployment steps will be monitored in real time to ensure that each step is executed in sequence.

[0210] 7. Workflow B execution result feedback

[0211] Specifically, a workflow feedback message for workflow B is sent to the management system. Referring to Table 11 below, the interface access method for the workflow feedback message is: POST / v1 / devopsMS / workflows / feedback. This workflow feedback message carries the following parameters: workflowId, problemDescription, informationLocation, priorityAdjustmentReason, and feedbackTimestamp. This workflow feedback message can return the deployment result and feedback status of workflow B to the management system.

[0212] Table 11 Workflow Feedback Messages for Workflow B

[0213] Application Example 2

[0214] This application example demonstrates a dynamically adjusted workflow management approach. In this example, workflow A and workflow B are dependent on each other; workflow B must be executed after workflow A has successfully completed. Furthermore, dynamic priority adjustment is performed if workflow A fails. The specific execution steps of this application example are as follows (it should be noted that the default execution subject in the following steps is the operator-side integrated R&D and operations system; the management system described in the following steps specifically refers to the operator-side integrated R&D and operations management system):

[0215] 1. Create workflow A

[0216] Specifically, the system receives a workflow creation message for workflow A from the management system. Referring to Table 12 below, the interface access method for this workflow creation message is: POST / v1 / devops / workflows. This workflow creation message carries the following parameters: workflowName, operatorId, workflowType, steps included in the workflow, priorityCalculationParams, and dynamicPriorityAdjustment. The workflow contains two steps, each of which further includes: step name, execution sequence, and description. The priority calculation parameters further include: businessLevel, dependencyRelation, iterationCount, and resourceUtilization. The dependency relationship further includes: the identifier of the dependent workflow (dependentWorkflowId) and the identifiers of other workflows that depend on the current workflow (dependencyWorkflowId).

[0217] Table 12 Workflow A Creation Workflow Messages

[0218] The parameters carried in the aforementioned workflow creation message define the test workflow configuration and priority calculation parameters for the temporary version of the vendor-delivered solution for targeted problem debugging and verification. Workflow A is created based on the parameters carried in the aforementioned workflow creation message, and priority is calculated using the basic workflow priority calculation formula P. A BL =w1*BL A The priority of workflow A is calculated; specifically, the business level BL of workflow A is... A=3, assuming the weight of the business level is w1=1, then: P A BL =w1*BL A =3.

[0219] After successfully creating workflow A, a workflow creation response message is sent to the management system. This workflow creation response message carries at least one of the following parameters: the created workflow identifier (workflowId=001), the created workflow priority (priority=3), the current execution order of the created workflow (executionOrder=1), and the creation result (status=success).

[0220] 2. Create workflow B

[0221] Specifically, the system receives a "Create Workflow" message for workflow B from the management system. Referring to Table 13 below, the interface access method for this message is POST / v1 / devops / workflows. This message carries the following parameters: workflow name (workflowName), operator ID (operatorId), workflow type (workflowType), steps included in the workflow (steps), priority calculation parameters (priorityCalculationParams), and dynamic priority adjustment strategy (dynamicPriorityAdjustment). Each of the three steps in the workflow further includes: step name (step name), execution order (sequence), and step description (description). The priority calculation parameters further include: business level (businessLevel) and dependency relationship (dependencyRelation). The dependency relationship further includes: the identifier of the dependent workflow (dependentWorkflowId) and the identifiers of other workflows that depend on the current workflow (dependencyWorkflowId).

[0222] Table 13 Workflow B Creation Workflow Messages

[0223] The parameters carried in the above workflow creation message define the target version NS deployment workflow configuration and priority calculation parameters delivered by the vendor. Based on the parameters carried in the above workflow creation message, workflow B is created. Since the priority calculation parameter (dependentWorkflowId: 001) for workflow B specifies that workflow B depends on workflow A, the priority of workflow B needs to be calculated according to the workflow dependencies, and the priority of workflow A needs to be recalculated (see the following section on workflow priority orchestration for details).

[0224] 3. Workflow Prioritization

[0225] Calculate the total number of dependencies of workflow A, TotalDependents[A] = 1, and calculate the total number of dependencies of workflow B, TotalDependents[B] = 0;

[0226] The execution order of workflows can be determined based on the total number of dependencies of workflows A and B: workflow A is executed first, and workflow B is executed second.

[0227] The dependency parameter (DR) is set to a value range of 0-3. Based on the current workflow execution order, the dependency parameter value RD for workflow A is obtained. A =3, and the dependency parameter RD of workflow B. B =1.5.

[0228] Recalculate the business level (BL) for workflow A and workflow B. A =BL B = (3+3) / 2 = 3.

[0229] Assuming that the business priority weights of workflows A and B are both w1 = 0.5, and the dependency weights are both w2 = 0.5, recalculate the priority of workflow A: P A RD =w1*BL A +w2*RD A =0.5*3+0.5*3=3;

[0230] Calculate the priority of workflow B: P B RD =w1*BL B +w2*RD B =0.5*3+0.5*1.5=2.25.

[0231] After successfully creating workflow B, a workflow creation response message is sent to the management system. This workflow creation response message carries at least one of the following parameters: the created workflow identifier (workflowId=002), the created workflow priority (priority=2.25), the current execution ranking of the created workflow (executionOrder=2), and the creation result (status=success).

[0232] 4. Execute workflow A

[0233] After priority-based detection and control, workflow A has a higher priority than workflow B, and workflow A is executed first. Workflow A performs targeted problem debugging and verification according to the step sequence and monitors the task execution status in real time.

[0234] 5. Workflow A execution result feedback

[0235] Specifically, a workflow feedback message for workflow A is sent to the management system. Referring to Table 14 below, the interface access method for the workflow feedback message is: POST / v1 / devopsMS / workflows / feedback. This workflow feedback message carries the following parameters: workflowId, problemDescription, informationLocation, priorityAdjustmentReason, and feedbackTimestamp. Through this workflow feedback message, the test results and feedback status of workflow A can be returned to the management system, including whether the test was successful or not and any problems found.

[0236] Table 14 Workflow Feedback Messages for Workflow A

[0237] 6. Dynamic adjustment of workflow priority

[0238] When workflow A fails, its priority is increased based on workflow feedback messages, and a dynamic workflow priority calculation mechanism is used to recalculate workflow A's priority. Specifically, workflow A's business level BL... A =3, the dependency parameter RD of workflow A is taken as RD. A =3, the abnormal state parameter EX value of workflow A A =1, assuming the business level weight of workflow A is w1 = 0.5, the dependency weight is w2 = 0.5, and the abnormal state weight is w3 = 0.1, then recalculate the priority of workflow A: P AEX =w1*BL A +w2*DR A ++w3*EX A =0.5*3+0.5*3+0.1*1=3.1.

[0239] Since workflow B is dependent on workflow A, after updating the priority of workflow A, it is still necessary to compare it with the priority of workflow B. The comparison shows that the priority of the updated workflow A (3.1) is higher than the priority of workflow B (2.25). Therefore, there is no need to adjust the priority of workflow B.

[0240] 7. Re-execute workflow A after priority update.

[0241] After priority-based detection and control, workflow A is prioritized over workflow B. Workflow A is then re-executed, and it performs targeted problem debugging and verification in the order of steps while monitoring the task execution status in real time.

[0242] 8. Feedback on the execution results of workflow A again.

[0243] Specifically, a workflow feedback message for workflow A is sent to the management system. Referring to Table 15 below, the interface access method for the workflow feedback message is: POST / v1 / devopsMS / workflows / feedback. This workflow feedback message carries the following parameters: workflowId, problemDescription, informationLocation, priorityAdjustmentReason, and feedbackTimestamp. Through this workflow feedback message, the test results and feedback status of workflow A can be returned to the management system, including whether the test was successful or not and any problems found.

[0244] Table 15 Workflow Feedback Messages for Workflow A

[0245] 9. Execute workflow B

[0246] After confirming the successful completion of Workflow A, Workflow B will begin execution. During the execution of Workflow B, the target version testing and deployment steps will be monitored in real time to ensure that each step is executed in sequence.

[0247] 10. Workflow B execution result feedback

[0248] Specifically, a workflow feedback message for workflow B is sent to the management system. Referring to Table 16 below, the interface access method for the workflow feedback message is: POST / v1 / devopsMS / workflows / feedback. This workflow feedback message carries the following parameters: workflowId, problemDescription, informationLocation, priorityAdjustmentReason, and feedbackTimestamp. This workflow feedback message can return the deployment result and feedback status of workflow B to the management system.

[0249] Table 16 Workflow Feedback Messages for Workflow B

[0250] Figure 5 is a schematic diagram of the structure of the workflow orchestration device provided in an embodiment of this application, applied to a server. As shown in Figure 5, the workflow orchestration device includes:

[0251] The determining unit 501 is configured to determine the priority of each workflow in one or more workflows; and to determine the execution order of the one or more workflows based on the priority of each workflow in the one or more workflows.

[0252] In some embodiments, the determining unit 501 is configured to calculate the priority of each workflow based on priority calculation parameters for each of the one or more workflows; wherein the priority calculation parameters include one or more of the following:

[0253] The first parameter, which characterizes the business level of the workflow;

[0254] The second parameter characterizes the dependencies of the workflow;

[0255] The third parameter characterizes the abnormal state of the workflow;

[0256] The fourth parameter characterizes the blocking state of the workflow.

[0257] In some implementations, the determining unit 501 is configured to calculate the priority of the workflow based on a first parameter and a first weight, wherein the first weight is a business level weight; or, to calculate the priority of the workflow based on a first parameter, a first weight, a second parameter, and a second weight, wherein the first weight is a business level weight and the second weight is a dependency weight; or, to calculate the priority of the workflow based on a first parameter, a first weight, a second parameter, a second weight, and at least one of the following: a third parameter, a third weight, a fourth parameter, and a fourth weight, wherein the first weight is a business level weight, the second weight is a dependency weight, the third weight is an abnormal state weight, and the fourth weight is a blocked state weight.

[0258] In some implementations, the determining unit 501 is configured to: determine the total number of dependencies of each workflow in the one or more workflows, where the total number of dependencies refers to the total number of workflows that the workflow depends on; sort the execution order of the one or more workflows based on the total number of dependencies of each workflow in the one or more workflows; check whether there is a workflow in the sort that is preceding the workflow and depends on the workflow; if so, adjust the workflow to precede the workflow that is preceding the workflow and depends on the workflow; and determine the value of a second parameter of each workflow in the one or more workflows based on the sorting of the one or more workflows.

[0259] In some embodiments, the determining unit 501 is configured to recalculate the priority of the workflow based on the updated priority calculation parameters if the priority calculation parameters of the workflow are updated; wherein the reasons for updating the priority calculation parameters include at least one of the following:

[0260] The business level of the workflow has been updated;

[0261] The workflow dependencies are updated;

[0262] The abnormal status of the workflow has been updated;

[0263] The workflow's blocking status is updated.

[0264] In some implementations, the determining unit 501 is configured to determine the execution order of the at least two workflows based on their creation time if at least two workflows in the one or more workflows have the same priority.

[0265] In some embodiments, the apparatus further includes: an interface unit 502 configured to receive a first message sent by the management system through a first interface, and / or send a second message to the management system; wherein the first message is used for workflow management, and the second message is used for workflow feedback.

[0266] In some implementations, the interface unit 502 is configured to receive a workflow creation message sent by the management system, the workflow creation message carrying at least one of the following parameters: workflow name, operator identifier, workflow type, processes included in the workflow, priority calculation parameters, and dynamic priority adjustment strategy; and to send a workflow creation response message to the management system, the workflow creation response message carrying at least one of the following parameters: created workflow identifier, created workflow priority, current execution ranking of the created workflow, and creation result.

[0267] In some embodiments, the interface unit 502 is configured to receive an update workflow message sent by the management system, the update workflow message carrying at least one of the following parameters: workflow identifier, update content, updated workflow type, processes included in the updated workflow, updated priority calculation parameters, and updated dynamic priority adjustment strategy; and to send an update workflow response message to the management system, the update workflow response message carrying at least one of the following parameters: updated workflow identifier, updated workflow priority, current execution ranking of the updated workflow, and update result status.

[0268] In some embodiments, the interface unit 502 is configured to receive a delete workflow message sent by the management system, the delete workflow message carrying the following parameters: workflow identifier; and to send a delete workflow response message to the management system, the delete workflow response message carrying at least one of the following parameters: the deleted workflow identifier, and the deletion result status.

[0269] In some implementations, the interface unit 502 is configured to receive a query workflow message sent by the management system, the query workflow message carrying at least one of the following parameters: workflow identifier, first query parameter, and second query parameter; the first query parameter represents the current priority of the query workflow, and the second query parameter represents the historical adjustment record of the query workflow priority; and to send a query workflow response message to the management system, the query workflow response message carrying at least one of the following parameters: workflow identifier, current status of the workflow, currently executing process of the workflow, current priority of the workflow, historical adjustment record of the workflow priority, and current execution ranking of the workflow.

[0270] In some implementations, the interface unit 502 is configured to send a workflow feedback message to the management system. The workflow feedback message carries at least one of the following parameters: workflow identifier, feedback problem description, information file acquisition address, priority adjustment reason, and feedback timestamp.

[0271] Those skilled in the art should understand that the functions of each unit in the workflow orchestration apparatus shown in Figure 5 can be understood with reference to the relevant description of the aforementioned method. The functions of each unit in the workflow orchestration apparatus shown in Figure 5 can be implemented by a program running on a processor, or by specific logic circuits.

[0272] Figure 6 is a schematic structural diagram of a server 600 provided in an embodiment of this application. The server 600 shown in Figure 6 includes a processor 610, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0273] Optionally, as shown in FIG6, the server 600 may further include a memory 620. The processor 610 may retrieve and run computer programs from the memory 620 to implement the methods described in the embodiments of this application.

[0274] The memory 620 can be a separate device independent of the processor 610, or it can be integrated into the processor 610.

[0275] Optionally, as shown in FIG6, the server 600 may further include a transceiver 630, which the processor 610 may control to communicate with other devices. Specifically, it may send information or data to other devices or receive information or data sent by other devices.

[0276] The transceiver 630 may include a transmitter and a receiver. The transceiver 630 may further include antennas, and the number of antennas may be one or more.

[0277] The server 600 can implement the corresponding processes of the various methods implemented in the embodiments of this application, which will not be described in detail here for the sake of brevity.

[0278] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0279] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0280] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0281] This application also provides a computer-readable storage medium for storing a computer program. This computer program causes a computer to execute the corresponding processes implemented by the various methods of this application embodiment; for brevity, these will not be elaborated upon here.

[0282] This application also provides a computer program product, including computer program instructions. These computer program instructions cause a computer to execute the corresponding processes implemented by the various methods of this application embodiment; for brevity, they will not be described in detail here.

[0283] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0284] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0285] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and 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 through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0286] 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.

[0287] In addition, the functional units in the various embodiments of this application 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.

[0288] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of 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), random access memory (RAM), magnetic disks, or optical disks.

[0289] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A workflow orchestration method, the method comprising: Determine the priority of each workflow in one or more workflows; The execution order of the one or more workflows is determined based on the priority of each workflow in the one or more workflows.

2. The method according to claim 1, wherein, Determining the priority of each workflow in one or more workflows includes: For each of the one or more workflows, a priority of the workflow is calculated based on priority calculation parameters; wherein the priority calculation parameters include one or more of the following: The first parameter, which characterizes the business level of the workflow; The second parameter characterizes the dependencies of the workflow; The third parameter characterizes the abnormal state of the workflow; The fourth parameter characterizes the blocking state of the workflow.

3. The method according to claim 2, wherein, The calculation of the priority of the workflow based on the priority calculation parameters of the workflow includes: The priority of the workflow is calculated based on the first parameter and the first weight, where the first weight is the weight of the business level; or, The priority of the workflow is calculated based on the first parameter, the first weight, the second parameter, and the second weight, where the first weight is the weight of the business level and the second weight is the weight of the dependency relationship; or, The priority of the workflow is calculated based on the first parameter, the first weight, the second parameter, the second weight, and at least one of the following: the third parameter, the third weight, the fourth parameter, and the fourth weight. The first weight is the weight of the business level, the second weight is the weight of the dependency relationship, the third weight is the weight of the abnormal state, and the fourth weight is the weight of the blocked state.

4. The method according to claim 2, wherein, The method further includes: Determine the total number of dependencies for each workflow in the one or more workflows, where the total number of dependencies refers to the total number of workflows that the workflow depends on; The execution order of the one or more workflows is sorted based on the total number of dependencies of each workflow in the one or more workflows; Check if there is a workflow in the sorting that precedes and depends on the workflow; if so, adjust the workflow to precede the workflow that precedes and depends on the workflow. The value of the second parameter for each of the one or more workflows is determined based on the order of the workflows.

5. The method according to claim 2, wherein, The method further includes: If the priority calculation parameters of the workflow are updated, the priority of the workflow is recalculated based on the updated priority calculation parameters; wherein the reasons for updating the priority calculation parameters include at least one of the following: The business level of the workflow has been updated; The workflow dependencies have been updated; The abnormal status of the workflow has been updated; The workflow's blocking status is updated.

6. The method according to any one of claims 1 to 5, wherein, The method further includes: If at least two of the one or more workflows have the same priority, the execution order of the at least two workflows is determined based on their creation time.

7. The method according to any one of claims 1 to 5, wherein, The method further includes: The system receives a first message from the management system via a first interface, and / or sends a second message to the management system; wherein the first message is used for workflow management, and the second message is used for workflow feedback.

8. The method according to claim 7, wherein, The first message sent by the receiving management system includes: Receive a workflow creation message sent by the management system. The workflow creation message carries at least one of the following parameters: workflow name, operator identifier, workflow type, processes included in the workflow, priority calculation parameters, and dynamic priority adjustment strategy. The method further includes: sending a workflow creation response message to the management system, the workflow creation response message carrying at least one of the following parameters: the workflow identifier, the workflow priority, the current execution ranking of the workflow, and the creation result.

9. The method according to claim 7, wherein, The first message sent by the receiving management system includes: Receive an update workflow message sent by the management system. The update workflow message carries at least one of the following parameters: workflow identifier, update content, updated workflow type, processes included in the updated workflow, updated priority calculation parameters, and updated dynamic priority adjustment strategy. The method further includes: sending an update workflow response message to the management system, the update workflow response message carrying at least one of the following parameters: updated workflow identifier, updated workflow priority, updated workflow current execution ranking, and update result status.

10. The method according to claim 7, wherein, The first message sent by the receiving management system includes: Receive a delete workflow message sent by the management system. The delete workflow message carries the following parameters: workflow identifier; The method further includes: sending a delete workflow response message to the management system, the delete workflow response message carrying at least one of the following parameters: the identifier of the deleted workflow, and the deletion result status.

11. The method according to claim 7, wherein, The first message sent by the receiving management system includes: The system receives a query workflow message sent by the management system. The query workflow message carries at least one of the following parameters: workflow identifier, first query parameter, and second query parameter; the first query parameter represents the current priority of the query workflow, and the second query parameter represents the historical adjustment record of the query workflow priority. The method further includes sending a query workflow response message to the management system, the query workflow response message carrying at least one of the following parameters: workflow identifier, current status of the workflow, currently executing process of the workflow, current priority of the workflow, historical adjustment record of workflow priority, and current execution ranking of the workflow.

12. The method according to claim 7, wherein, Sending the second message to the management system includes: Send a workflow feedback message to the management system. The workflow feedback message carries at least one of the following parameters: workflow identifier, feedback problem description, information file retrieval address, priority adjustment reason, and feedback timestamp.

13. A workflow orchestration apparatus, the apparatus comprising: The determination unit is configured to determine the priority of each workflow in one or more workflows; The execution order of the one or more workflows is determined based on the priority of each workflow in the one or more workflows.

14. A server, comprising: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the method as described in any one of claims 1 to 12.

15. A computer-readable storage medium for storing a computer program that causes a computer to perform the method as claimed in any one of claims 1 to 12.

16. A computer program product comprising computer program instructions that cause a computer to perform the method as described in any one of claims 1 to 12.

Images