A workflow orchestration system and method

Abstract

This disclosure provides a workflow orchestration system and method, relating to the field of artificial intelligence technology, and particularly to the field of deep learning technology. The system includes: a client, configured to receive a first workflow definition file input by a user, and in response to a user-triggered submission command, send a task submission request to a server, the task submission request including the workflow definition file and a specified orchestrator type; a server, configured to compile the workflow definition file into a language format applicable to the specified orchestrator type to obtain a second workflow definition file, and send a first task command to an orchestrator module, the first task command including the second workflow definition file; and an orchestrator module, configured to use a specified orchestrator to call components in a component module to run the workflow based on the second workflow definition file, wherein the specified orchestrator is an orchestrator of the specified orchestrator type. This disclosure improves the convenience of workflow orchestration.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence technology, and more particularly to the field of deep learning technology. Background Technology

[0002] To adapt to the industrial application of deep learning technology, the Artificial Intelligence (AI) production line system allows engineers in different industry scenarios to independently define production line processes, thereby obtaining AI production lines that conform to the characteristics of industry scenarios. Summary of the Invention

[0003] This disclosure provides a workflow orchestration system and method.

[0004] According to a first aspect of this disclosure, a workflow orchestration system is provided, comprising: a client, a server, an orchestrator module, a component module, and a data storage module, wherein the orchestrator module includes multiple types of orchestrators;

[0005] The client is configured to receive a first workflow definition file input by the user, and in response to a submission command triggered by the user, send a task submission request to the server. The task submission request includes the workflow definition file, running parameters, and a first orchestrator type.

[0006] The server is configured to respond to the task submission request by storing the running parameters in the data storage module, compiling the first workflow definition file into a language format applicable to the first orchestrator type to obtain a second workflow definition file, and sending a first task instruction to the first orchestrator in the orchestrator module, wherein the first task instruction includes the second workflow definition file and the first orchestrator is an orchestrator of the first orchestrator type.

[0007] The first orchestrator is used to call the components in the component module to run the workflow based on the second workflow definition file, wherein the parameters required for the components to run the workflow are the running parameters stored in the data storage module.

[0008] According to a second aspect of this disclosure, a workflow orchestration method is provided for use on a server, the method comprising:

[0009] Receive a task submission request sent by a client, the task submission request including a first workflow definition file, running parameters and a first orchestrator type;

[0010] The first workflow definition file is compiled into a language format applicable to the first orchestrator type to obtain a second workflow definition file, and the running parameters are saved in the data storage module;

[0011] A first task instruction is sent to the first orchestrator in the orchestrator module. The first task instruction includes the second workflow definition file, so that the first orchestrator calls the components in the component module to run the workflow based on the second workflow definition file. The first orchestrator is an orchestrator of the first orchestrator type. The parameters required for the components to run the workflow are the running parameters stored in the data storage module.

[0012] According to a third aspect of this disclosure, an electronic device is provided, comprising:

[0013] At least one processor; and

[0014] A memory communicatively connected to the at least one processor; wherein,

[0015] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in the second aspect.

[0016] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are configured to cause the computer to perform the method described in the second aspect.

[0017] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in the second aspect.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0019] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0020] Figure 1 This is a schematic diagram of the structure of a workflow orchestration system provided in an embodiment of this disclosure;

[0021] Figure 2 This is a schematic diagram of another workflow orchestration system provided in this embodiment of the disclosure;

[0022] Figure 3 This is a schematic diagram of the logical structure of a component provided in an embodiment of this disclosure;

[0023] Figure 4 This is an exemplary schematic diagram of a custom component provided in an embodiment of this disclosure;

[0024] Figure 5 This is a flowchart of a workflow orchestration method provided in an embodiment of this disclosure;

[0025] Figure 6 This is an interactive flowchart of a workflow orchestration method provided in an embodiment of this disclosure;

[0026] Figure 7 This is a schematic diagram of an electronic device structure for a workflow orchestration method provided in an embodiment of this disclosure. Detailed Implementation

[0027] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0028] The process of AI algorithms is similar to an assembly line in a factory. The assembly line may vary in different industry scenarios, but it is fixed for the same product. By repeatedly triggering the assembly line, the function of the model can be realized. A set of assembly lines can be called an AI production line.

[0029] Currently, engineers can design AI production lines using AI production line systems. AI production line systems fall under the category of Machine Learning Operations (MLOps), and their core functions are workflow construction, debugging, and operation.

[0030] There are currently various workflow orchestrators, such as kubeflow pipeline, airflow, and jekins. kubeflow pipeline, airflow, and jekins are all workflow orchestrator names. Each orchestrator has its own unique branching and task execution methods, and each orchestrator is best suited for different industry scenarios.

[0031] During the AI ​​production line construction phase, the AI ​​production line system can provide multiple orchestrators. Users can then select the desired orchestrator and write workflow definition files using the language applicable to that orchestrator. This requires users to understand the orchestrator's workflow definition and operation, placing a high demand on them. Alternatively, the AI ​​production line system can provide users with visual nodes, allowing them to build workflows by dragging and dropping nodes. Each node corresponds to a run script. This method is compatible with multiple orchestrators but lacks branching logic, resulting in less flexibility.

[0032] This disclosure provides a workflow orchestration system, such as Figure 1 As shown, the system includes a client 11, a server 12, an orchestrator module 13, a component module 14, and a data storage module 15. The orchestrator module 13 includes various types of orchestrators, and the component module includes multiple components 141.

[0033] The client 11 can be deployed in a terminal device, which can be an electronic device with a display screen, such as a mobile phone, tablet computer, or desktop computer.

[0034] Server-side module 12, orchestrator module 13, and component module 14 can be deployed in a distributed cluster across multiple servers, or they can be deployed on a single server. This makes the system suitable for both single-machine and cluster deployments, facilitating delivery.

[0035] Client 11 is used to receive the first workflow definition file input by the user and, in response to the submission command triggered by the user, send a task submission request to server 12. The task submission request includes the workflow definition file, running parameters and the first orchestrator type.

[0036] The client application can be implemented using a notebook plugin, which is an AI development platform. The client displays a workflow editing interface where users can edit the first workflow definition file and input runtime parameters. After editing, if the user clicks the submit button, the client receives the submission command triggered by the user.

[0037] Specifically, the workflow editing interface can be a YAML editing interface. Accordingly, the first workflow definition file is a YAML file. YAML is a highly readable format used to express data serialization, so the workflow definition file can be constructed using a simple language.

[0038] The first arranger type is the arranger type selected by the user.

[0039] Server 12 can provide the client with an interface for managing AI offline tasks in the form of Hypertext Transfer Protocol (HTTP) or Remote Procedure Call Protocol (RPC). Client 11 can then send task submission requests to the server via HTTP or RPC. That is, the task submission request can be an HTTP message or an RPC message.

[0040] Server 12 is used to respond to workflow task submission requests, save running parameters in data storage module 15, compile the first workflow definition file into a language format applicable to the first orchestrator type to obtain the second workflow definition file, and send a first task instruction to the first orchestrator in orchestrator module 13. The first task instruction includes the second workflow definition file, and the first orchestrator is an orchestrator of the first orchestrator type.

[0041] For example, if the first orchestrator type is airflow, then the first orchestrator is an airflow orchestrator.

[0042] Understandably, since each type of orchestrator uses a different language format, in order for the first orchestrator to recognize the workflow definition file, the server 12 can compile the first workflow definition file into the language format applicable to the first orchestrator type after receiving the task submission request.

[0043] The orchestrator module 13 includes various types of orchestrators. The server 12 can call the interface of the first orchestrator in the orchestrator module 13 to send the first task instruction to the first orchestrator.

[0044] Optionally, the orchestrator module 13 can provide submission interfaces, query interfaces, and abort interfaces for various types of orchestrators. If the server 12 needs to initiate a task to the first orchestrator, it can call the submission interface of the first orchestrator. If the server 12 needs to query the task status, it can call the query interface. If the server 12 needs to abort the task, it can call the abort interface.

[0045] The first orchestrator in orchestrator module 13 is used to call components in component module 14 to run the workflow based on the second workflow definition file.

[0046] The parameters required for the component to run the workflow are the running parameters stored in the data storage module 15. That is, the component can obtain the running parameters from the data storage module 15 and run the workflow under the scheduling of the first orchestrator.

[0047] In this embodiment, the task submission request sent by the client to the server includes a workflow definition file and a first orchestrator type input by the user. The server can compile the first workflow definition file into a language format suitable for the first orchestrator type. This eliminates the need for the user to write the workflow definition file in a language format appropriate for the first orchestrator type, reducing user requirements and simplifying operations. Furthermore, this method supports multiple orchestrator types, offering high adaptability. Subsequently, the server can send the compiled second workflow definition file to the first orchestrator in the orchestrator module. The first orchestrator then calls components to run the workflow based on the second workflow definition file. Compared to script-based methods, running the workflow through components allows for more complex execution logic and offers greater flexibility, thus balancing ease of use and flexibility.

[0048] Optionally, new orchestrator types can be added to the orchestrator module, and the corresponding language format for that orchestrator type can be added to the server, thereby expanding the types of orchestrators that the workflow orchestration system can adapt to.

[0049] Optionally, client 11 is also used to query the workflow's running status from server 12 and display the workflow's running status.

[0050] Optionally, the client 11 can proactively query the workflow's running status from the server 12, and can perform real-time queries to display the workflow's running status to the user in real time.

[0051] For example, the operating status can include normal operating status, stopped status, and abnormal status.

[0052] In this way, the client displays the workflow's running status without having to jump to the third-party platform's display interface of the orchestrator, and users can also view the workflow's running status, improving convenience.

[0053] In addition, the client can display detailed running status of workflows in a specified orchestrator.

[0054] Client 11 is also used to query the dashboard page link of the first orchestrator from server 12 when it receives a user-triggered request to query detailed running status, and to display the dashboard page link. The dashboard page corresponding to the dashboard page link displays the detailed running status of the workflow.

[0055] Once a user clicks the dashboard page link, they will be redirected to the dashboard page, which displays the detailed running status of the workflow in the specified orchestrator.

[0056] Specifically, this detailed operational status can include detailed information about the operation of each component.

[0057] By using the embodiments of this disclosure, users can select to query the detailed running status of the workflow according to their own needs, and then debug the first workflow definition file based on the detailed running status, thereby improving the convenience for users.

[0058] In this embodiment of the disclosure, when debugging the workflow, two running modes are supported: local running and remote running.

[0059] In remote operation mode, client 11 is also used to request orchestrator type information from server 12.

[0060] When a user triggers a submission command, if the client 11 determines that the user has selected the remote running mode, it can request the orchestrator type information from the server.

[0061] The server 12 is also used to send information about the types of orchestrators supported by the orchestrator module 13 to the client 11.

[0062] Client 11 is also used to display information on the types of orchestrators supported by orchestrator module 13 and to identify the first orchestrator type selected by the user.

[0063] Understandably, after the user selects the first orchestrator type, the client 11 can include the first orchestrator type in the job submission request.

[0064] By using the embodiments of this disclosure, the client can request the type of orchestrator supported by the orchestrator module from the server, so that the user can select the appropriate orchestrator type. That is, the system can support multiple orchestrator types, and the user can choose flexibly and make full use of the characteristics of each type of orchestrator, thereby improving the flexibility of production line deployment and the convenience of user use.

[0065] Furthermore, in remote operation mode, after recognizing a submission command, if the client 11 recognizes that the submission command includes a local operation command, it parses the first workflow definition file and calls the client host machine or container to run the parsed first workflow definition file as a process. Thus, this embodiment of the present disclosure can also support a local operation mode, allowing users to flexibly choose the required operation mode.

[0066] Understandably, after a user triggers the submission command, they can debug the first workflow definition file based on the actual running status, and then release it to the production line after completing the debugging.

[0067] Client 11 is also used to send production line release requests to server 12.

[0068] The production line release request includes a third workflow definition file, running parameters, and a first orchestrator type. The third workflow definition file is the file obtained after debugging the first workflow definition file.

[0069] Server 12 is also used to compile the third workflow definition file into a language format applicable to the first orchestrator type to obtain the fourth workflow definition file, and store the fourth workflow definition file and running parameters in the data storage module 15 with the workflow identifier as an index; and send a production line release response to client 11, which includes the workflow identifier.

[0070] The workflow identifier is the workflow identifier registered by the server 12 for the production line to publish the request. As an example, the workflow identifier can be pipeline-id.

[0071] In this embodiment of the disclosure, during the production line release phase, after receiving the production line release request, the server compiles the third workflow definition file into a language format suitable for the first orchestrator type, obtaining a fourth workflow definition file. Using the workflow identifier as an index, the fourth workflow definition file and its runtime parameters are stored in the data storage module. Furthermore, when a released production line needs to be run subsequently, the compiled fourth workflow definition file can be directly retrieved based on the workflow identifier, eliminating the need for recompilation and improving workflow runtime efficiency.

[0072] Furthermore, after a production line is released, users can choose to run it. For example, this released production line could be an AI production line, specifically a workflow for a deep learning model. Once the production line is released, the construction of the deep learning model is complete, and users can subsequently use the system's application state to train the model.

[0073] Client 11 is also used to send production line task execution instructions to server 12, which include workflow identifiers.

[0074] Server 12 is also used to respond to production line task execution instructions, retrieve the fourth workflow definition file from data storage module 15 using the workflow identifier as an index, and send a second task instruction to the first arranger in the arranger module 13. The second task instruction includes the fourth workflow definition file and the workflow identifier.

[0075] The first orchestrator in orchestrator module 13 is used to call components in component module 14 to run workflows based on the fourth workflow definition file.

[0076] The components in component module 14 are used to obtain the running parameters corresponding to the workflow flow identifier from data storage module 15, and run the workflow based on the running parameters under the scheduling of the first orchestrator.

[0077] The component can obtain running parameters from the data storage module 15, and can store the output results generated after running in the data storage module 15 so that other components can call them.

[0078] Optionally, the component can also feed the output back to the first orchestrator, enabling the orchestrator to implement advanced branching structures, such as ifelse logic, which is a programming statement.

[0079] In this embodiment of the disclosure, the production line task execution instruction sent by the client carries a workflow identifier. Subsequently, the server can use the workflow identifier as an index to obtain the corresponding workflow definition file from the data storage module. The component can also use the workflow identifier as an index to call the corresponding running parameters to run the workflow definition file. That is, the information transmission in the system is realized through the data storage module, so that the server and components can obtain the required information more quickly, thereby improving the operating efficiency of the workflow orchestration system.

[0080] Optionally, in another embodiment of this disclosure, after receiving the production line release request, the server 12 may also store a third workflow definition file in the data storage module using the workflow identifier as an index.

[0081] Therefore, when the production line needs to be run in the future, the solution described in the above embodiments can be adopted, and the production line will be run by default with the first orchestrator type when the production line is released, that is, the workflow will be run using the fourth workflow definition file.

[0082] Additionally, the type of programmable controller used can be changed when the production line needs to be run.

[0083] Client 11 is also used to send production line task execution instructions to server 12. The production line task execution instructions include a workflow identifier and a second orchestrator type, where the second orchestrator type is the orchestrator type reselected by the user.

[0084] Server 12, in response to the production line task execution command, retrieves the third workflow definition file from the data storage module 15, compiles the third workflow definition file into a language format suitable for the second orchestrator type to obtain the fifth workflow definition file, and stores the fifth workflow definition file in the data storage module 15; and sends a third task command to the second orchestrator in the orchestrator module 13, the third task command including the fifth workflow definition file and a workflow identifier. The second orchestrator is an orchestrator of the second orchestrator type.

[0085] The second orchestrator in orchestrator module 13 is used to call components in component module 14 to run the workflow based on the fifth workflow definition file.

[0086] The components in component module 14 are used to obtain the running parameters corresponding to the workflow identifier from data storage module 15, and run the workflow based on the running parameters under the scheduling of the second orchestrator.

[0087] In this embodiment of the disclosure, the data storage module also stores an uncompiled third workflow definition file. When running a published production line, the user can also change the type of orchestrator to be used according to real-time business needs. The server can then compile the third workflow definition file according to the changed orchestrator type, so that the workflow can be run by the orchestrator with the changed type. It can be seen that the system is highly flexible and the user can switch the orchestrator type according to needs.

[0088] In this embodiment of the disclosure, the user can also modify the operating parameters before running the production line. For example, when it is necessary to train the model, the operating parameters can be modified to training sample data.

[0089] Client 11 is also used to, upon receiving a user-triggered request to run a specified production line, if it is determined that the specified production line is being run for the first time after being published, obtain the running parameters stored in the data storage module 15 when the specified production line was published, and display the obtained running parameters; if it is recognized that the user has modified the running parameters, it carries the modified running parameters in the production line task running instruction.

[0090] The specified production line's operation request includes the workflow identifier corresponding to the specified production line. After the client 11 sends the workflow identifier to the server 12, the server 12 uses the workflow identifier as an index to obtain the corresponding operation parameters from the data storage module 15. Then, the client 11 can display the obtained operation parameters for the user to modify.

[0091] The server 12 is also used to update the running parameters indexed by the workflow identifier in the data storage module 15 based on the modified running parameters if the received production line task running instructions include modified running parameters.

[0092] Using the above embodiments, before running a specified production line, the client can provide users with an interface to modify the operating parameters, allowing users to modify the operating parameters of the specified production line, which facilitates user operation and makes the system more flexible, allowing users to modify the operating parameters as needed.

[0093] As an example, Figure 2 This is an exemplary schematic diagram of the structure of a workflow orchestration system provided in an embodiment of the present disclosure. The system includes a client 11, a server 12, a data storage module 15, an orchestrator module 13, and a component module 14, wherein the component module 14 includes multiple components.

[0094] The client can be implemented based on a notebook plugin. The client can run in development mode or application mode. Development mode is for developers to debug workflows or release production lines, while application mode is for users to use the released production lines.

[0095] Client 11 can include a YAML editing interface, a workflow (pipeline) debugging and management interface, and a deployment and execution interface. The YAML editing interface is for developers to edit workflow definition files in YAML format, the pipeline debugging and management interface is for users to debug workflow definition files, and the deployment and execution interface is for developers to deploy AI production lines or run deployed AI production lines.

[0096] Client 11, in development mode, receives workflow definition files edited by the user in the YAML editing interface. Based on these workflow definition files, it can run the workflow locally or request server 12 to run the workflow remotely, allowing the user to debug based on the results. After debugging, it can publish the production line to server 12 based on the user's instructions.

[0097] Client 11, in application mode, is used to trigger the production line based on the user's instructions, that is, to request the server 12 to run the published production line.

[0098] If the server 12 is logically divided into functional layers, it can be divided into a task receiving layer, a workflow compilation layer, a workflow management layer, and an orchestrator driver adaptation layer.

[0099] The task receiving layer can expose the management interface for AI offline tasks to the client, and then receive work task submission, query and abort requests, production line release requests and production line operation requests sent by the client 11 based on the management interface.

[0100] The workflow compilation layer is used to compile workflow definition files from various received requests into a language format suitable for the user-specified orchestrator type. For example, if client 11 sends a workflow definition file in YAML format, the user-specified orchestrator type is A, and the language format suitable for this type of orchestrator is 'a', then the workflow compilation layer can compile the YAML format workflow definition file into an 'a' format workflow definition file.

[0101] The workflow management layer, upon receiving a production line release request from client 11, stores the compiled workflow definition file and runtime parameters in data storage module 15 using the workflow identifier as an index, and returns the workflow identifier to client 11. Optionally, the uncompiled workflow definition file can also be stored in data storage module 15.

[0102] The workflow management layer is also used to obtain the running parameters of the production line during the last run or when the production line was released from the data storage module 15 after receiving the production line pre-run request of the released production line, and return the obtained running parameters to the client 11 so that the client 11 can display them to the user for modification.

[0103] The workflow management layer, upon receiving a published production line run request, retrieves the workflow definition file from the data storage module 15 using the production line's workflow identifier as an index, and sends the workflow definition file to the workflow compilation layer. This workflow definition file is the user-input workflow definition file. It also adapts to changes in the running parameters stored in the data storage module 15 upon receiving subsequent modifications from the user.

[0104] The orchestrator driver adaptation layer is used to send workflow definition files to the user-specified type of orchestrator in the orchestrator module 13 through the orchestrator interface, based on the user-specified orchestrator type.

[0105] The orchestrator driver adaptation layer abstracts interfaces for submission, query, and abort. If a submission request for a work task of a specified orchestrator type is received, the submission interface of the orchestrator of that specified orchestrator type is called; if a query request for a specified orchestrator type is received, the query interface of the orchestrator of that specified orchestrator type is called.

[0106] The orchestrators in orchestrator module 13 are used to call components within the workflow file to run the workflow. Orchestrator module 13 includes various types of orchestrators, such as kubeflow pipeline, airflow, and argo. The orchestrators supported in orchestrator module 13 can be pre-registered on server 12. If other types of orchestrators need to be added later, they only need to be registered with server 12, and an interface for adding new orchestrators should be provided to server 12, demonstrating good extensibility.

[0107] The data storage module 15 provides a unified interface for data storage, deletion, modification, and querying. Furthermore, databases can be deployed within the data storage module 15 according to user needs; for example, one or more of file systems, object storage databases, relational databases, and non-relational databases can be deployed. In other words, the system supports multiple databases, offering greater flexibility.

[0108] The components in component module 14 are used to obtain the running parameters corresponding to the workflow definition file from data storage module 15 during the debugging phase of the workflow definition file, and also to obtain the running parameters corresponding to the workflow identifier from data storage module 15 during the production line operation phase, so as to run the workflow based on the obtained running parameters.

[0109] Figure 2 Taking component module 14 as an example of a Kubernetes cluster, Kubernetes is an open-source container orchestration engine. The cluster includes Pod1-Podn. A Pod is a component in Kubernetes, and each Pod can contain one or more containers.

[0110] Here, components are the node units that make up the workflow. Optionally, components can be defined using a YAML format similar to standard components in kubeflowpipeline. For example... Figure 3 As shown, the components may include: an input data control layer, an AI business logic layer, and an output data control layer.

[0111] When the component is running, the input data control layer is used to read metadata and running parameters from the data storage module 15.

[0112] The AI ​​business logic layer is used to run workflows based on the acquired operating parameters.

[0113] The output data control layer is used to feed back the running results to the orchestrator, thereby supporting the implementation of the orchestrator's advanced branching structure (such as ifelse), and storing the running results in the data storage module 15.

[0114] As an example, Figure 3 The document displays the component's definition information, including the component name (name:Train), description (description:demo), input information (inputs: {name:task_id,type:String}), and output information (outputs: {name:output_path,type:String}). It should be noted that... Figure 3 The definitions shown are for illustrative purposes only and are not limited to those in actual implementation.

[0115] If secondary development of components is required, or new components are added, you only need to focus on the implementation of the AI ​​business logic layer code. Specifically, you can use a Software Development Kit (SDK) to develop and register standard components. Once registered, the components can be called by the orchestrator.

[0116] Furthermore, the components in this embodiment can also meet the needs of custom code, and can trigger user-written custom code in any language through a pre-built custom code component. For example... Figure 4As shown, for example, users can customize components using programming languages ​​such as Python, Java, R, and Shell. If they need to control the custom code component to run locally, the client can invoke the component via an entry command to run the workflow using a local process. Alternatively, if remote execution is required, the user can input the custom image name corresponding to the custom code component when triggering a request, allowing the orchestrator to invoke the custom component in the Kubernetes container orchestration engine based on that custom image name. This further enhances the flexibility of the workflow orchestration system.

[0117] Corresponding to the above system embodiments, this disclosure also provides a workflow orchestration method, which is applied to the server side, such as... Figure 5 As shown, the method includes:

[0118] S501. Receive a task submission request sent by the client. The task submission request includes a first workflow definition file, running parameters, and a first orchestrator type.

[0119] The first workflow definition file is a YAML file.

[0120] S502. Compile the first workflow definition file into a language format applicable to the first orchestrator type to obtain the second workflow definition file, and save the running parameters in the data storage module.

[0121] S503. Send a first task instruction to the first orchestrator in the orchestrator module. The first task instruction includes a second workflow definition file, so that the first orchestrator calls the component in the component module to run the workflow based on the second workflow definition file. The parameters required for the component to run the workflow are the running parameters stored in the data storage module.

[0122] Among them, the first arranger is an arranger of the first arranger type.

[0123] In this embodiment, the task submission request sent by the client to the server includes a workflow definition file and a first orchestrator type input by the user. The server can compile the first workflow definition file into a language format suitable for the first orchestrator type. This eliminates the need for the user to write the workflow definition file in a language format appropriate for the first orchestrator type, reducing user requirements and simplifying operations. Furthermore, this method supports multiple orchestrator types. Subsequently, the server can send a compiled second workflow definition file to the first orchestrator in the orchestrator module. The first orchestrator then calls components to run the workflow based on the second workflow definition file. Compared to script-based methods, running the workflow through components allows for more complex execution logic and offers greater flexibility, thus balancing ease of use and flexibility.

[0124] like Figure 6 As shown, Figure 6 An interactive flowchart of a workflow orchestration method provided in this disclosure embodiment is shown, the method comprising:

[0125] S601, The client sends a task submission request to the server.

[0126] The task submission request includes a first workflow definition file, runtime parameters, and a first orchestrator type. The first workflow definition file is a file edited by the user in the client's workflow editing interface, and can be in YAML format.

[0127] Optionally, prior to S601, the server may receive a request from the client to obtain the orchestrator type, and in response to the request, send the orchestrator type information supported by the orchestrator module to the client. The first orchestrator type is an orchestrator type selected by the user from the orchestrator type information supported by the orchestrator module.

[0128] S602. The server compiles the first workflow definition file into a language format applicable to the first orchestrator type to obtain the second workflow definition file.

[0129] S603, the server stores the runtime parameters in the data storage module.

[0130] S602 and S603 can be executed in parallel or in a specific order. This embodiment does not restrict the execution order of S602 and S603. Figure 6 Let's take S602 as an example.

[0131] S604. The server sends the first task instruction to the first arranger in the arranger module.

[0132] The first task instruction includes a second workflow definition file, and the first task instruction is used to instruct the first orchestrator to run the workflow based on the second workflow definition file.

[0133] S605, The first orchestrator calls the components in the component module to run the workflow based on the second workflow definition file.

[0134] Users can then debug the first workflow definition file based on the workflow's execution status. After debugging, production line deployment can proceed. Subsequent steps S606-S609 describe the production line deployment process.

[0135] S606. The client sends a production line release request to the server. The production line release request includes the third workflow definition file, running parameters, and the first orchestrator type.

[0136] The third workflow definition file is the file obtained after debugging the first workflow definition file.

[0137] S607. The server compiles the third workflow definition file into a language format applicable to the first orchestrator type to obtain the fourth workflow definition file.

[0138] Since each type of orchestrator recognizes the corresponding computer language, the user-defined third workflow definition file needs to be compiled so that subsequent orchestrators can recognize and execute the fourth workflow definition file.

[0139] S608: The server uses the workflow identifier as an index to store the fourth workflow definition file and running parameters in the data storage module.

[0140] S609. The server sends a production line release response to the client, which includes a workflow identifier.

[0141] After the production line is released, it can be run in application mode. S610-S613 then outline the process for running the production line.

[0142] S610: The client sends a production line task execution instruction to the server. The production line task execution instruction includes a workflow identifier.

[0143] S611. The server retrieves the fourth workflow definition file from the data storage module using the workflow identifier as an index.

[0144] S612, The server sends a second task instruction to the first orchestrator in the orchestrator module. The second task instruction includes a fourth workflow definition file and a workflow identifier.

[0145] S613, The first orchestrator calls the components in the component module to run the workflow based on the fourth workflow definition file.

[0146] Using the above method, the server can compile the workflow definition file into a workflow definition file of the first orchestrator type based on the user-edited workflow definition file and the selected first orchestrator type. Based on this, the first type of orchestrator can recognize the compiled workflow definition file and call the component to execute it. In other words, the user-edited workflow definition file can be adapted to multiple orchestrators. When the production line is deployed, the relevant parameters and workflow file corresponding to the workflow identifier are sent to the data storage module for storage. When the production line is running, the workflow file in the data storage module can be directly called, and then sent to the orchestrator module. The orchestrator in the orchestrator module calls the component in the component module to complete the workflow execution. This method of directly obtaining the workflow file and relevant parameters based on the workflow identifier improves operational efficiency. Furthermore, on the client side, users only need to edit the workflow definition file and specify the orchestrator type, improving the convenience of user operation.

[0147] Optionally, before running the production line, users can modify the operating parameters. Specifically, before step S612, the server can determine if the production line execution command includes the modified operating parameters. If it does, the server updates the operating parameters indexed by the workflow identifier in the data storage module based on the modified parameters. After the update is complete, step S612 is executed. Subsequent components can then run the business flow based on the modified operating parameters. This allows users to flexibly modify operating parameters to meet diverse business needs.

[0148] In another embodiment of this disclosure, the database storage module also stores a third workflow definition file indexed by the workflow identifier. Based on this, during the production line operation phase, the user can further change the scheduler type, specifically including the following steps:

[0149] Step 1: Receive the production line task execution instruction sent by the client. The production line task execution instruction includes a workflow identifier and a second orchestrator type. The second orchestrator type is the orchestrator type reselected by the user.

[0150] Step 2: In response to the production line task execution command, retrieve the third workflow definition file from the data storage module based on the workflow identifier.

[0151] Step 3: Compile the third workflow definition file into a language format suitable for the second orchestrator type to obtain the fifth workflow definition file, and store the fifth workflow definition file in the data storage module.

[0152] Step 4: Send a third task instruction to the second orchestrator so that the second orchestrator can call the components in the component module to run the workflow based on the fifth workflow definition file; wherein, the third task instruction includes the fifth workflow definition file and the workflow identifier, the second orchestrator is an orchestrator of the second orchestrator type; the parameters required for the components to run the workflow are the running parameters corresponding to the workflow identifier stored in the data storage module.

[0153] In this embodiment of the disclosure, the data storage module also stores an uncompiled third workflow definition file. When running a published production line, the user can also change the type of orchestrator to be used according to real-time business needs. The server can then compile the third workflow definition file according to the changed orchestrator type, so that the workflow can be run by the orchestrator with the changed type. It can be seen that the system is highly flexible and the user can switch the orchestrator type according to needs.

[0154] It should be noted that the method embodiments are basically similar to the system embodiments, so the description is relatively simple. For relevant details, please refer to the description of the system embodiments.

[0155] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0156] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product. The electronic device can be a server containing the aforementioned server-side component.

[0157] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0158] like Figure 7As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded from storage unit 708 into random access memory (RAM) 703. RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0159] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0160] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as workflow orchestration methods. For example, in some embodiments, the workflow orchestration method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the workflow orchestration method described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform workflow orchestration methods by any other suitable means (e.g., by means of firmware).

[0161] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0162] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0163] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0164] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0165] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0166] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0167] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0168] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A workflow orchestration system, comprising: The system comprises a client, a server, an orchestrator module, a component module, and a data storage module. The orchestrator module includes various types of orchestrators, each of which is applicable to different language formats. The client is configured to receive a first workflow definition file input by the user, and in response to a submission command triggered by the user, send a task submission request to the server. The task submission request includes the first workflow definition file, running parameters, and a first orchestrator type. The server is configured to respond to the task submission request by storing the running parameters in the data storage module, compiling the first workflow definition file into a language format applicable to the first orchestrator type to obtain a second workflow definition file, and sending a first task instruction to the first orchestrator in the orchestrator module, wherein the first task instruction includes the second workflow definition file and the first orchestrator is an orchestrator of the first orchestrator type. The first orchestrator is used to call the components in the component module to run the workflow based on the second workflow definition file, wherein the parameters required for the components to run the workflow are the running parameters stored in the data storage module.

2. The system according to claim 1, wherein, The client is also used to request orchestrator type information from the server; The server is also used to send the orchestrator type information supported by the orchestrator module to the client; The client is also used to display the orchestrator type information supported by the orchestrator module and to identify the first orchestrator type selected by the user.

3. The system according to claim 1 or 2, further comprising a data storage module; The client is also used to send a production line release request to the server. The production line release request includes a third workflow definition file, running parameters, and the first orchestrator type. The third workflow definition file is a file obtained after debugging the first workflow definition file. The server is further configured to compile the third workflow definition file into a language format applicable to the first orchestrator type to obtain a fourth workflow definition file, store the fourth workflow definition file and the running parameters in the data storage module using the workflow identifier as an index, and send a production line release response to the client, the production line release response including the workflow identifier.

4. The system according to claim 3, wherein, The client is also used to send production line task execution instructions to the server, wherein the production line task execution instructions include the workflow identifier; The server is also configured to respond to the production line task execution instruction, retrieve the fourth workflow definition file from the data storage module using the workflow identifier as an index, and send a second task instruction to the first arranger in the arranger module, wherein the second task instruction includes the fourth workflow definition file and the workflow identifier; The first orchestrator is used to call the components in the component module to run the workflow based on the fourth workflow definition file; The components in the component module are used to obtain the running parameters corresponding to the workflow flow identifier from the data storage module, and run the workflow under the scheduling of the first orchestrator based on the running parameters.

5. The system according to claim 4, wherein, The client is also configured to, upon receiving a user-triggered request to run a specified production line, if it is determined that the specified production line is being run for the first time after being published, obtain the running parameters stored in the data storage module when the specified production line was published, and display the obtained running parameters. If a user's modification of the operating parameters is detected, the modified operating parameters will be included in the production line task execution instruction. The server is further configured to update the running parameters indexed by the workflow identifier in the data storage module based on the modified running parameters if the received production line task running instruction includes modified running parameters.

6. The system according to claim 3, wherein, The server is also used to store the third workflow definition file in the data storage module using the workflow identifier as an index; The client is also used to send a production line task execution instruction to the server. The production line task execution instruction includes the workflow identifier and the second orchestrator type, where the second orchestrator type is the orchestrator type reselected by the user. The server is configured to respond to the production line task execution command, retrieve the third workflow definition file from the data storage module, compile the third workflow definition file into a language format applicable to the second orchestrator type to obtain a fifth workflow definition file, and store the fifth workflow definition file in the data storage module; Send a third task instruction to the second orchestrator in the orchestrator module. The third task instruction includes the fifth workflow definition file and the workflow identifier. The second orchestrator is an orchestrator of the second orchestrator type. The second orchestrator is used to call the components in the component module to run the workflow based on the fifth workflow definition file; The components in the component module are used to obtain the running parameters corresponding to the workflow flow identifier from the data storage module, and run the workflow under the scheduling of the second orchestrator based on the running parameters.

7. The system according to claim 1, wherein, The client is also used to query the workflow's running status from the server and display the workflow's running status.

8. The system according to claim 7, wherein, The client is also configured to, upon receiving a user-triggered request to query detailed running status, query the server for the dashboard page link of the first orchestrator and display the dashboard page link, wherein the dashboard page corresponding to the dashboard page link displays the detailed running status of the workflow.

9. The system according to claim 1, wherein, The language format of the first workflow definition file is YAML.

10. A workflow orchestration method, wherein, Applied to the server side, the method includes: Receive a task submission request sent by a client, the task submission request including a first workflow definition file, running parameters and a first orchestrator type; The first workflow definition file is compiled into a language format applicable to the first orchestrator type to obtain a second workflow definition file, and the running parameters are saved in the data storage module; A first task instruction is sent to the first orchestrator in the orchestrator module. The first task instruction includes the second workflow definition file, so that the first orchestrator calls the components in the component module to run the workflow based on the second workflow definition file. The first orchestrator is an orchestrator of the first orchestrator type. The parameters required for the components to run the workflow are the running parameters stored in the data storage module. The orchestrator module includes multiple types of orchestrators, and each orchestrator is applicable to different language formats.

11. The method according to claim 10, wherein, Before receiving the task submission request sent by the client, the method includes: Receive a request from the client to obtain orchestrator type information; In response to the request to obtain orchestrator type information, the orchestrator type information supported by the orchestrator module is sent to the client, wherein the first orchestrator type is an orchestrator type selected by the user from the orchestrator type information supported by the orchestrator module.

12. The method according to claim 10 or 11, further comprising: Receive a production line release request sent by the client. The production line release request includes a third workflow definition file, running parameters, and the first orchestrator type. The third workflow definition file is a file obtained after debugging the first workflow definition file. The third workflow definition file is compiled into a language format applicable to the first orchestrator type to obtain the fourth workflow definition file; The fourth workflow definition file and the running parameters are stored in the data storage module using the workflow identifier as an index. Send a production line release response to the client, the production line release response including the workflow identifier.

13. The method of claim 12, further comprising, after sending the production line release response to the client: Receive the production line task execution instruction sent by the client, wherein the production line task execution instruction includes the workflow identifier; In response to the production line task execution instruction, the fourth workflow definition file is retrieved from the data storage module using the workflow identifier as an index; A second task instruction is sent to the first orchestrator in the orchestrator module, so that the first orchestrator calls the components in the component module to run the workflow based on the fourth workflow definition file. The second task instruction includes the fourth workflow definition file and the workflow identifier. The parameters required for the component to run the workflow are the running parameters corresponding to the workflow identifier stored in the data storage module.

14. The method according to claim 13, wherein, Before sending the second task instruction to the first arranger in the arranger module, the method further includes: If the production line task execution instruction includes modified execution parameters, then based on the modified execution parameters, the execution parameters indexed by the workflow identifier in the data storage module are updated.

15. The method according to claim 12, wherein, The data storage module also stores the third workflow definition file, indexed by the workflow identifier; the method further includes: Receive production line task execution instructions sent by the client, wherein the production line task execution instructions include the workflow identifier and the second orchestrator type, wherein the second orchestrator type is the orchestrator type reselected by the user; In response to the production line task execution instruction, the third workflow definition file is retrieved from the data storage module according to the workflow identifier; The third workflow definition file is compiled into a language format applicable to the second orchestrator type to obtain a fifth workflow definition file, and the fifth workflow definition file is stored in the data storage module; A third task instruction is sent to the second orchestrator to cause the second orchestrator to call the components in the component module to run the workflow based on the fifth workflow definition file; wherein, the third task instruction includes the fifth workflow definition file and the workflow identifier, the second orchestrator is an orchestrator of the second orchestrator type; the parameters required for the component to run the workflow are the running parameters corresponding to the workflow identifier stored in the data storage module.

16. The method of claim 10, wherein, The language format of the first workflow definition file is YAML.

Images