Workflow processing method and device and electronic equipment

Abstract

The invention discloses a workflow processing method and device and electronic equipment. Relates to the technical field of computer application, and the method comprises the steps that a workflow instance created based on a workflow template is obtained, target fields in at least part of process nodes in the workflow template comprise first-class fields, the first-class fields are fields used for representing actions to be executed, and the first-class fields are used for representing the actions to be executed; at least part of the actions to be executed depend on linkage execution of an external system; determining a triggered target field in a target process node in the workflow instance; under the condition that the triggered target field is a first type of field, executing a to-be-executed action described by the target field, and determining field information associated with the target field based on execution information; and determining a node flow direction based on the field information associated with the target field. According to the method and the device, the technical problems that the function of the workflow template is single and functional requirements during workflow processing cannot be met in the prior art are solved.

Description

Technical Field

[0001] The present invention relates to the field of computer application technologies, and in particular, to a method, apparatus, and electronic device for processing a workflow. Background Art

[0002] The operations of different industries have their specific processes, and a complete process may include multiple tasks, and the execution order of these tasks may be the execution order of serial logic, parallel logic, or exclusive logic. To improve office efficiency, relevant personnel in the industry abstractly summarize the execution order of each task in the process and describe it as a workflow.

[0003] In the related art, the design of workflow templates often depends on the existing functions within the system, resulting in a single function of the workflow template and being unable to meet the functional requirements during workflow processing.

[0004] In view of the above problems, no effective solution has been proposed yet. Summary of the Invention

[0005] Embodiments of the present invention provide a method, apparatus, and electronic device for processing a workflow, so as to at least solve the technical problem that the function of the workflow template in the related art is single and cannot meet the functional requirements during workflow processing.

[0006] According to one aspect of the embodiments of the present invention, a method for processing a workflow is provided, including: obtaining a workflow instance created based on a workflow template, where the workflow template includes at least one process node, at least some of the process nodes include target fields, and at least some of the target fields in the process nodes include first-type fields, the first-type fields are fields used to represent actions to be executed, and at least some of the actions to be executed depend on external system linkage execution; determining the triggered target fields in the target process nodes in the workflow instance; in the case where the triggered target field is a first-type field, executing the action to be executed described by the target field, and determining the field information associated with the target field based on the execution information; determining the node transition direction based on the field information associated with the target field to determine the next target process node in the workflow instance.

[0007] Furthermore, the method for processing a workflow further includes: determining the triggered target fields based on the interaction information of the user with respect to the target process nodes in the workflow instance, or determining the triggered target fields based on the node change information of the target process nodes.

[0008] Further, the method for processing a workflow further includes: The first type of fields includes first sub-type fields, and the first sub-type fields are fields used to represent actions to be executed that depend on internal system execution. Wherein, when the triggered target field is a first sub-type field, determine the functional logic corresponding to the action to be executed described by the target field; execute the action to be executed described by the target field based on the functional logic.

[0009] Further, the method for processing a workflow further includes: The first type of fields includes second sub-type fields, and the second sub-type fields are fields used to represent actions to be executed that depend on external system linkage. Wherein, when the triggered target field is a second sub-type field, execute the action to be executed through the execution unit associated with the second sub-type field, and determine the field information associated with the target field based on the execution information. Wherein, the execution unit executes the action to be executed by means of sending information to an external interface and / or receiving information sent by an external interface.

[0010] Further, the method for processing a workflow further includes: When the execution unit is a trigger, send a target request to an external interface through the trigger to request the external interface to execute the action to be executed; receive the execution result feedback by the external interface, and determine the field value of at least one associated target field corresponding to the target field based on the execution result; determine the field value of at least one associated target field as the field information associated with the target field.

[0011] Further, the method for processing a workflow further includes: When the execution unit is a receiver, receive the event execution result sent by an external interface through the receiver, and parse the event execution result to obtain a parsing result to complete the action to be executed; determine the field value of at least one associated target field corresponding to the target field based on the parsing result; determine the field value of at least one associated target field as the field information associated with the target field.

[0012] Further, the method for processing a workflow further includes: When the execution unit is a notifier, send target information to an external interface to complete the action to be executed; determine the field information associated with the target field based on the execution information of the notifier.

[0013] Further, the method for processing a workflow further includes: The target fields in at least some process nodes include second type of fields, and the second type of fields are fields used to describe items to be recorded. Wherein, after determining the triggered target field in the target process node in the workflow instance, when the triggered target field is a second type of field, determine the field value of the target field based on the interaction information of the target user with respect to the target process node in the workflow instance, and determine the field value as the field information associated with the target field.

[0014] Further, the method for processing a workflow further includes: determining the constraint conditions in the target process node; determining the satisfied constraint conditions in the target process node based on the field information associated with the target field; and determining the node transition direction based on the satisfied constraint conditions in the target process node and the transition rules in the target process node, where the transition rules are used to record the constraint conditions required to trigger the transition direction of each node.

[0015] According to another aspect of the embodiments of the present invention, there is also provided a workflow processing apparatus, including: an acquisition module, configured to acquire a workflow instance created based on a workflow template, where the workflow template includes at least one process node, at least some of the process nodes include target fields, and at least some of the target fields in the process nodes include first-type fields, the first-type fields are fields used to represent actions to be executed, and at least some of the actions to be executed depend on external system linkage execution; a first determination module, configured to determine the triggered target fields in the target process node of the workflow instance; a second determination module, configured to, when the triggered target field is a first-type field, execute the action to be executed described by the target field, and determine the field information associated with the target field based on the execution information; and a third determination module, configured to determine the node transition direction based on the field information associated with the target field to determine the next target process node in the workflow instance.

[0016] According to another aspect of the embodiments of the present invention, there is also provided a computer-readable storage medium, in which a computer program is stored, where the computer program is configured to execute the above-mentioned method for processing a workflow when running.

[0017] According to another aspect of the embodiments of the present invention, there is also provided an electronic device, including one or more processors; a memory, configured to store one or more programs, when the one or more programs are executed by the one or more processors, enabling the one or more processors to implement a program for running, where the program is configured to execute the above-mentioned method for processing a workflow when running.

[0018] According to another aspect of the embodiments of the present invention, there is also provided a computer program product, including computer programs / instructions, where the computer programs / instructions implement the above-mentioned method for processing a workflow when executed by a processor.

[0019] In an embodiment of the present invention, an action that supports external linkage execution is set in a workflow to process the workflow. By obtaining a workflow instance created based on a workflow template, then determining a target field triggered in a target process node in the workflow instance, and then, when the triggered target field is a first type of field, executing the to-be-executed action described by the target field, and determining field information associated with the target field based on the execution information, so as to determine a node transition direction based on the field information associated with the target field to determine the next target process node in the workflow instance. Wherein, the workflow template includes at least one process node, at least some of the process nodes include target fields, and at least some of the target fields in the process nodes include first type of fields, the first type of fields are fields used to represent to-be-executed actions, and at least some of the to-be-executed actions depend on external system linkage execution.

[0020] In the above process, by setting the target fields in at least some of the process nodes in the workflow template to include the first type of fields used to represent to-be-executed actions, and at least some of the to-be-executed actions depend on external system linkage execution, when the target fields in the workflow are triggered, it supports linkage with external services, that is, other business logics can be reused, and there is no need to re-develop when docking with other businesses. The relevant workflow engine of the present application only needs to focus on the functions that the workflow itself should have. Thus, while realizing the lightweight and convenient maintenance of the workflow engine, the workflow engine can be compatible with the complex functions of other business modules, thereby enriching the applicable scenarios of the workflow and meeting the functional requirements during workflow processing. By determining the field information associated with the triggered target field based on the execution information of the action, and determining the node transition direction based on the field information associated with the triggered target field, it realizes supporting the determination of the transition situation of nodes in the workflow according to the relevant information of external system linkage, thereby ensuring the processing reliability of the workflow during external linkage processing.

[0021] It can be seen that the solution provided by the present application achieves the purpose of setting an action that supports external linkage execution in the workflow to process the workflow, thus realizing the technical effect of meeting the functional requirements during workflow processing, and further solving the technical problem that the function of the workflow template in the related art is single and cannot meet the functional requirements during workflow processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The illustrative embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation to the present invention. In the drawings:

[0023] Figure 1 is a schematic diagram of an optional workflow processing method according to an embodiment of the present invention;

[0024] Figure 2 It is a schematic diagram of an optional workflow engine according to an embodiment of the present invention;

[0025] Figure 3 It is a schematic diagram of an optional workflow template according to an embodiment of the present invention;

[0026] Figure 4 It is a schematic diagram of an optional trigger according to an embodiment of the present invention Figure 1 ;

[0027] Figure 5 It is a schematic diagram of an optional receiver according to an embodiment of the present invention Figure 1 ;

[0028] Figure 6 It is a schematic diagram of an optional notifier according to an embodiment of the present invention Figure 1 ;

[0029] Figure 7 It is a schematic diagram of an optional workflow according to an embodiment of the present invention;

[0030] Figure 8 It is a schematic diagram of an optional workflow template according to an embodiment of the present invention;

[0031] Figure 9 It is a schematic diagram of an optional trigger according to an embodiment of the present invention Figure 2 ;

[0032] Figure 10 It is a schematic diagram of an optional receiver according to an embodiment of the present invention Figure 2 ;

[0033] Figure 11 It is a schematic diagram of an optional processing device of a workflow according to an embodiment of the present invention;

[0034] Figure 12 It is a schematic diagram of an optional electronic device according to an embodiment of the present invention. Detailed implementation manners

[0035] In order to enable those skilled in the art to better understand the solution of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0036] It should be noted that the terms "first", "second", etc. in the specification, claims and above-mentioned drawings of the present invention are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that such data used can be interchanged under appropriate circumstances, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units does not necessarily limit to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0037] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards in the relevant regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0038] Embodiment 1

[0039] According to an embodiment of the present invention, an embodiment of a method for processing a workflow is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that here.

[0040] Figure 1 is a schematic diagram of an optional method for processing a workflow according to an embodiment of the present invention, as Figure 1 shown, the method includes the following steps:

[0041] Step S101, obtain a workflow instance created based on a workflow template, where the workflow template includes at least one process node, at least some of the process nodes include target fields, and at least some of the target fields in the process nodes include first-type fields, and the first-type fields are fields used to characterize actions to be executed, and at least some of the actions to be executed depend on external system linkage execution.

[0042] Optionally, devices such as electronic devices, application systems, servers, etc. can be used as the execution subject of this application. In this embodiment, the workflow engine is used as the execution subject to execute the method for processing a workflow.

[0043] Optionally, the workflow engine is presented in the form of an SDK. SDK (Software Development Kit) is a set of tools, libraries, documents and sample codes for developing specific software, applications or other content. SDK enables developers to build applications for specific platforms or technologies without having to write a lot of code from scratch. The workflow engine can provide a variety of functional interaction interfaces for upper-level business use, and implement multiple functional modules to digest the various internal complex functions of the workflow engine, so as to reduce the maintenance cost of the upper-level business system.

[0044] Figure 2 is a schematic diagram of an optional workflow engine according to an embodiment of the present invention, such as Figure 2 As shown, the workflow engine is expressed in the following ways: workflow template, node, field (global field and node field), flow relationship (constraints and flow rules), among which, node, field, flow relationship belong to workflow template, and workflow engine provides multiple SDK methods for upper-layer business access and use, including but not limited to defining workflow template, creating workflow by workflow template, recording node field content / completing node field action, workflow node flow, locating current node, obtaining and viewing the overall picture of workflow, etc. It should be noted that the "node" described in the previous and next texts can be understood as "process node", and the "field" described in the following texts can be understood as "target field", that is, the target field includes global field and node field.

[0045] like Figure 2As shown in the figure, the workflow template method is defined to provide an entry for workflow definition for upper-level services (users) to meet different requirements for the workflow engine in different business scenarios. A workflow template is a general definition design of a workflow. It defines the structure and rules of the workflow and can be designed by a process administrator. Considering the daily application scenarios, the same workflow will be repeatedly created and applied or serve different entities. Here, the same workflow means that the workflow process is the same, but the data or content associated with the process during its flow varies depending on the process initiator. For example, in the leave application process of an OA system, the process is the same for each employee. After the process is initiated, it will be transferred to the direct superior for approval, and then processed by the same department before finally being archived. However, the data or content associated with each process is different. For example, the leave application process initiated by A is associated with A's relevant information, such as name, employee number, number of days of leave, etc., while the leave application process initiated by B is associated with B's relevant information. The leave application process in the OA system example above can be understood as a workflow template. A workflow template defines a fixed workflow process, and the content and transfer relationships included in the process are described and agreed upon in the workflow template. Multiple workflows can be generated from a workflow template. A workflow needs to be bound to an initiator (such as employee A who applies for leave). It is the workflow that can actually generate transfer actions and record the content of the transfer process. It is equivalent to the workflow template being the definition and the workflow being the process instance. A workflow can only be bound to one initiator, while one initiator can be bound to multiple workflows.

[0046] Optionally, Figure 3 is a schematic diagram of an optional workflow template according to an embodiment of the present invention. As Figure 3 shown, the workflow template definition includes node definition (i.e., process node definition), field definition (i.e., target field definition), and transfer relationship definition. Among them, the node definition is used to describe each stage included in the workflow process. The basis for stage division is diverse, including but not limited to process steps, process status, process participants, process handler departments, etc. For example, in the request process of an OA system, taking the process participants as the basis for stage division, the process participants include initiators, approvers, archive systems, etc. Each process participant serves as a node definition and a process stage. That is, the request process of the OA system can be described as a process composed of multiple node definitions, such as the process initiated by the initiator, approved by the direct superior, approved by the department head, approved by the human resources department, and process archiving. The participants corresponding to each node definition are the initiator, approver, approver, approver, and archive system respectively.

[0047] At least one node definition shall be declared in a workflow template definition, that is, a workflow process requires at least one process node.

[0048] Field definitions are used to describe executable actions on nodes or descriptive items that can be recorded, etc. The target fields in the workflow template may include first-class fields and second-class fields. The first-class fields are fields used to characterize the actions to be executed, and the second-class fields are fields used to describe the items to be recorded. The first-class fields can also be divided into first subclass fields and second subclass fields. The first subclass fields are fields used to characterize the execution of the actions to be executed by the dependent system, and the second subclass fields are fields used to characterize the execution of the actions to be executed by the dependent external system linkage. The execution of the actions to be executed by the dependent external system linkage refers to the execution of the actions to be executed by the dependent external system linkage. The functional logic of the executable action can be provided by the workflow engine, or by the upper-level business, and the workflow engine can be linked with the upper-level business. The former is designed to provide convenient functional applications for the upper-level business, which are generally general functions, such as file upload, etc. The latter is designed to provide flexibility and scalability for the upper-level business to use the workflow engine, which is generally a customized function of the upper-level business, and the functional logic will be strongly related to the business. Assuming that the upper-level business is an office system, the action function logic of the upper-level business may be sending an email.

[0049] like Figure 3 As shown, field definitions are divided into node field definitions and global field definitions, and the two have different scopes. After a node field definition instance is defined, it becomes a node field, which needs to be associated with a node to take effect. After a global field definition instance is defined, it becomes a global node field, which takes effect after being associated with a workflow and referenced by the node. The scope of a node field is a node, that is, a node field. The results of the executable actions described by the node field definition or the content of the recorded description items are only visible in the node. The scope of a global field is a workflow, that is, the results of the executable actions described by the global field definition or the content of the recorded description items are visible to all nodes in the workflow, and the execution of the executable actions or the recording of the description items described by the global field definition can only be performed by the nodes that reference the global field instance. Other nodes can only read the results of the action execution and the content of the recorded description items.

[0050] Optionally, a node definition can declare multiple node field definitions or no node field definition; it can declare references to multiple global field definitions or no reference to global field definitions. That is, a node can have 0 or more fields.

[0051] like Figure 3As shown, the transfer relationship definition includes constraint condition definition and transfer rule definition. After the transfer relationship definition instance is the transfer relationship, which acts on nodes to describe the pointing relationship between the node and other nodes or the end node, that is, the nodes are strung together into a workflow through the transfer relationship. Among them, the end is the last virtual node of each workflow, which does not need to be explicitly defined through the workflow template. At the same time, the end node cannot be associated with node fields, cannot reference global fields, and cannot be associated with transfer relationships.

[0052] The constraint condition definition is the basis of the transfer rule definition, used to attach the expected description of the execution or recorded result of the field instance, that is, the expected description of the field value of the field. For example, two node fields are associated on a node, called node field 1 and node field 2 respectively. Node field 1 is defined as an executable action, and node field 2 is defined as a description item of the numeric type. Then, through the constraint condition definition, expected descriptions can be attached to the two node fields respectively. For example, constraint condition 1 can be defined as the completion of the node field 1 action, and constraint condition 2 can be defined as the content of the description item recorded by node field 2 being 100. After the constraint condition definition is instantiated, it becomes a constraint condition and takes effect when associated with the transfer rule.

[0053] A node definition can declare multiple constraint condition definitions. At the same time, a field definition can correspondingly declare multiple constraint condition definitions. And when there is no node field definition and no global field definition reference on a node, this node cannot declare a constraint condition definition.

[0054] Such as Figure 3As shown, the transfer rule definition is based on the constraint condition definition and is used to describe the next node that the specified current associated node can flow to when the expectations described by all associated constraint conditions are met (at this time, it is said that the transfer rule is satisfied). For example, transfer rule 1 can be defined to flow to node 2 when constraint condition 1 is satisfied, and transfer rule 2 can be defined to flow to the end node when constraint condition 2 is satisfied. Multiple constraint conditions can be combined through the logical relationships "AND" and "OR" in the transfer rule definition to form a constraint condition group. Among them, the "AND" logical relationship means that multiple constraint conditions need to be satisfied simultaneously, and the "OR" logical relationship means that as long as one of the multiple constraint conditions is satisfied. The two logical relationships can be combined. At the same time, the transfer action can be specified as automatic transfer or manual transfer in the transfer rule definition. When the transfer action is specified as automatic transfer, once the transfer rule is established, the workflow instance will flow into this node according to the next node that the current associated node specified in the rule can flow to. If the transfer action is manual transfer, when the relevant transfer rule is satisfied, the workflow engine can display a "transfer button" through the upper-layer service on the front-end interaction interface, so that when the user interacts with the "transfer button", the node transfer is executed. The automatic transfer has a higher priority than the manual transfer. When there are multiple transfer rules that are satisfied simultaneously, if there is a rule that specifies the transfer action as automatic transfer among them, the workflow instance will execute the automatic transfer action.

[0055] A node definition can declare multiple transfer rule definitions. There is a priority relationship among multiple transfer rule definitions. The default priority relationship is that the transfer rule declared earlier has a higher priority. When multiple transfer rules are satisfied and there are multiple rules that specify the transfer action as automatic transfer among them, the workflow instance flows into the next node pointed to according to the transfer rule definition of the automatic transfer with a higher priority. In some implementations, the priority among multiple transfer rules can also be freely set manually.

[0056] Optionally, as Figure 2 shown, the method of creating a workflow by the workflow template of the workflow engine provides an entry for the upper-layer service (user) to create a new workflow instance, enabling the workflow definition to be instantiated and applied or associated with multiple process applicants. The workflow instance is the actual application of the workflow template and represents a specific business process instance. It will flow according to the rules of the template, and the workflow instance can be displayed to the user through the front-end interaction interface.

[0057] Optionally, as Figure 2As shown in the figure, to support the above-mentioned various workflow engine presentation methods and the provided SDK methods, the workflow engine implementation logic includes workflow storage logic and workflow definition logic. Among them, the workflow storage logic is responsible for implementing the data persistence function of the workflow engine, including but not limited to workflow template definition, workflow instances and their correlations, operation logs, etc. At the same time, it docks and maintains the connection and interaction relationship with the storage component, and the storage component can be adapted and accessed according to business needs. The workflow definition logic is responsible for implementing the management and maintenance functions of workflow templates and workflow instances, including but not limited to workflow template definition, workflow template deletion, modification, and query, creating workflow instances from workflow templates, workflow instance deletion, modification, and query, etc.

[0058] Optionally, the upper-layer service can, upon receiving a workflow initiation request from the user, send the workflow initiation request to the workflow engine, so that the workflow engine creates a workflow instance based on the workflow template pointed to in the request, realizes the acquisition of the workflow example, and displays the workflow instance to the user through the front-end interaction interface of the upper-layer service. For example, when the user initiates a "leave process initiation request" through the upper-layer service, the workflow engine determines that the workflow template pointed to by the request is the leave template, and thus creates a workflow instance based on the leave template, and first displays the content of the first process node in the leave workflow on the front-end interaction interface of the upper-layer service. For example, words such as "Name:", "Number of leave days:", "Leave time:" and buttons such as "Upload leave form" are displayed on the front-end interaction interface for the user to fill in relevant information or perform relevant operations.

[0059] It should be noted that by using the workflow engine of the above design framework to implement the method provided in this embodiment, it can be easily docked with other services, and the workflow engine has clear functions, is easy to use, and is convenient for function expansion. Developers can perform iterative maintenance on the workflow engine without changing the workflow engine framework design.

[0060] Step S102, determine the target field triggered in the target process node of the workflow instance.

[0061] Optionally, as Figure 2 shown, the method of recording node field content / completing node field actions of the workflow engine provides an operation entry for the content carried on the workflow for the upper-layer service, enabling the workflow instance to carry the content input of process participants. This operation is of the interaction type and can have operation inputs or operation result feedback.

[0062] Optionally, the target process node is the node where the current workflow instance is located. The workflow engine can determine the target field triggered in the target process node based on the interaction information of the process participant (i.e., the user) on the front-end interaction interface of the upper-level business. For example, if the user enters "Zhang San" in the "Name" field of the front-end interaction interface, it is determined that the "Name" field in the target process node is triggered, and the "Name" field belongs to the second type of field. Another example is that if the user clicks the "File Upload" button on the front-end interaction interface, it is determined that the "Upload Attachment" field in the target process node is triggered, and the "Upload Attachment" field belongs to the first type of field. Optionally, the workflow engine can pre-store the trigger conditions corresponding to each field, so as to determine the field that meets the trigger conditions based on the interaction information, that is, to determine the triggered target field.

[0063] Optionally, the workflow engine can also determine the triggered target field based on the node change information of the target process node. The node change information of the target node includes, but is not limited to, the process flowing into the current node, the process flowing out of the current node, and the target field in the node meeting the trigger conditions.

[0064] Step S103, when the triggered target field is a first-type field, execute the to-be-executed action described by the target field, and determine the field information associated with the target field based on the execution information.

[0065] Optionally, the first-type field is a field used to represent the to-be-executed action. The first-type field includes a first subclass field, and the first subclass field is a field used to represent the to-be-executed action that depends on the internal execution of the system. The first-type field includes a second subclass field, and the second subclass field is a field used to represent the to-be-executed action that depends on the linkage execution of an external system.

[0066] When the triggered target field is a first-type field, the workflow engine can execute the to-be-described action based on the description information of the to-be-executed action in the target field. Optionally, if the target field is a first subclass field, the workflow engine has pre-defined the function logic corresponding to the action, and the workflow engine can directly execute the corresponding to-be-executed action based on the function logic. If the target field is a second subclass field, the workflow engine needs to rely on the linkage execution of an external system. In this case, the workflow engine can execute the corresponding action based on the execution unit defined in the second subclass field. The execution unit is used to interact with the external system, and the execution unit can be a trigger, a receiver, a notifier, etc.

[0067] For example, as Figure 2 shown, to support the above various workflow engine manifestation methods and the provided SDK methods, the workflow engine implementation logic includes external linkage logic, etc.

[0068] The external linkage logic is responsible for the linkage between the workflow instance and the external business logic, including three types of logic: trigger, receiver, and notifier. These three types of logic act on the workflow definition in the form of field definitions. The external business logic refers to the functional logic outside the workflow engine, which can be provided by the upper-level business system or any third party. The linkage method can be any message communication method, including but not limited to HTTP (Hypertext Transfer Protocol) / HTTPS (Hypertext Transfer Protocol Secure) requests, message communication mechanisms, etc. Which linkage method can be used depends on the implementation of the workflow engine, but the linkage method allows continuous iterative development and expansion according to the application scenario requirements without affecting the design and implementation of other functions of the workflow engine.

[0069] Among them, the trigger logic mainly realizes the function of triggering external business logic and receiving the execution result of this logic; the receiver logic mainly realizes the functions of receiving external business logic notifications and receiving the attached results of the notifications; the notifier logic mainly realizes the function of sending notifications to external business logic when the workflow instance enters a specified timing. With the help of the trigger, the workflow engine can access more complex functions. At the same time, these complex functions can be provided by external services or directly reuse external services, so as to realize the lightweight of the workflow engine while allowing the workflow engine to implement complex and powerful functions. In actual application scenarios, there are many business scenarios where "functions can only be implemented by external services but are restricted by various factors in the workflow engine or in the deployment environment of the workflow engine and cannot be implemented, and at the same time these functions need to be triggered in the workflow engine", such as the scenario of "providing the function of remotely enabling a certain device for maintaining the upper-layer business system for the participants of the workflow instance after the workflow instance enters a certain stage". By using the trigger, the workflow engine can provide such complex functions without secondary development, and even meet some scenarios where complex functions cannot be provided in the workflow engine even with secondary development. The receiver and the trigger are in a cooperative relationship. With the help of the receiver, the workflow engine can also access more complex functions. For example, in the threat alert linkage scenario, when the upper-layer business system sends threat alert information, the workflow instance can be linked through the receiver to enter the next node for processing, and the participants of the next node are specified as the relevant personnel for threat alert handling. The difference is that the trigger actively triggers the execution of external business logic through the linkage method by the workflow instance, while the receiver is in a waiting state, waiting to receive the signal after being triggered by the external business and executing specific logic. With the help of the notifier, the workflow engine can achieve more linkages with external services, thus serving more business scenarios. When using the notifier, the workflow engine will, according to the definition of the notifier, when the workflow instance meets the agreed conditions in the definition, achieve linkages with external services, such as calling external service HTTP / HTTPS interfaces, sending messages, etc. The specific linkage method also depends on the implementation support degree of the workflow engine and the linkage method selected when defining the notifier, and can be used for, including but not limited to, notification scenarios. For example, binding a notifier to a specific node. When the workflow instance flows into this node, the workflow engine will generate linkages with external services according to the linkage method.

[0070] Optionally, during the execution of the to-be-executed action, the corresponding execution information can be recorded to determine the field information associated with the target field based on the execution information. Among them, the execution information is the feedback information generated during the execution of the action, which can be the execution status (success, failure), the execution result data (such as the scan result, the URL of the file upload, etc.), and the context data during the execution of the action (such as the timestamp, the executor information), etc. The field information is used to update the status of the workflow instance and as a constraint condition for subsequent nodes to judge during the transfer.

[0071] Step S104: Determine the node transition direction based on the field information associated with the target field to determine the next target process node in the workflow instance.

[0072] In some embodiments, a mapping relationship between the node transition direction and the field information of each process node is pre-stored in the workflow engine, and the workflow engine can determine the node process direction of the target process node based on this mapping relationship.

[0073] In some embodiments, the workflow template includes constraint conditions and transition rules. The constraint conditions are used to attach an expected description of the execution or recorded result of the field instance, that is, an expected description of the field value of the field. The transition rules are used to record the constraint conditions that need to be satisfied to trigger each node transition direction. The target processing system can determine the satisfied constraint conditions in the target process node based on the field information associated with the target field, and thus determine the node transition direction based on the satisfied constraint conditions and the transition rules in the target process node.

[0074] Optionally, the node transition direction includes node information of the next target process node in the workflow instance, such as node identifiers, etc. The workflow engine can determine the next target process node in the workflow instance based on the node transition direction.

[0075] For example, as Figure 2 shown, to support the above-mentioned various workflow engine manifestation methods and the provided SDK methods, the workflow engine implementation logic further includes workflow decision logic.

[0076] The workflow decision logic is responsible for implementing the transition function of the workflow instance. This function, in accordance with the transition relationships associated with each node of the workflow instance, determines in real time whether there is a satisfied transition rule in the transition relationships based on the current status of the workflow instance, so as to complete the automatic or manual transition actions of the workflow nodes. However, whether it is an automatic transition action or a manual transition action, there is a corresponding trigger timing for whether to execute the action. The trigger timing for whether to execute the automatic transition action is when flowing into this node and when recording the node field content / completing the node field action. Once these two trigger timings are captured and completed, the workflow decision logic will determine in real time based on the current status of the workflow instance whether at least one of the transition relationships associated with this node is established. Once there is an established transition relationship, the workflow decision logic will, according to the priority of the transition relationships, preferentially flow automatically into the corresponding node in accordance with the high-priority transition relationship declaration.

[0077] In some embodiments, such as Figure 2As shown, the workflow engine provides multiple SDK methods for upper-layer services to access and use. In addition to the above methods of defining workflow templates, creating workflows from workflow templates, recording node field content / completing node field actions, it can also include workflow node transitions, locating the current node, obtaining and viewing the current overall picture of the workflow, etc.

[0078] The workflow node transition method provides an operation entry for workflow transition control for upper-layer services (users), enabling workflow instances to carry operation instructions and controls of process participants, and collaborating to complete the workflow transition according to the wishes of process participants and the constraints of the workflow itself. This transition is a manual workflow node transition operation. Corresponding to it is the node automatic transition function. The difference is that the automatic transition function is implemented internally by the workflow engine (such as Figure 2 the constraint conditions and transition rules shown in), without the intervention of upper-layer services (users).

[0079] The method of locating the current node provides an entry for upper-layer services (users) to quickly query the location of the current workflow instance and obtain the operable content of the current workflow instance, facilitating front-end interaction access.

[0080] The method of obtaining and viewing the current overall picture of the workflow provides a query entry for upper-layer services (users) to comprehensively understand the current status of each workflow instance, facilitating upper-layer services to manage workflow instances and front-end interaction to fully display workflow instances. Workflow process participants can monitor the current status of workflow instances at any time and adjust management content in a timely manner.

[0081] In some embodiments, the workflow engine is not limited to the above-mentioned methods, such as the event notification method. The event notification method provides an entry for upper-layer services (users) to link with the workflow engine. External linked services can use this method to provide external logic completion signals and completion results to the workflow engine, thereby having a necessary impact on the transition of workflow instances.

[0082] Based on the solution defined in the above steps S101 to S104, it can be learned that in the embodiment of the present invention, an action that supports external linkage execution is set in the workflow to process the workflow. By obtaining a workflow instance created based on a workflow template, then determining the target field triggered in the target process node in the workflow instance, and then, when the triggered target field is a first type of field, executing the to-be-executed action described by the target field, and determining the field information associated with the target field based on the execution information, so as to determine the node transition direction based on the field information associated with the target field, and determine the next target process node in the workflow instance. Among them, the workflow template includes at least one process node, at least some of the process nodes include target fields, and at least some of the target fields in the process nodes include first type of fields. The first type of fields are fields used to represent to-be-executed actions, and at least some of the to-be-executed actions depend on external system linkage execution.

[0083] It is easy to notice that in the above process, by setting the target fields in at least some of the process nodes in the workflow template to include the first type of fields used to represent to-be-executed actions, and at least some of the to-be-executed actions depend on external system linkage execution, when the target fields in the workflow are triggered, it supports linkage with external services, that is, other business logics can be reused, and there is no need to re-develop when docking with other businesses. The relevant workflow engine of this application only needs to focus on the functions that the workflow itself should have. Thus, while making the workflow engine lightweight and easy to maintain, the workflow engine can be compatible with the complex functions of other business modules, thereby enriching the applicable scenarios of the workflow and meeting the functional requirements during workflow processing. By determining the field information associated with the triggered target field based on the execution information of the action, and determining the node transition direction based on the field information associated with the triggered target field, it realizes the support for determining the transition situation of nodes in the workflow according to the relevant information of external system linkage, thus ensuring the processing reliability of the workflow during external linkage processing.

[0084] It can be seen that the solution provided by this application achieves the purpose of setting an action that supports external linkage execution in the workflow to process the workflow, thus realizing the technical effect of meeting the functional requirements during workflow processing, and further solving the technical problem that the function of the workflow template in the related technology is single and cannot meet the functional requirements during workflow processing.

[0085] In an optional embodiment, during the process of determining the target field triggered in the target process node in the workflow instance, the workflow engine can determine the triggered target field based on the interaction information of the user with respect to the target process node in the workflow instance, or determine the triggered target field based on the node change information of the target process node.

[0086] Optionally, the user interaction information refers to the information generated when a user (such as a process participant) interacts with a workflow instance through the interface or API (Application Programming Interface) provided by the upper-level business system. Such information includes, but is not limited to, the information filled in by the user, the form data submitted, the files uploaded, the button operations clicked, etc. All these operations may trigger specific target fields of the target process node. For example, in an OA management system, the number of leave days field filled in by an employee when submitting a leave application, or in a security service process, the customer communication result document uploaded by a security service personnel, etc., are all manifestations of user interaction information. When this information is submitted, the associated target fields are triggered.

[0087] Optionally, when a user interacts with a workflow instance, the upper-level business can record the interaction information and pass it to the workflow engine. The workflow engine will parse the user interaction information and identify the specific target fields triggered. These target fields can be node fields defined in the workflow template or global fields, depending on the context of the user operation and the design of the workflow template. For example, if a user clicks the "Upload Button" at an approval node, then the workflow engine will identify that the target field "Upload Approval File" has been triggered. Subsequently, based on the type of the triggered target field (such as the first type of field or the second type of field), the workflow engine will perform corresponding actions or update the field content, and at the same time determine the field information associated with the target field based on the execution information for subsequent node transfer decisions. For example, for the target field "Upload Approval File", which is the first type of field, the workflow engine can perform the corresponding upload action, such as receiving the approval file and then uploading the approval file to a preset storage area.

[0088] Optionally, the node change information refers to the information indicating that the current node has changed during the running of a workflow instance. For example, the change situation of the information flowing into the current node, flowing out of the current node, and the field information of the target field, etc. In these cases of node changes, some fields defined in the workflow template may be triggered to perform specific operations or record specific information.

[0089] Optionally, when the target process node of a workflow instance changes, the workflow engine will check all the target fields defined on the target process node and identify the fields that are triggered during the node change. These fields usually have specific trigger conditions, such as a notifier that automatically starts when the node enters, or a notifier that automatically executes when the node exits. In this way, the workflow engine can automatically perform some preset actions without additional interaction from the user, making the running of the workflow smoother and more efficient.

[0090] For example, when the process of a workflow instance flows into the current node, it is determined that a target field associated with a notifier is triggered, and the notifier sends a request to the outside. Another example is that when the field information of a target field in the current node changes (i.e., the field information is determined based on user operations), it is judged whether the trigger condition of the target field associated with the notifier in the current node is met. If it is met, the notifier sends a request to the outside.

[0091] It should be noted that by introducing a mechanism for determining the triggered target field based on user interaction information and node change information, the intelligence and flexibility of the workflow engine are further improved. The introduction of user interaction information enables the workflow instance to respond to user operations in real time. Whether it is recording the data input by the user or performing the actions of the user instructions, the state of the workflow can be updated immediately, making the flow of the workflow more in line with the actual business needs and enhancing the user experience. The utilization of node change information automates the execution of some preset actions, reduces the need for manual intervention, and improves the automation level and efficiency of workflow processing.

[0092] In an optional embodiment, the first type of fields includes first sub-type fields, and the first sub-type fields are fields used to represent actions to be executed that depend on the internal execution of the system. Among them, during the process of executing the actions to be executed described by the target field, when the triggered target field is a first sub-type field, the functional logic corresponding to the actions to be executed described by the target field is determined; the actions to be executed described by the target field are executed based on the functional logic.

[0093] Optionally, the first sub-type fields are used to indicate specific operations that need to be executed inside the workflow engine. These operations can be part of the basic functions of the workflow engine, such as file upload, data verification, status change, etc. The functional logic refers to the specific program code or algorithm implemented inside the workflow engine for executing the actions to be executed described by the target field. For example, if the target field describes a file upload action, the functional logic may include functions such as receiving the file, storing the file, and generating a file access link.

[0094] When the workflow engine detects that a first sub-type field is triggered, it will identify the actions to be executed described by the field and determine the functional logic required to execute the actions. For example, when the "upload approval file" field is triggered, the workflow engine will automatically identify that this is a file upload action and call the corresponding internal file upload functional logic to complete this task.

[0095] In some embodiments, the target fields belonging to the first subclass field in this embodiment are explained according to Table 1. The constraint definition is used to append the expected description of the execution or recorded result of the field instance. Table 1 shown below further supplements the specific type design of the field definition so that the "expected description" can be quantified and deduced in the workflow engine. The quantification and deduction logic of the "expected description" is implemented through the field judgment logic in this solution. The field judgment logic judges whether the execution result or recorded result of the field instance conforms to a certain logical judgment with the expected value, and the judgment result of the dictionary judgment logic is whether it holds. Specifically, the constraint definition can be described as selecting a certain field judgment logic supported by the type according to the specific type of the field definition, and at the same time giving the expected value of the execution or recorded result of the field instance, and the judgment logic of whether the constraint expectation is met is correspondingly implemented by executing the field judgment logic.

[0096] Table 1

[0097]

[0098]

[0099] As shown in Table 1, the specific types of field definitions include, but are not limited to, key-value pair classes, action classes, triggers, receivers, and notifiers, etc. Among them, the key-value pair class fields belong to the second type of fields, and the action class, trigger, receiver, and notifier class fields belong to the first type of fields. Moreover, the action class fields belong to the first subclass fields in the first type of fields, and the trigger, receiver, and notifier class fields belong to the second subclass fields in the first type of fields. Among them, the key-value pair class is mainly used to provide interactions for record-class content; the action class is used to provide interactions for tool-class content; the trigger, receiver, and notifier are used to provide interactions for the linkage between the workflow engine and external services.

[0100] Furthermore, the specific types of field definitions are divided into subtypes (for example, the action class is divided into two subtypes: uploading attachments and invoice parsing) so as to provide different field judgment logics according to different subtypes from a finer-grained perspective.

[0101] The specific type of the field definition of the action class is manifested as the field being an executable instance (or called a function) type. Correspondingly, the processing logic executed by the "record node field content / complete node field action" method of the workflow engine for this type of field is to execute a specific function and generate a specific result.

[0102] The action category includes, but is not limited to, various subtypes such as uploading attachments and invoice parsing. Among them, the uploading attachment subtype provides field judgment logics including, but not limited to, action trigger judgment, attachment type judgment, etc. After the fields of the uploading attachment subtype are triggered through the method of "recording node field content / completing node field action" of the workflow engine, the workflow engine will automatically execute the functional logic of uploading attachments, receive the file stream as input, save the file as output, and at the same time provide the functional logic for downloading the file. It also automatically identifies file attribute information including, but not limited to, the file type and file size of the uploaded attachment as a specific result for saving, that is, saving it to a preset storage area and determining it as execution information to be used as the field information of the fields of this uploading attachment subtype.

[0103] The invoice parsing subtype provides field judgment logics including, but not limited to, action trigger judgment, invoice type judgment, etc. After the fields of the invoice parsing subtype are executed through the method of "recording node field content / completing node field action" of the workflow engine, the workflow engine will automatically execute the functional logic of invoice parsing, receive the file stream as input, and use the parsed content as output. At the same time, it provides the functional logic for downloading the invoice, and automatically identifies attribute information including, but not limited to, the invoice type of the uploaded invoice as a specific result for saving, that is, saving it to a preset storage area and determining it as execution information to be used as the field information of the fields of this invoice parsing subtype.

[0104] Optionally, the field judgment logic of action trigger judgment is used to judge whether the field instance has been executed, that is, whether the field has been triggered to execute through the method of "recording node field content / completing node field action" of the workflow engine. The field judgment logic of attachment type judgment mainly judges whether the specific result after the execution of the field instance is consistent with the expected value. Specifically, it judges whether the file attributes of the uploaded attachment are consistent with the expected value.

[0105] It should be particularly noted that the specific types, subtypes, and field logic judgments of the field definitions listed in Table 1 are not a complete list. The technical solution of the present invention provides a design idea, and the specific functions depend on the logic implementation and function development of the workflow engine. The design of the technical solution of the present invention supports and is compatible with the iterative update and maintenance of the specific types, subtypes, and field logic judgments of the field definitions. In addition, the field definition and the design of the specific type of the field definition are independent of each other in design and dependent on each other in function, so that the specific type of the field definition ensures the possibility of continuous iterative update and expansion in design without affecting the field definitions in the existing workflow templates.

[0106] In some embodiments, the setting of the fields of the first subclass can support scenarios of multi-workflow cascading dependencies. For example, in a workflow process, the scenario of creating another workflow process. The implementation method for the scenario of "creating another workflow process in a workflow process" is as follows:

[0107] (1) The workflow engine extends the functional logic of "creating a workflow instance from a workflow template" into a subtype under the field definition concretization type of the action class, that is, the to-be-executed actions represented by the first subclass fields include actions for creating another workflow in a workflow.

[0108] (2) During the process of the process administrator editing the workflow template, select the target field of this action class subtype on the node. The target field can indicate the workflow template information of another workflow to be applied (such as, workflow template identifier, etc.). When the target field is triggered, it automatically triggers the instantiation of the workflow template of another workflow, and displays the instantiated another workflow to the user through the front-end interaction interface.

[0109] It should be noted that through the above method, it is ensured that the workflow engine can independently complete a series of basic and key process operations without relying on external linkage. This not only simplifies the execution process of the workflow instance, reduces the need for external systems, but also improves the response speed and reliability of the entire workflow system, because the actions executed internally generally have higher controllability and stability. In addition, by dividing the to-be-executed actions into two types: internal execution and external linkage, the workflow engine can more clearly define its functional boundaries, avoid unnecessary resource consumption and development complexity, while maintaining a high degree of scalability and adaptability, and can flexibly meet the needs of various business scenarios.

[0110] In an alternative embodiment, the first type of fields includes second subclass fields. The second subclass fields are fields used to represent to-be-executed actions that depend on external system linkage. Among them, during the process of executing the to-be-executed actions described by the target field and determining the field information associated with the target field based on the execution information, when the triggered target field is a second subclass field, the workflow engine can execute the to-be-executed actions through the execution unit associated with the second subclass field, and determine the field information associated with the target field based on the execution information. The execution unit depends on the way of sending information to the external interface and / or receiving information sent by the external interface to execute the to-be-executed actions.

[0111] Optionally, when the triggered target field is a second subclass field, the to-be-executed action it performs will need to be completed through linkage with an external system. This type of target field is closely related to the interaction with the external system, and the involved action execution usually cannot be achieved only through the internal logic of the workflow engine. Instead, it is necessary to call external interfaces or services, such as calling a third-party API for data processing, receiving event notifications from external systems, etc. Optionally, an external interface refers to the interface of an external system, that is, an interface on a system outside the workflow engine.

[0112] In the workflow engine, the execution unit associated with the second subclass field is responsible for processing the to-be-executed action described by the second subclass field. The execution unit can include a trigger, a receiver, and a notifier. As shown in Table 1, the field definition concretization types of the trigger, receiver, and notifier classes belong to special function definitions and have no subtype division. After being triggered by the "record node field content / complete node field action" method of the workflow engine or node change information, the corresponding function logic will be triggered to start.

[0113] Optionally, the trigger is used to actively send requests to external interfaces to trigger the execution of specific functions of external systems, such as calling an external asset scanning interface. The receiver is used to receive information sent by external interfaces and process the received events or data, such as receiving an event of a customer confirming a repair result. The notifier is used to send notifications to external interfaces when specific conditions are met, such as notifying an external system that the process has ended. When the workflow engine detects that a second subclass field is triggered, it will execute the to-be-executed action through the execution unit (one of the trigger, receiver, or notifier) associated with this field. For example, if the target field is "initiate asset scanning", then the workflow engine will call the external asset scanning interface through the trigger.

[0114] In some embodiments, after the external system performs an action, it can return information to the workflow engine, including but not limited to the execution status (success or failure), execution result data (such as a scan report, a file upload link), and execution context (such as execution time, executor, etc.). These information can be part of the execution information and be used to determine the field information associated with this target field. For example, the number of high-risk vulnerabilities returned after asset scanning, the scan report link, etc. all belong to the field information associated with the target field "initiate asset scanning".

[0115] It should be noted that by setting the second subclass field and the associated execution unit, a clear and effective mechanism is provided for the linkage between the workflow engine and external systems. It not only supports the workflow engine to call the powerful functions of external systems when necessary, such as asset scanning, data processing, etc., but also ensures that the results of the actions executed by the external system can be timely fed back to the workflow engine, updating the status of the workflow instance and affecting the transfer of subsequent nodes. Through external business linkage, the workflow engine can greatly enrich its own functions, apply to more business scenarios, effectively meet the functional requirements during workflow processing, and at the same time maintain the lightweight characteristics of the engine itself, which makes it more convenient and fast for other services to connect to the workflow engine.

[0116] In an alternative embodiment, during the process of executing the to-be-executed action by the execution unit associated with the second subclass field and determining the field information associated with the target field based on the execution information, when the execution unit is a trigger, the workflow engine can send a target request to the external interface through the trigger to request the external interface to execute the to-be-executed action; receive the execution result fed back by the external interface, and determine the field value of at least one associated target field corresponding to the target field based on the execution result; determine the field value of at least one associated target field as the field information associated with the target field.

[0117] Figure 4 Schematic diagram of an alternative trigger according to an embodiment of the present invention Figure 1 , Figure 4 Taking the HTTP / HTTPS request as an example in the linkage mode to illustrate the trigger design. If the linkage mode is extended to others, such as the message communication mechanism, then compared with the HTTP / HTTPS design, the "linkage interface URL (Uniform Resource Locator)" therein can be replaced with parameters related to message addresses, receiving message groups of the publish-subscribe message system, message topics, etc., which are required to be declared and specified for communication with the publish-subscribe message system itself.

[0118] Optionally, as Figure 4 shown, Figure 4The node one and node two in [[]] are process nodes in the workflow template. The trigger definition includes the definition of the linkage interface URL (parameters required for message communication), the definition of the linkage result, etc. Among them, the parameters required for message communication define the parameters specifications and contents related to HTTP / HTTPS requests such as the linkage interface URL, the request method of the interface, and the interface request parameters. The workflow engine recognizes and forms an HTTP / HTTPS request (i.e., the target request) according to this part of the definition and sends it to the external interface. The linkage result definition provides more possibilities for the linkage, allowing the execution result of the external business logic to be associated with and act on the workflow instance, thereby affecting the determination of the transfer relationship, so that the transfer of the workflow instance can affect the flow direction of the next node or the judgment of whether it can flow into the next node in combination with the execution result of the external business logic. The linkage result definition is used to define at least one associated target field corresponding to the target field associated with this trigger (i.e., Figure 4 the node field 1 and node field 2 shown in [[]]), and is used to define which information in the result returned by the linkage method is used as the field value of the associated target field. These associated target fields have the same definition as the target field and can also be applied to the constraint condition definition, thus forming a part of the transfer relationship. The only difference is that the associated target fields declared by the trigger association do not need to record the field content through the method of "recording the node field content / completing the node field action", but after the trigger sends an HTTP / HTTPS request to the external business and makes a mapping according to the request return result and the linkage result definition, the content of this part of the associated target field is automatically determined according to the linkage result.

[0119] Optionally, in addition to the node field mapping explicitly declared by the linkage result definition, the trigger will also implicitly generate a node field mapping of "whether the trigger has been started" as an associated target field. This associated target field can also be used for the constraint condition definition, thus forming a part of the transfer relationship. For example, in the transfer relationship definition of flowing into the next node, it is declared that an associated target field of "whether the trigger has been started" needs to meet the result expectation of "yes".

[0120] In some embodiments, since the field value of the associated target field does not need to be determined by user operation, the associated target field may not be displayed to the user through the front-end interaction interface.

[0121] Optionally, the trigger definition is manifested as a node field definition. Similarly, it can trigger the execution of the corresponding logic through the method of "recording the node field content / completing the node field action" provided by the workflow engine. That is, generally speaking, a node field (i.e., the target field) containing a trigger can be defined in the workflow template.

[0122] For example, when a trigger field on a certain process node in a workflow instance is triggered, the workflow engine will send a target request to an external system based on the configuration information in the trigger (such as the URL of an external interface, the request method, request parameters, etc.), requesting the external system to execute a specific action to be performed, such as asset scanning, data processing, etc. After receiving the target request, the external interface will execute the functions or actions related to the request, such as calling an asset scanning service to perform asset scanning, etc. After the processing is completed, it will return the execution result to the workflow engine. After the external interface completes the request action, the workflow engine will receive the execution result feedback from the external interface. The execution result may contain various information, such as the action execution status (success or failure), the data generated by the executed action (asset scanning report, processed data result), etc. The workflow engine will parse the received execution result, extract the information associated with the target field, and convert it into a field value for updating the associated target field in the workflow instance. For example, after the asset scanning trigger is executed, the workflow engine will parse the asset scanning report, extract the number of vulnerabilities, high-risk vulnerability information, etc., and update them to the corresponding associated target fields. Thus, the field value of at least one associated target field is determined as the field information associated with the target field to which the asset scanning trigger belongs, so as to determine the subsequent node transition direction.

[0123] It should be noted that realizing the linkage with the external system based on the trigger enables the workflow engine to actively call the powerful functions of the external system to execute complex actions, and effectively obtain the execution result of the external interface to update the state of the workflow instance. This mechanism enables the workflow instance to continuously collect and update key execution information during the interaction with the external system, providing rich and timely data support for dynamically judging the workflow transition path, so that the workflow engine can more flexibly and intelligently adapt to various business scenarios, improving the automation degree and efficiency of business processing.

[0124] In an optional embodiment, during the process of executing the action to be performed by the execution unit associated with the second subclass field and determining the field information associated with the target field based on the execution information, when the execution unit is a receiver, the workflow engine can receive the event execution result sent by the external interface through the receiver, and parse the event execution result to obtain the parsing result to complete the action to be performed; determine the field value of at least one associated target field corresponding to the target field based on the parsing result; and determine the field value of at least one associated target field as the field information associated with the target field.

[0125] Figure 5 Schematic diagram of an optional receiver according to an embodiment of the present invention Figure 1 , such as Figure 5 shown in Figure 5Node 1 and Node 2 in it are process nodes in the workflow template. The receiver definition includes event ID definition, linkage result definition, etc. The event ID is the identifier used by the workflow engine to distinguish external business linkage signals. External linkage services can use the "event notification" method provided by the workflow engine to declare the event ID of the notification in the method. The workflow engine will identify the receiver used to listen for this event in the workflow instance and trigger the execution of the receiver logic to parse the external logic execution result data (i.e., the event execution result) of the event to which the incoming event ID belongs to obtain the parsing result. The principle of the linkage result definition in the receiver is the same as that of the trigger, so it will not be elaborated here.

[0126] In addition to the node field mapping explicitly declared in the linkage result definition, the receiver will also implicitly and automatically generate a node field mapping of "whether the event signal has been received" as the associated target field. This associated target field can also be used for constraint condition definition, thus forming part of the flow relationship. For example, in the flow relationship definition for flowing into the next node, it is declared that an associated target field of "whether the event signal has been received" needs to meet the result expectation of "yes".

[0127] Optionally, the receiver definition, like the trigger definition, is expressed as node field definition. Similarly, it can trigger the execution of the corresponding logic through the "record node field content / complete node field action" method provided by the workflow engine. That is, generally speaking, node fields (i.e., target fields) containing receivers can be defined in the workflow template.

[0128] For example, when an external system completes an action related to the workflow engine, such as a customer confirming the repair result, it sends the event execution result to the workflow engine. Based on the event ID corresponding to the event execution result, the workflow engine determines the receiver for listening to this event ID, thereby triggering the receiver and passing the event execution result into the receiver. The event execution result may include information such as the execution status, result data, timestamp, etc. After receiving the event execution result, the receiver parses these data and identifies the valid information associated with the associated target field, such as the specific content of the customer feedback, the processing status, etc. This parsing is based on the rules defined in the receiver in advance to ensure correct mapping to the to-be-executed actions described by the target field. Based on the generation of the parsing result, the workflow engine confirms that the to-be-executed action of a specific target field has been completed. For example, if the "confirm customer confirms repair result" receiver has obtained the parsing result, the "customer confirmation" action is regarded as completed. Optionally, based on the parsing result, the receiver updates the value of the associated target field. For example, if the parsing result indicates that the customer is satisfied with the repair result, the value of the associated target field "repair result satisfaction" will be updated to "satisfied". Thus, the field value of at least one associated target field is determined as the field information associated with the target field to which the "confirm customer confirms repair result" receiver belongs, so as to determine the subsequent node transfer direction.

[0129] It should be noted that realizing the linkage of the external system based on the receiver enables the workflow engine to receive and parse the event execution result of the external system, thereby completing specific to-be-executed actions. This design is particularly important when dealing with some business scenarios that rely on the confirmation or feedback of the external system. For example, in the security service process, the confirmation or feedback of the customer on the vulnerability repair. The acquisition and processing of this information are directly related to the further progress of the workflow, such as whether to enter the vulnerability review stage, thereby further improving the applicability and flexibility of the workflow.

[0130] In an alternative embodiment, during the process of executing the to-be-executed action through the execution unit associated with the second subclass field and determining the field information associated with the target field based on the execution information, when the execution unit is a notifier, the workflow engine can send the target information to the external interface to complete the to-be-executed action and determine the field information associated with the target field based on the execution information of the notifier.

[0131] Optionally, Figure 6 is a schematic diagram of an alternative notifier according to an embodiment of the present invention Figure 1 , Figure 6 The notifier is explained by taking the HTTP / HTTPS request as the linkage method. As Figure 6 shown, Figure 6The node N in it is a process node in the workflow template. The notifier definition includes the definition of the linkage interface URL (parameters required for message communication) and the definition of the notification timing, etc. The definition of the parameters required for message communication is the same as the design of the parameters required for message communication in the trigger, so it will not be elaborated here. The definition of the notification timing is divided into three types of timings. The first is when flowing into this node, the second is when flowing out of this node, and the third is conditional trigger (that is, the field information of the changed field meets the established conditions), that is, the notification timing is determined based on the node change information of the target process node. When the notification timing is set to when flowing into this node, the workflow engine will, when the current node changes to the node bound by this notifier, form an HTTP / HTTPS request (that is, the target information) according to the definition of the parameters required for message communication, and send it to the external interface; when the notification timing is set to when flowing out of this node, the workflow engine will, when the current node bound by the notifier changes to any non-node bound by this notifier (including the end node), form an HTTP / HTTPS request according to the definition of the parameters required for message communication, and send it to the external interface; when the notification timing is set to conditional trigger, it is necessary to synchronously define the constraint conditions and the trigger rules in the notifier. The design of the trigger rules is the same as the design of the aforementioned flow rules. The timing for judging the establishment of the trigger rules is the same as the design of the automatic flow. The notifier determines which constraint conditions in the notifier are met based on the field information of the target field in the node it binds, so as to determine whether the notification timing is reached based on the satisfied constraint conditions and the trigger rules in the notifier, that is, to determine whether to trigger the target field associated with the notifier.

[0132] Optionally, the notifier definition is manifested as the target field definition, but it does not trigger the execution of the corresponding logic through the method of "recording the node field content / completing the node field action" provided by the workflow engine. Instead, the workflow engine judges whether the trigger rule is established at the above three judgment timings to decide whether to trigger the notifier to execute the corresponding logic.

[0133] Optionally, the execution information of the notifier can be information used to characterize whether the notifier has sent a notification, and it can also include information such as the sending time, the notification content, and the target interface.

[0134] In some embodiments, the notifier is different from the trigger and the receiver and does not perform linkage result mapping, so it does not affect the workflow instance flow relationship. The design of the notifier aims to trigger the linkage of external business logic when the workflow instance meets certain conditions, that is, after determining the field information associated with the target field based on the execution information of the notifier, when determining the node flow direction, if the field information associated with the target field belongs to the notifier, the execution information of this notifier can be ignored, that is, the node flow direction is determined based on the field information other than the field information associated with the target field.

[0135] In some embodiments, the execution information of the notifier can also be set to affect the transfer relationship of the workflow instance. That is, the expected description of the field information for the target field to which the notifier belongs is set in the constraint condition.

[0136] For example, when the trigger condition of the notifier field is satisfied (such as after a specific node transfer or based on certain field value judgments), the notifier will actively send target information (such as notification events, specific field values, etc.) to the defined external interface. For example, in the security service process, after the vulnerability repair is completed, a "vulnerability repair completed" notification is sent to the IT operation and maintenance system through the notifier. In the scenario of the notifier, sending the target information to the external interface is regarded as completing the to-be-executed action described by the second subclass field. Based on the execution information of the notifier, the workflow engine can record or update the field information related to the target field. For example, after sending the "vulnerability repair completed" notification, the "notification sending status" field can be updated to "sent" and the sending time can be recorded.

[0137] In some embodiments, the linkage setting of the receiver and the notifier can support the scenario of multi-workflow cascade dependency. For example, the end of one workflow process depends on whether another workflow process ends. The implementation method for the scenario of "the end of one workflow process depends on whether another workflow process ends" is as follows:

[0138] (1) In the workflow template definition of the first workflow, select the receiver definition node field on the node that needs to depend on the end of another workflow. Further, based on the associated target field of this node field (the implicit node field "whether the event signal has been received" automatically generated by the actual receiver), form a constraint condition with an expected value of "the event signal has been received" and use it as part of the transfer rule to form a dependency on the transfer that can only occur after another workflow process ends;

[0139] (2) Define the notifier class node field on the last node of another workflow. Set the notification timing to "when flowing out of the current node", the linkage method to call the SDK method "event notification", and the event ID of the notification to be the same as the definition of the receiver in the previous step. In this way, when this workflow ends (when flowing out of the last node), a signal will be automatically sent to the first workflow to form a dependency relationship.

[0140] It should be noted that realizing the linkage with the external system based on the notifier enables the workflow engine to send notifications to the external system under appropriate conditions, thereby providing higher applicability and flexibility for the workflow instance, that is, it can meet more functional requirements.

[0141] In an alternative embodiment, the target fields in at least some of the process nodes include second type fields, where the second type fields are fields used to describe items to be recorded. After determining the target fields triggered in the target process node of the workflow instance, when the triggered target field is a second type field, the workflow engine can determine the field value of the target field based on the interaction information of the target user with respect to the target process node in the workflow instance, and determine the field value as the field information associated with the target field.

[0142] Optionally, the second type fields are the key-value pair type fields in Table 1 above. The field definition of the key-value pair type is specifically manifested as the field being of the record type. Correspondingly, the processing logic executed by the "Record Node Field Content / Complete Node Field Action" method of the workflow engine for this type of field is manifested as recording the field result, that is, storing the recorded content and mapping it to the record result content type format constrained by the corresponding subtype as its corresponding field value.

[0143] As shown in Table 1 above, the key-value pair type includes, but is not limited to, various subtype divisions such as text, integer, floating point number, date, boolean value, etc. The key in the key-value pair can be understood as the field name, and the value in the key-value pair can be understood as the field value. Among them, the text subtype provides field judgment logics including, but not limited to, non-empty judgment, inclusion judgment, dictionary judgment, equality judgment, etc. At the same time, the record result content type of the constrained field can correspond to the String data type in the Java language. It should be noted that in this embodiment, the Java language is used as an example for illustration, but it does not mean that the field definition specific type in the technical solution of the present invention can only be developed and implemented through the Java language.

[0144] Optionally, the non-empty judgment field judgment logic mainly judges whether there is a recorded result for the field.

[0145] The inclusion judgment field judgment logic mainly judges whether a specified character segment is included in the recorded result of the field. For example, assume that the recorded result of a field declared as text type is "test", and the expected "character segment" specified in the constraint condition for this field is "test-more", then the judgment result after executing the inclusion judgment logic is established. If the expected "character segment" specified in the expected description is "more", then the judgment result after executing the inclusion judgment logic is not established.

[0146] The field judgment logic of dictionary judgment mainly judges whether the recorded result of the field is within a certain specified text range. For example, assume that the recorded result of a certain field declared as text type is "test", and the expected "text range" specified in the expected description for this field is "test" or "more", then the judgment result after executing the dictionary judgment logic is established. If the expected "text range" specified in the expected description is "another" or "more", then the judgment result after executing the dictionary judgment logic is not established.

[0147] The field judgment logic of equality judgment mainly judges whether the recorded result of the field is exactly the same as a certain specified content. For example, assume that the recorded result of a certain field declared as text type is "test", and the expected "content for exact match" specified in the expected description for this field is "test", then the judgment result after executing the equality judgment logic is established. If the expected "content for exact match" specified in the expected description is "test-more", then the judgment result after executing the equality judgment logic is not established.

[0148] The integer subtype provides field judgment logics including but not limited to non-null judgment, logical operation judgment, and dictionary judgment, etc. At the same time, the content type of the recorded result of the constrained field corresponds to the Integer data type in the Java language. Among them, the non-null judgment and dictionary judgment of the two field judgment logics are the same as those of the text type, so they will not be elaborated here.

[0149] The field judgment logic of logical operation judgment mainly judges whether it holds after performing logical operations such as greater than, less than, equal to, etc. in the mathematical concept on the recorded result of the field and the expected value.

[0150] The floating-point subtype provides field judgment logics including but not limited to non-null judgment, logical operation judgment, and dictionary judgment, etc. At the same time, the content type of the recorded result of the constrained field corresponds to the Float data type in the Java language.

[0151] The date subtype provides field judgment logics including but not limited to non-null judgment, logical operation judgment, and between judgment, etc. At the same time, the content type of the recorded result of the constrained field corresponds to the Date data type in the Java language.

[0152] The field judgment logic of between judgment mainly judges whether the recorded result of the field is within the range defined by the expected value, such as whether it is within a given date range.

[0153] The boolean subtype provides field judgment logics including but not limited to non-null judgment and is judgment, etc. At the same time, the content type of the recorded result of the constrained field corresponds to the Boolean type in the Java language.

[0154] The judgment logic of the field to be judged mainly determines whether the recorded result of the main judgment field is established, which corresponds to true or false in the Java language.

[0155] For example, when a user operates on a target process node in a workflow instance, the user provides information to the workflow engine, such as filling in the name, leave date, etc. The interaction information includes the field name corresponding to the information filled in by the user and the information filled in by the user. The workflow engine determines the target field to be triggered based on the field name corresponding to the information filled in by the user, and determines the information filled in by the user as the field value of the target field. For example, if the target field is "reason for leave", then the field value will be determined based on the specific reason filled in by the user at the leave application node, so as to determine the field value as the field information associated with the target field for use in the transfer rule judgment of subsequent approval nodes, such as judging whether the constraint condition of "the reason for leave is not empty" is met.

[0156] It should be noted that based on the second type of field to record specific items to be recorded, a systematic and automated method is provided for collecting and processing user input, enabling the workflow engine to effectively capture and record the operations and information of users in the process, thereby promoting the progress of the workflow, and further improving the flexibility of workflow processing in this application, that is, it can meet more functional requirements.

[0157] In an optional embodiment, in the process of determining the node transfer direction based on the field information associated with the target field, the workflow engine can determine the constraint conditions in the target process node; determine the satisfied constraint conditions in the target process node based on the field information associated with the target field; and determine the node transfer direction based on the satisfied constraint conditions in the target process node and the transfer rules in the target process node, where the transfer rules are used to record the constraint conditions required to trigger the transfer direction of each node.

[0158] In some embodiments, the workflow template includes constraint conditions and transfer rules. The constraint conditions are used to attach an expected description of the execution or recorded result of the field instance, that is, an expected description of the field value of the field, and the transfer rules are used to record the constraint conditions required to trigger the transfer direction of each node. The constraint conditions can be a logical combination based on multiple fields. For example, in a security service process, the constraint conditions of a node can be "complete customer communication" (the boolean value field is true) and "customer scanned assets have been determined" (a non-empty string field). The transfer rules are formulated based on the satisfaction of the constraint conditions, and can be that a single condition is satisfied to trigger the transfer (or called the "or" rule), or multiple conditions need to be satisfied simultaneously to trigger the transfer (or called the "and" rule).

[0159] Optionally, before the workflow engine transfers to the target process node, it determines all the constraint conditions defined in that node. This step is based on the status of the current workflow instance to confirm which constraint conditions need to be checked to evaluate the possibility of transfer. Subsequently, the workflow engine can, based on the field information associated with the target field, determine one by one whether the constraint conditions defined in the target process node are met. For example, if the file upload status of the "Customer Communication Result File" field is completed, then the corresponding constraint condition "Complete customer communication" is considered satisfied.

[0160] Optionally, after determining all the satisfied constraint conditions, the workflow engine can decide the transfer direction of the workflow instance node according to the transfer rules defined in the target process node. For example, in the security service process, if the "Communication Phase" sets a transfer rule with an "AND" logic, requiring both constraint conditions "Complete customer communication" and "Customer scanned assets determined" to be satisfied before transferring to the "Asset Scanning Phase", then the workflow engine will determine whether the transfer conditions are met based on the field information corresponding to these two conditions, and then decide whether the workflow instance should transfer to the next node.

[0161] It should be noted that by evaluating the satisfaction of constraint conditions based on the field information associated with the target field, and determining the node transfer direction according to the satisfied constraint conditions and transfer rules, the effective determination of the next pending process node in the workflow is achieved, thus realizing the automated and intelligent management of the process and improving the efficiency and reliability of workflow processing.

[0162] In an optional embodiment, the application process in this embodiment is exemplarily described. The application process of this embodiment may include the following steps:

[0163] (1) The process administrator creates a workflow template through the upper-layer service. Assume that the template name is set as the security service process template. After the template is defined, the subsequent development and implementation of such processes are equivalent to the process of creating a workflow instance;

[0164] (2) If a certain security service personnel (i.e., process participant) needs to carry out this security service process, at this time, the upper-layer service designates to create a workflow instance through the security service process template. The workflow instance can be graphically interacted at the upper-layer service end for the convenience of process participants to operate, and the viewing and operation of the workflow instance actually need the upper-layer service to use the SDK method provided by the workflow engine;

[0165] (3) This security service personnel can view and edit this workflow instance at the upper-layer service end;

[0166] (4) The security service personnel carry out offline work according to the task content of the first node. After completion, they perform process content operations on the upper-layer business end, and the upper-layer business end then transfers to the workflow engine SDK method for workflow instance operations.

[0167] The workflow engine SDK methods called by the upper-layer business during this period include: locating the current node, obtaining and viewing the entire current workflow, recording node field content / completing node field actions, workflow node transitions, etc.

[0168] (5) When the security service process proceeds to the next node, the security service personnel carry out work according to the task content of the current node. After completion, they perform process content operations on the upper-layer business end until the process is archived (for the workflow engine, the current node where this workflow instance is located is the end node).

[0169] In an optional embodiment, Figure 7 is a schematic diagram of an optional workflow according to an embodiment of the present invention. Figure 8 is a schematic diagram of an optional workflow template according to an embodiment of the present invention. As Figure 7 、 Figure 8 shown, taking the workflow as the security service process as an example, a process of an optional design of a workflow template in this embodiment is described. Optionally, the process participants of the security service process include security service personnel, etc. As Figure 7 shown, this security service process can be divided into three stages: a communication stage, an asset scanning stage, and a vulnerability repair stage. Each stage lists the tasks that security service personnel need to complete in Figure 7 . The three stages can correspond to creating three nodes. Optionally, first, the process administrator sorts out the manifestation methods of each task in the process management. For example, to complete the customer communication task, which belongs to the offline work of security service personnel, after the work is completed, content such as the handler, whether the customer communication task has been completed, and the customer communication result file should be recorded. Then, as Figure 8 shown, three node fields can be created in the first node to correspond to them. At the same time, because these contents belong to the record result type, the key-value pair type of field definition is selected to specify the type to correspond to them. As Figure 8 shown, the handler generally records text information such as the handler's name, and the text subtype of the key-value pair type can be selected to correspond to it; whether the customer communication task has been completed generally records yes or no, and the boolean value subtype of the key-value pair type can be selected to correspond to it; the customer communication result file is generally a file archiving action, and the upload attachment subtype of the action type can be selected to correspond to it.

[0170] For the task of "clarifying the customer's scanned assets, scanning time, and later communication methods", it is relatively clear and belongs to the type of recording results. Three recording results can be broken down, as Figure 8 shown. You can select a certain subtype in the key-value pair class to correspond to it. It should be particularly noted that the purpose of defining these three recording results through global fields rather than node fields is that these three fields need to be visible in Figure 8 Node 2 or Node 3 later. Their scope of action should not be limited to Node 1 only. Therefore, global fields are selected for definition, and then these three global fields are referenced in Node 1.

[0171] By decomposing each task according to the above ideas and converting the tasks into corresponding field definitions, one task can form multiple field definitions.

[0172] After having the field definitions, constraint conditions can be further formed, and then the transfer relationship definitions can be further formed. Still taking Node 1 as an example, two constraint conditions are formed here. The expected value of the node field for completing the customer communication task is true, and the expected result of the customer communication result document is that the action is completed. Further forming the transfer rule definition, the transfer rule is that after both of these two constraint conditions are met, it flows into Node 2 in the manual transfer mode.

[0173] Optionally, as Figure 8 shown, a node field of the trigger type, asset scanning, is defined in Node 3. From a functional perspective, asset scanning is a complex function and cannot be processed corresponding to the concretization type of the field definition of the workflow engine action class. Or rather, asset scanning is not a function that the workflow engine can provide and should provide. It cannot be promoted to the basic function class and packaged as a subtype of the action class like uploading attachments. After all, asset scanning only belongs to a small-class requirement scenario. Therefore, a node field of the trigger type can be selected to rely on the linkage of external systems to implement relevant functions.

[0174] Optionally, as Figure 8As shown, a node field of the receiver type is defined in Node 3 for customer repair result confirmation. An implicit assumption is attached here that the customer's confirmation of the repair result is not an action that can be manually confirmed by a security service personnel, and the process participant is a security service personnel who cannot manually record the customer's confirmation result, that is, this action cannot be processed through a field definition of the key-value pair class. At the same time, the customer's confirmation of the repair result is a logical function existing in the upper-level business. From the perspective of the workflow engine, the customer's confirmation of the repair result is an operation that can be linked with external services and cannot be completed by the workflow engine, and it does not belong to recording. Therefore, through the receiver definition, by reusing the existing logical function of the upper-level business for customer confirmation of repair results, the workflow engine only needs to wait for the signal of the customer's confirmation result.

[0175] Optionally, as Figure 8 shown, in the transfer relationship definition in Node 3, it includes a constraint condition that the expected value of the number of high-risk vulnerabilities is 0. However, the number of high-risk vulnerabilities is neither a node field of Node 3 nor a global field. The reason why it can be further defined as a constraint condition is that the trigger definition can declare the linkage result as a supplement to the node field definition, that is, the number of high-risk vulnerabilities is a linkage result of the asset scan trigger as a supplement to the node field definition, and the number of high-risk vulnerabilities is equivalent to the aforementioned associated target field. It should be noted that Figure 8 the relevant associated target fields are hidden, and only the target fields in the node are shown.

[0176] Figure 9 is a schematic diagram of an optional trigger according to an embodiment of the present invention Figure 2 , as Figure 9 shown, the linkage interface URL (necessary parameters for message communication) in the trigger declares the interface for asset scanning. The linkage result definition declares that the vulnerability details result in the return result of the asset scanning interface can be used as an associated target field of the text subtype of the key-value pair class, and the number of high-risk vulnerability results can be used as an associated target field of the integer subtype of the key-value pair class, so as to bind the associated target field to Node 2 where the trigger is located.

[0177] Figure 10 is a schematic diagram of an optional receiver according to an embodiment of the present invention Figure 2 , as Figure 10 shown, the event ID sent by the user through the upper-level business is declared as "a certain customer confirms the vulnerability repair result". The linkage result definition of the receiver declares that the "customer feedback result" in the external business logic data corresponding to "a certain customer confirms the vulnerability repair result" can be used as an associated target field of the text subtype of the key-value pair class, so as to bind the associated target field to Node 3 where the receiver is located.

[0178] As can be seen, the solution provided by the present application achieves the purpose of setting actions that support external linkage execution in a workflow to process the workflow, thereby achieving the technical effect of meeting the functional requirements during workflow processing, and further solving the technical problem that the functions of workflow templates in the related art are single and cannot meet the functional requirements during workflow processing.

[0179] Embodiment 2

[0180] According to an embodiment of the present invention, an embodiment of a processing device for a workflow is provided, wherein Figure 11 is a schematic diagram of an optional processing device for a workflow according to an embodiment of the present invention, as Figure 11 shown, the device includes:

[0181] An acquisition module 1101, configured to acquire a workflow instance created based on a workflow template, wherein the workflow template includes at least one process node, at least some of the process nodes include target fields, and at least some of the target fields in the process nodes include first-type fields, the first-type fields are fields used to represent actions to be executed, and at least some of the actions to be executed depend on external system linkage execution;

[0182] A first determination module 1102, configured to determine a triggered target field in a target process node in the workflow instance;

[0183] A second determination module 1103, configured to, when the triggered target field is a first-type field, execute the action to be executed described by the target field, and determine field information associated with the target field based on execution information;

[0184] A third determination module 1104, configured to determine a node transition direction based on the field information associated with the target field to determine a next target process node in the workflow instance.

[0185] It should be noted that the above acquisition module 1101, first determination module 1102, second determination module 1103, and third determination module 1104 correspond to steps S101 to S104 in the above embodiment. The examples and application scenarios implemented by the four modules and the corresponding steps are the same, but are not limited to the content disclosed in the above Embodiment 1.

[0186] Optionally, the first determination module 1102 further includes: a first determination sub-module, configured to determine the triggered target field based on the interaction information of the user with respect to the target process node in the workflow instance, or a second determination sub-module, configured to determine the triggered target field based on the node change information of the target process node.

[0187] Optionally, the first type of fields includes first sub-type fields, and the first sub-type fields are fields used to characterize actions to be executed that depend on internal execution within the system. Among them, the second determination module further includes: a third determination sub-module, configured to, when the triggered target field is a first sub-type field, determine the functional logic corresponding to the action to be executed described by the target field; a first execution sub-module, configured to execute the action to be executed described by the target field based on the functional logic.

[0188] Optionally, the first type of fields includes second sub-type fields, and the second sub-type fields are fields used to characterize actions to be executed that depend on linkage with an external system. Among them, the second determination module further includes: a second execution sub-module, configured to, when the triggered target field is a second sub-type field, execute the action to be executed through an execution unit associated with the second sub-type field, and determine the field information associated with the target field based on the execution information, where the execution unit executes the action to be executed depending on a manner of sending information to an external interface and / or a manner of receiving information sent by the external interface.

[0189] Optionally, the second execution sub-module further includes: a first sending unit, configured to, when the execution unit is a trigger, send a target request to the external interface through the trigger to request the external interface to execute the action to be executed; a first receiving unit, configured to receive the execution result fed back by the external interface, and determine the field values of at least one associated target field corresponding to the target field based on the execution result; a first determination unit, configured to determine the field values of at least one associated target field as the field information associated with the target field.

[0190] Optionally, the second execution sub-module further includes: a second receiving unit, configured to, when the execution unit is a receiver, receive the event execution result sent by the external interface and parse the event execution result to obtain a parsing result to complete the action to be executed; a second determination unit, configured to determine the field values of at least one associated target field corresponding to the target field based on the parsing result; a third determination unit, configured to determine the field values of at least one associated target field as the field information associated with the target field.

[0191] Optionally, the second execution sub-module further includes: a second sending unit, configured to, when the execution unit is a notifier, send target information to the external interface to complete the action to be executed; a fourth determination unit, configured to determine the field information associated with the target field based on the execution information of the notifier.

[0192] Optionally, the target fields in at least some of the process nodes include second - type fields, where the second - type fields are fields used to describe items to be recorded. Further, the processing device of the workflow further includes: a fourth determination module, configured to, when the triggered target field is a second - type field, determine the field value of the target field based on the interaction information of the target user with respect to the target process node in the workflow instance, and determine the field value as the field information associated with the target field.

[0193] Optionally, the third determination module further includes: a fourth determination sub - module, configured to determine the constraint conditions in the target process node; a fifth determination sub - module, configured to determine the satisfied constraint conditions in the target process node based on the field information associated with the target field; a sixth determination sub - module, configured to determine the node transition direction based on the satisfied constraint conditions in the target process node and the transition rules in the target process node, where the transition rules are used to record the constraint conditions required to trigger the transition directions of each node.

[0194] Embodiment 3

[0195] According to another aspect of the embodiments of the present invention, there is also provided a computer - readable storage medium storing a computer program, where the computer program is configured to execute the above - described workflow processing method when running.

[0196] Embodiment 4

[0197] According to another aspect of the embodiments of the present invention, there is also provided an electronic device, where Figure 12 is a schematic diagram of an optional electronic device according to the embodiments of the present invention, as Figure 12 shown, the electronic device includes one or more processors; a memory for storing one or more programs, when the one or more programs are executed by the one or more processors, enabling the one or more processors to implement running the program, where the program is configured to execute the above - described workflow processing method when running.

[0198] The above - mentioned serial numbers of the embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0199] In the above - mentioned embodiments of the present invention, the descriptions of the respective embodiments have their own emphases. For parts not detailed in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0200] In several embodiments provided by the present application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only illustrative. For example, the division of units can be a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the couplings or direct couplings or communication connections shown or discussed with each other can be through some interfaces. The indirect couplings or communication connections of units or modules can be in electrical or other forms.

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

[0202] In addition, in each embodiment of the present invention, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0203] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in each embodiment of the present invention. The aforementioned storage medium includes: USB flash drives, read-only memories (ROMs), random access memories (RAMs), mobile hard disks, magnetic disks, or optical discs, etc., which can store program codes.

[0204] The above is only the preferred embodiment of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.

Claims

1. A workflow processing method, characterized in that: include: Acquire a workflow instance created based on a workflow template, wherein the workflow template includes at least one process node, at least some of the process nodes include target fields, and at least some of the target fields in the process nodes include first-category fields, the first-category fields are fields used to characterize actions to be performed, and at least some of the actions to be performed depend on the linkage execution of an external system; Determine a target field to be triggered in a target process node in the workflow instance; In the case where the triggered target field is the first type of field, executing the to-be-executed action described by the target field, and determining field information associated with the target field based on the execution information; The node flow direction is determined based on the field information associated with the target field to determine the next target process node in the workflow instance.

2. The method according to claim 1, characterized in that Determining a target field to be triggered in a target process node in the workflow instance includes: Determine the triggered target field based on the user's interaction information with respect to the target process node in the workflow instance, or, Based on the node change information of the target process node, a triggered target field is determined.

3. The method according to claim 1, characterized in that The first category field includes a first subcategory field, and the first subcategory field is a field used to characterize an action to be performed inside a dependent system, wherein executing the action to be performed described by the target field includes: In a case where the triggered target field is the first subcategory field, determining a functional logic corresponding to the to-be-executed action described by the target field; Execute the action to be performed described by the target field based on the functional logic.

4. The method according to claim 1, characterized in that The first category field includes a second subcategory field, and the second subcategory field is a field used to represent an action to be executed in conjunction with an external system, wherein the action to be executed described by the target field is executed, and field information associated with the target field is determined based on the execution information, including: In the case where the triggered target field is the second subclass field, the action to be executed is executed by the execution unit associated with the second subclass field, and the field information associated with the target field is determined based on the execution information, wherein the execution unit depends on a method of sending information to an external interface and / or a method of receiving information sent by an external interface to execute the action to be executed.

5. The method according to claim 4, characterized in that Executing the to-be-executed action by the execution unit associated with the second subclass field, and determining the field information associated with the target field based on the execution information, including: In the case where the execution unit is a trigger, sending a target request to an external interface through the trigger to request the external interface to execute the action to be executed; receiving an execution result fed back by the external interface, and determining a field value of at least one associated target field corresponding to the target field based on the execution result; The field value of the at least one associated target field is determined as the field information associated with the target field.

6. The method according to claim 4, characterized in that Executing the to-be-executed action by the execution unit associated with the second subclass field, and determining the field information associated with the target field based on the execution information, including: In the case where the execution unit is a receiver, the event execution result sent by the external interface is received through the receiver, and the event execution result is parsed to obtain a parsing result to complete the action to be executed; Based on the parsing result, a field value of at least one associated target field corresponding to the target field is determined; and the field value of the at least one associated target field is determined as field information associated with the target field.

7. The method according to claim 4, characterized in that Executing the to-be-executed action by the execution unit associated with the second subclass field, and determining the field information associated with the target field based on the execution information, including: In the case where the execution unit is a notifier, sending target information to an external interface to complete the action to be executed; The field information associated with the target field is determined based on the execution information of the notifier.

8. The method according to claim 4, characterized in that The target fields in at least some of the process nodes include second-category fields, where the second-category fields are fields for describing items to be recorded, wherein after determining the target fields triggered in the target process nodes in the workflow instance, the method further includes: When the triggered target field is the second type of field, the field value of the target field is determined based on the target user's interaction information with respect to the target process node in the workflow instance, and the field value is determined as the field information associated with the target field.

9. The method according to claim 1, characterized in that: Determining the node flow direction based on the field information associated with the target field includes: Determining constraints in the target process node; Determining a constraint condition satisfied in the target process node based on field information associated with the target field; The node flow direction is determined based on the constraints satisfied in the target process node and the flow rules in the target process node, wherein the flow rules are used to record the constraints that need to be satisfied to trigger the flow direction of each node.

10. A workflow processing device, characterized in that: include: An acquisition module, used to acquire a workflow instance created based on a workflow template, wherein the workflow template includes at least one process node, at least some of the process nodes include target fields, and at least some of the target fields in the process nodes include first-category fields, the first-category fields are fields used to characterize actions to be performed, and at least some of the actions to be performed depend on the linkage execution of an external system; A first determination module, used to determine a target field to be triggered in a target process node in the workflow instance; A second determination module is used to execute the to-be-executed action described by the target field when the triggered target field is the first type of field, and determine the field information associated with the target field based on the execution information; The third determination module is used to determine the node flow direction based on the field information associated with the target field, so as to determine the next target process node in the workflow instance.

11. An electronic device, characterized in that: The electronic device includes one or more processors; A memory for storing one or more programs, which, when executed by the one or more processors, enables the one or more processors to run the programs, wherein the programs are configured to execute the workflow processing method described in any one of claims 1 to 9 when run.

Images