Process orchestration methods, apparatus, electronic equipment, and storage media

Abstract

To provide a process orchestration method and apparatus, an electronic device, and a storage medium for effectively describing diversified task types in practical service, thereby improving the compatibility and usability of an orchestration engine.SOLUTION: A method includes: generating a to-be-orchestrated service process, in response to a node selection operation and a node parameter configuration operation based on an interface; and executing the nodes in the service process successively according to an order of the nodes in the service process. By implementing visualized process orchestration, the efficiency of process orchestration is improved and the difficulty of orchestration is reduced, to support selection of synchronous nodes and asynchronous nodes. The method enables orchestration of synchronization nodes and orchestration of asynchronous nodes in the service process.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] This application relates to the technical field of computer applications, and specifically, to a process orchestration method, apparatus, electronic device, and storage medium.

Background Art

[0002] Process orchestration refers to the process of combining each task related to a certain executable process in the order of execution by an orchestration engine. However, the current orchestration engine is inferior in orchestration ability, while the tasks related to the actual business process are often diversified. Therefore, the current orchestration engine cannot adapt to the diversified orchestration needs in the actual business process.

Summary of the Invention

Problems to be Solved by the Invention

[0003] The objective of the embodiments of this application is to provide a process orchestration method, apparatus, electronic device, and storage medium for improving the problem that the current orchestration engine cannot adapt to the diversified orchestration needs in the actual business process and is inferior in the availability of the orchestration engine.

Means for Solving the Problems

[0004] In the first aspect, an embodiment of the present invention provides a process orchestration method. This method generates business processes requiring orchestration in response to interface-based node selection operations and node parameter setting operations. Nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes. Synchronous nodes represent tasks that can be executed without waiting for external operations, while asynchronous nodes represent tasks that cannot be executed without waiting for external operations. Furthermore, the nodes in the business process are executed sequentially according to the order of the nodes in the business process.

[0005] The above method can be applied to process orchestration engines. In the implementation process described above, users perform node selection and node parameter setting operations on an interface to generate business processes that require orchestration, thereby realizing visualized process orchestration. Since this orchestration process does not require writing a large amount of code, the efficiency of process orchestration is improved and the probability of code syntax errors is reduced. In addition, the business process orchestration process becomes more visual and easier to operate for general users.

[0006] Furthermore, in node selection operations, the nodes that can be selected include both synchronous and asynchronous nodes. That is, it is possible to orchestrate synchronous nodes in a business process to realize tasks that can be executed without waiting for external operations, or to orchestrate asynchronous nodes to realize tasks that cannot be executed without waiting for external operations (of course, these two types of nodes can be orchestrated simultaneously). As a result, the resulting business processes can effectively describe the diverse types of tasks in actual business operations, thus improving the problem that conventional orchestration engines could not adapt to the orchestration needs of actual business processes, and improving the compatibility and availability of the orchestration engine.

[0007] Selectively, in embodiments of the present invention, the properties of a node include a node identifier, a flow instance identifier, and a thread identifier. The node identifier is used to identify different nodes within a business process. Also, one flow instance is created each time the business process is executed. The flow instance identifier is used to identify the flow instance to which the node belongs. A flow instance contains one or more threads. The thread identifier is used to identify the thread to which the node belongs. A thread is a concurrent execution branch within a flow instance.

[0008] In the implementation process described above, introducing threads into flow instances improves process execution efficiency. Furthermore, by setting properties such as node identifiers, flow instance identifiers, and thread identifiers for each node, and distinguishing different entities related to the execution of business processes, it becomes advantageous in ensuring the accuracy and reliability of process execution.

[0009] Selectively, in embodiments of the present invention, if the external operation corresponding to the asynchronous node is an operation in which a user submits data on a target page, the steps of executing the asynchronous node include the following: obtaining the node identifier, flow instance identifier, and thread identifier of the asynchronous node, and concatenating the node identifier, flow instance identifier, and thread identifier of the asynchronous node to generate the address of the target page. Next, notifying the user executing the external operation corresponding to the asynchronous node of the address of the target page in a pre-configured manner, and receiving the data submitted by the user on the target page. The data includes business data, the node identifier, flow instance identifier, and thread identifier of the asynchronous node.

[0010] In the implementation process described above, the node identifier, flow instance identifier, and thread identifier of the asynchronous node are concatenated to generate the address of the target page, and this address is then notified to the user. This allows the user to submit the node identifier, flow instance identifier, and thread identifier of the asynchronous node along with the data submitted on the target page. These identifiers allow the thread of the flow instance to which the asynchronous node belongs to be located, enabling subsequent nodes to continue executing after the asynchronous node. In other words, the implementation process described above enables support for asynchronous nodes at the execution level, effectively enhancing the compatibility and availability of the process orchestration engine.

[0011] Selectively, in the embodiments of the present invention, a node pointer is provided for each thread within a flow instance. The node pointer indicates the node currently executing within the thread. After receiving data submitted by the user on the target page, the method further includes: obtaining the node identifier of the asynchronous node, the flow instance identifier, and the thread identifier from the data submitted by the user, and identifying the target node pointer based on the flow instance identifier and the thread identifier. The target node pointer is the node pointer corresponding to the flow instance and thread to which the asynchronous node belongs. If the node identifier of the asynchronous node matches the node identifier of the node indicated by the target node pointer, the execution of the nodes in the business process from the asynchronous node onward is continued.

[0012] In the implementation process described above, the node pointer indicates the node currently executing within the thread. Furthermore, the target node pointer is identified using the flow instance identifier and thread identifier in the user-submitted data, and a decision is made whether to continue execution by comparing the node identifiers. This is convenient for controlling and managing the movement of execution logic between nodes within a flow instance, ensuring the accuracy and reliability of process execution.

[0013] Selectively, in the embodiments of the present application, the target page includes a form page or an approval page.

[0014] In the implementation process described above, the target pages include form pages or approval pages. Because different business processes can be implemented depending on the format of the target pages, this is advantageous in improving the availability of the process orchestration engine, and is particularly applicable to enterprise settings (since filling out forms and approving tasks are common in businesses).

[0015] Selectively, in the embodiments of the present invention, if the target page is a form page of an edited form, generating the address of the target page by concatenating the node identifier, flow instance identifier, and thread identifier of the asynchronous node includes the following: obtaining the form instance identifier corresponding to the edited form, and generating the address of the target page by concatenating the node identifier, flow instance identifier, thread identifier, and form instance identifier of the asynchronous node. The form instance identifier is used to retrieve the form data of the edited form, and the form data is used to render the target page. In addition, the data submitted by the user on the target page includes the updated form data, the node identifier of the asynchronous node, the flow instance identifier, the thread identifier, and the form instance identifier.

[0016] In the implementation process described above, if the target page is the form page of an edited form, the form instance identifier is concatenated to the address of the target page so that the form data of the edited form can be searched based on the form instance identifier, and that form data can be presented to the user on the target page. This allows the user to re-edit the form based on the edited form, thereby enabling the reuse of the form data. Furthermore, when the user submits the updated form data, the form instance identifier is submitted along with the node identifier, flow instance identifier, and thread identifier of the asynchronous node. This allows the process orchestration engine to manage the updated form data based on the form instance identifier.

[0017] Selectively, in embodiments of the present invention, pre-configured methods for notifying users who perform external operations corresponding to asynchronous nodes include the following:

[0018] Method 1: Obtain user information of the user executing the external operation corresponding to the asynchronous node, and send notification information to the user based on the user information. The notification information includes the address of the target page.

[0019] Method 2: Retrieves the user's To-Do list. It also generates a target To-Do item based on the address of the target page. The target To-Do item is used to instruct the user to proceed to the target page. The target To-Do item is added to the user's To-Do list.

[0020] Third method: Obtain a list of user data. Additionally, generate interaction buttons based on the target page address. These interaction buttons are used to instruct the user to proceed to the target page. The interaction buttons are added to the user's data list.

[0021] The above implementation process provides diverse and flexible notification methods for users, allowing users to select the appropriate method based on specific application scenarios and page requirements. This enables users to obtain the address of the target page, proceed to the page, and complete the external actions corresponding to the asynchronous node.

[0022] Selectively, in embodiments of the present invention, if the external operation corresponding to the asynchronous node is a callback operation of a target function by a third party, the steps for executing the asynchronous node include: storing the node identifier, flow instance identifier, and thread identifier of the asynchronous node in association with the function identifier of the target function corresponding to the asynchronous node; then, calling an interface provided by the third party to send the function identifier to the third party; and then, in response to a call to the target function by the third party using the function identifier, identifying the node identifier, flow instance identifier, and thread identifier of the asynchronous node stored in association with the function identifier based on the function identifier of the called target function.

[0023] In the implementation process described above, the external operation corresponding to the asynchronous node may be a callback operation of the target function by a third party. By sending a function identifier to the third party, the node identifier, flow instance identifier, and thread identifier of the asynchronous node, which are stored in association with the function identifier, are identified based on the function identifier of the called target function. Then, by positioning the thread of the flow instance to which the asynchronous node belongs using these identifiers, subsequent nodes can continue to execute after the asynchronous node. In other words, according to the implementation process described above, support for asynchronous nodes is realized at the execution level.

[0024] In addition, it can be seen that the asynchronous nodes in the embodiments of the present application can support external operations in many application scenarios (for example, operations such as form filling and approval executed by humans, and function call back operations executed by devices). Thereby, the diversified orchestration needs in the actual business process can be better satisfied, so the compatibility and availability of the process orchestration engine are effectively enhanced.

[0025] Optionally, in the embodiments of the present application, a node pointer is provided for each thread in the flow instance. The node pointer indicates the node currently being executed within the thread. After identifying the node identifier, flow instance identifier, and thread identifier of the asynchronous node stored in association with the function identifier, the method further includes the following. That is, based on the flow instance identifier and thread identifier of the asynchronous node, a target node pointer is identified. The target node pointer is the node pointer corresponding to the flow instance and thread to which the asynchronous node belongs. If the node identifier of the asynchronous node matches the node identifier of the node indicated by the target node pointer, then the nodes after the asynchronous node in the business process are continuously executed.

[0026] In the above realization process, by comparing whether the node identifier of the asynchronous node matches the node identifier of the node indicated by the target node pointer, it is determined whether to continuously execute the nodes after the asynchronous node. This is convenient for controlling and managing the movement of the execution logic between nodes within the flow instance, and the accuracy and reliability of the process execution are ensured.

[0027] Optionally, in the embodiments of the present application, a loop node is included in the node. A loop node is a node that needs to repeat the execution of child nodes in the loop body until the loop termination condition is satisfied. The parameters of the loop node include a parallel property. When the parallel property of the loop node is set to parallel execution when the loop node is executed, under the thread to which the loop node belongs, generate the same number of secondary threads as the sum of the values taken by the loop variable of the loop node, and use the secondary threads to parallelly execute the loop body when the loop variable takes each value. On the other hand, when the parallel property of the loop node is set to non-parallel execution when the loop node is executed, use the thread to which the loop node belongs to repeatedly execute the loop body according to the change of the loop variable.

[0028] In the above implementation process, a loop node is included in the node. The parallel property of the loop node can be set to parallel execution and non-parallel execution, and the parallel property of the loop node can be set as needed. When the parallel property of the loop node is set to parallel execution, since multiple secondary threads are generated and the loop body is executed in parallel, the execution efficiency and performance of the loop node can be improved.

[0029] Optionally, in the embodiments of the present application, when the parallel property of the loop node is set to parallel execution, the execution result of the loop node is obtained based on the execution results corresponding to each secondary thread.

[0030] In the above implementation process, when the parallel property of the loop node is set to parallel execution, the execution result of the loop node is obtained based on the execution results corresponding to each secondary thread. Thereby, corresponding rules can be set based on actual needs, and the execution results corresponding to each secondary thread can be mapped as the execution result of the loop node (for example, it becomes possible to perform weighting, statistics, etc. on the execution results of each thread). As a result, the execution logic of the loop node can better reflect actual business needs.

[0031] Selectively, in embodiments of the present invention, when the parallel property of a loop node is set to parallel execution, the loop termination conditions include the completion of execution of each secondary thread, the execution of any one secondary thread up to the loop's pre-termination instruction, or the execution of any one secondary thread timing out. Furthermore, after the execution of the loop node is completed, the generated secondary threads are discarded, and the nodes within the business process continue to be executed using the thread to which the loop node belongs.

[0032] In the implementation process described above, since there are multiple termination methods for the loop, the execution logic of the loop node can better reflect actual business needs. Furthermore, after the execution of the loop node is complete, the generated secondary thread is promptly discarded, freeing up resources such as memory, CPU, and network connection that the thread occupied. Then, by continuing to execute nodes within the business process using the thread to which the loop node belongs, the consumption of system resources during the execution of the business process can be reduced.

[0033] Selectively, in embodiments of the present invention, the rules for generating a node's thread identifier include the following: If a node is not a child node of a loop node whose concurrency property is set to concurrent execution, the node's thread identifier matches the flow instance identifier. On the other hand, if a node is a child node of a loop node whose concurrency property is set to concurrent execution, the node's thread identifier is generated based on the thread identifier of the loop node that is closest to the node among the child node's parent nodes and whose concurrency property is set to concurrent execution, and the loop number corresponding to the node. The loop number corresponding to the node is the number within the total range of values ​​that the loop variable corresponding to the thread to which the node belongs can take at that time.

[0034] In the implementation process described above, thread identifiers corresponding to nodes are generated based on rules. Such thread identifiers not only allow identification of the thread in which a node resides, but can also represent the parent-child relationships between nodes, making them convenient for managing nodes within a process.

[0035] Selectively, in the embodiments of the present invention, the business process includes a first node and a second node. Of these, the execution order of the first node is earlier than that of the second node. The node identifier, flow instance identifier, thread identifier, and execution result of the node are stored in association with each other after the node's execution is complete. If the parameters set for the second node include a reference to the execution result of the first node, the step of obtaining the execution result of the first node includes the following: that is, the node identifier and flow instance identifier of the first node are obtained. Next, in reverse order of the execution order of the business process, starting from the second node, nodes whose execution order of the business process is earlier than that of the second node are searched. During the search process, based on the thread identifier generation rules and the thread identifier of the second node, the thread identifier of each search target node is identified until the node identifier of the search target node becomes the node identifier of the first node, and the thread identifier of the first node is identified as the thread identifier of the search target node. Then, the execution result of the first node, which is stored in association with the node identifier, flow instance identifier, and thread identifier of the first node, is obtained.

[0036] In the implementation process described above, the execution results of a preceding node (e.g., the first node) can be obtained using the node identifier, flow instance identifier, and thread identifier generation rules of the preceding node. As a result, subsequent nodes in the business process (e.g., the second node) can refer to the execution results of the preceding node as input during their execution, leading to a richer range of input types for the node. Consequently, the node's execution logic can better reflect actual business needs.

[0037] In a second aspect, the embodiment of the present invention further provides a process orchestration device. The device is an orchestration module that generates business processes requiring orchestration in response to node selection operations and node parameter setting operations based on an interface, wherein the nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes, the synchronous nodes represent tasks that can be executed without waiting for external operations, and the asynchronous nodes represent tasks that cannot be executed without waiting for external operations, and the device includes an orchestration module and an execution module that executes the nodes in the business process in order according to the order of the nodes in the business process.

[0038] In a third aspect, embodiments of the present application further provide electronic equipment, which includes a processor and memory. The memory stores machine-readable instructions that the processor can execute, and the method described above is performed when the processor executes the machine-readable instructions.

[0039] In a fourth aspect, embodiments of the present invention further provide a computer-readable storage medium in which a computer program is stored, and the method described above is performed when the computer program is run by a processor. [Effects of the Invention]

[0040] By using the process orchestration method, apparatus, electronic equipment, and storage medium provided in this application, visualized programming is realized by generating business processes requiring orchestration through node selection operations and node parameter setting operations. This makes the process execution logic visible, displayable, and processable, making it more intuitive and easier to understand, and improving the speed of process development. Furthermore, since it is not necessary to write a large amount of code during the process orchestration process, the probability of code syntax errors is reduced. Moreover, in the node selection operation, the nodes that can be selected include synchronous nodes and asynchronous nodes. This enables orchestration and execution of synchronous nodes and / or asynchronous nodes, effectively enhancing the compatibility and availability of the process orchestration engine. As a result, the problems of limited application scope and poor availability of the process orchestration engine are improved.

[0041] To provide a clearer explanation of the technical means of the embodiments of this application, the drawings required for use in the embodiments of this application are briefly described below. It should be understood that the following drawings are merely examples of some embodiments of this application and should not be considered limiting in scope. Those skilled in the art may obtain other relevant drawings from these drawings without requiring any creative work. [Brief explanation of the drawing]

[0042] [Figure 1] Figure 1 is a schematic flowchart of the process orchestration method provided in the embodiment of the present application. [Figure 2] Figure 2 is a schematic diagram of the visualized orchestration interface provided in the embodiment of the present invention. [Figure 3] Figure 3 is a schematic diagram of the node parameter setting operation provided in the embodiment of the present invention. [Figure 4] Figure 4 is a schematic diagram of a loop node in an embodiment of the present invention where the parallel property is set to parallel execution. [Figure 5] Figure 5 is a schematic diagram of the execution process of a loop node in an embodiment of the present invention where the parallel property is set to non-parallel execution. [Figure 6] Figure 6 is a schematic diagram of the execution process of a loop node in an embodiment of the present invention where the parallel property is set to parallel execution. [Figure 7] Figure 7 is a schematic diagram of the execution process of the nested loop node provided in the embodiment of the present application. [Figure 8] Figure 8 is a schematic diagram showing how to refer to the execution results of the node provided in the embodiment of this application. [Figure 9] Figure 9 is a schematic diagram of a data table including an interaction button provided in an embodiment of the present application. [Figure 10] Figure 10 is a schematic diagram of the process orchestration apparatus provided in the embodiment of the present application. [Figure 11] Figure 11 is a schematic diagram of the electronic device provided in the embodiment of the present application. [Modes for carrying out the invention]

[0043] Next, the drawings will be combined to describe in detail embodiments of the technical means of the present application. The following embodiments are merely illustrative and should not limit the scope of protection of the present application, as they are intended only to provide a clearer explanation of the technical means of the present application.

[0044] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those generally understood by those skilled in the art. Furthermore, the terms used herein are solely for the purpose of describing specific embodiments and are not intended to limit this application.

[0045] In the descriptions of the embodiments of this application, technical terms such as "first," "second," etc., are merely used to distinguish different subjects and should not be interpreted as explicitly or implicitly indicating relative importance, nor as suggesting the number of technical features, a specific order, or a hierarchical relationship. Furthermore, in the descriptions of the embodiments of this application, unless otherwise clearly and specifically limited, "multiple" means two or more.

[0046] Before describing the process orchestration method provided in the embodiments of this application, we will first explain some concepts related to the embodiments of this application.

[0047] Typically, process orchestration refers to completing a business process through the orchestration of several nodes. Each node represents a task that needs to be completed in the business process. During the orchestration process, each node is combined sequentially to form a specific execution chain (i.e., a business process). Examples of nodes in this context include IF (single branch decision), IF-ELSE (two-branch decision), FOR (for loop), BREAK (exit loop), CONTINUE (end current loop), SWITCH (multi-branch selection), Function Call (various functions are possible), Create Variable (variable creation), Set Variable (variable setting), Return (return), Termination (end), etc.

[0048] A process orchestration engine is software that supports process orchestration functionality. The process orchestration engine in this application interacts with the user through a visualized interface, enabling process orchestration in response to orchestration operations performed by the user on the interface.

[0049] The inventors, through their research, realized that current process orchestration engines only support the orchestration of synchronous tasks. Synchronous tasks are tasks that can be completed automatically by following task logic and do not require waiting for external actions during execution. However, tasks related to actual business processes may include asynchronous tasks. Asynchronous tasks are tasks that cannot be executed without waiting for external actions. Since current process orchestration engines do not currently support the orchestration of asynchronous tasks, they cannot adapt to the diverse orchestration needs in actual business processes, resulting in inferior compatibility and availability of process orchestration engines.

[0050] The embodiments of this invention provide a process orchestration method, apparatus, electronic device, and storage medium that enable visualized process orchestration by allowing a user to perform node selection and node parameter setting operations on an interface to generate a business process requiring orchestration. In the node selection operation, the nodes that can be selected include synchronous nodes and asynchronous nodes. That is, it is possible to orchestrate synchronous nodes in a business process to support synchronous tasks, or to orchestrate asynchronous nodes to support asynchronous tasks. As a result, the resulting business process can effectively describe the diverse types of tasks in actual business operations, thereby improving the problem that conventional orchestration engines cannot adapt to the orchestration needs of actual business processes, and improving the compatibility and availability of the orchestration engine.

[0051] It should be understood that, in addition to the technical means provided in the embodiment of this application, the above analysis of the technical problems present in conventional process orchestration engines is not content that exists in the prior art, but rather represents the inventor's contribution to this application. Here, we refer to the schematic flowchart of the process orchestration method provided in the embodiment of this application shown in Figure 1. The process orchestration method provided in the embodiment of this application is applicable to electronic devices. A process orchestration engine is deployed in the electronic device. The process orchestration method can be executed by the process orchestration engine, but is not limited to this. The electronic device can be a terminal and a server having a computer program execution function. Specifically, the terminal can be a smartphone, tablet PC, computer, personal digital assistant (PDA), etc. Also, the server may be an application server or a web server. The number of electronic devices may be one or multiple, for example, a cluster composed of multiple servers. The electronic device may be a physical device or a virtual device. The process orchestration method may include the following.

[0052] Step S110: The process orchestration engine generates business processes requiring orchestration in response to node selection and node parameter setting operations based on the interface. Nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes. Synchronous nodes represent tasks that can be executed without waiting for external actions, while asynchronous nodes represent tasks that cannot be executed without waiting for external actions.

[0053] In step S110, the interface refers to a visualized orchestration interface for the user to perform process orchestration, such as a GUI of application software or a web page. The node selection operation is the operation in which the user selects a node for a business process that requires orchestration from among the nodes that are supported for selection within the interface. The node parameter setting operation is the operation in which the user sets parameters for the selected node. Naturally, other process orchestration-related operations that the user can perform on the interface are not excluded.

[0054] The interface and the process orchestration engine are related to each other. For example, the interface can be displayed on a user's terminal device (e.g., a smartphone or computer), and the process orchestration engine can be deployed on a backend server. Of course, this does not exclude the case where the interface and the process orchestration engine are located on the same device. Various process orchestration operations performed by the user on the interface can form corresponding operation data, which can then be transmitted to the process orchestration engine. This allows the process orchestration engine to detect and respond to the operations performed by the user.

[0055] Each node represents a task that the process orchestration engine supports the execution of. Users can configure business processes by selecting nodes based on the needs of their business processes. Regarding node selection operations, there are two types of nodes that users can select: synchronous nodes and asynchronous nodes. However, a single business process does not necessarily have to contain both types of nodes simultaneously; it may contain only one type. A synchronous node represents a task that can be executed without waiting for external actions. These are the synchronous tasks mentioned above. For example, tasks that perform data statistics based on pre-configured formulas, or tasks that send emails to pre-configured recipients. An asynchronous node represents a task that cannot be executed without waiting for external actions. These are the asynchronous tasks mentioned above. For example, a form-filling task that cannot be executed without waiting for a specific user to fill out a form; in this case, the user filling out the form is the so-called external action. Another example is a function callback task that cannot be executed without waiting for a callback from a third party (which could mean any software other than the process orchestration engine); in this case, the callback from the third party is the so-called external action. However, it should be noted that asynchronous tasks can sometimes be divided into multiple internal components. Some of these components may be able to execute automatically, while others may require external action to execute. However, when considering the task as a whole, it is considered that either it cannot execute without waiting for external action, or its execution cannot be completed without waiting for external action.

[0056] As a selective approach, Figure 2 is a schematic diagram of a visualized orchestration interface provided in an embodiment of the present invention. Referring to Figure 2, the visualized orchestration interface may include a selection interface and a process configuration interface. The process configuration interface is used to display business processes that have already been orchestrated at that time. The selection interface is used to display nodes that support selection (can be abbreviated as selection nodes). As described above, selection nodes may include two types: synchronous nodes and asynchronous nodes. For example, a node selection operation can be an operation in which the user selects the required node from the selection nodes displayed in the selection interface and drags it to the appropriate position in the process configuration interface, or an operation in which the user clicks on the required node on the selection interface to select it, and the clicked node is automatically displayed in the appropriate position in the process configuration interface.

[0057] In the process configuration interface, the user may determine the execution order of nodes by connecting the nodes selected in the node selection operation with links. Alternatively, in either implementation method, the nodes may be connected automatically (for example, clicking on any node automatically connects it to the end of the business process).

[0058] Some nodes have configurable parameters. These nodes cannot be executed correctly unless the user sets the appropriate parameters. Of course, this does not exclude cases where the process orchestration engine can specify default parameters for a node even if the user does not set the parameters. Here, refer to the schematic diagram of the node parameter setting operation provided in the embodiment of the present invention shown in Figure 3. An IF node is a node whose parameters can be set. In the node parameter setting operation, for example, when the user places the mouse over an IF node or clicks on an IF node, the interface on the right pops up. This interface displays input boxes that allow the user to set specific parameters for the IF node, for example, setting the condition for the IF node (in this case, the amount is less than 500).

[0059] In some implementations, in addition to node selection and node parameter setting operations, users may also perform other orchestration operations on the interface, such as node deletion. Referring again to Figure 3, a delete button may be displayed when the mouse hovers over the current node in the business process (e.g., the first SET node or the second SET node). This allows the node to be deleted when the user clicks the delete button.

[0060] Orchestrated business processes may be described within the orchestration engine according to certain syntax rules. For example, a node may be described by a set of fields, and these fields may be nested with each other. Next, we will explain possible ways of describing nodes within a process orchestration engine, using the IF-ELSE node in Figure 3 (an IF-ELSE node can be considered a combination of an IF node and an ELSE node; this node implements the logic of an if-else statement in structured programming) as an example. This node includes several fields: id, type, nodeName, condition, subFlow, and elseSubFlow. id is the node identifier, type is the node type, nodeName is the node name, and condition is the node's setting condition (e.g., amount is less than 500). subFlow represents the subflow that should be executed if the condition is met, and may include fields corresponding to one or more nodes (e.g., the first SET node). Furthermore, these fields may be nested within subFlow. elseSubFlow represents the subflow to be executed if the condition is not met, and may contain fields corresponding to one or more nodes (e.g., the second SET node). These fields may also be nested within elseSubFlow. Nodes within subFlow and elseSubFlow can also be referred to as child nodes of the IF-ELSE node.

[0061] The above example illustrates the concept of child nodes, but not only IF-ELSE nodes have child nodes; several other nodes, such as loop nodes (discussed later), also have child nodes. If a node in a business process does not have child nodes, it is easier to determine whether that node is a synchronous or asynchronous node. On the other hand, if a node has child nodes, it can be defined that if all of its child nodes are synchronous nodes, the node itself is a synchronous node, and if its child nodes include asynchronous nodes, the node itself is an asynchronous node.

[0062] Step S120: The process orchestration engine executes the nodes in the business process in order according to the sequence of nodes in the business process.

[0063] In step S120, after orchestrating the business process, the user can send an execution confirmation command to the process orchestration engine by clicking the execution confirmation button on the interface. After receiving the execution confirmation command, the process orchestration engine executes the nodes in the business process sequentially. The execution logic within each node is pre-implemented by the process orchestration engine. To make it clear, the execution may occur automatically after the user orchestrates the business process, or it may be triggered by certain conditions. Alternatively, the orchestrated portion may be automatically executed during the process of the user orchestrating the business process.

[0064] An interpretive execution method may be used to execute business processes. However, to improve execution efficiency, the process may be executed by translating the business process into high-level computer language code and then executing the corresponding high-level computer language code.

[0065] If execution reaches a synchronous node within the business process, the corresponding synchronous task may be completed automatically according to the execution logic pre-configured by the process orchestration engine, and subsequent nodes within the business process (if any) will then be executed. If execution reaches an asynchronous node within the business process, the execution of the business process will be blocked (in some cases only one thread may be blocked; see the definition of threads below for details), and the corresponding asynchronous task may be completed after waiting for external action, and subsequent nodes within the business process (if any) will then be executed. Here, the entity performing the external action may be a person, some third-party software, or some device.

[0066] The process orchestration engine can detect whether or not an external action has been executed. For example, when a user fills out a form and then clicks the form submission button on the interface, the form data is returned to the process orchestration engine, allowing the process orchestration engine to detect that the user has completed the form data submission. Similarly, if a third party calls a target function and that function belongs to or is monitored by the process orchestration engine, the process orchestration engine can detect that the third party has completed the function's callback operation.

[0067] If external operations are not performed for an extended period, the process may remain blocked in the asynchronous node, preventing subsequent nodes from executing. To address this problem, a timeout mechanism may be provided for the asynchronous node. This allows the process orchestration engine to execute a timeout command if it does not detect the execution of external operations within a predetermined time cycle. For example, by forcibly assigning an execution result to the asynchronous node, subsequent nodes can continue to execute, or the process execution can be forcibly stopped. The predetermined time cycle may be set internally within the process orchestration engine, or it may be set by the user as a parameter for the asynchronous node.

[0068] Furthermore, it should be noted that external operations refer to those performed during the execution phase of a business process, while node parameter setting operations performed during the orchestration phase of a business process do not fall under the category of external operations.

[0069] In the implementation process described above, users perform node selection and node parameter setting operations on the interface to generate business processes requiring orchestration, thereby achieving visualized process orchestration. This orchestration process does not require writing large amounts of code, thus improving the efficiency of process orchestration and reducing the probability of code syntax errors. Furthermore, the business process orchestration process becomes more visual and easier to operate for general users.

[0070] Furthermore, in node selection operations, the nodes that can be selected include both synchronous and asynchronous nodes. That is, it is possible to orchestrate synchronous nodes in a business process to realize tasks that can be executed without waiting for external operations, or to orchestrate asynchronous nodes to realize tasks that cannot be executed without waiting for external operations (of course, these two types of nodes can be orchestrated simultaneously). As a result, the resulting business processes can effectively describe the diverse types of tasks in actual business operations, thus improving the problem that conventional orchestration engines could not adapt to the orchestration needs of actual business processes, and improving the compatibility and availability of the orchestration engine.

[0071] Selectively, in embodiments of the present invention, the properties of a node include a node identifier, a flow instance identifier, and a thread identifier. These identifiers may be automatically assigned by the process orchestration engine, but are not excluded from being configurable by the user (considered as node parameters).

[0072] A node identifier is a unique identifier for a node, used to identify different nodes within a business process, and can also be used for reference within the business process. A node identifier can be displayed as Node ID.

[0073] Each time a business process is executed, one flow instance is created. If we consider a business process as a template, then a flow instance can be seen as an actual object built upon this template. While business processes do not contain actual data, flow instances do. A flow instance identifier is used to identify the flow instance to which a node belongs. Since a flow instance is the materialization of a business process, it contains all the nodes within the business process.

[0074] In the same execution of the same business process, the flow instance identifiers of all nodes within the business process will be the same. However, in different executions of the same business process, the flow instance identifiers will be different, even for the same node. For example, in the first (or second) execution of a business process, the flow instance identifiers of all nodes within the business process will be the same, but the flow instance identifiers generated during the first and second executions of that business process will be different. Therefore, nodes within different flow instances can be distinguished and identified from the flow instance identifier. The flow instance identifier can be displayed as Flow Instance ID.

[0075] A flow instance contains one or more threads. A thread is a concurrent execution branch within a flow instance. A thread can correspond to a fragment containing several nodes in a business process (for example, as will be clear from the following, a thread can correspond to the loop body of a loop node). In particular, if a flow instance contains only one thread, this thread may be considered the flow instance itself, or in this case, the flow instance may be considered to have no threads. The threads contained within a flow instance may also have a hierarchical structure. That is, some threads may not be directly subordinate to a flow instance, but rather to other threads. For example, if a flow instance contains three threads, and the first thread contains two secondary threads, then all five threads can be considered as threads contained within the flow instance. Thread identifiers are used to identify the thread to which a node belongs. In a business process, the thread identifier corresponding to a node in the same thread is the same. Thread identifiers can be expressed as Thread ID.

[0076] In the implementation process described above, introducing threads into flow instances improves process execution efficiency (because threads can be executed concurrently). Furthermore, by setting properties such as node identifiers, flow instance identifiers, and thread identifiers for each node, it becomes advantageous to ensure the accuracy and reliability of process execution by distinguishing different entities (nodes, flow instances, and threads) related to the execution of business processes. For specific details on how to use these node properties, please refer to the examples described later.

[0077] Selectively, in embodiments of the present invention, nodes within a business process include loop nodes. A loop node is a node whose execution of a loop body must be repeated until a loop termination condition is met. A loop body is a process fragment defined within a loop node that is to be repeatedly executed. A loop body may contain one or more nodes, and these nodes may be referred to as child nodes of the loop node. Child nodes within a loop body define the operations or logic that the loop node should execute. In particular, child nodes of a loop node may be loop nodes themselves.

[0078] A loop node can be either a synchronous or asynchronous node. If all elements within its loop body are synchronous nodes, the loop node can be considered a synchronous node. Conversely, if its loop body contains asynchronous nodes, the loop node can be considered an asynchronous node.

[0079] The parameters of a loop node include a parallelism property. The parallelism property of a loop node can be set to parallel execution or non-parallel execution.

[0080] If, upon execution up to the loop node in step S120, the loop node's concurrency property is set to concurrent execution, the process orchestration engine generates a number of secondary threads under the thread to which the loop node belongs (in this case, the flow instance may be considered as a single thread) equal to the sum of the values ​​that the loop variable of the loop node can take, and uses these secondary threads to concurrently execute the loop body for each value the loop variable takes. Here, each secondary thread is used to concurrently execute the loop body for each value the loop variable takes.

[0081] If, when the execution reaches the loop node in step S120, the loop node's parallel property is set to non-parallel execution, the thread to which the loop node belongs will repeatedly execute the loop body according to the changes in the loop variables. In other words, the loop body will be executed serially according to the loop logic.

[0082] In response to the above, nodes within a business process may include non-loop nodes. A non-loop node can be defined as a node that does not need to repeatedly execute the loop body. Since it does not participate in the repetition of execution, non-loop nodes can usually be executed serially.

[0083] Refer to the schematic diagram of a loop node in the embodiment of the present invention shown in Figure 4, where the parallel property provided is set to parallel execution.

[0084] The FOR node, being an asynchronous node, is a loop node (the FOR node implements the logic of the for statement in structured programming), and the loop body is the part from the approval request node to the true value return node. Furthermore, if the parallel property of the loop node is set to parallel execution, the method of setting this parallel property parameter can be by checking the parallel option, but of course, other methods are not excluded. For example, if approval from multiple approvers is required for one form, and the approvers are USER1, USER2, and USER3, then these three approvers, USER1, USER2, and USER3, become the three possible values ​​for the loop variable USERS in the loop node. When the process orchestration engine has executed up to the loop node, it generates three secondary threads under the thread to which the loop node belongs. Then, using these three secondary threads, it executes the loop body in parallel when the loop variable takes the values ​​of USER1, USER2, and USER3.

[0085] If the parallel property of the loop node in Figure 4 is set to non-parallel execution, that is, if the parallel option is not checked, the process orchestration engine will not create a secondary thread in the thread to which the loop node belongs. The thread to which the loop node belongs will then sequentially execute the loop body when the loop variables take USER1, USER2, and USER3, respectively.

[0086] In the example above, the FOR node was used to explain the loop node, but in structured programming, loops are not limited to the for statement; for example, a while statement can also implement a loop. Therefore, in any implementation method, the loop node may include a WHILE node and can be analyzed in the same way as the FOR node.

[0087] As mentioned above, a flow instance may contain one or more threads. These threads may arise when a loop node with the concurrency property set to concurrent execution is running.

[0088] Next, we will describe the execution process of loop nodes with two types of parallel properties using a schematic diagram.

[0089] Refer to the schematic diagram of the execution process of a loop node in an embodiment of the present invention where the parallel property is set to non-parallel execution, as shown in Figure 5.

[0090] The business process in Figure 5 includes nodes 1 to 3. Of these, node 2 is a loop node, and its concurrency property is set to non-concurrent execution. The values ​​that node 2's loop variable i can take are i=1, i=2, and i=3. If the thread to which node 2 belongs is 1000 (thread identifier is 1000), when the process orchestration engine has executed up to node 2, it will use thread 1000 to which node 2 belongs to sequentially execute the loop body for i=1, i=2, and i=3 (the loop body is not shown). It should be noted that in this case, no thread is generated for node 2, so thread 1000 to which node 2 belongs can be considered as the flow instance itself. To make it easy to understand, when the concurrency property of a loop node is set to non-concurrent execution, the execution of the loop node is no different from that of a non-loop node, and all are executed serially.

[0091] Refer to the schematic diagram of the execution process of a loop node in the embodiment of the present invention shown in Figure 6, where the parallel property provided is set to parallel execution.

[0092] The business process in Figure 6 includes nodes 1 to 4. Of these, node 2 is a loop node, and its parallel property is set to parallel execution. Node 2's loop body contains node 3. The loop variable i of the loop node can take values ​​i=1, i=2, and i=3. That is, the sum of the values ​​the loop variable can take is 3. Therefore, three secondary threads are generated under the thread to which node 2 belongs. If the thread to which the loop node belongs is represented as 1000, the three secondary threads can be represented as 1000-1, 1000-2, and 1000-3, respectively. Then, secondary thread 1000-1 is used to execute the loop body of node 2 when i=1, secondary thread 1000-2 is used to execute the loop body of node 2 when i=2, and secondary thread 1000-3 is used to execute the loop body of node 2 when i=3. Furthermore, the execution method is to execute the corresponding loop bodies in parallel for the three secondary threads.

[0093] In the implementation process described above, the nodes within the business process include loop nodes. The parallelism property of a loop node can be set to concurrent execution or non-concurrent execution, and the parallelism property of the loop node should be set as needed. When the parallelism property of a loop node is set to concurrent execution, multiple secondary threads are generated and the loop body is executed in parallel, thereby improving the execution efficiency and performance of the loop node.

[0094] Selectively, in the embodiments of this application, if the parallel property of the loop node is set to parallel execution, the execution result of the loop node is obtained based on the execution result corresponding to each secondary thread. In specific implementation, corresponding rules may be set based on actual needs, and the execution result corresponding to each secondary thread may be mapped as the execution result of the loop node. For example, weighting or statistics may be applied to the execution result of each thread so that the execution logic of the loop node better reflects actual business needs.

[0095] Next, refer to Figures 6 and 4 together. Following the above embodiment, if the approvers are USER1, USER2, and USER3, the three secondary threads execute the loop bodies corresponding to USER1, USER2, and USER3, respectively, and obtain the execution results corresponding to each secondary thread (i.e., the approval results of the three approvers). The execution result of the loop node can be determined based on the approval results of the three approvers and pre-set conditions. For example, the pre-set conditions are that if the number of people who approved the approval is greater than a pre-set threshold (e.g., two-thirds), the execution result of the loop node is considered to be approval, but if the number of people who approved the approval is less than or equal to the pre-set threshold, the execution result of the loop node is considered to be rejection.

[0096] Selectively, in embodiments of the present invention, when the parallel property of a loop node is set to parallel execution, the loop termination conditions include (1) completion of execution of each secondary thread, (2) execution of any one secondary thread up to the loop's pre-termination instruction, or (3) execution of any one secondary thread times out. Furthermore, after the execution of the loop node is completed, the generated secondary threads are discarded, and the nodes within the business process continue to be executed using the thread to which the loop node belongs.

[0097] Regarding condition (1), for example, in the cases of Figures 6 and 4, the completion of the execution of the three secondary threads is indicated when all three secondary threads return an approval result corresponding to the approver.

[0098] Regarding condition (2), if any secondary thread has executed up to a pre-termination instruction for the loop, such as a break instruction, the loop will be terminated immediately at that point. These instructions may be associated with specific nodes during orchestration.

[0099] Regarding condition (3), a timeout in the execution of any single secondary thread means that the execution time of any single secondary thread exceeds a predetermined time cycle. Condition (3) primarily applies when an asynchronous node is included in the loop body (because the external operations corresponding to asynchronous nodes are prone to causing timeouts), but it may also apply to loop bodies that contain only synchronous nodes. The predetermined time cycle may be set internally within the process orchestration engine, or it may be set by the user as a parameter of the loop node.

[0100] When the loop termination condition is reached, the execution of the loop node is considered complete. In this case, secondary threads generated under the thread to which the loop node belongs are discarded, freeing the resources occupied by the secondary threads, and the thread to which the loop node belongs is used to continue executing the nodes in the business process. For example, referring to Figure 6, after the execution of node 2 is completed, secondary threads 1000-1, 1000-2, and 1000-3 are all discarded. As a result, the thread currently executing becomes 1000 again, and node 4 is continued to be executed using thread 1000. However, if there are no other nodes after the loop node, the execution of the business process may be terminated. In addition, if any special instruction such as a termination instruction is encountered within the loop body, the execution of the business process may be terminated without continuing to execute the nodes after the loop node.

[0101] In the implementation process described above, since there are multiple termination methods for the loop, the execution logic of the loop node can better reflect actual business needs. Furthermore, after the execution of the loop node is complete, the generated secondary thread is promptly discarded, freeing up resources such as memory, CPU, and network connection that the thread occupied. Then, by continuing to execute nodes within the business process using the thread to which the loop node belongs, the consumption of system resources during the execution of the business process can be reduced.

[0102] Selectively, in embodiments of the present invention, the rules for generating thread identifiers for nodes in a business process include the following: If a node is not a child node of a loop node whose concurrency property is set to concurrent execution, the node's thread identifier matches the flow instance identifier. On the other hand, if a node is a child node of a loop node whose concurrency property is set to concurrent execution, the node's thread identifier is generated based on the thread identifier of the loop node that is closest to the node among the child node's parent nodes and whose concurrency property is set to concurrent execution, and the loop number corresponding to the node. The loop number corresponding to the node is the number within the range of values ​​that the loop variable corresponding to the thread to which the node belongs can take at that time.

[0103] First, let's explain the definition of a child node. All nodes belonging to a single node, regardless of whether they belong directly to it or not, are referred to as child nodes of that node. For example, if loop node A has a loop body containing three nodes, all three of these nodes are child nodes of the loop node. Furthermore, assuming that one of these three nodes is also a loop node, we will denote it as loop node B. If loop node B contains four child nodes, these four child nodes do not directly belong to loop node A, but can still be considered child nodes of loop node A. In addition, corresponding to the above, any child node of loop node A can refer to loop node A as its parent node.

[0104] Only loop nodes with the concurrency property set to concurrent execution will generate new threads. Therefore, if a node is not a child node of a loop node with any of its concurrency properties set to concurrent execution, that node will still be on the main thread of the flow instance and will not be on any secondary threads generated during the execution of the flow instance. Thus, the thread identifier of a node can be set to match the flow instance identifier.

[0105] Refer to Figure 6. Nodes 1, 2, and 4 are not child nodes of a loop node whose concurrency property is set to concurrent execution; therefore, their thread identifiers are all 1000, the same as the flow instance identifier.

[0106] If the concurrency property of a loop node is set to concurrent execution, the thread identifier of a child node directly belonging to that loop node can be generated based on the thread identifier of the loop node and the loop number corresponding to the child node. Similarly, if any child node directly belonging to that loop node is also a loop node and its concurrency property is set to concurrent execution, the thread identifier of that child node directly belonging to that child node can be derived in the same manner. On the other hand, if any child node directly belonging to that loop node is also a loop node but its concurrency property is set to non-concurrent execution, or if it is a non-loop node, the thread identifier of that child node directly belonging to that child node will match the thread identifier of the child node. The thread identifiers of each node within a business process can be obtained in the same manner.

[0107] The process described above can be simply summarized as follows: If a loop node with the concurrency property set to concurrent execution is encountered in the path from any top-level node to any lower-level child node, a new thread identifier must be derived for the child nodes of that loop node. Otherwise, the thread identifier at that point will remain unchanged.

[0108] This allows a node to traverse one layer at a time upwards from its direct parent node if it is a child node of a loop node whose concurrency properties are set to concurrent execution. Based on the definition of child nodes described above, all nodes along the traversal path can be referred to as the parent nodes of that node. Of these parent nodes, the loop node closest to the node in question and whose concurrency properties are set to concurrent execution becomes the loop node used to derive the thread identifier of that node.

[0109] Refer to Figure 6. Node 2 is a loop node, and its concurrency property is set to concurrent execution. Node 3 is a child node within the loop body of node 2. Next, we will explain the thread identifier generation rules using node 3 of the first thread (the leftmost thread) as an example. Of the parent nodes of node 3 of the first thread, the loop node closest to node 3 of the first thread is node 2. Furthermore, node 2 is a loop node with its concurrency property set to concurrent execution. Therefore, we obtain the thread identifier 1000 for node 2. Next, we obtain the loop number of node 3 of the first thread. The loop number corresponding to node 3 of the first thread is the number within the total range of values ​​that the loop variable corresponding to the thread to which the node belongs can take at that time. For example, if the value that the loop variable can take at that time is 2, and the total range of values ​​includes 2, 4, and 6, then the number within the total range of values ​​that the loop variable can take at that time can be 1.

[0110] After obtaining that the thread identifier of node 2 is 1000 and that the loop number corresponding to node 3 of the first thread is 1, the thread identifier of node 3 of the first thread is generated based on the thread identifier of node 2 and the loop number corresponding to node 3 of the first thread. For example, the thread identifier of node 3 of the first thread is generated by concatenating the thread identifier of node 2, 1000, with the loop number corresponding to node 3 of the first thread, 1. For example, in Figure 6, the two numbers are concatenated using a hyphen to obtain the thread identifier 1000-1. Alternatively, the thread identifier of node 3 of the first thread may be obtained by performing a calculation on the thread identifier of node 2 and the loop number corresponding to node 3 of the first thread using a pre-configured method.

[0111] Refer to the schematic diagram of the execution process of the nested loop node provided in the embodiment of the present invention shown in Figure 7.

[0112] As described above, the child nodes of a loop node refer to all nodes within the loop body corresponding to the loop node. In an optional embodiment, the child nodes of a loop node may include the loop node itself. As shown in Figure 7, the child nodes of loop node 2 include nodes 3, 4, and 5. Node 3 is also a loop node, and its child nodes include node 4. Furthermore, the parallel properties of both nodes 2 and 3 are set to parallel execution.

[0113] Next, we will explain the thread identifier generation rules using node 4 of the first thread (the leftmost thread) as an example. Node 4 of the first thread is the leftmost node 4. First, we identify that the parent nodes of node 4 of the first thread include nodes 3 and 2 of the first thread. Since node 4 of the first thread has multiple parent nodes, we further need to identify that the closest parent node to node 4 of the first thread is node 3 of the first thread, and obtain that the thread identifier of node 3 of the first thread is 1000-1. Next, we obtain that the loop number of node 4 of the first thread is 1. Then, based on the thread identifier 1000-1 of node 3 of the first thread and the loop number 1 of node 4 of the first thread, we can generate a thread identifier for node 4 of the first thread, for example, 1000-1-1. For how to obtain the thread identifier of node 3 of the first thread, please refer to the detailed description above for Figure 6. When actually executing a business process, the thread identifier of a node can only be identified when the process has reached that node. Furthermore, once the first thread has executed up to node 4, node 3 of the first thread has clearly already been executed, so at this point, the thread identifier of node 3 of the first thread is known.

[0114] In the implementation process described above, thread identifiers corresponding to nodes are generated based on rules. Such thread identifiers not only allow identification of the thread in which a node exists, but can also represent the parent-child relationship between nodes, making them convenient for managing nodes within a process. For example, in Figure 6, by combining the rules for generating thread identifiers, it can be seen from the thread identifier 1000-1 of node 3 and the thread identifier 1000 of node 2 that node 3 is a child node of node 2 and belongs to the first thread that originated in node 2.

[0115] In a business process, each node typically contains inputs and outputs, and generally, the output of a node also becomes the execution result of that node. In a business process, nodes that run later in the execution order can reference the execution results of earlier nodes as input. Below, we will explain how to analyze the reference of node execution results, using the first and second nodes as examples. Let's assume that the business process contains a first node and a second node, and that the first node runs before the second node. Needless to say, the first and second nodes are broad general terms and do not represent two specific nodes.

[0116] Selectively, in the embodiments of the present invention, after each node has finished executing, the node identifier, flow instance identifier, thread identifier, and execution result of that node are stored in association with the node after the node has finished executing. For example, they may be stored in a database so that they can be read and used later.

[0117] If the parameters set for the second node include a reference to the execution result of the first node, the steps to obtain the execution result of the first node include the following: Obtain the node identifier and flow instance identifier of the first node. Next, starting from the second node, search for nodes whose execution order precedes the second node, in reverse order of the business process execution. During the search, based on the thread identifier generation rules and the thread identifier of the second node, identify the thread identifier of each target node until the node identifier of the target node becomes the node identifier of the first node, and identify the thread identifier of the first node as the thread identifier of the target node. Then, obtain the execution result of the first node, which is stored in association with the node identifier, flow instance identifier, and thread identifier of the first node (since the first node has clearly been executed by the time the second node is executed, the execution result is already saved).

[0118] The parameters set for the second node are visualized as inputs to the second node. When a parameter includes a reference to the execution result of the first node, it means that the execution result (all or part of it) of the first node is used as the value for the setting parameter of the second node. For example, the task corresponding to the first node is to retrieve a user's email address, and the execution result is the retrieved user's email address. The task corresponding to the second node is to send an email to the above user. Therefore, when setting the parameters for the second node, it is necessary to refer to the execution result of the first node. This is because the email address must be known in order to send an email. When the process orchestration engine executes the second node, it parses the reference to retrieve the execution result of the first node, and then assigns the execution result of the first node to the second node, thereby enabling the completion of the task of sending an email to the user corresponding to the second node.

[0119] Refer to the schematic diagram of how to refer to the execution results of a node provided in the embodiment of the present invention shown in Figure 8. As shown in Figure 8, the method of referring to the execution results of the first node includes referencing based on the node identifier and a pre-set reference symbol of the first node. In the $1.email address on the right side of Figure 8, "$" is a reference symbol, and 1 is the node identifier of the first node. Therefore, $1 represents the execution result of the first node. In addition, the email address represents the specific data item of the execution result (other data items are not excluded).

[0120] Next, we will describe the step of obtaining the execution result of the first node.

[0121] First, obtain the node identifier and flow instance identifier of the first node whose execution results need to be referenced. If the first and second nodes reside in the same flow instance, the flow instance identifiers of the first and second nodes will match. Also, if the second node needs to reference the execution results of the first node, it goes without saying that the node identifier of the first node is already known. Otherwise, it cannot be set as a parameter for the second node.

[0122] Next, in reverse order of the business process execution sequence, starting from the second node, the system searches for nodes whose business process execution sequence precedes that of the second node. The purpose of this search is to identify the thread identifier of the first node based on the thread identifier generation rules and the thread identifier of the second node. This search process can be understood by combining the examples described later. Subsequently, the system reads the execution results of the first node, which are pre-associated and stored based on the node identifier, flow instance identifier, and thread identifier of the first node.

[0123] For example, as shown in Figure 7, if node 4 is the second node and node 2 is the first node, then in order to set the parameters of node 4, it is necessary to refer to the execution results of node 2. There are a total of nine nodes 4 in Figure 7, but for simplicity, only the leftmost node 4 is shown as an example. The node identifier of this node 4 is 4, the thread identifier is 1000-1-1, and the flow instance identifier is 1000. Also, the node identifier of node 2 is 2, the flow instance identifier is 1000, but the thread identifier is not yet known. This is because, at the point when execution has reached node 4, the position of node 2 within the business process is not yet known.

[0124] When searching for nodes in the business process that are executed before node 4, we first search for the leftmost node, Node 3. This allows us to find that Node 3 is a loop node with the parallel property set to parallel execution, and is also the parent node to which Node 4 directly belongs. Next, based on the thread identifier generation rules, we can use the thread identifier 1000-1-1 of Node 4 to derive the thread identifier 1000-1 of Node 3 in reverse. Although the node identifier of Node 3 is found to be 3, the node identifier to be referenced is 2, so Node 3 is not the first node to be referenced.

[0125] It is important to note that although Figure 7 shows three nodes 3, the leftmost node 4 can only search the leftmost node 3, and cannot search the two nodes 3 to its right. In other words, when the leftmost node 4 refers to the execution result of node 3, it will only refer to the execution result of the leftmost node 3.

[0126] By continuing to search in reverse order of the execution sequence of the business process, when the target node becomes node 2, it is found that node 2 is a loop node with the parallel property set to parallel execution, and is also the parent node to which node 3 directly belongs. Next, based on the thread identifier generation rules, it is possible to derive the thread identifier 1000 of node 2 in reverse using the thread identifier 1000-1 of node 3 (or the thread identifier 1000-1-1 of node 4). It is also found that the node identifier of node 2 is 2. As the node identifier to be referenced is also 2, node 2 is identified as the first node to be referenced. Thus, the thread identifier of the first node can be identified as 1000 as the thread identifier of the target node.

[0127] After determining that the thread identifier of the first node is 1000, the node identifier is 2, and the flow instance identifier is 1000 through the steps described above, the execution results of the first node, which are stored in association with the node identifier, flow instance identifier, and thread identifier of the first node, are retrieved, and the second node is executed.

[0128] To make it clear, after searching until the node identifier of the target node matches the node identifier of the first node, it is not necessary to continue searching the nodes in reverse order, and the search can be stopped.

[0129] In an optional embodiment, a variable may be defined to store the execution result of the first node. The scope of the variable may be the entire process, or it may be a node executed after the first node so that the variable storing the execution result of the first node can be accessed in the second node. Refer to Figure 8 again. A variable setting node may be inserted between the first and second nodes, and the variable may be created by executing that node. The name of the variable is "email address", and the variable value is the email address in the execution result of the first node.

[0130] When setting the parameters for the second node, you may include a reference to a variable. For example, you may directly write the name of the variable (or other reference syntax). The process orchestration engine can obtain the value of a variable by parsing the variable reference. This achieves the same effect as directly referencing the execution result of the first node. Refer to Figure 8 again. For example, for the second node, you may write #email address in the recipient field. "#" is a reference symbol, and what follows it is the name of a variable. This allows the process orchestration engine to look up a predefined variable based on the variable name "email address". Then, it uses the value of the retrieved variable as the value of the recipient parameter of the second node and executes the email sending task corresponding to the second node based on this value.

[0131] In the implementation process described above, the execution results of a preceding node (e.g., the first node) can be obtained using the node identifier, flow instance identifier, and thread identifier generation rules of the preceding node. As a result, subsequent nodes in the business process (e.g., the second node) can refer to the execution results of the preceding node as input during their execution, leading to a richer range of input types for the node. Consequently, the node's execution logic can better reflect actual business needs.

[0132] In addition to selectively referencing the execution results of preceding nodes, child nodes of a loop node can also reference loop variables. The referencing methods are explained above in relation to referencing execution results or variables, so a detailed explanation will not be repeated.

[0133] Selectively, in the embodiment of the present invention, if the external operation corresponding to the asynchronous node is an operation in which a user submits data on the target page, the step of executing the asynchronous node in step S120 includes the following: obtaining the node identifier, flow instance identifier, and thread identifier of the asynchronous node, and concatenating the node identifier, flow instance identifier, and thread identifier of the asynchronous node to generate the address of the target page. Next, notifying the user executing the external operation corresponding to the asynchronous node of the address of the target page in a pre-configured manner, and receiving the data submitted by the user on the target page. This data includes business data, the node identifier, flow instance identifier, and thread identifier of the asynchronous node.

[0134] After receiving the data submitted by the user, the process orchestration engine may continue executing subsequent nodes (if any) within the business process, starting with the asynchronous node. Alternatively, if a timeout mechanism is configured for the asynchronous node, the process orchestration engine may force the execution of subsequent nodes after the asynchronous node times out.

[0135] Next, we will describe in detail the steps for executing an asynchronous node. First, the process orchestration engine obtains the node identifier, flow instance identifier, and thread identifier of the asynchronous node. Since the execution of each node is entirely under the control of the process orchestration engine, the process orchestration engine can obtain all the properties of each node.

[0136] Next, the process orchestration engine generates the target page address by concatenating the node identifier, flow instance identifier, and thread identifier of the asynchronous node according to pre-configured rules. It should be noted that, in addition to the node identifier, flow instance identifier, and thread identifier of the asynchronous node, the target page address may also include other information such as the protocol used to access the web page, the IP address, and the page storage path. The target page address is a unique identifier for identifying and locating the web page, and is, for example, the URL (Uniform Resource Locator) of the target page.

[0137] Next, the process orchestration engine notifies the user performing the external action corresponding to the asynchronous node of the address of the target page using a pre-configured method. For example, an external action corresponding to an asynchronous node is when user A fills in the information fields on a personal information entry page and submits the completed personal information. In this case, the personal information entry page is the target page. After obtaining the address of the target page, the system can obtain user A's information and then notify user A of the address of the target page by sending the information or by attaching user A's ToDo items.

[0138] User A receives the address of the target page on their terminal device, clicks the address to open the target page, fills in personal information on the page, and then submits the data on the target page. This data is submitted to the process orchestration engine. The data includes business data, the node identifier of the asynchronous node, the flow instance identifier, and the thread identifier. Business data is the personal information that User A enters on the target page. The node identifier, flow instance identifier, and thread identifier are stored in the address of the target page, and User A does not need to be aware of the submission of these three pieces of data. To make it clear, depending on the business scenario, business data may be other types of data, for example, approval results and approval opinions submitted by the user after approving the content on the target page.

[0139] In the implementation process described above, the node identifier, flow instance identifier, and thread identifier of the asynchronous node are concatenated to generate the address of the target page, and this address is notified to the user. This allows the user to submit the node identifier, flow instance identifier, and thread identifier of the asynchronous node along with the data submitted on the target page. These identifiers allow the thread of the flow instance to which the asynchronous node belongs to be located, enabling subsequent nodes to continue executing after the asynchronous node. In other words, according to the implementation process described above, support for asynchronous nodes is realized at the execution level (support for asynchronous nodes is already realized at the interface level through node selection operations), thus effectively enhancing the compatibility and availability of the process orchestration engine.

[0140] Selectively, in the embodiments of the present invention, a node pointer is provided for each thread within each flow instance. The node pointer indicates the node currently executing within the thread. After receiving data submitted by the user on the target page, the method further includes: obtaining the node identifier of the asynchronous node, the flow instance identifier, and the thread identifier from the data submitted by the user, and identifying the target node pointer based on the flow instance identifier and the thread identifier. The target node pointer is the node pointer corresponding to the flow instance and thread to which the asynchronous node belongs. If the node identifier of the asynchronous node matches the node identifier of the node indicated by the target node pointer, the execution of the nodes in the business process from the asynchronous node onward is continued.

[0141] The process orchestration engine assigns a node pointer to each thread within a flow instance (the flow instance itself is also considered a thread). The node pointer indicates the node currently executing within the thread. As each node finishes execution, the node pointer's value is updated to indicate the next node in the thread. Subsequently, the process orchestration engine also executes the next node. On the other hand, if a thread is terminated, the corresponding node pointer may also be released.

[0142] During the execution step of an asynchronous node, after the user submits data on the target page, the process orchestration engine can identify the target node pointer based on the flow instance identifier and thread identifier in the data submitted by the user. The target node pointer is the node pointer corresponding to the flow instance and thread to which the asynchronous node belongs. The flow instance to which the asynchronous node belongs is identified based on the flow instance identifier submitted by the user, and the thread to which the asynchronous node belongs is identified based on the thread identifier submitted by the user. The target node pointer indicates the node currently executing within the thread to which it belongs.

[0143] If the node identifier of an asynchronous node matches the node identifier of the node pointed to by the target node pointer, it means that the thread to which the target node pointer belongs has just executed up to the position of the asynchronous node, and then the process execution has been suspended, waiting for data submission from the user. The data submitted by the user corresponds to the external operation that the asynchronous node is waiting for. This allows the process orchestration engine to continue executing nodes in the business process from the asynchronous node onward. On the other hand, if the node identifier of an asynchronous node does not match the node identifier of the node pointed to by the target node pointer, an exception may be thrown.

[0144] In the implementation process described above, the node pointer indicates the node currently executing within the thread. Furthermore, the target node pointer is identified using the flow instance identifier and thread identifier in the user-submitted data, and a decision is made whether to continue execution by comparing the node identifiers. This is convenient for controlling and managing the movement of execution logic between nodes within a flow instance, ensuring the accuracy and reliability of process execution.

[0145] Selectively, the process orchestration engine may identify the flow instance and thread to which the asynchronous node belongs based on the flow instance identifier and thread identifier in the data submitted by the user, and then, based on the node identifier in the data submitted by the user, locate the asynchronous node at that time within that thread, and then continue execution downwards. In other words, it may not be necessary to verify the node pointer, and consequently, it may not be necessary to implement a node pointer.

[0146] Selectively, in the embodiments of this application, the target page includes either a form page or an approval page. If the target page corresponding to either asynchronous node is a form page, it may be referred to as a form node. Also, if the target page corresponding to either asynchronous node is an approval page, it may be referred to as an approval node.

[0147] The target page is the page on which the user submits data. A form page may also be a page for collecting user input data, and this data can be used to form the user's form. A form page may include input widgets corresponding to each field in the form, such as text boxes, dropdown lists, checkboxes, and radio buttons, and be used to accept user input. The user can enter form data on the form page and submit the form data, along with the identifiers of each form node in the form page address, to the process orchestration engine.

[0148] An approval page is a page for processing and managing approval tasks. It presents applications or tasks awaiting approval and provides an interface for approvers to approve these requests. For example, the interface may include buttons for approving and rejecting approval, as well as a text box for approval comments. Users can write their approval comments and approval results within the approval page and submit these, along with the identifiers of the approval nodes within the approval page address, to the process orchestration engine. Selectively, some approval pages may also allow users to input data other than approval comments and results. Approval pages can also be considered an exception to form pages.

[0149] In the implementation process described above, the target pages corresponding to asynchronous nodes include form pages or approval pages. Because different business processes can be implemented depending on the format of the target page, this is advantageous in improving the availability of the process orchestration engine, and is particularly applicable to enterprise settings. This is because filling out forms and approving them are common business processes in enterprises.

[0150] For example, by combining loop nodes within a business process, the embodiments of this invention enable the realization of complex and flexible approval processes. For instance, if an approval node is included within a loop node and the parallel property of the loop node is set to non-parallel execution, a serial approval process can be realized. Conversely, if the parallel property of the loop node is set to parallel execution, a parallel approval process can be realized. Furthermore, by nesting loop nodes, even more complex approval processes can be realized.

[0151] In the embodiments of this application, an entity can be rephrased as something that defines data, for example, defining which fields are included in a data table. A form is one form of representation of an entity. For example, different fields in a data table can be viewed depending on the user. In this way, it is possible to form different forms based on the same entity. A form instance is a form that contains actual data, and differences between form instances can be distinguished by a form instance identifier. The form instance identifier can be displayed as Entity Data ID.

[0152] Selectively, in the embodiments of this application, if the target page is a form page of a new form (i.e., a form without data), the execution process of the asynchronous node proceeds as described above. After receiving the form data submitted by the user, the process orchestration engine can assign a form instance identifier. Naturally, this does not exclude cases where the user specifies the form instance identifier (within the node parameters). If the user specifies the form instance identifier, the form instance identifier may be submitted to the process orchestration engine along with the form data.

[0153] If the target page is the form page of an edited form, generating the address of the target page by concatenating the node identifier, flow instance identifier, and thread identifier of the asynchronous node includes the following: obtaining the form instance identifier corresponding to the edited form, and concatenating the node identifier, flow instance identifier, thread identifier, and form instance identifier of the asynchronous node to generate the address of the target page. The form instance identifier is used to look up the form data of the edited form, and the form data is used to render the target page. In addition, the data submitted by the user on the target page includes the updated form data, the node identifier of the asynchronous node, the flow instance identifier, the thread identifier, and the form instance identifier.

[0154] The target page being the form page of an edited form can include the following situations. The first situation is, for example, when the form data submitted by the user needs to be corrected or edited a second time. In this case, the data submitted by the user becomes the data on the form page of the edited form. The second situation is when the edited form is a previously stored form. For example, this is when a single approval form requires approval from multiple people, or when a single data form requires entry from multiple people, and subsequent entries are based on the previous data. After each person has approved or entered the data, the updated data is saved, and the edited form becomes the form to be presented to the next user on their target page.

[0155] If the target page is the form page of an edited form, when generating the address of the target page, it is necessary to concatenate the form instance identifier corresponding to the edited form to the address of the target page. The process of generating the address of the target page is described in detail below. Specifically, the form instance identifier corresponding to the edited form is obtained. The form instance identifier corresponding to the edited form is generated after the form is first submitted. The form instance identifier may be custom generated by the user, or it may be automatically generated by the process orchestration engine after it has obtained the data submitted by the user for the target page. Subsequently, when processing the edited form, the form instance identifier generated after the form was first submitted can be used as is.

[0156] The form instance identifier can be used to retrieve the form data of an edited form, and the form data is used to render the target page and inform the user of the contents of the edited form. For example, in the first scenario, the user needs to modify the submitted form data. After the user first submits the data, a form instance identifier is generated for that form. After notifying the user of the address of the edited form's page, when the user clicks that address, the process orchestration engine can retrieve the form data the user initially submitted using the form instance identifier concatenated to the address. This allows the system to render the edited form's page based on that data and return that page to the user. The user can then modify the form data based on this page.

[0157] Accordingly, if the target page is a form page of an edited form, the data submitted by the user on the target page includes the updated form data, the node identifier of the asynchronous node, the flow instance identifier, the thread identifier, and the form instance identifier. After receiving the data submitted by the user, the process orchestration engine may continue to execute subsequent nodes in the business process. The specifics can be found in the above description, so they will not be repeated in detail. In addition, the process orchestration engine may further manage the updated form data based on the form instance identifier submitted by the user from the target page.

[0158] In the implementation process described above, if the target page is a form page of an edited form, the form instance identifier is concatenated to the address of the target page, and the form data can be presented to the user on that page. This allows the user to re-edit the form based on the edited form, thereby enabling the reuse of the form data.

[0159] Selectively, in embodiments of the present invention, the process orchestration engine needs to generate the address of the target page and then notify the user of the address of the target page. This allows the user to proceed to the target page based on the address and execute the corresponding external operation. Pre-configured methods for notifying the user include the following:

[0160] Method 1: Obtain user information of the user executing the external operation corresponding to the asynchronous node, and send notification information to the user based on the user information. The notification information includes the address of the target page.

[0161] Method 2: Retrieves the user's To-Do list. It also generates a target To-Do item based on the address of the target page. The target To-Do item is used to instruct the user to proceed to the target page. The target To-Do item is added to the user's To-Do list.

[0162] Third method: Obtain a list of user data. Additionally, generate interaction buttons based on the target page address. These interaction buttons are used to instruct the user to proceed to the target page. The interaction buttons are added to the user's data list.

[0163] In the first method, information is sent to the user. This information contains the address of the target page. Specifically, for example, user information is obtained. The user is a user who performs external operations corresponding to the asynchronous node. User information is personal information that can receive messages, such as a user account on a social media platform, the user's mobile phone number, or the user's mailbox. After obtaining the user information, notification information containing the address of the target page is sent to the user.

[0164] The second method generates user ToDo items based on the address of the target page. For example, it retrieves the user's ToDo list. The ToDo list may be the user's ToDo list in a task management system or the user's ToDo list in a personal workflow. For example, the ToDo list may contain one or more ToDo items. Each ToDo item may also be a text description of the ToDo item. This text description may include the page address to complete the ToDo item.

[0165] The process orchestration engine can generate target ToDo items based on the address of the target page. The text of the target ToDo items can be structured based on information such as the purpose of the target page, the content of the target page, and the name of the user who wants to use the target page. This information can be retrieved from the database by the process orchestration engine.

[0166] After generating the target ToDo item, the process orchestration engine may add the target ToDo item to the user's ToDo list, and may also send a reminder message to the user that the ToDo item has been added. The user can then click the page address corresponding to the target ToDo item to proceed to the page and complete external actions such as form completion or data approval corresponding to the asynchronous node.

[0167] In the third method, a button to navigate to a target page is added to the user's data list. For example, the user's data list is retrieved. This data list may be located within the user's system. The user can view this data list by navigating to a specific page within the system. An interaction button is added to the user's data list. The interaction button is used to instruct the user to navigate to the target page. The interaction button is mapped to the address of the target page. Additionally, a response event for the interaction button is created by writing code so that the corresponding target page opens when the user clicks the interaction button.

[0168] Figure 9 is a schematic diagram of a data table including an interaction button provided in an embodiment of the present invention. Figure 9 shows a data list that can be viewed by a certain approver. Each time approval information is generated in the system, one table entry is added to the data list. The last column of the table entry is an interaction button. This button is associated with the approval page. Therefore, by clicking the button, the approver can access the page and perform the external action corresponding to the approval node.

[0169] The above implementation process provides diverse and flexible notification methods for users, allowing users to select the appropriate method based on specific application scenarios and page requirements. This enables users to obtain the address of the target page, proceed to the page, and complete the external actions corresponding to the asynchronous node.

[0170] Selectively, in embodiments of the present invention, if the external operation corresponding to the asynchronous node is a callback operation of a target function by a third party, the step of executing the asynchronous node in step S120 includes the following: storing the node identifier, flow instance identifier, and thread identifier of the asynchronous node in association with the function identifier of the target function corresponding to the asynchronous node; then, calling an interface provided by the third party to send the function identifier to the third party; and then, in response to a call to the target function by the third party using the function identifier, identifying the node identifier, flow instance identifier, and thread identifier of the asynchronous node that are stored in association with the function identifier based on the function identifier of the called target function.

[0171] External actions corresponding to asynchronous nodes may include callback actions of a target function by a third party. The callback function is one that is invoked when a specific event occurs. For example, the target function may be a WebHook type function. Of course, it may also be any other type of function defined by the process orchestration engine.

[0172] The following describes the steps for executing an asynchronous node, using a WebHook function as an example. A WebHook contains a function identifier. The function identifier is used to distinguish between different WebHook functions. The function identifier of a WebHook can be represented by a WebHook ID. Before executing an asynchronous node, the process orchestration engine first stores the node identifier, flow instance identifier, and thread identifier of the asynchronous node, associating them with the function identifier of the target function corresponding to the asynchronous node. For example, it stores this information in a database.

[0173] Next, the process orchestration engine obtains an interface provided by a third party. This interface may have specific functionality, such as a message push interface. The third party may also be software that requires the invocation of a WebHook function. Based on the description or requirements of the interface provided by the third party, the interface is invoked. The parameters invoked include the WebHook ID.

[0174] After receiving the WebHook ID, the third party invokes the WebHook based on the WebHook ID (callback). In response to the third party's WebHook invocation using the WebHook ID, the process orchestration engine searches for the node identifier, flow instance identifier, and thread identifier of the asynchronous node stored in association with the WebHook ID, based on the WebHook ID of the invoked WebHook function.

[0175] In the process described above, the process orchestration engine only needs to transmit the WebHook ID to the third party; it does not need to transmit the node identifier, flow instance identifier, or thread identifier. This makes the execution of asynchronous nodes more efficient and simpler.

[0176] After retrieving the retrieved data, the process orchestration engine may continue executing subsequent nodes (if any) within the business process after the asynchronous node. Alternatively, if a timeout mechanism is configured for the asynchronous node, the process orchestration engine may force the execution of subsequent nodes after the asynchronous node times out.

[0177] In the implementation process described above, the external operation corresponding to the asynchronous node may be a callback operation of the target function by a third party. By sending a function identifier to the third party, the node identifier, flow instance identifier, and thread identifier of the asynchronous node, which are stored in association with the function identifier, are identified based on the function identifier of the called target function. Then, by positioning the thread of the flow instance to which the asynchronous node belongs using these identifiers, subsequent nodes can continue to be executed after the asynchronous node. In other words, according to the implementation process described above, support for asynchronous nodes is realized at the execution level (support for asynchronous nodes at the interface level is realized through node selection operations).

[0178] Furthermore, the asynchronous nodes in the embodiments of this application can support external operations in many application scenarios (for example, human-performed actions such as form completion and approval, and machine-performed function callback operations). This allows for better satisfaction of the diverse orchestration needs in actual business processes, thereby effectively enhancing the compatibility and availability of the process orchestration engine.

[0179] Selectively, in embodiments of the present invention, a node pointer is provided for each thread within each flow instance. The node pointer indicates the node currently executing within the thread. After identifying the node identifier, flow instance identifier, and thread identifier of an asynchronous node stored in association with a function identifier, the method further includes: identifying a target node pointer based on the flow instance identifier and thread identifier of the asynchronous node. The target node pointer is the node pointer corresponding to the flow instance and thread to which the asynchronous node belongs. If the node identifier of the asynchronous node matches the node identifier of the node indicated by the target node pointer, the execution of the nodes in the business process from the asynchronous node onward is continued.

[0180] Node pointers have already been described in detail above, so we will not elaborate again. The process orchestration engine identifies the node identifier, flow instance identifier, and thread identifier of an asynchronous node, which are stored in association with the function identifier. Based on the flow instance identifier and thread identifier of the asynchronous node, it can then identify the target node pointer. The target node pointer is the node pointer corresponding to the flow instance and thread to which the asynchronous node belongs. The flow instance to which the asynchronous node belongs is identified based on the flow instance identifier submitted by the user, and the thread to which the asynchronous node belongs is identified based on the thread identifier submitted by the user.

[0181] The process orchestration engine compares the node identifier of the asynchronous node, found based on its function identifier, with the node identifier of the node pointed to by the target node pointer. If the asynchronous node's node identifier matches the node identifier of the node pointed to by the target node pointer, it means that the thread to which the target node pointer belongs has just executed up to the position of the asynchronous node, and then the process execution has been suspended, waiting for a callback from the target function by a third party. However, since the target function corresponding to the asynchronous node was called by the third party, the external operation that the asynchronous node was waiting for has been completed. As a result, the process orchestration engine can continue to execute nodes in the business process from the asynchronous node onward. On the other hand, if the asynchronous node's node identifier does not match the node identifier of the node pointed to by the target node pointer, an exception may be thrown.

[0182] In the implementation process described above, the node identifier of the asynchronous node is compared with the node identifier of the node pointed to by the target node pointer to determine whether to continue executing the nodes after the asynchronous node. This is convenient for controlling and managing the movement of execution logic between nodes within a flow instance, ensuring the accuracy and reliability of process execution.

[0183] Selectively, the process orchestration engine may identify the flow instance and thread to which the asynchronous node belongs based on the flow instance identifier and thread identifier retrieved using the function identifier, and then, based on the node identifier retrieved using the function identifier, locate the asynchronous node at that time within the thread, and then continue execution downwards. In other words, it may not be necessary to verify the node pointer, and consequently, it may not be necessary to implement the node pointer.

[0184] Refer to the schematic structural diagram of the process orchestration apparatus provided in the embodiment of the present application shown in Figure 10. The embodiment of the present application provides a process orchestration apparatus 200 including the following modules.

[0185] Orchestration Module 210: Used to generate business processes requiring orchestration in response to node selection and node parameter setting operations based on the interface. Nodes supported for selection in node selection operations include synchronous and asynchronous nodes. Synchronous nodes represent tasks that can be executed without waiting for external actions, while asynchronous nodes represent tasks that cannot be executed without waiting for external actions.

[0186] Execution module 220: Used to execute nodes in a business process sequentially according to the order of the nodes in the business process.

[0187] Selectively, in embodiments of the present invention, the process orchestration device includes a node identifier, a flow instance identifier, and a thread identifier in the properties of a node. The node identifier is used to identify different nodes within a business process. Also, one flow instance is created each time the business process is executed. The flow instance identifier is used to identify the flow instance to which a node belongs. A flow instance contains one or more threads. The thread identifier is used to identify the thread to which a node belongs. A thread is a concurrent execution branch within a flow instance.

[0188] Selectively, in embodiments of the present invention, if the process orchestration device's external operation corresponding to an asynchronous node is an operation in which a user submits data on a target page, the execution module further obtains the node identifier, flow instance identifier, and thread identifier of the asynchronous node, and concatenates the node identifier, flow instance identifier, and thread identifier of the asynchronous node to generate the address of the target page. Next, it notifies the user performing the external operation corresponding to the asynchronous node of the address of the target page in a pre-configured manner and receives the data submitted by the user on the target page. The data includes business data, the node identifier, flow instance identifier, and thread identifier of the asynchronous node.

[0189] Selectively, in embodiments of the present invention, the process orchestration device is provided with a node pointer for each thread within a flow instance. The node pointer indicates the node currently executing within the thread. The process orchestration device also includes a first pointer determination module for obtaining the node identifier of an asynchronous node, a flow instance identifier, and a thread identifier from data submitted by the user, and for identifying the target node pointer based on the flow instance identifier and the thread identifier. The target node pointer is the node pointer corresponding to the flow instance and thread to which the asynchronous node belongs. If the node identifier of the asynchronous node matches the node identifier of the node indicated by the target node pointer, the execution of the nodes in the business process from the asynchronous node onward continues.

[0190] Selectively, in the embodiments of the present application, the process orchestration apparatus includes a form page or an approval page on the target page.

[0191] Selectively, in embodiments of the present invention, if the target page is a form page of an edited form, the process orchestration device further obtains a form instance identifier corresponding to the edited form, and generates the address of the target page by concatenating the node identifier of the asynchronous node, the flow instance identifier, the thread identifier, and the form instance identifier. The form instance identifier is used to retrieve the form data of the edited form, and the form data is used to render the target page. In addition, the data submitted by the user on the target page includes the updated form data, the node identifier of the asynchronous node, the flow instance identifier, the thread identifier, and the form instance identifier.

[0192] Selectively, in embodiments of the present invention, the process orchestration device includes the following as a pre-configured method for notifying a user who performs an external operation corresponding to an asynchronous node:

[0193] Method 1: Obtain user information of the user executing the external operation corresponding to the asynchronous node, and send notification information to the user based on the user information. The notification information includes the address of the target page.

[0194] Method 2: Retrieves the user's To-Do list. It also generates a target To-Do item based on the address of the target page. The target To-Do item is used to instruct the user to proceed to the target page. The target To-Do item is added to the user's To-Do list.

[0195] Third method: Obtain a list of user data. Additionally, generate interaction buttons based on the target page address. These interaction buttons are used to instruct the user to proceed to the target page. The interaction buttons are added to the user's data list.

[0196] Selectively, in embodiments of the present invention, if the process orchestration device's external operation corresponding to an asynchronous node is a callback operation of a target function by a third party, the execution module further stores the node identifier, flow instance identifier, and thread identifier of the asynchronous node in association with the function identifier of the target function corresponding to the asynchronous node. Next, it calls an interface provided by the third party to send the function identifier to the third party. Then, in response to the third party's call to the target function using the function identifier, it identifies the node identifier, flow instance identifier, and thread identifier of the asynchronous node that are stored in association with the function identifier, based on the function identifier of the called target function.

[0197] Selectively, in the embodiments of the present invention, the process orchestration device is provided with a node pointer for each thread within a flow instance. The node pointer indicates the node currently executing within the thread. The second pointer determination module is used to identify the target node pointer based on the flow instance identifier and thread identifier of the asynchronous node. The target node pointer is the node pointer corresponding to the flow instance and thread to which the asynchronous node belongs. If the node identifier of the asynchronous node matches the node identifier of the node indicated by the target node pointer, the execution of the nodes in the business process from the asynchronous node onward continues.

[0198] Selectively, in embodiments of the present invention, the process orchestration device includes loop nodes in its nodes. A loop node is a node that needs to repeatedly execute the child nodes within its loop body until a loop termination condition is met. The loop node's parameters include a parallel property. When the execution module has reached the loop node, if the loop node's parallel property is set to parallel execution, it generates a number of secondary threads under the thread to which the loop node belongs equal to the sum of the values ​​that the loop variable of the loop node can take, and uses these secondary threads to execute the loop body in parallel as the loop variable takes each value. On the other hand, when the execution has reached the loop node, if the loop node's parallel property is set to non-parallel execution, it uses the thread to which the loop node belongs to repeatedly execute the loop body according to the changes in the loop variable.

[0199] Selectively, in the embodiments of the present invention, if the parallel property of a loop node is set to parallel execution in the process orchestration device, the execution result of the loop node is obtained based on the execution result corresponding to each secondary thread.

[0200] Selectively, in embodiments of the present invention, the process orchestration device further includes a thread discard module. When the parallel property of a loop node is set to parallel execution, the module includes the completion of execution of each secondary thread, execution of any one secondary thread up to the loop's pre-termination instruction, or execution of any one secondary thread times out as loop termination conditions. After the execution of the loop node is completed, the generated secondary threads are discarded, and the nodes in the business process continue to be executed using the thread to which the loop node belongs.

[0201] Selectively, in embodiments of the present invention, the process orchestration device includes the following rules for generating node thread identifiers: If a node is not a child node of a loop node whose concurrency property is set to concurrent execution, the node's thread identifier matches the flow instance identifier. On the other hand, if a node is a child node of a loop node whose concurrency property is set to concurrent execution, the node's thread identifier is generated based on the thread identifier of the loop node that is closest to the node among the child node's parent nodes and whose concurrency property is set to concurrent execution, and the loop number corresponding to the node. The loop number corresponding to the node is the number within the total range of values ​​that the loop variable corresponding to the thread to which the node belongs can take at that time.

[0202] Selectively, in the embodiments of the present invention, the business process includes a first node and a second node. Of these, the execution order of the first node is earlier than that of the second node. The node identifier, flow instance identifier, thread identifier, and execution result of the node are stored in association with each other after the node's execution is completed. If the parameters set for the second node include a reference to the execution result of the first node, the process orchestration device further includes an execution result acquisition module. This module acquires the node identifier and flow instance identifier of the first node. Next, in reverse order of the business process execution order, starting from the second node, it searches for nodes whose business process execution order is earlier than that of the second node. During the search process, based on the thread identifier generation rules and the thread identifier of the second node, the thread identifier of each target node is identified until the node identifier of the target node becomes the node identifier of the first node, and the thread identifier of the first node is identified as the thread identifier of the target node. Then, the execution result of the first node, which is stored in association with the node identifier, flow instance identifier, and thread identifier of the first node, is acquired.

[0203] It should be understood that the device corresponds to the embodiment of the process orchestration method described above and is capable of performing each step mentioned in the embodiment of the method described above. For details on the specific functions of the device, please refer to the description above; therefore, to avoid duplication, detailed descriptions will be omitted here as appropriate. The device includes at least one software function module that can be stored in memory in software or firmware format, or that is fixed to the device's operating system (OS).

[0204] Refer to the schematic diagram of the electronic device provided in the embodiment of the present application shown in Figure 11. The electronic device 300 provided in the embodiment of the present application includes a processor 310 and a memory 320. The memory 320 stores machine-readable instructions that the processor 310 can execute. The above method is performed when a machine-readable instruction is executed by the processor 310.

[0205] Embodiments of the present invention further provide a storage medium on which a computer program is stored. The above method is performed when the computer program is run by a processor.

[0206] The storage medium can be implemented using any type of volatile or non-volatile storage device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable red-only memory (PROM), read-only memory (ROM), magnetic storage devices, flash memory, magnetic disks, or optical disks.

[0207] In some embodiments provided herein, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The embodiments of the apparatus described above are only schematic. For example, the flowcharts and block diagrams in the figures illustrate the architecture, functions, and operations that can be implemented by apparatus, methods, and computer program products based on some of the embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, program segment, or part of code. A module, program segment, or part of code may contain one or more executable instructions for implementing a given logical function. It should be noted that in some alternative implementations, the functions shown in a block may occur in an order different from the order shown in the figure. For example, two consecutive blocks may actually be executed almost in parallel, or in some cases in reverse order. These are determined according to the functions involved. Furthermore, it should be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system for performing a given function or operation, or by a combination of dedicated hardware and computer instructions.

[0208] In addition, each functional module in each embodiment of the embodiments of the present application may be integrated together to form a single independent part, each module may exist individually, or two or more modules may be integrated to form a single independent part.

[0209] The foregoing description is merely an example of selectable embodiments of the embodiments of this application, and the scope of protection of the embodiments of this application is not limited thereto. Any modification or substitution that a person skilled in the art could easily conceive of within the scope of the art disclosed in the embodiments of this application shall be included within the scope of protection of the embodiments of this application.

Claims

1. A process orchestration method performed by a computer equipped with a process orchestration engine, A step of generating a business process requiring orchestration in response to node selection operations and node parameter setting operations based on an interface, Each time the aforementioned business process is executed, one flow instance is generated. The step includes executing the nodes in the business process in order according to the order of the nodes in the business process, The nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes, wherein the synchronous nodes represent tasks that can be executed without waiting for external operations, and the asynchronous nodes represent tasks that cannot be executed without waiting for external operations. The properties of the node include a node identifier, a flow instance identifier, and a thread identifier, the node identifier being used to identify different nodes within the business process. The aforementioned flow instance identifier is used to identify the flow instance to which the node belongs. The flow instance includes one or more threads, the thread identifier is used to identify the thread to which the node belongs, and the thread is a concurrent execution branch within the flow instance. If the external operation corresponding to the asynchronous node is an operation in which a user submits data on the target page, the step of executing the nodes in order is: When execution reaches the asynchronous node, the steps include obtaining the node identifier of the asynchronous node, the flow instance identifier, and the thread identifier, The steps include: generating the address of the target page by concatenating the node identifier of the asynchronous node, the flow instance identifier, and the thread identifier; The steps include notifying the user of the address of the target page, The step includes receiving data submitted by the user on the aforementioned target page, The data includes the node identifier of the asynchronous node, the flow instance identifier, and the thread identifier. Based on the node identifier of the asynchronous node, the flow instance identifier and the thread identifier of the asynchronous node included in the received data, the steps include: positioning the thread of the flow instance to which the asynchronous node belongs; A method characterized by including the step of continuing to execute subsequent nodes of the asynchronous node in the positioned thread.

2. A process orchestration method performed by a computer equipped with a process orchestration engine, A step of generating a business process requiring orchestration in response to node selection operations and node parameter setting operations based on an interface, Each time the aforementioned business process is executed, one flow instance is generated. The step includes executing the nodes in the business process in order according to the order of the nodes in the business process, The nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes, wherein the synchronous nodes represent tasks that can be executed without waiting for external operations, and the asynchronous nodes represent tasks that cannot be executed without waiting for external operations. The properties of the node include a node identifier, a flow instance identifier, and a thread identifier, wherein the node identifier is used to identify a different node within the business process, the flow instance identifier is used to identify the flow instance to which the node belongs, the flow instance includes one or more threads, the thread identifier is used to identify the thread to which the node belongs, and the thread is a concurrent execution branch within the flow instance. The node includes a loop node, which is a node that must repeat the execution of its child nodes within the loop body until the loop termination condition is met, and the parameters of the loop node include a parallel property. The thread identifier generation rules include: if the node is not a child node of a loop node whose concurrency property is set to concurrent execution, the thread identifier of the node matches the flow instance identifier; if the node is a child node of a loop node whose concurrency property is set to concurrent execution, the thread identifier of the node is generated based on the thread identifier of the loop node that is closest to the node among the parent nodes of the child node and whose concurrency property is set to concurrent execution, and the loop number corresponding to the node, wherein the loop number corresponding to the node is a number within the total range of values ​​that the loop variable corresponding to the thread to which the node belongs can take at that time. If the parallel property of the loop node is set to parallel execution, the loop termination conditions include the completion of execution of each secondary thread, execution of any one of the secondary threads up to the loop's pre-termination instruction, or execution of any one of the secondary threads timing out. The step of executing the aforementioned nodes in order is: When execution reaches the aforementioned loop node, if the parallel property of the loop node is set to parallel execution, the following steps are taken: Create a number of secondary threads under the thread to which the loop node belongs equal to the sum of the values ​​that the loop variables of the loop node can take. The steps include: using the aforementioned secondary thread to execute the loop body in parallel as the loop variable takes each value; If, upon execution up to the aforementioned loop node, the parallel property of the loop node is set to non-parallel execution, the thread to which the loop node belongs is used to repeatedly execute the loop body in accordance with the changes in the loop variable. A method characterized in that, when the parallel property of the loop node is set to parallel execution, after the execution of the loop node is completed, the generated secondary thread is discarded and the node in the business process is continued to be executed using the thread to which the loop node belongs.

3. A process orchestration method performed by a computer equipped with a process orchestration engine, A step of generating a business process requiring orchestration in response to node selection operations and node parameter setting operations based on an interface, Each time the aforementioned business process is executed, one flow instance is generated. A step of executing the nodes in the business process in order according to the order of the nodes in the business process, The step includes, after the execution of the node is completed, storing the node identifier, flow instance identifier, thread identifier, and execution result of the node in association with each other. The nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes, wherein the synchronous nodes represent tasks that can be executed without waiting for external operations, and the asynchronous nodes represent tasks that cannot be executed without waiting for external operations. The properties of the node include a node identifier, a flow instance identifier, and a thread identifier, wherein the node identifier is used to identify a different node within the business process, the flow instance identifier is used to identify the flow instance to which the node belongs, the flow instance includes one or more threads, the thread identifier is used to identify the thread to which the node belongs, and the thread is a concurrent execution branch within the flow instance. The node includes a loop node, which is a node that must repeat the execution of its child nodes within the loop body until the loop termination condition is met, and the parameters of the loop node include a parallel property. The thread identifier generation rules include the following: if the node is not a child node of a loop node whose concurrency property is set to concurrent execution, the thread identifier of the node matches the flow instance identifier; if the node is a child node of a loop node whose concurrency property is set to concurrent execution, the thread identifier of the node is generated based on the thread identifier of the loop node that is closest to the node among the parent nodes of the child node and whose concurrency property is set to concurrent execution, and the loop number corresponding to the node, wherein the loop number corresponding to the node is a number within the total range of values ​​that the loop variable corresponding to the thread to which the node belongs can take at that time. The aforementioned business process includes a first node and a second node, and the execution order of the first node is before that of the second node. The step of executing the aforementioned nodes in order is: When execution reaches the aforementioned loop node, if the parallel property of the loop node is set to parallel execution, the following steps are taken: Create a number of secondary threads under the thread to which the loop node belongs equal to the sum of the values ​​that the loop variables of the loop node can take. The steps include: using the aforementioned secondary thread to execute the loop body in parallel as the loop variable takes each value; If, upon execution up to the aforementioned loop node, the parallel property of the loop node is set to non-parallel execution, the thread to which the loop node belongs is used to repeatedly execute the loop body in accordance with the changes in the loop variable. If the parameters set in the second node include a reference to the execution result of the first node, the step includes obtaining the execution result of the first node. The step of obtaining the execution result of the first node is: The steps include obtaining the node identifier and flow instance identifier of the first node, In reverse order of the execution sequence of the business process, starting from the second node, the search is performed to find nodes whose execution sequence of the business process precedes that of the second node, and during the search process, based on the thread identifier generation rules and the thread identifier of the second node, the thread identifier of each target node is identified until the node identifier of the target node becomes the node identifier of the first node, and the thread identifier of the first node is identified as the thread identifier of the target node. A method characterized by comprising the step of obtaining the execution result of the first node, which is stored in association with the node identifier, flow instance identifier, and thread identifier of the first node.

4. Each thread within the flow instance is provided with a node pointer, which indicates the node currently executing within the thread. After receiving the data submitted by the user on the target page, the method further... Obtain the node identifier, flow instance identifier, and thread identifier of the asynchronous node from the data submitted by the user. Based on the flow instance identifier and the thread identifier, the target node pointer is identified, and the target node pointer is the node pointer corresponding to the flow instance and thread to which the asynchronous node belongs. If the node identifier of the asynchronous node matches the node identifier of the node indicated by the target node pointer, the process continues to execute the nodes from the asynchronous node onward within the business process. The method according to claim 1, characterized by the above.

5. The method according to claim 1, characterized in that the aforementioned target page includes a form page or an approval page.

6. If the target page is the form page of an edited form, then the node identifier, flow instance identifier, and thread identifier of the asynchronous node mentioned above are concatenated to generate the address of the target page. Obtain the form instance identifier corresponding to the edited form, The node identifier, flow instance identifier, thread identifier, and form instance identifier of the asynchronous node are concatenated to generate the address of the target page, the form instance identifier is used to search for the form data of the edited form, and the form data is used to render the target page. Includes, The method according to claim 5, characterized in that the data submitted by the user on the target page includes the updated form data, the node identifier of the asynchronous node, the flow instance identifier, the thread identifier, and the form instance identifier.

7. The pre-configured method for notifying users who perform external operations corresponding to the asynchronous node is: First method: Obtain user information of the user performing the external operation corresponding to the asynchronous node, send notification information to the user based on the user information, and the notification information includes the address of the target page. Second method: Obtain the user's To-Do list, generate a target To-Do item based on the address of the target page, use the target To-Do item to instruct the user to proceed to the target page, and add the target To-Do item to the user's To-Do list. Third method: Obtain the user's data list, generate an interaction button based on the address of the target page, use the interaction button to instruct the user to proceed to the target page, and add the interaction button to the user's data list. The method according to claim 1, characterized by including the following:

8. The method according to claim 2, characterized in that when the parallel property of the loop node is set to parallel execution, the execution result of the loop node is obtained based on the execution result corresponding to each secondary thread.

9. A process orchestration apparatus comprising a processor and memory, A process orchestration apparatus wherein the processor is configured to execute the process orchestration method according to any one of claims 1 to 8 by executing instructions stored in the memory.

10. An electronic device comprising a processor and a memory, wherein the memory stores machine-readable instructions that the processor can execute, and when the machine-readable instructions are executed by the processor, the process orchestration method described in any one of claims 1 to 8 is executed.

11. A computer-readable storage medium in which a computer program is stored, and when the computer program is operated by a processor, the process orchestration method described in any one of claims 1 to 8 is executed.

Images