Process orchestration method and apparatus, electronic device and storage medium
The process orchestration method supports synchronous and asynchronous nodes, addressing the limitations of existing engines by enhancing compatibility and availability through visualized orchestration and efficient execution control.
Patent Information
- Application Number
- JP2024218884
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-01-25
- Filing Date
- 2024-12-13
- Publication Date
- 2025-08-06
- Estimated Expiration
- 2044-12-13
AI Technical Summary
Current orchestration engines struggle to adapt to the diverse and asynchronous nature of actual business processes, leading to poor compatibility and availability.
A process orchestration method that supports both synchronous and asynchronous nodes, allowing users to select and set parameters on an interface, enabling visualized orchestration without extensive coding, and includes features like node identifiers and threads for improved execution control.
Enhances the compatibility and availability of orchestration engines by enabling the orchestration of diverse business processes, reducing code errors, and improving process execution efficiency and visibility.
Smart Images

Figure 2025115367000001_ABST
Abstract
Description
[Technical Field]
[0001] The present application relates to the technical field of computer applications, and more particularly to a process orchestration method, apparatus, electronic device, and storage medium. [Background technology]
[0002] Process orchestration is the process of combining tasks related to some executable process in an order of execution using an orchestration engine. However, current orchestration engines have poor orchestration capabilities, while the tasks related to actual business processes are often diverse. As a result, current orchestration engines are unable to adapt to the diverse orchestration needs of actual business processes. Summary of the Invention [Problem to be solved by the invention]
[0003] The objective of the embodiments of the present application is to provide a process orchestration method, device, electronic device, and storage medium to address the problem that current orchestration engines are unable to adapt to the diversified orchestration needs in actual business processes and have poor orchestration engine availability. [Means for solving the problem]
[0004] In a first aspect, an embodiment of the present application provides a process orchestration method. The method generates a business process requiring orchestration in response to a node selection operation and a node parameter setting operation based on an interface. Nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes. A synchronous node represents a task that can be executed without waiting for an external operation, while an asynchronous node represents a task that cannot be executed without waiting for an external operation. Furthermore, the nodes in the business process are executed in order according to the order of the nodes in the business process.
[0005] The above method can be applied to a process orchestration engine. In the above implementation process, a user selects nodes and sets node parameters on the interface to generate a business process that requires orchestration, resulting in a visualized process orchestration. This orchestration process does not require writing a large amount of code, which improves the efficiency of process orchestration and reduces the probability of code syntax errors. In addition, the orchestration process of a business process becomes more visible to general users and easier to operate.
[0006] Furthermore, in the node selection operation, the nodes supported for selection include synchronous nodes 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 actions, or to orchestrate asynchronous nodes to realize tasks that cannot be executed without waiting for external actions (of course, these two types of nodes may be orchestrated simultaneously). This makes it possible for the resulting business process to effectively describe the diversified types of tasks in actual business, thereby resolving the issue that conventional orchestration engines are unable to adapt to the orchestration needs of actual business processes, and improving the compatibility and availability of the orchestration engine.
[0007] Optionally, in the present embodiment, 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 in a business process. Furthermore, one flow instance is generated each time a business process is executed. The flow instance identifier is used to identify the flow instance to which the node belongs. A flow instance includes one or more threads. The thread identifier is used to identify the thread to which the node belongs. A thread is a parallel execution branch within a flow instance.
[0008] In the above implementation, threads are introduced into the flow instances to improve the efficiency of process execution, and properties such as node identifiers, flow instance identifiers, and thread identifiers are set to distinguish different entities related to the execution of business processes, which is beneficial to ensuring the accuracy and reliability of process execution.
[0009] Optionally, in an embodiment of the present application, if the external operation corresponding to the asynchronous node is an operation in which a user submits data on a target page, the step of executing the asynchronous node includes: 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 an address of the target page; notifying the address of the target page in a predetermined manner to the user executing the external operation corresponding to the asynchronous node, 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 above implementation, the node identifier, flow instance identifier, and thread identifier of the asynchronous node are concatenated to generate the address of the target page, and the address of the target page is notified to the user. This allows the user to submit the node identifier, flow instance identifier, and thread identifier of the asynchronous node together when submitting data on the target page. These identifiers are used to locate the thread of the flow instance to which the asynchronous node belongs, allowing subsequent nodes of the asynchronous node to continue execution. In other words, the above implementation realizes support for asynchronous nodes at the execution level, thereby effectively enhancing the compatibility and availability of the process orchestration engine.
[0011] Optionally, in an embodiment 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 in the thread. After receiving data submitted by a user on the target page, the method further includes: obtaining the node identifier, flow instance identifier, and thread identifier of the asynchronous node from the data submitted by the user, and identifying the target node pointer based on the flow instance identifier and thread identifier. The target node pointer is a 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 nodes following the asynchronous node in the business process are executed.
[0012] In the above implementation, the node pointer indicates the node currently being executed in the thread. The target node pointer is identified using the flow instance identifier and thread identifier in the data submitted by the user, and the node identifier is compared to determine whether to continue execution. This is convenient for controlling and managing the movement of execution logic between nodes within the flow instance, ensuring the accuracy and reliability of process execution.
[0013] Optionally, in the present embodiment, the target page includes a form page or an approval page.
[0014] In the above implementation process, the target page includes a form page or an approval page, which can realize different tasks depending on the format of the target page, which is advantageous for improving the availability of the process orchestration engine and is particularly applicable to enterprise scenarios (since filling out forms and approving decisions are common tasks in enterprises).
[0015] Optionally, in an embodiment of the present application, if the target page is a form page of an edited form, generating an address of the target page by concatenating the node identifier, flow instance identifier, and thread identifier of the asynchronous node includes: obtaining a 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 an address of the target page; the form instance identifier is used to retrieve form data of the edited form, and the form data is used to render the target page; and the data submitted by the user on the target page includes the updated form data, the node identifier, flow instance identifier, thread identifier, and form instance identifier of the asynchronous node.
[0016] In the above implementation process, if the target page is the form page of an edited form, the form instance identifier is linked 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 the 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 realizing the reuse of form data. Furthermore, when the user submits the updated form data, the form instance identifier is also submitted in addition to the node identifier of the asynchronous node, the flow instance identifier, and the thread identifier. This allows the process orchestration engine to manage the updated form data based on the form instance identifier.
[0017] Optionally, in the embodiment of the present application, the preset manner of notifying a user who performs an external operation corresponding to an asynchronous node includes:
[0018] First method: Obtain user information of the user who executes 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] Second method: Obtain the user's ToDo list. Also, generate a target ToDo item based on the address of the target page. The target ToDo item is used to instruct the user to proceed to the target page. The target ToDo item is added to the user's ToDo list.
[0020] The third method: Obtain the user's data list. Also, generate an interaction button based on the address of the target page. The interaction button is used to instruct the user to proceed to the target page. The interaction button is added to the user's data list.
[0021] The above implementation process provides various and flexible notification methods for users, allowing them to select the appropriate method based on the specific application scenario and page requirements of the target page. By doing so, the user can obtain the address of the target page, go to the target page, and complete the external operation corresponding to the asynchronous node.
[0022] Optionally, in an embodiment of the present application, 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 includes: 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; calling an interface provided by the third party to send the function identifier to the third party; and 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 in response to the third party calling the target function using the function identifier.
[0023] In the above implementation process, 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 stored in association with the function identifier are identified based on the function identifier of the called target function. These identifiers are then used to locate the thread of the flow instance to which the asynchronous node belongs, allowing subsequent nodes of the asynchronous node to continue execution. In other words, the above implementation process realizes support for asynchronous nodes at the execution level.
[0024] In addition, it can be seen that the asynchronous node in the embodiment of the present application can support external actions in many application scenarios (for example, actions such as form filling and approval performed by a person, and function callback actions performed by a device), which can better meet the diversified orchestration needs of actual business processes, and effectively enhance the compatibility and availability of the process orchestration engine.
[0025] Optionally, in an embodiment of the present application, a node pointer is provided for each thread in the flow instance. The node pointer indicates the node currently executing in 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: identifying a target node pointer based on the flow instance identifier and thread identifier of the asynchronous node. The target node pointer is a 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 nodes following the asynchronous node in the business process are executed.
[0026] In the above implementation process, whether to continue executing the nodes following the asynchronous node is determined by comparing whether the node identifier of the asynchronous node matches the node identifier of the node pointed to by the target node pointer. This is convenient for controlling and managing the movement of execution logic between nodes within a flow instance, and ensures the accuracy and reliability of process execution.
[0027] Optionally, in the embodiment of the present application, the node includes a loop node. A loop node is a node that requires repeated execution of a child node in a loop body until a loop termination condition is met. The parameters of the loop node include a parallel property. If the parallel property of the loop node is set to parallel execution when execution reaches the loop node, secondary threads are generated under the thread to which the loop node belongs, the number of which is equal to the total number of values taken by the loop variable of the loop node, and the secondary threads are used to execute the loop body in parallel when the loop variable takes each value. On the other hand, if the parallel property of the loop node is set to non-parallel execution when execution reaches the loop node, the thread to which the loop node belongs is used to repeatedly execute the loop body according to changes in the loop variable.
[0028] In the above implementation process, the nodes include loop nodes. The parallel property of a loop node can be set to parallel execution or non-parallel execution, and the parallel property of the loop node can be set as needed. If the parallel property of a loop node is set to parallel execution, multiple secondary threads are generated and the loop body is executed in parallel, improving the execution efficiency and performance of the loop node.
[0029] Optionally, in the embodiment of the present 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.
[0030] In the above implementation process, 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 results corresponding to each secondary thread. This allows you to set corresponding rules based on actual needs and map the execution results corresponding to each secondary thread as the execution result of the loop node (for example, you can perform weighting and statistics on the execution results of each thread). As a result, the execution logic of the loop node can better reflect actual business needs.
[0031] Optionally, in the present embodiment, when the parallel property of the loop node is set to parallel execution, the loop termination conditions include completion of execution of each secondary thread, execution of any one secondary thread until the loop pre-termination command, or execution of any one secondary thread until a time-out occurs. Also, after the execution of the loop node is completed, the generated secondary thread is discarded, and the thread to which the loop node belongs is used to continue executing the nodes in the business process.
[0032] In this implementation, the loop has multiple termination methods, allowing the loop node's execution logic to better reflect actual business needs. Furthermore, after the loop node completes execution, the generated secondary thread is quickly discarded, freeing up resources such as memory, CPU, and network connections occupied by the thread. Then, the thread containing the loop node continues to execute nodes in the business process, reducing system resource consumption during business process execution.
[0033] Optionally, in the embodiment of the present application, the rule for generating a thread identifier for a node includes the following: if the node is not a child node of a loop node whose parallel property is set to parallel execution, the thread identifier of the node matches the flow instance identifier; on the other hand, if the node is a child node of a loop node whose parallel property is set to parallel execution, the thread identifier of the node is generated based on the thread identifier of the loop node whose parallel property is set to parallel execution and is closest to the node among the parent nodes of the child node, and whose parallel property is set to parallel execution, and the loop number corresponding to the node; the loop number corresponding to the node is a number within all values currently held by the loop variable corresponding to the thread to which the node belongs.
[0034] In the above implementation, a thread identifier corresponding to a node is generated based on a rule. Such a thread identifier not only identifies the thread in which the node exists, but also represents the father-child relationship between nodes, making it convenient for managing nodes within a process.
[0035] Optionally, in an embodiment of the present application, the business process includes a first node and a second node. Of these, the first node is executed before the second node. The node identifier, flow instance identifier, thread identifier, and execution result of the node are associated and stored after the node is completed. If the parameters set for the second node include a reference to the execution result of the first node, the step of acquiring the execution result of the first node includes the following: Acquire the node identifier and flow instance identifier of the first node. Next, in reverse order of the execution order of the business process, starting from the second node, search for nodes whose execution order of the business process precedes the second node. During the search process, the thread identifiers of each search target node are identified based on the thread identifier generation rule and the thread identifier of the second node 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 acquired.
[0036] In the above implementation process, the execution result of a preceding node (e.g., the first node) can be obtained using the node identifier and flow instance identifier of the preceding node and the generation rule of the thread identifier. This allows a subsequent node (e.g., the second node) in the business process to refer to the execution result of the preceding node as input during its execution process, thereby increasing the number of input types for the node and enabling the node's execution logic to better reflect actual business needs.
[0037] In a second aspect, an embodiment of the present application further provides a process orchestration apparatus, including: an orchestration module that generates a business process requiring orchestration in response to a node selection operation and a node parameter setting operation based on an interface, where nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes, where the synchronous nodes represent tasks that can be executed without waiting for an external operation, and the asynchronous nodes represent tasks that cannot be executed without waiting for an external operation; 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 an electronic device, the electronic device including a processor and a memory, the memory storing machine-readable instructions executable by the processor, the machine-readable instructions, when executed by the processor, performing the method described above.
[0039] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium having a computer program stored therein, the computer program executing the above-described method when run by a processor. [Effects of the Invention]
[0040] The process orchestration method, device, electronic device, and storage medium provided herein enable business processes requiring orchestration to be generated through node selection and node parameter setting operations, thereby achieving visualized programming. This allows the process execution logic to be visualized, displayed, and processed, making it more intuitive and easy to understand, thereby accelerating process development. Furthermore, the process orchestration process does not require the writing of large amounts of code, reducing the likelihood of code syntax errors. Furthermore, the nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes. This enables the orchestration and execution of synchronous and / or asynchronous nodes, effectively enhancing the compatibility and availability of the process orchestration engine. These improvements address the limited application range and poor availability of process orchestration engines.
[0041] In order to more clearly describe the technical solutions of the embodiments of the present application, the following briefly describes the drawings that need to be used in the embodiments of the present application. It should be understood that the following drawings only illustrate some embodiments of the present application, and should not be considered as limiting the scope. Those skilled in the art can also obtain other related drawings from these drawings without requiring creative work. [Brief explanation of the drawings]
[0042] [Figure 1] FIG. 1 is a schematic flowchart of a process orchestration method provided in an embodiment of the present application. [Figure 2] FIG. 2 is a schematic diagram of a visualized orchestration interface provided in an embodiment of the present application. [Figure 3] FIG. 3 is a schematic diagram of the node parameter setting operation provided in an embodiment of the present application. [Figure 4] FIG. 4 is a schematic diagram of a loop node with the parallel property set to parallel execution provided in an embodiment of the present application. [Figure 5] FIG. 5 is a schematic diagram of the execution process of a loop node in which the parallel property is set to non-parallel execution in an embodiment of the present application. [Figure 6] FIG. 6 is a schematic diagram of the execution process of a loop node whose parallel property is set to parallel execution in an embodiment of the present application. [Figure 7] FIG. 7 is a schematic diagram of the execution process of the nested loop node provided in the embodiment of the present application. [Figure 8] FIG. 8 is a schematic diagram for referring to the execution results of the node provided in the embodiment of the present application. [Figure 9] FIG. 9 is a schematic diagram of a data table including interaction buttons provided in an embodiment of the present application. [Figure 10] FIG. 10 is a schematic structural diagram of a process orchestration device provided in an embodiment of the present application. [Figure 11] FIG. 11 is a schematic structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION OF THE INVENTION
[0043] Next, the embodiments of the technical solution of the present application will be described in detail in combination with the drawings. The following embodiments are merely for the purpose of more clearly illustrating the technical solution of the present application, and are merely illustrative and should not be used to limit the scope of protection of the present application.
[0044] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art. Furthermore, the terms used herein are for the purpose of describing specific examples only and are not intended to limit the present application.
[0045] In the description of the embodiments of the present application, technical terms such as "first," "second," etc. are merely used to distinguish between different objects, and should not be interpreted as expressing or implying relative importance, or as suggesting the number, specific order, or hierarchical relationship of the technical features in question. Furthermore, in the description of the embodiments of the present application, unless otherwise clearly and specifically limited, "plurality" means two or more.
[0046] Before describing the process orchestration method provided in the embodiment of the present application, some concepts related to the embodiment of the present application will first be explained.
[0047] Process orchestration typically refers to completing some kind of business process through orchestration using several nodes. Each node represents a task that needs to be completed in the business process. During the orchestration process, each node is combined in order to form a specific execution chain (i.e., a business process). Examples of nodes here include IF (single-branch decision), IF-ELSE (two-branch decision), FOR (for loop), BREAK (exit from the loop), CONTINUE (end the current loop), SWITCH (multiple-branch choice), Function Call (function call; various functions are possible), Create Variable (create variable), Set Variable (set variable), Return, and Termination.
[0048] A process orchestration engine is software that supports process orchestration functionality. The process orchestration engine in this application can realize process orchestration in response to orchestration operations performed by a user on a visualized interface by interacting with the user through the interface.
[0049] Through research, the inventors have found that current process orchestration engines only support the orchestration of synchronous tasks. A synchronous task is a task that can be completed by automatically executing according to task logic and does not need to wait for external actions during execution. However, tasks related to actual business processes may include asynchronous tasks. An asynchronous task is a task that cannot be executed without waiting for external actions. Because current process orchestration engines do not currently support the orchestration of asynchronous tasks, they are unable to adapt to the diversified orchestration needs of actual business processes, resulting in poor compatibility and availability of the process orchestration engine.
[0050] In an embodiment of the present application, a process orchestration method, device, electronic device, and storage medium are provided that realize visualized process orchestration by allowing a user to perform node selection operations and node parameter setting operations on an interface to generate a business process requiring orchestration. In the node selection operation, nodes supported for selection 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. This allows the resulting business process to effectively describe the diversified task types in actual business operations, thereby addressing the problem of conventional orchestration engines being unable to 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 the technical solutions provided in the embodiments of the present application, as well as the above analysis of the technical issues existing in conventional process orchestration engines, are not present in the prior art and are contributions of the inventors to the present application. Reference is now made to the schematic flowchart of the process orchestration method provided in the embodiments of the present application shown in FIG. 1. The process orchestration method provided in the embodiments of the present application is applicable to an electronic device. 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 may be a terminal or server having a computer program execution function. Specific examples of the terminal include a smartphone, a tablet PC, a computer, a personal digital assistant (PDA), etc. Specific examples of the server may include an application server or a web server. The number of the electronic device may be one or more, for example, a cluster consisting 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 a business process requiring orchestration in response to the node selection operation and node parameter setting operation based on the interface. Nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes. A synchronous node represents a task that can be executed without waiting for an external operation, while an asynchronous node represents a task that cannot be executed without waiting for an external operation.
[0053] The interface in step S110 refers to a visualized orchestration interface that allows a user to perform process orchestration, such as a GUI for application software or a web page. The node selection operation refers to an operation in which a user selects a node of a business process that requires orchestration from among nodes that support selection in the interface. The node parameter setting operation refers to an operation in which a user sets parameters for the selected node. Naturally, this does not exclude other operations related to process orchestration that a user can perform on the interface.
[0054] The interface and the process orchestration engine are related to each other. For example, the interface can be displayed on a terminal device used by a user (e.g., a smartphone or a computer), and the process orchestration engine can be deployed on a backend server. Of course, the interface and the process orchestration engine can be located on the same device. Various process orchestration operations performed by a user on the interface can generate corresponding operation data and transmit it 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 whose execution is supported by the process orchestration engine. Users can configure a business process by selecting nodes based on the needs of the business process. Regarding node selection, two types of nodes are supported for user selection: synchronous nodes and asynchronous nodes. However, a business process does not necessarily have to contain both types of nodes at the same time; it can contain only one type of node. A synchronous node represents a task that can be executed without waiting for an external action. This is the synchronous task described above. Examples include a task that performs data statistics based on a predefined formula or a task that sends an email to a predefined recipient. An asynchronous node represents a task that cannot be executed without waiting for an external action. This is the asynchronous task described above. For example, a form-filling task cannot be executed unless a specific user fills out a form. In this case, the user filling out a form is considered an external action. Another example is a function callback task that cannot be executed unless a callback of the target function from a third party (which may mean some software other than the process orchestration engine) is considered an external action. However, it is important to note that an asynchronous task may be internally divided into multiple parts, some of which may be automatically executable and some of which may require external action, but the task as a whole is considered to be either executable only or unable to complete execution without waiting for external action.
[0056] As an alternative, FIG. 2 is a schematic diagram of a visualized orchestration interface provided in an embodiment of the present application. Referring to FIG. 2, the visualized orchestration interface may include a selection interface and a process setting interface. The process setting interface is used to display a business process that has already been orchestrated at that point in time. The selection interface is used to display nodes that support selection (which may 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 may involve selecting a required node from the selection nodes displayed in the selection interface and dragging it to an appropriate position in the process setting interface, or clicking and selecting a required node in the selection interface, with the clicked node automatically displayed in an appropriate position in the process setting interface.
[0057] In the process configuration interface, a user may determine the execution order of nodes by connecting selected nodes with links. Alternatively, in either implementation, nodes may be automatically connected (e.g., 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 appropriate parameters. Of course, this does not preclude the process orchestration engine from assigning default parameters to nodes without the user setting parameters. Here, reference is made to FIG. 3 , which shows a schematic diagram of the node parameter setting operation provided in the embodiment of the present application. An IF node is a node for which parameters can be set. In the node parameter setting operation, for example, when a user places a mouse over an IF node or clicks on an IF node, the interface on the right pops up. The interface displays input boxes that allow the user to set specific parameters for the IF node, such as setting the condition for the IF node (here, the amount is less than 500).
[0059] In some implementations, in addition to the node selection operation and node parameter setting operation, the user may also perform other orchestration operations on the interface, such as a node deletion operation. Continuing with reference to FIG. 3, when the mouse is placed over a current node (e.g., the first SET node or the second SET node) in the business process, a delete button may be displayed, thereby deleting the node when the user clicks the delete button.
[0060] An orchestrated business process may be described within an orchestration engine according to certain syntax rules. For example, a node may be described using a set of several fields, and these fields may have a nested relationship. Next, we will explain a possible method of describing a node within a process orchestration engine, using the IF-ELSE node in Figure 3 as an example. (The IF-ELSE node can be considered as a combination of an IF node and an ELSE node. This node implements the logic of an if-else statement in structured programming.) 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 a subflow to be executed when the condition is met and may include fields corresponding to one or more nodes (e.g., the first SET node). These fields may also be nested within the subFlow. elseSubFlow represents a subflow to be executed if the condition is not met, and may contain fields corresponding to one or more nodes (e.g., a second SET node). These fields may be nested within elseSubFlow. The nodes within subFlow and elseSubFlow may also be referred to as child nodes of the IF-ELSE node.
[0061] The above example presented the concept of child nodes, but not only do IF-ELSE nodes have child nodes, but several other nodes, such as loop nodes described below, also have child nodes. If a node in a business process has no child nodes, it is easy to determine whether the node is a synchronous node or an asynchronous node. On the other hand, if a node has child nodes, if all of the node's child nodes are synchronous nodes, the node itself becomes a synchronous node, and if the node's child nodes include an asynchronous node, the node itself becomes an asynchronous node.
[0062] Step S120: The process orchestration engine executes the nodes in the business process in order according to the order of the nodes in the business process.
[0063] In step S120, after orchestrating a business process, the user can send an execution confirmation command to the process orchestration engine by clicking an execution confirmation button on the interface. After receiving the execution confirmation command, the process orchestration engine executes the nodes in the business process in order. The execution logic within each node is pre-implemented by the process orchestration engine. As can be understood, after the user orchestrates the business process, it may be executed automatically, or execution may be triggered by some condition. Alternatively, as the user orchestrates the business process, the orchestrated parts may be executed automatically.
[0064] The business process may be executed by an interpretive execution method, but to improve execution efficiency, the business process may be translated into a high-level computer language code and the corresponding high-level computer language code may be executed to execute the process.
[0065] If a business process reaches a synchronous node, the process orchestration engine automatically executes the process according to the execution logic preset in the process, completing the corresponding synchronous task and continuing execution of the subsequent node (if it exists) in the business process. If a business process reaches an asynchronous node, the execution of the business process is blocked (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 an external action, and continuing execution of the subsequent node (if it exists) in the business process. Here, the entity executing the external action may be a person, some third-party software, or some kind of device.
[0066] The process orchestration engine can detect whether an external operation has been performed. For example, when a user fills out a form and clicks a form submit button on an 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 operation. Also, after a third party calls back a target function, if the target function is part of or monitored by the process orchestration engine, the process orchestration engine can detect that the third party has completed the function callback operation.
[0067] If an external operation is not executed for a long time, the process will remain blocked in the asynchronous node, making it impossible to execute subsequent nodes. To address this issue, a timeout processing mechanism may be provided in the asynchronous node. This allows the process orchestration engine to execute a timeout processing command if it does not detect the execution of an external operation within a specified time cycle. For example, by forcibly providing the execution result to the asynchronous node, the subsequent node can continue to execute, or the process execution can be forcibly stopped. The specified time cycle may be set within the process orchestration engine, or may be set by the user as a parameter of the asynchronous node.
[0068] Additionally, it should be noted that external actions are those related to the execution stage of a business process, and the node parameter setting operation performed in the orchestration stage of a business process does not belong to external actions.
[0069] In the above implementation process, users select nodes and set node parameters on the interface to generate business processes that require orchestration, resulting in visualized process orchestration. This orchestration process eliminates the need to write large amounts of code, improving the efficiency of process orchestration and reducing the probability of code syntax errors. Furthermore, the orchestration process for business processes becomes more visible and easier for general users to operate.
[0070] Furthermore, in the node selection operation, the nodes supported for selection include synchronous nodes 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 actions, or to orchestrate asynchronous nodes to realize tasks that cannot be executed without waiting for external actions (of course, these two types of nodes may be orchestrated simultaneously). This makes it possible for the resulting business process to effectively describe the diversified types of tasks in actual business, thereby resolving the issue that conventional orchestration engines are unable to adapt to the orchestration needs of actual business processes, and improving the compatibility and availability of the orchestration engine.
[0071] Optionally, in the present embodiment, the properties of a node include a node identifier, a flow instance identifier, and a thread identifier, which may be automatically assigned by the process orchestration engine, but do not exclude the case where they can be set by the user (considered as node parameters).
[0072] The node identifier is a unique identifier for a node and is used to identify different nodes within a business process and can also be used for reference within a business process. The node identifier can be displayed as Node ID.
[0073] A single flow instance is generated each time a business process is executed. If a business process is considered as a template, a flow instance can be considered as an actual object constructed based on this template. A business process does not contain actual data, but a flow instance does. A flow instance identifier is used to identify the flow instance to which a node belongs. Here, a flow instance is the result of instantiating a business process, so a flow instance includes all nodes within a business process.
[0074] During the same execution of the same business process, the flow instance identifiers of all nodes within the business process will be the same, but during different executions of the same business process, the flow instance identifiers will be different even for the same nodes. For example, during the first execution (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 the business process will be different. Therefore, it is possible to distinguish and identify nodes within different flow instances from the flow instance identifiers. The flow instance identifier can be displayed as Flow Instance ID.
[0075] A flow instance includes one or more threads. A thread is a branch of parallel execution within a flow instance. A thread can correspond to a fragment that includes several nodes in a business process (for example, as will be apparent from the following description, a thread can correspond to the loop body of a loop node). In particular, if a flow instance includes only one thread, this thread may be considered to be the flow instance itself, or in this case, the flow instance may be considered to have no threads. Threads included in a flow instance may also have a hierarchical structure. That is, a thread may not be directly dependent on the flow instance, but may be dependent on other threads. For example, if a flow instance includes three threads and the first thread includes two secondary threads, all five threads can be considered to be threads included in the flow instance. A thread identifier is used to identify the thread to which a node belongs. In a business process, the thread identifier corresponding to nodes in the same thread is the same. A thread identifier can be represented as a Thread ID.
[0076] In the above implementation process, introducing threads into flow instances improves the efficiency of process execution (because threads can be executed in parallel). In addition, by setting properties such as node identifiers, flow instance identifiers, and thread identifiers of nodes, it is possible to distinguish between different entities (nodes, flow instances, threads) related to the execution of a business process, which is advantageous in ensuring the accuracy and reliability of process execution. See the examples below for specific examples of how to use these node properties.
[0077] Optionally, in the embodiment of the present application, the nodes in the business process include a loop node. A loop node is a node whose loop body needs to be repeatedly executed until a loop termination condition is met. A loop body is a process fragment that is defined inside the loop node and needs to be repeatedly executed. A loop body may include one or more nodes, which may be referred to as child nodes of the loop node. A child node in the loop body defines an operation or logic that the loop node should execute. In particular, a child node of a loop node may be a loop node.
[0078] A loop node can be either a synchronous node or an asynchronous node. If all nodes within the loop body of the loop node are synchronous nodes, the loop node can also be considered a synchronous node. On the other hand, if the loop body of the loop node contains an asynchronous node, the loop node can be considered an asynchronous node.
[0079] The parameters of a loop node include a parallel property, which can be set to run in parallel or non-parallel.
[0080] When the execution reaches the loop node in step S120, if the parallel property of the loop node is set to parallel execution, the process orchestration engine generates, under the thread to which the loop node belongs (in this case, a flow instance may be considered as one thread), secondary threads in the same number as the total number of values that the loop variable of the loop node takes, and uses the secondary threads to execute the loop body in parallel when the loop variable takes each value. Here, each secondary thread is used to execute the loop body in parallel when the loop variable takes one value.
[0081] When execution reaches the loop node in step S120, if the parallel property of the loop node is set to non-parallel execution, the loop body is repeatedly executed according to the changes in the loop variable using the thread to which the loop node belongs. In other words, the loop body is executed serially according to the loop logic.
[0082] In response to the above, nodes in a business process may include non-loop nodes. A non-loop node can be defined as a node whose loop body does not need to be executed repeatedly. Since non-loop nodes are not involved in repeated execution, they can usually be executed serially.
[0083] Please refer to FIG. 4, which is a schematic diagram of a loop node with the parallel property set to parallel execution provided in an embodiment of the present application.
[0084] The asynchronous FOR node is a loop node (the FOR node implements the logic of the for statement in structured programming), and the loop body is the portion from the approval request node to the true-value return node. If the parallel property of the loop node is set to parallel execution, the parameter setting for this parallel property can be set by checking the parallel option, but other methods are also possible. For example, if a form requires approval from multiple approvers, and the approvers are USER1, USER2, and USER3, respectively, these three approvers, USER1, USER2, and USER3, are the three possible values for the loop variable USERS of the loop node. When the process orchestration engine executes up to the loop node, it generates three secondary threads under the thread to which the loop node belongs. The three secondary threads are then used to execute the loop body in parallel when the loop variable is USER1, USER2, or USER3, respectively.
[0085] If the parallel property of the loop node in Figure 4 is set to non-parallel execution, i.e., if the parallel option is not checked, the process orchestration engine will not generate a secondary thread for the thread to which the loop node belongs. Then, the thread to which the loop node belongs will sequentially execute the loop bodies when the loop variables are USER1, USER2, and USER3, respectively.
[0086] In the above example, the loop node was explained using the FOR node, but in structured programming, loops can be realized not only with the for statement, but also with, for example, the while statement. Therefore, in either implementation method, the loop node may contain a WHILE node, which can be analyzed in the same way as the FOR node.
[0087] As mentioned above, a flow instance may contain one or more threads, which may arise during the execution of a loop node whose parallel property is set to execute in parallel.
[0088] Next, we use a schematic diagram to describe the execution process of loop nodes with two types of parallel properties.
[0089] Please refer to FIG. 5, which is a schematic diagram of the execution process of a loop node whose parallel property is set to non-parallel execution in the embodiment of the present application.
[0090] The business process in Figure 5 includes nodes 1 to 3. Of these, node 2 is a loop node, and its parallel property is set to non-parallel execution. The loop variable i of node 2 takes the values 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 uses thread 1000 to which node 2 belongs to sequentially execute the loop bodies for i=1, i=2, and i=3 (loop bodies are not shown). It should be noted that in this case, since no thread is generated for node 2, thread 1000 to which node 2 belongs can be considered the flow instance itself. As can be easily understood, when the parallel property of a loop node is set to non-parallel execution, the execution of the loop node is the same as that of a non-loop node, and both are executed serially.
[0091] Please refer to FIG. 6, which is a schematic diagram of the execution process of a loop node whose parallel property is set to parallel execution in the embodiment of the present application.
[0092] The business process in Figure 6 includes nodes 1 to 4. Node 2 is a loop node, and its parallel property is set to "parallel execution." The loop body of node 2 includes node 3. The loop variable i of the loop node takes values of i=1, i=2, and i=3. That is, the total value of the loop variable 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 denoted as 1000, the three secondary threads can be named 1000-1, 1000-2, and 1000-3, respectively. 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. The execution method is to execute the corresponding loop bodies of the three secondary threads in parallel.
[0093] In the above implementation process, the nodes in the business process include loop nodes. The parallel property of a loop node can be set to parallel execution or non-parallel execution, and the parallel property of the loop node can be set as needed. If the parallel property of a loop node is set to parallel execution, multiple secondary threads are generated and the loop body is executed in parallel, improving the execution efficiency and performance of the loop node.
[0094] Optionally, in the embodiment of the present 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 results corresponding to each secondary thread. In specific implementation, corresponding rules may be set based on actual needs, and the execution results corresponding to each secondary thread may be mapped as the execution result of the loop node. For example, weighting or statistics may be performed on the execution results of each thread so that the execution logic of the loop node can better reflect actual business needs.
[0095] Please continue to refer to Figure 6 and Figure 4 together. Following the above example, if the approvers are USER1, USER2, and USER3, respectively, three secondary threads execute the loop bodies corresponding to USER1, USER2, and USER3, respectively, to 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 a preset condition. For example, the preset condition may be such that if the number of people approving the approval is greater than a preset threshold (e.g., two-thirds), the execution result of the loop node is deemed to be approval, but if the number of people approving the approval is equal to or less than the preset threshold, the execution result of the loop node is deemed to be rejection.
[0096] Optionally, in an embodiment of the present application, when the parallel property of the 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 until the pre-termination command of the loop, or (3) timeout of execution of any one secondary thread. Also, after the execution of the loop node is completed, the generated secondary thread is discarded, and the nodes in the business process continue to be executed using the thread to which the loop node belongs.
[0097] Regarding condition (1), for example, in the case of FIGS. 6 and 4, when all three secondary threads return the decision results corresponding to the authorizer, this means that the execution of the three secondary threads is completed.
[0098] Regarding condition (2), if any one secondary thread is executed up to a pre-termination instruction of the loop, such as a break instruction, the current loop is immediately terminated. These instructions may be associated with a specific node during orchestration.
[0099] Regarding condition (3), a timeout in the execution of any one secondary thread means that the execution time of any one secondary thread exceeds a predetermined time cycle. Condition (3) is primarily applied when an asynchronous node is included in the loop body (because external actions corresponding to asynchronous nodes are likely to cause a timeout), but it may also be applied to a loop body that contains only synchronous nodes. The predetermined time cycle may be set internally in the process orchestration engine, or 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, the secondary thread created under the thread to which the loop node belongs is discarded, the resources occupied by the secondary thread are released, and the nodes in the business process continue to be executed using the thread to which the loop node belongs. 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 currently executing thread becomes 1000 again, and node 4 continues 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 some special command, such as a termination command, 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 this implementation, the loop has multiple termination methods, allowing the loop node's execution logic to better reflect actual business needs. Furthermore, after the loop node completes execution, the generated secondary thread is quickly discarded, freeing up resources such as memory, CPU, and network connections occupied by the thread. Then, the thread containing the loop node continues to execute nodes in the business process, reducing system resource consumption during business process execution.
[0102] Optionally, in an embodiment of the present application, the rules for generating thread identifiers for nodes in a business process include the following: if the node is not a child node of a loop node whose parallel property is set to "parallel execution," the thread identifier of the node matches the flow instance identifier; on the other hand, if the node is a child node of a loop node whose parallel property is set to "parallel execution," the thread identifier of the node is generated based on the thread identifier of the loop node whose parallel property is set to "parallel execution" and is closest to the node among the parent nodes of the child node, and whose parallel property is set to "parallel execution," and the loop number corresponding to the node; the loop number corresponding to the node is a number within all values currently held by the loop variable corresponding to the thread to which the node belongs.
[0103] First, let us explain the definition of a child node. All nodes belonging to a node are called child nodes of that node, regardless of whether they belong directly to that node or not. For example, if the loop body of loop node A contains three nodes, all three nodes are child nodes of the loop node. Furthermore, assuming that one of these three nodes is also a loop node, it will be represented as loop node B. Furthermore, if loop node B contains four child nodes, these four child nodes can also be considered child nodes of loop node A, even though they do not belong directly to loop node A. Furthermore, corresponding to the above, any child node of loop node A can call loop node A its parent node.
[0104] Because only loop nodes with the parallel property set to "run in parallel" spawn new threads, if a node is not a child node of any loop node with the parallel property set to "run in parallel," the node remains in the main thread of the flow instance, and is not in any secondary thread that spawns during the execution of the flow instance. Therefore, the thread identifier of a node can be set to match the flow instance identifier.
[0105] Continuing with reference to Figure 6, since nodes 1, 2, and 4 are not child nodes of the loop node whose parallel property is set to parallel execution, their thread identifiers are all 1000, the same as the identifier of the flow instance.
[0106] When the parallel property of a loop node is set to parallel execution, the thread identifier of a child node directly belonging to the loop node can be generated based on the thread identifier of the loop node and the loop number corresponding to the child node. Furthermore, when any child node directly belonging to the loop node is also a loop node and the parallel property is also set to parallel execution, the thread identifier of the child node directly belonging to the child node can also be derived in a similar manner. On the other hand, when any child node directly belonging to the loop node is also a loop node but the parallel property is set to non-parallel execution, or when the child node is a non-loop node, the thread identifier of the child node directly belonging to the child node matches the thread identifier of the child node. Similarly, the thread identifier of each node in a business process can be obtained.
[0107] The above process can be summarized simply as follows: if a loop node with its parallel property set to parallel execution is encountered on the path from any top-level node to any of its descendant nodes, then a new thread identifier must be derived for that loop node's descendant nodes; otherwise, the current thread identifier will be maintained.
[0108] This allows a node to be traced back one layer at a time from the parent node to which the node directly belongs, upwards, if the node is a child node of one or more loop nodes whose parallel property is set to "parallel execution." Based on the definition of a child node described above, all nodes on the traceback path can be referred to as the parent node of the node. Among these parent nodes, the loop node closest to the node and whose parallel property is set to "parallel execution" is the loop node used to derive the thread identifier for the node.
[0109] Continuing with reference to FIG. 6, node 2 is a loop node, and the concurrency property of this loop node is set to parallel execution. Node 3 is a child node in the loop body of node 2. Next, the thread identifier generation rule will be explained using node 3 of the first thread (the leftmost thread) as an example. Of the parent nodes of node 3 of the first thread, node 2 is the loop node closest to node 3 of the first thread. Node 2 is also a loop node whose concurrency property is set to parallel execution. Therefore, the thread identifier 1000 of node 2 is obtained. Next, the loop number of node 3 of the first thread is obtained. The loop number corresponding to node 3 of the first thread is the number within all values currently held by the loop variable corresponding to the thread to which this node belongs. For example, if the value currently held by the loop variable is 2 and the all values include 2, 4, and 6, the number within all values currently held by the loop variable can be set to 1.
[0110] After obtaining that the thread identifier of node 2 is 1000 and the loop number corresponding to node 3 of the first thread is 1, a 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 FIG. 6, the thread identifier is 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 calculating the thread identifier of node 2 and the loop number corresponding to node 3 of the first thread using a preset method.
[0111] Please refer to FIG. 7, which is a schematic diagram of the execution process of the nested loop node provided in the embodiment of the present application.
[0112] As mentioned above, the child nodes of a loop node refer to all nodes within the loop body corresponding to the loop node. In an alternative 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 node 3, node 4, and node 5. Node 3 is also a loop node, and the child nodes of node 3 include node 4. The parallel properties of both node 2 and node 3 are set to parallel execution.
[0113] Next, the thread identifier generation rules will be explained 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, it is determined that node 3 and node 2 of the first thread are included as parent nodes of node 4 of the first thread. Because node 4 of the first thread has multiple parent nodes, it is necessary to further determine from the parent nodes that the parent node closest 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, it is determined 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, it is possible to generate, for example, 1000-1-1 as the thread identifier of node 4 of the first thread. For details on how to obtain the thread identifier of node 3 of the first thread, please refer to the detailed description above regarding Figure 6. When actually executing a business process, the thread identifier of a node can only be identified when the process has executed up to that node. Furthermore, when the first thread has been executed up to node 4, node 3 of the first thread has clearly been executed, so at this point the thread identifier of node 3 of the first thread is already known.
[0114] In the above implementation process, thread identifiers corresponding to nodes are generated based on rules. Such thread identifiers not only identify the thread in which a node exists, but also represent the father-child relationship between nodes, making them convenient for managing nodes within a process. For example, in Figure 6, by combining the thread identifier generation rules, it can be seen that node 3 is a child node of node 2 and belongs to the first thread generated in node 2 from the thread identifier 1000-1 of node 3 and the thread identifier 1000 of node 2.
[0115] In a business process, each node typically has input and output, and the output of a node generally becomes the execution result of the node. In a business process, a node that is later in the execution order can reference the execution result of a node that is earlier in the execution order as its input. Below, we will explain how to analyze the reference to the execution result of a node, using a first node and a second node as examples. Let us assume that a business process contains a first node and a second node, and that the execution order of the first node is before that of the second node. Needless to say, the first node and the second node are broad and general terms, and do not represent two specific nodes.
[0116] Optionally, in the embodiment of the present application, each time the execution of a node is completed, the node identifier, flow instance identifier, thread identifier, and execution result of the node are associated with each other and stored after the execution of the node is completed, for example, in a database so that they can be retrieved and used later.
[0117] If the parameters set for the second node include a reference to the execution result of the first node, the step of acquiring the execution result of the first node includes the following: Acquire the node identifier and flow instance identifier of the first node. Next, in reverse order of the execution order of the business process, starting from the second node, search for nodes whose execution order of the business process precedes the second node. During the search process, based on the thread identifier generation rule and the thread identifier of the second node, identify the thread identifier of each node to be searched for until the node identifier of the node to be searched for matches the node identifier of the first node, and identify the thread identifier of the first node as the thread identifier of the node to be searched for. Then, acquire the execution result of the first node 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 has been executed, the execution result has already been saved).
[0118] The parameters set in the second node are visualized as inputs to the second node. When a parameter contains a reference to the execution result of the first node, this means that the execution result of the first node (in whole or in part) is used as the value of the parameter set in the second node. For example, the task corresponding to the first node is to obtain a user's email address, and the execution result is the obtained user's email address. Furthermore, the task corresponding to the second node is to send an email to the user. Therefore, when setting the parameters of 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 analyzes the reference to obtain the execution result of the first node, and then assigns the execution result of the first node to the second node, thereby completing the task of sending an email to the user corresponding to the second node.
[0119] Please refer to the schematic diagram of referencing the execution results of a node provided in the embodiment of the present application shown in Figure 8. As shown in Figure 8, the method of referencing the execution results of the first node mentioned above includes referencing based on the node identifier of the first node and a preset reference symbol. In the $1.email address on the right side of Figure 8, "$" is the 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 a specific data item of the execution result (other data items are not excluded).
[0120] Next, the step of acquiring the execution result of the first node will be described.
[0121] First, obtain the node identifier and flow instance identifier of the first node whose execution results need to be referenced. If the first node and second node exist in the same flow instance, the flow instance identifier of the first node and the flow instance identifier of the second node 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 in the parameters of the second node.
[0122] Next, in reverse order of the execution order of the business process, starting from the second node, a search is performed for nodes that precede the second node in the execution order of the business process. The purpose of the search is to identify the thread identifier of the first node based on the thread identifier generation rule and the thread identifier of the second node. This search process can be understood by combining it with the example described below. Next, based on the node identifier, flow instance identifier, and thread identifier of the first node, the execution result of the first node that has been previously associated and stored is read.
[0123] For example, as shown in Figure 7, if node 4 is the second node and node 2 is the first node, then the execution result of node 2 needs to be referenced to set the parameters of node 4. There are a total of nine nodes 4 in Figure 7, but for simplicity, only the leftmost node 4 is illustrated. The node identifier of node 4 is 4, the thread identifier is 1000-1-1, and the flow instance identifier is 1000. The node identifier of node 2 is 2, and 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, it is not yet known where node 2 is in the business process.
[0124] When sequentially searching for nodes that precede node 4 in the execution order within the business process, first, by searching for node 3, the leftmost node, it is possible 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, it is possible to derive the thread identifier 1000-1 of node 3 in the reverse direction using the thread identifier 1000-1-1 of node 4. It is also found that the node identifier of node 3 is 3, but since the node identifier to reference is 2, node 3 is not the first node to reference.
[0125] 7, there are three nodes 3, but the leftmost node 4 can only search the leftmost node 3, and cannot search the two rightmost nodes 3. In other words, even when the leftmost node 4 refers to the execution result of a node 3, it only refers to the execution result of the leftmost node 3.
[0126] By continuing the search in reverse order of the business process execution, when the node to be searched 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 the reverse direction using the thread identifier 1000-1 of node 3 (or using the thread identifier 1000-1-1 of node 4). It is also found that the node identifier of node 2 is 2. Then, since the node identifier to be referenced is also 2, node 2 is determined to be the first node to be referenced. As a result, it is possible to identify the thread identifier of the first node as 1000 as the thread identifier of the node to be searched.
[0127] After the above steps have determined that the thread identifier of the first node is 1000, the node identifier is 2, and the flow instance identifier is 1000, the execution result of the first node stored in association with the node identifier, flow instance identifier, and thread identifier of the first node is obtained, and the second node is executed.
[0128] As can be seen, after searching until the node identifier of the node being searched for matches the node identifier of the first node, it is not necessary to continue searching for nodes in reverse order, and the search may be stopped.
[0129] In an optional embodiment, a variable may be further defined to store the execution result of the first node. The scope of the variable may be the entire process, or the variable storing the execution result of the first node may be accessible at a second node that is a node subsequent to the first node in the execution order. Continuing with reference to FIG. 8, a variable setting node may be inserted between the first and second nodes, and the variable may be created by executing the 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 of the second node, you may include a variable reference. For example, you may directly enter the name of the variable (or other reference syntax). The process orchestration engine can obtain the variable value by analyzing the variable reference. This achieves the same effect as directly referencing the execution result of the first node. Continuing with Figure 8, for example, for the second node, you may enter #email address in the recipient field. The "#" is a reference symbol, and the part after it indicates the name of the variable. This allows the process orchestration engine to search for a predefined variable based on the variable name "email address." The obtained variable value is then used as the value of the recipient parameter of the second node, and the email sending task corresponding to the second node is executed based on this value.
[0131] In the above implementation process, the execution result of a preceding node (e.g., the first node) can be obtained using the node identifier and flow instance identifier of the preceding node and the generation rule of the thread identifier. This allows a subsequent node (e.g., the second node) in the business process to refer to the execution result of the preceding node as input during its execution process, thereby increasing the number of input types for the node and enabling the node's execution logic to better reflect actual business needs.
[0132] Alternatively, in addition to referencing the execution result of the preceding node, the child node of the loop node can also refer to the loop variable. The reference method can be referred to in the above-mentioned execution result or variable reference, so it will not be described in detail again.
[0133] Optionally, in an embodiment of the present application, if the external operation corresponding to the asynchronous node is an operation in which a user submits data on a 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; then notifying the user who executes the external operation corresponding to the asynchronous node of the address of the target page in a predetermined 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 retrieving the data submitted by the user, the process orchestration engine may continue to execute the nodes following the asynchronous node (if any) in the business process, or, if the asynchronous node has a timeout mechanism configured, the process orchestration engine may force the execution of the subsequent nodes after the asynchronous node execution times out.
[0135] Next, the steps of executing an asynchronous node will be described in detail. 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 completely 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 address of the target page by concatenating the node identifier, flow instance identifier, and thread identifier of the asynchronous node according to a preset rule. It should be noted that in addition to the node identifier, flow instance identifier, and thread identifier of the asynchronous node, the address of the target page may include other information, such as the protocol used to access the web page, the IP address, and the page storage path. The address of the target page is a unique identifier for identifying and locating the web page, such as the URL (Uniform Resource Locator) of the target page.
[0137] Next, the process orchestration engine notifies the user who executes the external action corresponding to the asynchronous node of the address of the target page using a preset method. For example, the external action corresponding to the asynchronous node is when User A fills in the information fields on a personal information entry page and submits the filled-in personal information. Note that the personal information entry page in this case is the target page. In this case, after obtaining the address of the target page, the engine can obtain User A's information and notify User A of the address of the target page by sending the information to User A or by attaching User A's to-do items, etc.
[0138] After receiving the address of the target page on his / her terminal device, User A clicks on the address of the target page to open the target page, enters personal information on the target page, and then submits the data on the target page. This data is submitted to the process orchestration engine. The data content includes business data, the node identifier of the asynchronous node, the flow instance identifier, and the thread identifier. The business data is the personal information that User A enters on the target page. The node identifier, the flow instance identifier, and the 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. As can be understood, depending on the business scenario, the business data may be other data, such as the approval result and approval opinion submitted by the user after approving the content on the target page.
[0139] In the above implementation, the node identifier, flow instance identifier, and thread identifier of the asynchronous node are concatenated to generate the address of the target page, and the address of the target page is notified to the user. This allows the user to submit the node identifier, flow instance identifier, and thread identifier of the asynchronous node together when submitting data on the target page. These identifiers allow the thread of the flow instance to which the asynchronous node belongs to be located, allowing subsequent nodes of the asynchronous node to continue execution. In other words, the above implementation realizes support for asynchronous nodes at the execution level (asynchronous nodes are supported at the interface level through the node selection operation), thereby effectively enhancing the compatibility and availability of the process orchestration engine.
[0140] Optionally, in an embodiment of the present application, a node pointer is provided for each thread in each flow instance. The node pointer indicates the node currently being executed in the thread. After receiving data submitted by a user on the target page, the method further includes: obtaining the node identifier, flow instance identifier, and thread identifier of the asynchronous node from the data submitted by the user, and identifying the target node pointer based on the flow instance identifier and thread identifier. The target node pointer is a 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, continue executing the nodes following the asynchronous node in the business process.
[0141] The process orchestration engine sets one node pointer for each thread in a flow instance (a flow instance itself is considered a thread). The node pointer indicates the node currently being executed in the thread. Each time a node finishes executing, the value of the node pointer is updated accordingly to indicate the next node in the thread. Following this, the process orchestration engine also executes the next node. On the other hand, when a thread is destroyed, the corresponding node pointer may also be released.
[0142] In the execution step of the asynchronous node, after a user submits data on a target page, the process orchestration engine can identify a target node pointer based on the flow instance identifier and thread identifier in the data submitted by the user. The target node pointer is a 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 in the thread to which it belongs.
[0143] If the node identifier of an asynchronous node matches the node identifier of the node indicated by the target node pointer, it means that the thread to which the target node pointer belongs had previously executed up to the position of the asynchronous node, and then the process execution was suspended and is waiting for data submission from the user. The data submitted by the user corresponds to the external operation for which the asynchronous node is waiting. This allows the process orchestration engine to continue executing nodes after the asynchronous node in the business process. On the other hand, if the node identifier of the asynchronous node does not match the node identifier of the node indicated by the target node pointer, an exception can be thrown.
[0144] In the above implementation, the node pointer indicates the node currently being executed in the thread. The target node pointer is identified using the flow instance identifier and thread identifier in the data submitted by the user, and the node identifier is compared to determine whether to continue execution. This is convenient for controlling and managing the movement of execution logic between nodes within the flow instance, ensuring the accuracy and reliability of process execution.
[0145] Alternatively, 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 user-submitted data, and may locate the current asynchronous node in the thread based on the node identifier in the user-submitted data, and then continue executing downward, i.e., without validating the node pointer and thus without implementing the node pointer.
[0146] Optionally, in the present embodiment, the target page includes a form page or an approval page. If the target page corresponding to any asynchronous node is a form page, it may be referred to as a form node. Also, if the target page corresponding to any asynchronous node is an approval page, it may be referred to as an approval node.
[0147] A target page is a page on which a user submits data. A form page may be a page for collecting user input data, which can form a user form. The form page may contain input widgets corresponding to each field in the form, such as text boxes, pull-down lists, check boxes, and radio buttons, and may be used to accept user input. A user can enter form data on the form page and submit the form data, along with each identifier of the 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 requests 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 opinions. A user can enter their approval opinion and decision results in the approval page and submit them, along with the identifiers of the approval nodes in the approval page address, to the process orchestration engine. Optionally, some approval pages allow users to enter data other than the approval opinion and decision results. Approval pages can also be considered a special case of form pages.
[0149] In the above implementation process, the target pages corresponding to asynchronous nodes include form pages and approval pages. Different target page formats can be used to implement different tasks, which is advantageous for improving the availability of the process orchestration engine and is particularly applicable to enterprise scenarios, where form filling and approval are common tasks.
[0150] For example, in an embodiment of the present application, by combining loop nodes within a business process, a complex and flexible approval process can be realized. For example, if a loop node includes an approval node and the parallel property of the loop node is set to non-parallel execution, a serial approval process can be realized. Also, 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, a more complex approval process can be realized.
[0151] In the embodiments of the present application, an entity can be said to define data, for example, which fields are included in a data table. A form is one representation format of an entity. For example, different users can see different fields in a data table. In this way, different forms can be created based on the same entity. A form instance is a form that contains actual data, and different form instances can be distinguished by a form instance identifier. A form instance identifier can be displayed as an Entity Data ID.
[0152] Alternatively, in an embodiment of the present 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 is as described above. After receiving the form data submitted by the user, the process orchestration engine can assign a form instance identifier. Of course, this does not exclude the case where the user specifies the form instance identifier (in the node parameters). If the user specifies the form instance identifier, the form instance identifier may be submitted to the process orchestration engine together with the form data.
[0153] If the target page is the form page of the 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: obtaining a 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 form data of the edited form, and the form data is used to render the target page. Furthermore, the data submitted by the user on the target page includes the updated form data, the node identifier, flow instance identifier, thread identifier, and form instance identifier of the asynchronous node.
[0154] The following situations may occur when the target page is the form page of an edited form. 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 is used as the data in the form page of the edited form. The second situation is when the edited form is a previously stored form. For example, when multiple people need to approve a single approval form, or when multiple people need to fill out a single data form, and subsequent approvals or entries are based on the previous data. After each person approves or fills out the form, the updated data is saved, and the edited form becomes the form to be presented on the target page of the next user.
[0155] If the target page is the form page of the edited form, when generating the address of the target page, it is necessary to further 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 will be described in detail below. That is, 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 submitted for the first time. The form instance identifier may be custom-generated by a user, or may be automatically generated by a process orchestration engine after obtaining the data submitted by the user for the target page. Thereafter, when processing the edited form, the form instance identifier generated after the form is submitted for the first time can be used as is.
[0156] The form instance identifier can be used to retrieve the form data of the edited form, and the form data is used to render the target page and inform the user of the contents of the edited form. Taking the edited form in the first situation as an example, the user needs to modify the submitted form data. After the user submits the data for the first time, a form instance identifier for the form is generated. After notifying the user of the form page address of the edited form, when the user clicks on the address, the process orchestration engine can retrieve the form data that the user originally submitted from the form instance identifier linked to the address. This makes it possible to render the form page of the edited form based on the form data and return the page to the user. The user can then modify the form data based on this.
[0157] Corresponding to the above, 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. For details, please refer to the above content, and detailed descriptions will not be repeated. 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 above process, if the target page is the form page of an edited form, the form instance identifier can be linked to the address of the target page, and the 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, realizing the reuse of form data.
[0159] Optionally, in the embodiment of the present application, after generating the address of the target page, the process orchestration engine needs to notify the address of the target page to the user, so that the user can go to the target page based on the address of the target page and perform a corresponding external operation. Pre-defined ways of notifying the user include:
[0160] First method: Obtain user information of the user who executes 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] Second method: Obtain the user's ToDo list. Also, generate a target ToDo item based on the address of the target page. The target ToDo item is used to instruct the user to proceed to the target page. The target ToDo item is added to the user's ToDo list.
[0162] The third method: Obtain the user's data list. Also, generate an interaction button based on the address of the target page. The interaction button is used to instruct the user to proceed to the target page. The interaction button is added to the user's data list.
[0163] In the first method, information is sent to a user. The information includes the address of a target page. Specifically, for example, user information of the user is acquired. The user is a user who executes an external operation corresponding to an asynchronous node. The 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 acquiring the user information, notification information including the address of the target page is sent to the user.
[0164] In a second method, a user's to-do items are generated based on the address of a target page. For example, a user's to-do list is obtained. The to-do list may be the user's to-do list in a task management system, the user's to-do list in a personal workflow, or the like. For example, the to-do list may include one or more to-do items. Each to-do item may also be a text description of the to-do item. The text description may also include a page address for completing the to-do item.
[0165] The process orchestration engine can generate a target ToDo item based on the address of the target page. The text description of the target ToDo item can be configured 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 searched for in a 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 click on the page address corresponding to the target ToDo item to proceed to the target page and complete an external action, such as filling out a form or approving data, corresponding to the asynchronous node.
[0167] In the third method, a button for proceeding to a target page is added to the user's data list. For example, the user's data list is obtained. The data list can be located in the user's system. The user can view the data list by proceeding to a specific page in the system. An interaction button is added to the user's data list. The interaction button is used to instruct the user to proceed to the target page. The interaction button is associated with the address of the target page. In addition, code is written to create a response event for the interaction button so that the corresponding target page opens when the user clicks the interaction button.
[0168] FIG. 9 is a schematic diagram of a data table including an interaction button provided in an embodiment of the present application. FIG. 9 shows a data list that an authorizer can view. 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. The button is associated with an approval page. Therefore, by clicking the button, the authorizer can access the page and execute an external action corresponding to the approval node.
[0169] The above implementation process provides various and flexible notification methods for users, allowing them to select the appropriate method based on the specific application scenario and page requirements of the target page. By doing so, the user can obtain the address of the target page, go to the target page, and complete the external operation corresponding to the asynchronous node.
[0170] Optionally, in an embodiment of the present application, if the external operation corresponding to the asynchronous node is a callback operation of the target function by a third party, the step of executing the asynchronous node in step S120 includes: 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; calling an interface provided by the third party to send the function identifier to the third party; and 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 in response to the third party calling the target function using the function identifier.
[0171] The external action corresponding to the asynchronous node may be a callback action of a target function by a third party. The callback function is a function that is called when a specific event occurs. For example, the target function may be a WebHook type function. Of course, the target function may also be any other type of function defined by the process orchestration engine.
[0172] The steps for executing an asynchronous node will be described below using a WebHook function as an example. A WebHook includes 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 associates the node identifier, flow instance identifier, and thread identifier of the asynchronous node with the function identifier of the target function corresponding to the asynchronous node and stores them in a database, for example.
[0173] Next, the process orchestration engine obtains the interface provided by the third party. The interface may be an interface with specific functionality, such as a message push interface. The third party may be software that requires a WebHook function call. Based on the interface description or requirements provided by the third party, the process orchestration engine invokes the interface. The invoked parameters 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 invocation of the WebHook using the WebHook ID, the process orchestration engine searches for the node identifier, flow instance identifier, and thread identifier of the asynchronous node that are stored in association with the WebHook ID, based on the WebHook ID of the invoked WebHook function.
[0175] In the above process, the process orchestration engine only needs to send the WebHook ID to the third party, and does not need to send the node identifier, flow instance identifier, and thread identifier, which makes the execution of the asynchronous node more efficient and simple.
[0176] After retrieving the searched data, the process orchestration engine may continue to execute the nodes following the asynchronous node (if any) in the business process. Alternatively, if a timeout mechanism is configured for the asynchronous node, the process orchestration engine may force the execution of the subsequent nodes after the execution of the asynchronous node times out.
[0177] In the above implementation process, 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 stored in association with the function identifier are identified based on the function identifier of the called target function. These identifiers are then used to locate the thread of the flow instance to which the asynchronous node belongs, thereby enabling subsequent nodes of the asynchronous node to be executed. In other words, the above implementation process realizes support for asynchronous nodes at the execution level (support for asynchronous nodes at the interface level is realized by the node selection operation).
[0178] In addition, it can be seen that the asynchronous node in the embodiment of the present application can support external actions in many application scenarios (for example, actions such as form filling and approval performed by a person, and function callback actions performed by a device), which can better meet the diversified orchestration needs of actual business processes, and effectively enhance the compatibility and availability of the process orchestration engine.
[0179] Optionally, in an embodiment of the present application, a node pointer is provided for each thread in each flow instance. The node pointer indicates the node currently executing in 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: identifying a target node pointer based on the flow instance identifier and thread identifier of the asynchronous node. The target node pointer is a 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 nodes following the asynchronous node in the business process are executed.
[0180] The node pointer has already been described in detail above, so it will not be described again in detail. After the process orchestration engine identifies the node identifier, flow instance identifier, and thread identifier of the asynchronous node stored in association with the function identifier, it can identify the target node pointer based on the flow instance identifier and thread identifier of the asynchronous node. The target node pointer is a 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 node identifier of the asynchronous node found based on the function identifier is compared with the node identifier of the node indicated by the target node pointer to determine whether they match. If the node identifier of the asynchronous node matches the node identifier of the node indicated by the target node pointer, this means that the thread to which the target node pointer belongs had previously executed up to the position of the asynchronous node, and then the process execution was suspended and is waiting for a callback of the target function by a third party. However, because the target function corresponding to the asynchronous node was called by the third party, the external operation for which the asynchronous node was waiting has completed. This allows the process orchestration engine to continue executing nodes after the asynchronous node in the business process. On the other hand, if the node identifier of the asynchronous node does not match the node identifier of the node indicated by the target node pointer, an exception can be thrown.
[0182] In the above implementation process, whether to continue executing the nodes following the asynchronous node is determined by comparing whether the node identifier of the asynchronous node matches the node identifier of the node pointed to by the target node pointer. This is convenient for controlling and managing the movement of execution logic between nodes within a flow instance, and ensures the accuracy and reliability of process execution.
[0183] Alternatively, 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 may locate the asynchronous node at that point in time within the thread based on the node identifier retrieved using the function identifier, and then continue executing downward, i.e., it may not be necessary to verify the node pointer, and therefore it may not be necessary to implement the node pointer.
[0184] Please 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, which includes the following modules:
[0185] The orchestration module 210 is used to generate a business process requiring orchestration in response to a node selection operation and a node parameter setting operation based on the interface. Nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes. A synchronous node represents a task that can be executed without waiting for an external operation, while an asynchronous node represents a task that cannot be executed without waiting for an external operation.
[0186] Execution module 220: Used to execute the nodes in the business process in order according to the order of the nodes in the business process.
[0187] Optionally, in an embodiment of the present application, in the process orchestration device, 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 in a business process. Furthermore, one flow instance is generated each time a business process is executed. The flow instance identifier is used to identify the flow instance to which the node belongs. A flow instance includes one or more threads. The thread identifier is used to identify the thread to which the node belongs. A thread is a parallel execution branch within a flow instance.
[0188] Optionally, in an embodiment of the present application, in the process orchestration apparatus, if the external operation corresponding to the 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 generates the address of the target page by concatenating the node identifier, flow instance identifier, and thread identifier of the asynchronous node. Then, the address of the target page is notified to the user executing the external operation corresponding to the asynchronous node in a predetermined manner, and the data submitted by the user on the target page is received. The data includes business data, the node identifier, flow instance identifier, and thread identifier of the asynchronous node.
[0189] Optionally, in an embodiment of the present application, the process orchestration device is provided with a node pointer for each thread in the flow instance. The node pointer indicates a node currently being executed in the thread. The process orchestration device further includes a first pointer determination module for acquiring a node identifier of the asynchronous node, a flow instance identifier, and a thread identifier from data submitted by a user, and for identifying a target node pointer based on the flow instance identifier and the thread identifier. The target node pointer is a 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 nodes following the asynchronous node in the business process.
[0190] Optionally, in the embodiment of the present application, in the process orchestration apparatus, the target page includes a form page or an approval page.
[0191] Optionally, in the process orchestration apparatus of the present embodiment, if the target page is a form page of an edited form, the execution module further obtains a form instance identifier corresponding to the edited form, and generates an 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 search for 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] Optionally, in the embodiment of the present application, the process orchestration apparatus may include the following preset ways of notifying a user who executes an external operation corresponding to an asynchronous node:
[0193] First method: Obtain user information of the user who executes 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] Second method: Obtain the user's ToDo list. Also, generate a target ToDo item based on the address of the target page. The target ToDo item is used to instruct the user to proceed to the target page. The target ToDo item is added to the user's ToDo list.
[0195] The third method: Obtain the user's data list. Also, generate an interaction button based on the address of the target page. The interaction button is used to instruct the user to proceed to the target page. The interaction button is added to the user's data list.
[0196] Optionally, in an embodiment of the present application, in the process orchestration apparatus, if the external operation corresponding to the asynchronous node is a callback operation of the 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, the execution module 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 of the target function using the function identifier, the execution module identifies 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.
[0197] Optionally, in an embodiment of the present application, the process orchestration device is provided with a node pointer for each thread in the flow instance. The node pointer indicates the node currently being executed in the thread. The second pointer determination module is used to identify a target node pointer based on the flow instance identifier and thread identifier of the asynchronous node. The target node pointer is a 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 nodes following the asynchronous node in the business process are executed.
[0198] Optionally, in an embodiment of the present application, the process orchestration apparatus includes a loop node among the nodes. A loop node is a node that requires repeated execution of a child node in a loop body until a loop termination condition is satisfied. The loop node's parameters include a parallel property. If the parallel property of the loop node is set to parallel execution when the execution reaches the loop node, the execution module further generates, under the thread to which the loop node belongs, secondary threads in the number equal to the total number of values taken by the loop variable of the loop node, and uses the secondary threads to execute the loop body in parallel when the loop variable takes each value. On the other hand, if the parallel property of the loop node is set to non-parallel execution when the execution reaches the loop node, the execution module uses the thread to which the loop node belongs to repeatedly execute the loop body according to changes in the loop variable.
[0199] Optionally, in the embodiment of the present application, in the process orchestration apparatus, 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.
[0200] Optionally, in an embodiment of the present application, the process orchestration apparatus further includes a thread abandonment module. When the parallel property of the loop node is set to parallel execution, the module includes, as loop termination conditions, that each secondary thread completes execution, that any one secondary thread executes until a pre-termination command of the loop, or that any one secondary thread times out. After the loop node completes execution, the module abandons the generated secondary thread and continues to execute nodes in the business process using the thread to which the loop node belongs.
[0201] Optionally, in an embodiment of the present application, the process orchestration apparatus includes the following as a rule for generating a thread identifier for a node: if the node is not a child node of a loop node whose parallel property is set to parallel execution, the thread identifier of the node matches the flow instance identifier; on the other hand, if the node is a child node of a loop node whose parallel property is set to parallel execution, the thread identifier of the node is generated based on the thread identifier of the loop node whose parallel property is set to parallel execution and is closest to the node among the parent nodes of the child node, and whose parallel property is set to parallel execution, and the loop number corresponding to the node; the loop number corresponding to the node is a number within all values currently held by the loop variable corresponding to the thread to which the node belongs.
[0202] Optionally, in an embodiment of the present application, the business process includes a first node and a second node. Of these, the first node is executed before the second node. The node identifier, flow instance identifier, thread identifier, and execution result of the node are associated and stored after the execution of the node 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. The module acquires the node identifier and flow instance identifier of the first node. Next, in reverse order of the execution order of the business process, starting from the second node, a node whose execution order of the business process precedes the second node is searched for. During the search process, the thread identifier of each search target node is identified based on the thread identifier generation rule and the thread identifier of the second node 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 acquired.
[0203] It should be understood that the apparatus corresponds to the embodiment of the process orchestration method described above and is capable of executing each step mentioned in the embodiment of the method. For specific functions of the apparatus, reference can be made to the above description, and detailed description will be omitted here to avoid duplication. The apparatus includes at least one software function module that can be stored in memory in the form of software or firmware, or that can be fixed to the operating system (OS) of the apparatus.
[0204] Please refer to the schematic structural 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 executable by the processor 310. When the machine-readable instructions are executed by the processor 310, the above-mentioned method is performed.
[0205] An embodiment of the present application further provides a storage medium having a computer program stored therein, the computer program executing the above method when run by a processor.
[0206] The storage medium can be any type of volatile or non-volatile storage device, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage device, flash memory, magnetic disk, or optical disk, or a combination thereof.
[0207] In some embodiments provided herein, it should be understood that the disclosed apparatus and method may be implemented in other manners. The apparatus embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation that may be implemented by apparatuses, methods, and computer program products according to some embodiments of the present application. In this regard, each block in a flowchart or block diagram may represent a module, program segment, or part of code. Furthermore, a module, program segment, or part of code includes one or more executable instructions for implementing a given logical function. It should be noted that in some alternative implementations, the functions depicted in the blocks may occur in a different order from that depicted in the figures. For example, two consecutive blocks may actually be executed substantially in parallel, or may even be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, 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 present application may be integrated together to form a single independent part, each module may exist separately, or two or more modules may be integrated to form a single independent part.
[0209] The above description is merely a selection of embodiments of the present application, and the scope of protection of the present application is not limited thereto. Any modifications or replacements that a person skilled in the art can easily think of within the technical scope disclosed in the present application shall be included in the scope of protection of the present application.
Claims
1. 1. A process orchestration method comprising: A business process requiring orchestration is generated in response to a node selection operation and a node parameter setting operation based on the interface, and nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes, the synchronous nodes representing tasks that can be executed without waiting for an external operation, and the asynchronous nodes representing tasks that cannot be executed without waiting for an external operation; Sequentially executing the nodes in the business process according to the order of the nodes in the business process; A method comprising:
2. The properties of the node include a node identifier, a flow instance identifier, and a thread identifier; the node identifiers are used to identify different nodes within the business process; One flow instance is generated each time the business process is executed, and the flow instance identifier is used to identify the flow instance to which the node belongs; 2. The method of claim 1, wherein the flow instance includes one or more threads, the thread identifier is used to identify the thread to which the node belongs, the thread being a concurrently executing branch within the flow instance.
3. When the external operation corresponding to the asynchronous node is an operation of a user submitting data on a target page, the step of executing the asynchronous node includes: obtaining a node identifier, a flow instance identifier, and a thread identifier of the asynchronous node; generating an address of the target page by concatenating the node identifier, the flow instance identifier, and the thread identifier of the asynchronous node; notifying a user who executes an external operation corresponding to the asynchronous node of the address of the target page in a preset manner; receiving data submitted by the user on the target page, the data including business data, a node identifier of the asynchronous node, a flow instance identifier, and a thread identifier; 3. The method of claim 2, comprising:
4. a node pointer is provided for each thread in the flow instance, the node pointer indicating a currently executing node in the thread; and after receiving the user-submitted data on the target page, the method further comprises: obtaining a node identifier, a flow instance identifier, and a thread identifier of the asynchronous node from the user-submitted data; Identifying a target node pointer based on the flow instance identifier and the thread identifier, wherein the target node pointer is a 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, continue to execute the asynchronous node and subsequent nodes in the business process.
4. The method of claim 3, comprising:
5. The method of claim 3 , wherein the target page includes a form page or an approval page.
6. When the target page is a form page of an edited form, generating an address of the target page by concatenating the node identifier, flow instance identifier, and thread identifier of the asynchronous node, obtaining a form instance identifier corresponding to the edited form; generating an 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 being used to retrieve form data of the edited form, and the form data being used to render the target page; Including, 6. The method of claim 5, wherein the data submitted by the user on the target page includes updated form data, a node identifier of the asynchronous node, a flow instance identifier, a thread identifier, and the form instance identifier.
7. The predetermined manner of notifying a user who performs an external operation corresponding to the asynchronous node is: First method: obtain user information of a user who executes an external operation corresponding to the asynchronous node, and send notification information to the user based on the user information, where the notification information includes an 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, and 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, and 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; 4. The method of claim 3, comprising:
8. When 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 includes: 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; calling an interface provided by the third party to send the function identifier to the third party; In response to a call by the third party of the target function using the function identifier, based on the function identifier of the called target function, identifying the node identifier, flow instance identifier, and thread identifier of the asynchronous node that are stored in association with the function identifier; 3. The method of claim 2, comprising:
9. a node pointer is provided for each thread in the flow instance, the node pointer indicating a node currently being executed in the thread; and 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 comprises: Identifying a target node pointer based on the flow instance identifier and the thread identifier of the asynchronous node, wherein the target node pointer is a 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, continue to execute the asynchronous node and subsequent nodes in the business process.
9. The method of claim 8, comprising:
10. The nodes include a loop node, which is a node that requires repeated execution of a child node in a loop body until a loop termination condition is satisfied, and a parameter of the loop node includes a parallel property; When the execution reaches the loop node, if the parallel property of the loop node is set to parallel execution, generate secondary threads under the thread to which the loop node belongs, the number of which is equal to the total number of values that the loop variable of the loop node takes, and use the secondary threads to execute the loop body in parallel when the loop variable takes each value; 3. The method according to claim 2, wherein, when execution reaches the loop node, if the parallel property of the loop node is set to non-parallel execution, the loop body is repeatedly executed according to changes in the loop variable using the thread to which the loop node belongs.
11. The method of claim 10 , wherein 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 results corresponding to each secondary thread.
12. If the parallel property of the loop node is set to parallel execution, the loop termination conditions include: each secondary thread completing execution; any one of the secondary threads executing to a loop pre-termination instruction; or any one of the secondary threads timing out; 11. The method according to claim 10, wherein after execution of the loop node is completed, the generated secondary thread is discarded, and the thread to which the loop node belongs is used to continue executing nodes in the business process.
13. The rule for generating thread identifiers for the nodes includes: If the node is not a child node of a loop node with the parallel property set to parallel execution, the thread identifier of the node matches the flow instance identifier; If the node is a child node of a loop node whose parallel property is set to "parallel 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 parallel property is set to "parallel execution," and the loop number corresponding to the node, and the loop number corresponding to the node is a number within all values currently taken by the loop variable corresponding to the thread to which the node belongs; 11. The method of claim 10, comprising:
14. the business process includes a first node and a second node, the first node is executed before the second node, and the node identifier, flow instance identifier, thread identifier, and execution result of the node are stored in association with each other after the execution of the node is completed; When the parameter set in the second node includes a reference to the execution result of the first node, the step of acquiring the execution result of the first node includes: obtaining a node identifier and a flow instance identifier of the first node; searching for a node that precedes the second node in the execution order of the business process in reverse order of the execution order of the business process, starting from the second node, and during the search process, identifying thread identifiers of each search target node based on a thread identifier generation rule and the thread identifier of the second node until the node identifier of the search target node becomes the node identifier of the first node, and identifying the thread identifier of the first node as the thread identifier of the search target node; acquiring the execution result of the first node stored in association with the node identifier, flow instance identifier, and thread identifier of the first node; 14. The method of claim 13, comprising:
15. A process orchestration device, comprising: an orchestration module that generates a business process requiring orchestration in response to a node selection operation and a node parameter setting operation based on an interface, wherein nodes supported for selection in the node selection operation include synchronous nodes and asynchronous nodes, the synchronous nodes representing tasks that can be executed without waiting for an external operation, and the asynchronous nodes representing tasks that cannot be executed without waiting for an external operation; an execution module that executes the nodes in the business process in order according to the order of the nodes in the business process.
16. An electronic device comprising a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and wherein the method according to any one of claims 1 to 14 is performed when the machine-readable instructions are executed by the processor.
17. A computer-readable storage medium having stored thereon a computer program, the computer program causing a processor to execute the method according to any one of claims 1 to 14 when the computer program is run by the processor.
Citation Information
Patent Citations
Extensible flamework for designing work flow
JP2006107478A
Restarting a Robotic Process Automation Workflow Based on an External Trigger
JP2022550224A