Non-templated business flow conversion method and device based on zero-process gateway

Abstract

The embodiment of the application provides a non-templated business flow conversion method and device based on a zero-process gateway, the method is that a process configuration module encapsulates approval content and a business type as starting metadata and creates a starting node in a graph database, creates a first node for each first approval subject, and sends the starting metadata to the first node based on a first zero-process gateway edge relationship between the starting node and the first node; determines a second approval subject and first metadata of the first node based on first approval information of the first approval subject and the starting metadata, creates a second node for the second approval subject, and sends the first metadata to the second node based on a second zero-process gateway edge relationship between the first node and the second node; creates an ending node based on second approval information indicating that the second approval subject indicates that the flow conversion ends, sends the second approval information and the first metadata to the ending node as sub-flow conversion results of a sub-flow conversion path, and the ending node determines a flow conversion result based on a plurality of sub-flow conversion results.

Description

Technical Field

[0001] This application relates to the field of office automation technology, specifically to a non-template-based business flow method and apparatus based on a zero-process gateway. Background Technology

[0002] Traditional business process management systems rely on pre-configured, rigid process models to drive business workflows. During the process design phase, the order of nodes, the transmission path, and the matching rules for approval executors must be fixed. During system operation, they only support users submitting documents according to predetermined linear or simplified branch templates, and are only suitable for office tasks with fixed steps and standardized workflow logic, such as leave approvals and routine financial reimbursements. However, in complex government and enterprise office scenarios, most official documents and comprehensive business processes exhibit significant unstructured workflow characteristics. Taking document co-signing and approval as an example, documents need to circulate among multiple responsible persons, and dynamically select whether to transfer to the lead department, copy other responsible entities, or directly archive them based on real-time approval content, creating a flexible workflow requirement with multiple paths. The existing rigid process architecture is ill-suited for this type of business, exhibiting several technical shortcomings: Firstly, the workflow path is fixed, failing to support free and unordered connections between nodes; adding temporary approval steps requires re-editing the workflow template, resulting in high modification costs and long adjustment cycles. Secondly, parallel co-signing processing is inefficient; when multiple departments approve simultaneously, all steps must be completed before proceeding to the next, and delays in a single department's processing can impede the entire process. Thirdly, dynamic adaptability is weak; after the workflow template is released, the workflow logic cannot be dynamically changed based on real-time user business assessments, making it difficult to match unstructured office scenarios with fixed business objectives and uncertain workflow paths. Therefore, it is evident that the existing business approval process suffers from low approval efficiency, high costs for process expansion and adjustment, complex modeling operations, and an inability to dynamically change workflow logic during operation. It cannot adapt to unstructured office businesses with dynamically changing paths, such as government and enterprise document co-signing, and lacks overall process flexibility, failing to meet the actual usage requirements of flexible approval, free transfer, and parallel independent workflow in complex scenarios. Summary of the Invention

[0003] To address the problems in the prior art, this application provides a non-template-based business workflow method and apparatus based on a zero-process gateway, which can improve approval efficiency and flexibility.

[0004] To solve at least one of the above problems, this application provides the following technical solution: Firstly, this application provides a non-template-based business workflow method based on a zero-process gateway, comprising: reading the approval content, business type, and at least one first approval entity of the business to be processed from a business database; a workflow configuration module encapsulating the approval content and the business type into initial metadata and creating a start node in a graph database; for each first approval entity, creating a first node in the graph database and constructing a first non-process gateway edge relationship between the start node and the first node; sending the initial metadata to the first node based on the first non-process gateway edge relationship; and upon obtaining the first approval information of the first approval entity, determining a second approval entity based on the first approval information and the initial metadata. First metadata of the first node is constructed. A second node is created for the second approval subject in the graph database. A second process-free gateway edge relationship is constructed between the first node and the second node. The first metadata is sent to the second node based on the second process-free gateway edge relationship. When the second approval information of the second approval subject indicates the end of the process, an end node is created in the graph database. A third process-free gateway edge relationship is constructed between the second node and the end node. The second approval information and the first metadata are sent to the end node based on the third process-free gateway edge relationship, so that the end node can obtain the sub-process result corresponding to a sub-process path. The process result is determined based on multiple sub-process results.

[0005] In some embodiments, before reading the approval content, business type, and at least one first approval entity of the business to be transferred from the business database, the method further includes: creating the approval content of the business to be transferred by a creating entity; querying multiple initial first approval entities with a transfer-out type entity connection relationship to the creating entity from a subject relationship database based on the creating entity's creation identifier, wherein the subject relationship database stores subject connection relationships between pairs of entities, the subject connection relationships including transfer-out type entity connection relationships from a first entity to a second entity and transfer-in type entity connection relationships from a first entity to the first entity; selecting at least one first approval entity from the multiple initial first approval entities using the creating entity, or obtaining a first historical approval process based on the business type, obtaining multiple historical first approval entities from the first historical approval process, selecting at least one first approval entity included in the multiple historical first approval entities from the multiple initial first approval entities, and encapsulating at least one first approval entity, the approval content, and the business type into a business to be transferred and storing it in the business database.

[0006] In some embodiments, the step of creating a first node in the graph database for each first approval subject, constructing a first process-free gateway edge relationship between the starting node and the first node, and sending the starting metadata to the first node based on the first process-free gateway edge relationship includes: for each first approval subject, extracting the subject identifier, approval authority, and flow marker of the first approval subject; determining whether the first approval subject has approval authority for the business type based on the approval authority; if so, using the subject identifier as the first node identifier of the first node, and using the approval authority and the flow marker as node attributes of the first node, to create the first node in the graph database. If the first approval entity does not have the approval authority for the business type, then the first node of the first approval entity is not created; the starting identifier of the starting node is obtained, and a first entity connection relationship is constructed between the starting identifier and the first node identifier, so as to create a first unconditionally driven, process-free gateway edge relationship in the graph database based on the first entity connection relationship, from the starting node to the first node; the starting node reads the first node identifier from the first process-free gateway edge relationship, sends the starting metadata to the first node corresponding to the first node identifier, and updates the flow mark of the first node to "flowed" to indicate that the starting metadata has flowed to the first node.

[0007] In some embodiments, determining the second approval subject based on the first approval information and the initial metadata and constructing the first metadata of the first node includes: when the first node receives the initial metadata, it queries a plurality of initial second approval subjects with a transfer-out subject connection relationship with the first node from the subject relationship database based on the first node identifier of the first node; the first approval subject selects a second approval subject from the plurality of initial second approval subjects and performs approval processing on the initial metadata to obtain review information; the review information and the second approval subject are used as the first approval information; if the first approval information indicates that the second approval subject is empty, a second historical approval process containing the first approval subject is obtained based on the business type, and the second historical approval process is used as the first approval information. The system retrieves multiple historical second approval entities that are approved after the first approval entity. It selects a second approval entity from among the multiple initial second approval entities that is included in the multiple historical second approval entities. If there is no second historical approval process, it determines a threshold for the number of approval nodes for a single sub-processing path based on the business type. If the number of approval nodes for the sub-processing path is lower than the threshold, it selects a general approval entity from among the multiple initial second approval entities that can approve the business type to be processed, and uses this general approval entity as the second approval entity. If the number of approval nodes is not lower than the threshold, it uses the completion of approval as the second approval entity. The first approval information and the initial metadata are encapsulated into the first metadata of the first node.

[0008] In some embodiments, when the second approval information of the second approval entity indicates the end of the process, an end node is created in the graph database, a third process-free gateway edge relationship is constructed between the second node and the end node, and the second approval information and the first metadata are sent to the end node based on the third process-free gateway edge relationship, so that the end node obtains the sub-processing result corresponding to a sub-processing path, and determines the process result based on multiple sub-processing results, including: when the second node receives the first metadata, if no initial third approval entity with a transfer-out type entity connection relationship with the second node is found in the entity relationship database based on the second node identifier of the second node, then the process end is taken as the third approval entity; when the second approval entity is processing the approval, the third approval entity is selected as the process end, and it is regarded as the process end. The second approval information of the second approval subject indicates the end of the flow. If there is no end node for the business to be flowed in the graph database, an end node is created in the graph database. A third no-flow gateway edge relationship is constructed between the second node and the end node. The second approval subject that issued the indication of the end of the flow is taken as the target second approval subject. Based on the target second no-flow gateway edge relationship and the target third no-flow gateway edge relationship corresponding to the target second approval subject, and the target first no-flow gateway edge relationship corresponding to the target first node in the target second no-flow gateway edge relationship, a sub-flow path is formed. The first metadata and the second approval information received by the second node corresponding to the target second approval subject are encapsulated into a sub-flow result. The sub-flow result is sent to the end node so that the end node determines the flow result based on multiple sub-flow results.

[0009] In some embodiments, the method further includes: for each of the sub-flow paths, when the business to be flowed has not flowed to the end node on the sub-flow path, and the business to be flowed needs to be modified, the starting node performs sub-flow rollback processing to actively cancel the unfinished sub-flow path of the business to be flowed; when the approval subject corresponding to any approval node on the sub-flow path identifies an error in the approval content, the approval node performs rejection processing to return the business to be flowed to the starting node.

[0010] In some embodiments, the method further includes: for each of the sub-flow paths, if there are two target nodes with a bidirectional edge connection relationship on the sub-flow path, then the two target nodes are encapsulated into a merge node. In the merge node, the two target nodes can perform business flow processing multiple times until the review information of both target nodes indicates that the review has been passed. Then, the business to be flowed is flowed from the merge node to the next node. The bidirectional edge connection relationship means that, with one target node as a reference, there is a transfer-out subject connection relationship and a transfer-in subject connection relationship between the two target nodes at the same time.

[0011] Secondly, this application provides a non-template-based business workflow device based on a zero-process gateway, comprising: a creation unit, configured to read the approval content, business type, and at least one first approval subject of the business to be processed from a business database; a workflow configuration module encapsulates the approval content and the business type into initial metadata and creates a start node in a graph database; for each first approval subject, a first node is created in the graph database, and a first zero-process gateway edge relationship is constructed between the start node and the first node; and the initial metadata is sent to the first node based on the first zero-process gateway edge relationship; the creation unit is configured to determine a second approval subject based on the first approval information and the initial metadata when the first approval information of the first approval subject is obtained. The approval entity constructs the first metadata of the first node, creates a second node for the second approval entity in the graph database, constructs a second process-free gateway edge relationship between the first node and the second node, and sends the first metadata to the second node based on the second process-free gateway edge relationship; the flow unit is used to create an end node in the graph database when the second approval information of the second approval entity indicates the end of the flow, constructs a third process-free gateway edge relationship between the second node and the end node, and sends the second approval information and the first metadata to the end node based on the third process-free gateway edge relationship, so that the end node obtains the sub-flow result corresponding to a sub-flow path, and determines the flow result based on multiple sub-flow results.

[0012] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the non-template-based business flow method based on a zero-process gateway.

[0013] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the described non-template-based business flow method based on a zero-process gateway.

[0014] Fifthly, this application provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the steps of the described non-template-based business flow method based on a zero-process gateway.

[0015] As can be seen from the above technical solution, this application provides a non-template-based business flow method and apparatus based on a zero-flow gateway. This invention employs a non-template-based flow scheme using a zero-flow gateway combined with a graph database dynamic topology, abandoning the traditional pre-fixed rigid flow templates. It eliminates the need to pre-define node order, flow branches, and approval rules. The system dynamically generates a starting node and a first node after reading the review content, business type, and first approval subject. It determines the next review subject of the current node based on the approval information and business type of each node and creates a corresponding next node for that next review subject. Based on the non-template gateway edge relationship between the current node and the next node, the business flow to be processed is realized from the current node to the next node. In other words, this solution deduces the next approval subject and creates a new flow link in real time based on the approval feedback and business type of the approval subject corresponding to each node. During operation… The workflow can be freely expanded without modifying the process template, significantly reducing the cost and cycle of approval process adjustments. Each sub-workflow path is generated and advanced independently, and the results of each sub-workflow are then aggregated to generate the complete business workflow result. This breaks away from the limitation of traditional parallel signing, which requires all approvals to be completed before the process can proceed. It also avoids a single approval node slowing down the overall workflow and significantly improves the efficiency of simultaneous approval by multiple approval entities. The overall workflow relies on the edge of the workflow gateway to carry metadata and approval information transmission. There is no need to preset a large number of conditional branches and flow selection components, which simplifies the workflow modeling and configuration logic. The workflow direction can be dynamically adjusted as needed, adapting to unstructured office scenarios with uncertain paths, such as repeated approvals of government and enterprise documents and random transfers and archiving. This effectively solves the problems of insufficient flexibility and poor dynamic adaptation of traditional processes, improves workflow flexibility and approval efficiency, and is suitable for complex approval scenarios. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the non-template-based business flow method based on a zero-flow gateway in this application embodiment; Figure 2 This is a schematic diagram of the approval process for pending business transactions in an embodiment of this application. Figure 3 This is a schematic diagram of the approval process for another pending business in this application embodiment; Figure 4 This is a structural diagram of the non-template-based business flow device based on a zero-process gateway in this application embodiment. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0020] In view of the problems existing in the prior art, this application provides a non-template-based business flow method and apparatus based on a zero-flow gateway. It adopts a non-template-based flow scheme using a zero-flow gateway combined with a graph database dynamic topology, abandoning the traditional pre-fixed rigid flow templates. There is no need to pre-define node order, flow branches, and approval rules. After reading the review content, business type, and first approval subject, the system dynamically generates the starting node and the first node. Based on the approval information and business type of each node, the next approval subject of the current node is determined, and a corresponding next node is created for the next approval subject. Based on the non-template gateway edge relationship between the current node and the next node, the business flow to be processed is realized from the current node to the next node. In other words, this scheme deduces the next approval subject and creates a new flow link in real time based on the approval feedback and business type of the approval subject corresponding to each node. During operation... The workflow can be freely expanded without modifying the process template, significantly reducing the cost and cycle of approval process adjustments. Each sub-workflow path is generated and advanced independently, and the results of each sub-workflow are then aggregated to generate the complete business workflow result. This breaks away from the limitation of traditional parallel signing, which requires all approvals to be completed before the process can proceed. It also avoids a single approval node slowing down the overall workflow and significantly improves the efficiency of simultaneous approval by multiple approval entities. The overall workflow relies on the edge of the workflow gateway to carry metadata and approval information transmission. There is no need to preset a large number of conditional branches and flow selection components, which simplifies the workflow modeling and configuration logic. The workflow direction can be dynamically adjusted as needed, adapting to unstructured office scenarios with uncertain paths, such as repeated approvals of government and enterprise documents and random transfers and archiving. This effectively solves the problems of insufficient flexibility and poor dynamic adaptation of traditional processes, improves workflow flexibility and approval efficiency, and is suitable for complex approval scenarios.

[0021] To improve approval flexibility and efficiency, this application provides an embodiment of a non-template-based business workflow method based on a zero-process gateway. See [link to embodiment]. Figure 1 The non-template-based business flow method based on the zero-process gateway specifically includes the following: Step S110: Read the approval content, business type, and at least one first approval entity of the business to be processed from the business database. The process configuration module encapsulates the approval content and the business type into starting metadata and creates a start node in the graph database. For each first approval entity, create a first node in the graph database and construct a first process-free gateway edge relationship between the start node and the first node. Based on the first process-free gateway edge relationship, send the starting metadata to the first node.

[0022] The business database refers to a database that persistently stores basic information about business documents, such as business approval content, business type, business creator, business creation time, and approval entity. Businesses awaiting approval refer to those requiring approval. Approval content refers to the content requiring approval. Business type refers to the business type of the business that generates the approval content, such as the equipment procurement type for equipment procurement, the travel expense reimbursement type for travel expense reimbursement, the external contract type for external contracts, the official seal usage registration type for official seal usage approval, and the employee transfer type for employee transfer. The process configuration module is the system's underlying scheduling unit, responsible for data encapsulation, graph database node and edge creation, and message distribution. Initial metadata refers to standardized, encapsulated basic business messages with a unified transmission format, carrying the business type, approval content, and the first approval entity. The graph database uses nodes and directed edges to store topological relationships, used to dynamically generate approval links in real time, rather than pre-stored fixed approval flowcharts. The starting node is the unified starting point of each sub-processing path in the business awaiting approval, carrying the distribution capability of initial metadata. Each pending business transaction corresponds to only one start node and one end node. The first approval entity refers to the department or approver who conducts the first round of approval for the pending business transaction. The first node refers to the graph node in the graph database that maps to the first approval entity. The first gateway-free edge relationship refers to a directed edge that directly connects the start node to the first node. This directed edge itself does not carry branch judgment conditions, does not rely on the process gateway to complete route distribution, and directly relies on the pointing relationship of the directed edge to complete route distribution. There is no gateway access to the routing logic throughout the entire process.

[0023] For example, the pending business 1 includes two primary approval entities: a department manager and a finance specialist. This means that the business 1 needs to be initially distributed to the department manager and the finance specialist. When the process configuration module receives the two primary approval entities from the starting node, it constructs a primary node for each entity, such as primary node 1 for the department manager and primary node 2 for the finance specialist. Simultaneously, it constructs two primary non-gateway edges: starting node → primary node 1 and starting node → primary node 2. Neither edge is configured with approval, rejection, or amount threshold conditions, and no parallel gateway is set up for branching and merging. The starting node directly pushes the initial metadata to primary node 1 and primary node 2 based on the directions of the two edges, without the need for a gateway component to relay the routing.

[0024] In some examples, before reading the approval content, business type, and at least one first approval entity of the business to be transferred from the business database in step S110, the method further includes: creating the approval content of the business to be transferred by the creating entity; querying multiple initial first approval entities with a transfer-out type entity connection relationship to the creating entity from the entity relationship database based on the creation identifier of the creating entity; wherein the entity relationship database stores entity connection relationships between pairs of entities, including transfer-out type entity connection relationships from the first entity to the second entity and transfer-in type entity connection relationships from the first entity to the first entity; selecting at least one first approval entity from the multiple initial first approval entities using the creating entity, or obtaining a first historical approval process based on the business type, obtaining multiple historical first approval entities from the first historical approval process, selecting at least one first approval entity included in the multiple historical first approval entities from the multiple initial first approval entities, and encapsulating at least one first approval entity, the approval content, and the business type into a business to be transferred and storing it in the business database.

[0025] Here, "Creating Entity" refers to the person or department that initiates the pending business process. "Entity Relationship Database" is a database that independently stores organizational permission associations, recording the transferable relationships between two departments or two individuals. "Transfer-out Entity Connection Relationship" refers to the forward transfer permission that can be transferred from Approving Entity A to Approving Entity B after Approval by Approving Entity A. "Transfer-in Entity Connection Relationship" refers to the reverse association that Approving Entity B can receive pending business processes transferred from Approving Entity A. "Initial First Approving Entity" refers to the approving entity automatically matched based on the entity relationships in the entity relationship database. "First Historical Approval Process" refers to the complete record of past approval links for the same business type.

[0026] For example, Entity 1 initiates an equipment procurement request. The business type of this equipment procurement request is equipment procurement. The process configuration module queries the entity relationship database to find that the initial first approval entities that can be transferred from Entity 1 are the department head and the procurement specialist. The process configuration module retrieves multiple historical approval processes for the equipment procurement type. In these multiple historical approval processes, the first approval entities for the first round of equipment procurement approval are the department head, the procurement specialist, and the team leader, respectively. Based on the historical first approval entities, the module automatically selects the department head and the procurement specialist from the initial first approval entities as the first approval entities.

[0027] Therefore, by pre-establishing inter-entity flow relationships through the entity relationship database, and automatically matching compliant candidates with the initial first approval entity based on the created entity identifier, the range of selectable approvers is limited from the source, avoiding illegal approval links without flow permissions. Simultaneously, it provides two approver selection modes: manual selection and intelligent matching of historical processes of the same business type. It extracts only historically high-frequency approval roles from the compliant candidate set, balancing operational flexibility with the reuse of historical approval experience. Finally, the approval content, business type, and the selected first approval entity are uniformly encapsulated into the database, forming standardized business data to be flowed. This provides a regular and reliable data source for subsequent dynamic generation of nodes in the graph database and flow edges without process gateways. The entire selection logic does not require preset fixed process templates; changes in organizational structure or flow permissions only require updating the entity relationship database to automatically adapt to the first-round approver recommendation rules, significantly reducing the process configuration and iterative maintenance costs for various unstructured businesses. Furthermore, by selecting the first approval entity from multiple initial first approval entities based on the historical approval entity determined by the business type, the system automatically selects the first approval entity. This eliminates the need for the entity to select the first approval entity from multiple initial first approval entities when creating the entity. In other words, when the entity does not need to select the first approval entity, it provides a pre-selection option for the first approval entity. The entity can determine the first approval entity with a single click, which greatly reduces the approval operation for the entity and the risk of the entity mistakenly selecting the first approval entity from multiple initial first approval entities. This improves the accuracy and efficiency of the approval process and enhances the user approval experience.

[0028] Specifically, in the aforementioned step S110, the step of creating a first node in the graph database for each of the first approval entities, constructing a first process-free gateway edge relationship between the starting node and the first node, and sending the starting metadata to the first node based on the first process-free gateway edge relationship includes: for each of the first approval entities, extracting the entity identifier, approval authority, and flow marker of the first approval entity; determining whether the first approval entity has approval authority for the business type based on the approval authority; if so, using the entity identifier as the first node identifier of the first node, and using the approval authority and the flow marker as node attributes of the first node, in order to create a first node in the graph database. If the first approval entity does not have the approval authority for the business type, then the first node of the first approval entity will not be created; obtain the starting identifier of the starting node, construct a first entity connection relationship between the starting identifier and the first node identifier, and create a first unconditionally driven, process-free gateway edge relationship in the graph database based on the first entity connection relationship, from the starting node to the first node; the starting node reads the first node identifier from the first process-free gateway edge relationship, sends the starting metadata to the first node corresponding to the first node identifier, and updates the flow mark of the first node to "flowed" to indicate that the starting metadata has flowed to the first node.

[0029] Among them, the subject identifier refers to the unique identifier of the approving subject. The approving subject is not limited to any particular approval subject; it can be the first or second approving subject. Approval authority refers to whether the approving subject has the qualification to review the corresponding business type. The flow marker is a node status field, marked "Not Flown," "Flowed," or "Under Review." "Not Flown" indicates that the business to be flowed is currently at the current node, possibly unreviewed or reviewed but not yet flowed out. "Under Review" indicates that the current node is reviewing the business to be flowed out. "Flowed" indicates that the business to be reviewed has been flowed out from the current node. Node attributes refer to the attached information bound to the graph node; approval authority and flow markers are stored here. A non-conditionally driven, process-free gateway edge refers to an edge that does not carry branch judgment logic and does not require a gateway for routing; data is directly transmitted based on the edge direction. The start identifier is the unique identifier of the starting node.

[0030] Therefore, by adding a secondary verification mechanism for business permissions to the selected first approval entities, approval entities without the corresponding business type review qualifications are automatically filtered out, and invalid graph nodes are not generated. This avoids workflow errors caused by unauthorized personnel participating in the approval process and reduces the storage resource consumption caused by invalid topologies in the graph database. Structured nodes are constructed using entity identifiers, approval permissions, and workflow markers as node attributes, enabling one-to-one binding of approval entities, permission status, and graph nodes, facilitating subsequent workflow status identification and permission verification. A first, unconditional workflow gateway edge is constructed based on the start identifier and the first node identifier, eliminating the need for traditional workflow gateway condition judgment operations and directly relying on edge pointers to complete the initial metadata distribution, improving the efficiency of parallel document issuance. The workflow marker of the first node is updated synchronously to visualize the workflow link status, accurately distinguishing between distributed and undistributed nodes. No preset workflow templates or gateway branch configurations are required throughout the process, ensuring compliance, lightweight design, and traceability of the workflow topology while enabling parallel first-round approval for multiple entities.

[0031] Step S120: When the first approval information of the first approval subject is obtained, the second approval subject is determined based on the first approval information and the starting metadata, and the first metadata of the first node is constructed. A second node is created for the second approval subject in the graph database, and a second process-free gateway edge relationship is constructed between the first node and the second node. The first metadata is sent to the second node based on the second process-free gateway edge relationship.

[0032] The first approval information refers to the review operation data submitted by the first approval entity, including review opinions and the selected next-level approval entity. The review opinions may include whether the review was approved or not, the reasons for the disapproval, and suggested modifications. The second approval entity refers to the next-level approval entity after the first approval entity has completed its approval process. The first metadata refers to the new transmission message that integrates the initial metadata with the first-round approval opinions from the first approval entity. The second node refers to the graph node that maps to the second approval entity. The second process-free gateway edge relationship refers to the directly connected directed edges from the first node to the second node.

[0033] Specifically, in the aforementioned step S120, determining the second approval subject based on the first approval information and the initial metadata and constructing the first metadata of the first node includes: when the first node receives the initial metadata, it queries the subject relationship database based on the first node identifier of the first node to find multiple initial second approval subjects that have a transfer-out subject connection relationship with the first node; the first approval subject selects a second approval subject from the multiple initial second approval subjects and performs approval processing on the initial metadata to obtain review information; the review information and the second approval subject are used as the first approval information; if the first approval information indicates that the second approval subject is empty, a second historical approval process containing the first approval subject is obtained based on the business type, and the second historical approval process is used as the first approval information. In the batch process, multiple historical second approval entities that are approved after the first approval entity are obtained. A second approval entity included in the multiple historical second approval entities is selected from the multiple initial second approval entities. If there is no second historical approval process, the number of approval nodes for a single sub-flow path is determined based on the business type. If the number of approval nodes for the sub-flow path is lower than the number of approval nodes, a general approval entity that can approve the business type to be flowed is selected from the multiple initial second approval entities, and the general approval entity is used as the second approval entity. If the number of approval nodes is not lower than the number of approval nodes, the approval is completed and the second approval entity is used. The first approval information and the starting metadata are encapsulated into the first metadata of the first node.

[0034] Here, "initial second approval entity" refers to the next-level candidate approval entity of the first approval entity obtained from the entity relationship database. "Second historical approval process" refers to the complete historical approval chain of the current first approval entity within the historical approval process of the business type. "Approval node number threshold" refers to the minimum number of approval nodes allowed in a single sub-flow path; an approval node is a node in the sub-flow path excluding the start and end nodes. "General approval entity" refers to an approval entity suitable for all business types, or an approval entity suitable for multiple business types, including the business type to be processed.

[0035] For example, the first node in the equipment procurement process is the department head node. After receiving the initial metadata, the department head node queries the entity relationship database based on its own node identifier to obtain the initial second approval entities that the department head node can transfer to, which are the procurement specialist and the finance specialist. If the department head does not manually select the next approval entity during the approval process, the second approval entity in the first approval information is empty. The system retrieves the second historical approval process for the equipment procurement type that includes the department head, extracts the subsequent approval entity of the department head node in the history as the procurement specialist, and matches the procurement specialist as the second approval entity from the initial second approval entities. The system integrates and encapsulates the department head's approval opinion, the selected procurement specialist, and the original initial metadata into the first metadata, which is then sent to the second node corresponding to the procurement specialist. If there is no corresponding historical approval process, and the current sub-flow path has only 1 approval node, which is less than the preset threshold of 3 approval nodes, then the general approval entity, the general manager, is automatically matched as the second approval entity. If the current path already has 3 approval nodes, reaching the threshold, then the approval is directly determined to end.

[0036] Therefore, this solution constructs a three-tiered, progressive automatic matching mechanism for the second approval entity, consisting of manual selection, historical process matching, and path threshold fallback. This enables fully automated intelligent replacement of lower-level approvers in non-template-based workflow scenarios. First, it dynamically filters compliant lower-level candidate approval entities based on the entity transfer relationship, ensuring the workflow always conforms to organizational authority specifications. When the approval entity does not manually specify the next approval node from the lower-level candidate approval entities, it automatically reuses historical approval process experience for the same business type to accurately match compliant historical successor approval entities. In new business scenarios without historical processes for reference, it further adaptively determines the workflow strategy through an approval node number threshold. If the path is too short, it automatically supplements with a general approval entity to ensure approval integrity; if the path is too long, it automatically terminates the workflow to avoid redundancy and delays. Finally, it integrates and encapsulates the approval and review information with the original starting metadata into first metadata, enabling incremental retention and iterative updates of approval data at each level. The entire process does not rely on fixed process templates or preset branch rules, effectively solving the technical problems of easy interruption, non-standardized links, and lack of available processes for new businesses in traditional non-template approval workflows. This greatly improves the integrity, intelligence, and adaptability of dynamic business workflows. Furthermore, by selecting a second approval entity from multiple initial second approval entities based on the historical approval entity determined by the business type, the system automatically selects the second approval entity. This eliminates the need for approvers to choose from multiple initial second approval entities, providing them with pre-selected options. Approvers can then confirm the second approval entity with a single click, significantly reducing the approval process and minimizing the risk of mistakenly selecting the second approval entity from multiple initial options. This improves approval accuracy and efficiency while enhancing the user approval experience.

[0037] Step S130: When the second approval information of the second approval subject indicates the end of the flow, an end node is created in the graph database, a third process-free gateway edge relationship is constructed between the second node and the end node, and the second approval information and the first metadata are sent to the end node based on the third process-free gateway edge relationship, so that the end node can obtain the sub-flow result corresponding to a sub-flow path, and the flow result is determined based on multiple sub-flow results.

[0038] The second approval information refers to the review operation data submitted by the second approval entity, including review opinions and the selected next-level approval entity. Review opinions may include approval (passed), disapproved, the reasons for disapproval, and suggested modifications. The third, gateway-free edge relationship refers to the direct connection between the final approval node and the end node. A sub-flow path refers to a complete and independent approval link from the start node to the end node. A sub-flow result refers to the complete set of approval data for a single independent approval link. The flow result refers to the final approval conclusion regarding the pending business, output by the end node aggregating all parallel sub-flow paths.

[0039] Specifically, in step S130 above, when the second approval information of the second approval entity indicates the end of the process, an end node is created in the graph database, a third process-free gateway edge relationship is constructed between the second node and the end node, and the second approval information and the first metadata are sent to the end node based on the third process-free gateway edge relationship, so that the end node obtains the sub-processing result corresponding to a sub-processing path, and determines the process result based on multiple sub-processing results, including: when the second node receives the first metadata, if no initial third approval entity with a transfer-out type entity connection relationship with the second node is found in the entity relationship database based on the second node identifier of the second node, then the process end is taken as the third approval entity; when the second approval entity is processing the approval, the third approval entity is selected as the process end. If the second approval information of the second approval subject is considered to indicate the end of the flow, and there is no end node for the business to be flowed in the graph database, an end node is created in the graph database. A third process-free gateway edge relationship is constructed between the second node and the end node. The second approval subject that issued the indication of the end of the flow is taken as the target second approval subject. Based on the target second process-free gateway edge relationship and the target third process-free gateway edge relationship corresponding to the target second approval subject, and the target first process-free gateway edge relationship corresponding to the target first node in the target second process-free gateway edge relationship, a sub-flow path is formed. The first metadata and the second approval information received by the second node corresponding to the target second approval subject are encapsulated into a sub-flow result. The sub-flow result is sent to the end node so that the end node determines the flow result based on multiple sub-flow results.

[0040] The third approval body refers to the next level approval body after the second approval body.

[0041] For example, such as Figure 2 As shown, when the next node after the start node is the draft node, and the next nodes after the draft node are review node 1 and review node 2, review node 1 indicates the end of review after review. At this time, the next node after review node 1 is the end node. After review node 2, the next node to continue review is review node 3. After review node 3, the next node to continue review is review node 3. At this time, review node 3 points to the end node. The start node - review node 1 - end node is the first sub-flow path. The review information of each review node on the first sub-flow path and the corresponding starting metadata are the first sub-flow result. The start node - review node 2 - review node 3 - end node is the second sub-flow path. The review information of each review node on the second sub-flow path and the corresponding starting metadata are the second sub-flow result.

[0042] Therefore, by setting dual-stage termination judgment logic, the system supports automatic termination based on the absence of lower-level review subjects in the subject relationship database, and also allows the approval subject to manually trigger the termination of the process, adapting to various business termination scenarios. Each business to be terminated generates only a unique termination node, and each final-level approval node is directly connected to the termination node through an unconditional third-party process-free gateway edge, eliminating the need to configure a parallel merging gateway to complete multi-path aggregation and reducing gateway merging computation overhead. Each independent sub-process path is automatically and completely restored based on the process-free gateway edges at each level, and the results of each sub-process are encapsulated separately to achieve data isolation and storage for multiple parallel paths, facilitating individual tracing of a single approval link. The final business process conclusion is generated by a unified termination node that summarizes all sub-process results, naturally adapting to multi-branch parallel approval scenarios. The entire process relies on a graph database to dynamically construct the termination topology, without depending on preset process templates and merging branch configurations. While achieving independent multi-path flow and unified aggregation and archiving, it simplifies the parallel approval termination logic and reduces the computation and configuration costs of the process engine.

[0043] In some embodiments, the method further includes: for each of the sub-flow paths, when the business to be flowed has not flowed to the end node on the sub-flow path, and the business to be flowed needs to be modified, the starting node performs sub-flow rollback processing to actively cancel the unfinished sub-flow path of the business to be flowed; when the approval subject corresponding to any approval node on the sub-flow path identifies an error in the approval content, the approval node performs rejection processing to return the business to be flowed to the starting node.

[0044] Among them, sub-flow rollback processing refers to the entity creating the pending business actively canceling all incomplete approval sub-flow links of the pending business. Rejection processing refers to the approving entity actively canceling the entire incomplete approval sub-flow link. If the approver discovers an error in the document, they reject it and return it to the business initiation node. The target approval node is the node whose approval opinion indicates that the approval is not approved; the approval node is a node on the aforementioned sub-flow path. The approving entity is the approving entity mapped to the approval node; for example, the first node maps to the first approving entity. If the approval node is the first node, then the approving entity is the first approving entity.

[0045] Therefore, two differentiated workflow error correction mechanisms are set up to adapt to two business correction scenarios: one where the creator actively cancels the workflow, and the other where the approver verifies and finds errors. The creator can initiate a sub-flow rollback through the start node, which can terminate all parallel sub-flow paths at once and shut down incomplete approval links in batches, making the operation highly efficient. When the approval node triggers rejection processing, the workflow to be processed is directly rolled back to the unified start node on the sub-flow path corresponding to the approval node, which facilitates error verification by the creator and allows the creator to determine whether to centrally modify the original approval content. The entire rollback and single sub-flow path rejection logic relies on the generated forward workflow-free gateway edge topology to achieve workflow status control. There is no need to configure additional rollback gateways, reverse workflow edges, and rollback branch templates. It adapts to the zero-flow gateway non-template workflow architecture, improves business fault tolerance capabilities with a lightweight topology control method, and enhances the convenience of dynamic approval content modification and cancellation operations.

[0046] In some embodiments, the method further includes: for each of the sub-flow paths, if there are two target nodes with a bidirectional edge connection relationship on the sub-flow path, then the two target nodes are encapsulated into a merge node. In the merge node, the two target nodes can perform business flow processing multiple times until the review information of both target nodes indicates that the review has been passed. Then, the business to be flowed is flowed from the merge node to the next node. The bidirectional edge connection relationship means that, with one target node as a reference, there is a transfer-out subject connection relationship and a transfer-in subject connection relationship between the two target nodes at the same time.

[0047] In this context, a bidirectional edge connection means that target node A forwards the business to be processed to target node B, and target node B also needs to forward the business to be processed to target node A, providing bidirectional transfer permissions. Target nodes refer to two nodes with a bidirectional transfer relationship. A merging node refers to encapsulating the two target nodes that mutually review each other into a unified logical unit. Multiple business transfer processing means that the two target nodes can repeatedly review and transfer each other's business processes.

[0048] For example, such as Figure 3As shown, the next node after the start node of the pending business 2 is the drafting node, the next node after the drafting node is the review node 1, and the next nodes after the review node 1 are the countersigning node 1 and the countersigning node 2. Since the review node 1 has bidirectional edge connections with both the countersigning node 1 and the countersigning node 2, the countersigning node 1 and the review node 1 form a merge node 1, and the countersigning node 2 and the review node 1 form a merge node 2. The next node after the review node 1 is the responsible review node, so the merge node 1 and the merge node 2 are considered the previous nodes of the responsible review node. The review process for the pending business 2 ends when the next node after the responsible review node is the end node.

[0049] Therefore, based on the bidirectional edge connection relationship in the graph database, the system automatically identifies a pair of target nodes corresponding to the mutual review scenario, eliminating the need for manual pre-configuration of mutual review process templates and review branch gateways. It automatically encapsulates these nodes into a unified logical unit called a merged node. The merged node supports repeated cross-flow between the two target nodes and multiple mutual review rectifications, making it suitable for collaborative review scenarios such as contract review and joint verification of procurement and finance. The constraint logic based on the mutual review information indicating whether to continue the flow ensures the compliance and integrity of the mutual review business. The entire mutual review control logic is implemented based on the native bidirectional flow relationship of the main body, eliminating the need for additional topology branches and judgment gateways. It fits the overall architecture of zero-process gateway and non-template dynamic flow, significantly reducing the workload of process configuration for two-person cross-review business and improving the automation and adaptability of mutual review business flow.

[0050] In some embodiments, when a new approval entity is needed for a business A to be processed, the relationship between the new approval entity and other approval entities of the business A to be processed can be added in the entity relationship database. For example, if there is no general manager approval entity in the entity relationship database, and the business A to be processed needs to add a general manager approval entity, then the approval entity to which the business A to be processed has been processed is determined, the entity relationship between the approval entity and the general manager approval entity is constructed and stored in the entity relationship database, or other required approval entities of the business A to be processed are constructed, and the entity relationship between the other required approval entities and the general manager approval entity is constructed. No specific restrictions are imposed here.

[0051] Therefore, by dynamically supplementing the relationship between newly added approval entities through the entity relationship database, approval steps can be flexibly added to in-transit business without modifying the preset process template. It can build a link to the newly added approval entity based on the current flow nodes, or establish a corresponding relationship based on the existing mandatory approval entities, adapting to different temporary signing scenarios. The original flow topology is not changed throughout the process, and the link expansion of the newly added approval entity is completed quickly. It avoids the high cost and long cycle caused by the need to redesign and release process templates for signing in traditional process systems. It effectively improves the ease of operation and dynamic expansion capability of temporarily adding approvers in in-transit business, and adapts to various office scenarios such as temporarily adding entity instructions in document flow.

[0052] In summary, this invention employs a non-template-based workflow solution using a zero-flow gateway and a dynamic graph database topology. It abandons the traditional pre-fixed rigid workflow templates, eliminating the need to pre-define node order, workflow branches, and approval rules. The system dynamically generates a starting node and a first node after reading the review content, business type, and first approval entity. Based on the approval information and business type of each node, it determines the next approval entity for the current node and creates a corresponding next node for that entity. Based on the gateway-free edge relationship between the current and next nodes, the workflow is transferred from the current node to the next node. In other words, this solution deduces the next approval entity and creates a new workflow link in real time based on the approval feedback and business type of the approval entity corresponding to each node. During operation, the workflow path can be freely expanded without modifying the workflow template. The system significantly reduces the cost and cycle time of approval process adjustments. Each sub-process is generated and advanced independently, and the results of each sub-process are then aggregated to generate the complete business process result. This eliminates the limitation of traditional parallel signing, which requires all approvals to be completed before the process can proceed. It also avoids a single approval node slowing down the overall process and significantly improves the efficiency of simultaneous approval by multiple approval entities. The overall process relies on a gateway-free edge to carry metadata and approval information transmission. It does not require the pre-setting of a large number of conditional branches and flow selection components, simplifying the process modeling and configuration logic. The process direction can be dynamically adjusted as needed, adapting to unstructured office scenarios with uncertain paths, such as repeated approvals of government and enterprise documents and random transfers and archiving. This effectively solves the problems of insufficient flexibility and poor dynamic adaptation of traditional processes, improving the flexibility of the process and the efficiency of approval, making it suitable for complex approval scenarios.

[0053] To improve approval flexibility and efficiency, this application provides an embodiment of a zero-process gateway-based non-template-based business workflow device for implementing all or part of the aforementioned zero-process gateway-based non-template-based business workflow method. See [link to embodiment]. Figure 4 The non-template-based business flow device based on the zero-process gateway specifically includes the following: The creation unit 10 is used to read the approval content, business type and at least one first approval subject of the business to be processed from the business database. The process configuration module encapsulates the approval content and the business type into starting metadata and creates a start node in the graph database. For each first approval subject, a first node is created in the graph database, and a first process-free gateway edge relationship is constructed between the start node and the first node. Based on the first process-free gateway edge relationship, the starting metadata is sent to the first node.

[0054] The creation unit 10 is used to determine the second approval subject and construct the first metadata of the first node based on the first approval information and the starting metadata when the first approval information of the first approval subject is obtained, create a second node for the second approval subject in the graph database, construct a second process-free gateway edge relationship between the first node and the second node, and send the first metadata to the second node based on the second process-free gateway edge relationship.

[0055] The flow unit 20 is used to create an end node in the graph database when the second approval information of the second approval subject indicates the end of the flow, construct a third process-free gateway edge relationship between the second node and the end node, and send the second approval information and the first metadata to the end node based on the third process-free gateway edge relationship, so that the end node can obtain the sub-flow result corresponding to a sub-flow path, and determine the flow result based on multiple sub-flow results.

[0056] As described above, the non-template-based business flow device based on a zero-flow gateway provided in this application adopts a non-template-based flow scheme using a zero-flow gateway combined with a graph database dynamic topology. It abandons the traditional pre-fixed rigid flow templates, eliminating the need to pre-define node order, flow branches, and approval rules. The system dynamically generates a starting node and a first node after reading the review content, business type, and first approval subject. It determines the next approval subject of the current node based on the approval information and business type of each node and creates a corresponding next node for that subject. Based on the non-template gateway edge relationship between the current node and the next node, it realizes the flow of the business to be processed from the current node to the next node. In other words, this scheme deduces the next approval subject and creates a new flow link in real time based on the approval feedback and business type of the approval subject corresponding to each node. During operation, it can automatically... By expanding the workflow path, no modification to the process template is required, significantly reducing the cost and cycle of approval process adjustments. Each sub-workflow path is generated and advanced independently, and the results of each sub-workflow are then aggregated to generate the complete business workflow result. This breaks away from the limitation of traditional parallel signing requiring all approvals to be completed before the process can proceed, avoiding the slowdown of the overall workflow by a single approval node, and significantly improving the efficiency of simultaneous approval by multiple approval entities. The overall workflow relies on the edge of the workflow gateway to carry metadata and approval information transmission, eliminating the need to preset a large number of conditional branches and flow selection components, simplifying the workflow modeling and configuration logic, and allowing dynamic adjustment of the workflow direction as needed. It is suitable for unstructured office scenarios with uncertain paths, such as repeated approvals of government and enterprise documents and random transfer and archiving, effectively solving the problems of insufficient flexibility and poor dynamic adaptation of traditional processes, improving workflow flexibility and approval efficiency, and is suitable for complex approval scenarios.

[0057] To further illustrate this solution, this application also provides a specific application example of implementing the non-template-based business flow method based on the zero-flow gateway using the aforementioned non-template-based business flow device based on the zero-flow gateway, specifically including the following: In some embodiments, before reading the approval content, business type, and at least one first approval entity of the business to be transferred from the business database, the device is further configured to: create the approval content of the business to be transferred by the creating entity; query a plurality of initial first approval entities with a transfer-out type entity connection relationship with the creating entity from the entity relationship database based on the creation identifier of the creating entity, wherein the entity relationship database stores entity connection relationships between pairs of entities, the entity connection relationships include transfer-out type entity connection relationships from the first entity to the second entity and transfer-in type entity connection relationships from the first entity to the first entity; select at least one first approval entity from the plurality of initial first approval entities using the creating entity, or obtain a first historical approval process based on the business type, obtain a plurality of historical first approval entities from the first historical approval process, select at least one first approval entity included in the plurality of historical first approval entities from the plurality of initial first approval entities, and encapsulate at least one first approval entity, the approval content, and the business type into a business to be transferred and store it in the business database.

[0058] In some embodiments, the step of creating a first node in the graph database for each first approval subject, constructing a first process-free gateway edge relationship between the starting node and the first node, and sending the starting metadata to the first node based on the first process-free gateway edge relationship includes: for each first approval subject, extracting the subject identifier, approval authority, and flow marker of the first approval subject; determining whether the first approval subject has approval authority for the business type based on the approval authority; if so, using the subject identifier as the first node identifier of the first node, and using the approval authority and the flow marker as node attributes of the first node, to create the first node in the graph database. If the first approval entity does not have the approval authority for the business type, then the first node of the first approval entity is not created; the starting identifier of the starting node is obtained, and a first entity connection relationship is constructed between the starting identifier and the first node identifier, so as to create a first unconditionally driven, process-free gateway edge relationship in the graph database based on the first entity connection relationship, from the starting node to the first node; the starting node reads the first node identifier from the first process-free gateway edge relationship, sends the starting metadata to the first node corresponding to the first node identifier, and updates the flow mark of the first node to "flowed" to indicate that the starting metadata has flowed to the first node.

[0059] In some embodiments, determining the second approval subject based on the first approval information and the initial metadata and constructing the first metadata of the first node includes: when the first node receives the initial metadata, it queries a plurality of initial second approval subjects with a transfer-out subject connection relationship with the first node from the subject relationship database based on the first node identifier of the first node; the first approval subject selects a second approval subject from the plurality of initial second approval subjects and performs approval processing on the initial metadata to obtain review information; the review information and the second approval subject are used as the first approval information; if the first approval information indicates that the second approval subject is empty, a second historical approval process containing the first approval subject is obtained based on the business type, and the second historical approval process is used as the first approval information. The system retrieves multiple historical second approval entities that are approved after the first approval entity. It selects a second approval entity from among the multiple initial second approval entities that is included in the multiple historical second approval entities. If there is no second historical approval process, it determines a threshold for the number of approval nodes for a single sub-processing path based on the business type. If the number of approval nodes for the sub-processing path is lower than the threshold, it selects a general approval entity from among the multiple initial second approval entities that can approve the business type to be processed, and uses this general approval entity as the second approval entity. If the number of approval nodes is not lower than the threshold, it uses the completion of approval as the second approval entity. The first approval information and the initial metadata are encapsulated into the first metadata of the first node.

[0060] In some embodiments, when the second approval information of the second approval entity indicates the end of the process, an end node is created in the graph database, a third process-free gateway edge relationship is constructed between the second node and the end node, and the second approval information and the first metadata are sent to the end node based on the third process-free gateway edge relationship, so that the end node obtains the sub-processing result corresponding to a sub-processing path, and determines the process result based on multiple sub-processing results, including: when the second node receives the first metadata, if no initial third approval entity with a transfer-out type entity connection relationship with the second node is found in the entity relationship database based on the second node identifier of the second node, then the process end is taken as the third approval entity; when the second approval entity is processing the approval, the third approval entity is selected as the process end, and it is regarded as the process end. The second approval information of the second approval subject indicates the end of the flow. If there is no end node for the business to be flowed in the graph database, an end node is created in the graph database. A third no-flow gateway edge relationship is constructed between the second node and the end node. The second approval subject that issued the indication of the end of the flow is taken as the target second approval subject. Based on the target second no-flow gateway edge relationship and the target third no-flow gateway edge relationship corresponding to the target second approval subject, and the target first no-flow gateway edge relationship corresponding to the target first node in the target second no-flow gateway edge relationship, a sub-flow path is formed. The first metadata and the second approval information received by the second node corresponding to the target second approval subject are encapsulated into a sub-flow result. The sub-flow result is sent to the end node so that the end node determines the flow result based on multiple sub-flow results.

[0061] In some embodiments, the apparatus is further configured to: for each of the sub-flow paths, when the business to be flowed has not flowed to the end node on the sub-flow path, and the business to be flowed needs to be modified, the starting node performs sub-flow rollback processing to actively cancel the unfinished sub-flow path of the business to be flowed; when the approval subject corresponding to any approval node on the sub-flow path identifies an error in the approval content, the approval node performs rejection processing to return the business to be flowed to the starting node.

[0062] In some embodiments, the apparatus is further configured to: for each of the sub-flow paths, if there are two target nodes with a bidirectional edge connection relationship on the sub-flow path, encapsulate the two target nodes into a merge node, in which the two target nodes can perform business flow processing multiple times until the review information of both target nodes indicates that the review has been passed, and then transfer the business to be flowed from the merge node to the next node, wherein the bidirectional edge connection relationship refers to the existence of both a transfer-out class subject connection relationship and a transfer-in class subject connection relationship between the two target nodes with one target node as the reference.

[0063] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the non-template-based business flow method based on a zero-process gateway.

[0064] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described non-template-based business flow method based on a zero-process gateway.

[0065] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described non-template-based business flow method based on a zero-process gateway.

[0066] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0067] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0068] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0069] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0070] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A non-template-based business flow method based on a zero-process gateway, characterized in that, The method includes: The process configuration module reads the approval content, business type, and at least one first approval entity of the business to be processed from the business database. The approval content and business type are encapsulated into starting metadata and a starting node is created in the graph database. For each first approval entity, a first node is created in the graph database, and a first process-free gateway edge relationship is constructed between the starting node and the first node. The starting metadata is sent to the first node based on the first process-free gateway edge relationship. When the first approval information of the first approval subject is obtained, the second approval subject is determined based on the first approval information and the starting metadata, and the first metadata of the first node is constructed. A second node is created for the second approval subject in the graph database, and a second process-free gateway edge relationship is constructed between the first node and the second node. The first metadata is sent to the second node based on the second process-free gateway edge relationship. When the second approval information of the second approval subject indicates the end of the flow, an end node is created in the graph database, a third process-free gateway edge relationship is constructed between the second node and the end node, and the second approval information and the first metadata are sent to the end node based on the third process-free gateway edge relationship, so that the end node can obtain the sub-flow result corresponding to a sub-flow path, and the flow result is determined based on multiple sub-flow results.

2. The non-template-based business flow method based on a zero-process gateway according to claim 1, characterized in that, Before retrieving the approval content, business type, and at least one primary approval entity of the business to be processed from the business database, the method further includes: The approval content of the business to be transferred is created by the creation entity. Based on the creation identifier of the creation entity, multiple initial first approval entities with transfer-out entity connection relationships with the creation entity are retrieved from the entity relationship database. The entity relationship database stores the entity connection relationships between pairs of entities. The entity connection relationships include transfer-out entity connection relationships from the first entity to the second entity and transfer-in entity connection relationships from the first entity to the first entity. Using the creation entity, at least one first approval entity is selected from multiple initial first approval entities, or a first historical approval process is obtained based on the business type, multiple historical first approval entities are obtained from the first historical approval process, at least one first approval entity included in multiple historical first approval entities is selected from multiple initial first approval entities, and at least one first approval entity, the approval content, and the business type are encapsulated as a business to be processed and stored in the business database.

3. The non-template-based business flow method based on a zero-process gateway according to claim 1, characterized in that, For each of the first approval entities, the step of creating a first node in the graph database and constructing a first process-free gateway edge relationship between the starting node and the first node, and sending the starting metadata to the first node based on the first process-free gateway edge relationship, includes: For each of the first approval entities, extract the entity identifier, approval authority, and flow mark of the first approval entity. Based on the approval authority, determine whether the first approval entity has the approval authority for the business type. If it does, use the entity identifier as the first node identifier of the first node, and use the approval authority and the flow mark as the node attributes of the first node to create the first node in the graph database. If the first approval entity does not have the approval authority for the business type, do not create the first node of the first approval entity. Obtain the starting identifier of the starting node, construct a first principal connection relationship between the starting identifier and the first node identifier, and create a first unconditionally driven, flow-free gateway edge relationship in the graph database based on the first principal connection relationship, from the starting node to the first node. The starting node reads the first node identifier from the first flow-free gateway edge relationship, sends the starting metadata to the first node corresponding to the first node identifier, and updates the flow mark of the first node to indicate that the starting metadata has flowed to the first node.

4. The non-template-based business flow method based on a zero-process gateway according to claim 1, characterized in that, The step of determining the second approval subject and constructing the first metadata of the first node based on the first approval information and the initial metadata includes: When the first node receives the initial metadata, it queries the subject relationship database based on the first node identifier of the first node to find multiple initial second approval subjects that have a transfer-out subject connection relationship with the first node. The first approval subject selects a second approval subject from the multiple initial second approval subjects and performs approval processing on the initial metadata to obtain review information. The review information and the second approval subject are used as the first approval information. If the first approval information indicates that the second approval subject is empty, then based on the business type, a second historical approval process containing the first approval subject is obtained, and multiple historical second approval subjects that are approved after the first approval subject are obtained from the second historical approval process. Then, a second approval subject contained in the multiple historical second approval subjects is selected from the multiple initial second approval subjects. If there is no second historical approval process, then the threshold for the number of approval nodes in a single sub-processing path is determined based on the business type. If the number of approval nodes in the sub-processing path is lower than the threshold, then a general approval entity that can approve the business type to be processed is selected from multiple initial second approval entities, and the general approval entity is used as the second approval entity. If the number of approval nodes is not lower than the threshold, then the approval is completed and the second approval entity is used. The first approval information and the starting metadata are encapsulated as the first metadata of the first node.

5. The non-template-based business flow method based on a zero-process gateway according to claim 1, characterized in that, When the second approval information of the second approval entity indicates the end of the process, an end node is created in the graph database. A third process-free gateway edge relationship is constructed between the second node and the end node. Based on the third process-free gateway edge relationship, the second approval information and the first metadata are sent to the end node so that the end node obtains the sub-processing result corresponding to a sub-processing path. The process result is determined based on multiple sub-processing results, including: When the second node receives the first metadata, if it does not find an initial third approval entity with a transfer-out type entity connection relationship with the second node in the entity relationship database based on the second node identifier of the second node, then the transfer is completed as the third approval entity. When the second approval entity is processing the approval, the third approval entity is selected as the end of the process. This is regarded as the second approval information of the second approval entity indicating the end of the process. If there is no end node for the business to be processed in the graph database, an end node is created in the graph database. The third process-free gateway relationship between the second node and the end node is constructed. The second approval entity that issued the instruction to end the process is taken as the target second approval entity. Based on the target second no-process gateway edge relationship and the target third no-process gateway edge relationship corresponding to the target second approval subject, and the target first node corresponding to the target first no-process gateway edge relationship in the target second no-process gateway edge relationship, a sub-flow path is formed. The first metadata and the second approval information received by the second node corresponding to the target second approval subject are encapsulated into a sub-flow result. The sub-flow result is sent to the end node so that the end node determines the flow result based on multiple sub-flow results.

6. The non-template-based business flow method based on a zero-process gateway according to claim 1, characterized in that, The method further includes: For each of the sub-flow paths, if the service to be flowed has not flowed to the end node on the sub-flow path, and the service to be flowed needs to be modified, the start node performs sub-flow rollback processing to actively cancel the unfinished sub-flow path of the service to be flowed. When the approval entity corresponding to any approval node on the sub-processing path identifies an error in the approval content, the approval node performs a rejection process to return the pending processing to the starting node.

7. The non-template-based business flow method based on a zero-process gateway according to claim 1, characterized in that, The method further includes: For each of the sub-flow paths, if there are two target nodes with a bidirectional edge connection on the sub-flow path, then the two target nodes are encapsulated into a merge node. In the merge node, the two target nodes can perform business flow processing multiple times until the review information of both target nodes indicates that the review has been passed. Then, the business to be flowed is flowed from the merge node to the next node. The bidirectional edge connection means that, with one target node as a reference, there is a transfer-out subject connection relationship and a transfer-in subject connection relationship between the two target nodes.

8. A non-template-based business flow device based on a zero-process gateway, characterized in that, The device includes: A creation unit is used to read the approval content, business type, and at least one first approval subject of the business to be processed from the business database. The process configuration module encapsulates the approval content and the business type into starting metadata and creates a start node in the graph database. For each first approval subject, a first node is created in the graph database, and a first process-free gateway edge relationship is constructed between the start node and the first node. Based on the first process-free gateway edge relationship, the starting metadata is sent to the first node. The creation unit is used to determine the second approval subject and construct the first metadata of the first node based on the first approval information and the starting metadata when the first approval information of the first approval subject is obtained; to create a second node for the second approval subject in the graph database; to construct a second process-free gateway edge relationship between the first node and the second node; and to send the first metadata to the second node based on the second process-free gateway edge relationship. The flow unit is used to create an end node in the graph database when the second approval information of the second approval subject indicates the end of the flow, construct a third process-free gateway edge relationship between the second node and the end node, and send the second approval information and the first metadata to the end node based on the third process-free gateway edge relationship, so that the end node can obtain the sub-flow result corresponding to a sub-flow path, and determine the flow result based on multiple sub-flow results.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the non-template-based business flow method based on a zero-process gateway as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the non-template-based business flow method based on a zero-process gateway as described in any one of claims 1 to 7.

Images