Method for constructing visual workflow

Abstract

The invention discloses a method for constructing a visual workflow, and relates to the technical field of data processing. The method is used for solving the problems of incoherence and fragmentation of a data processing flow. When a user drags an algorithm node to construct a workflow, if the data types of node ports dragged and connected by the user are incompatible, a system automatically retrieves one or more target bridging nodes in a preset node library, and the input data type of the target bridging nodes is compatible with the output data type of a previous node; and the output data type is compatible with the input data type of the next node. And finally, the system automatically inserts the bridging node between the two nodes to establish a data flow. According to the method, a manual conversion process is converted into automatic data flow repair, so that operation interruption is avoided, and the automation degree and efficiency of workflow construction are improved.

Description

Technical Field

[0001] This application relates to the field of data processing and analysis, and in particular to a method for constructing visual workflows. Background Technology

[0002] In modern scientific research and engineering, to handle the diverse and complex processing of massive amounts of experimental data, the industry has developed visual workflow orchestration platforms. These platforms allow users to graphically construct data processing pipelines by dragging and dropping functional "nodes" and connecting them, thereby simplifying the design of data analysis processes.

[0003] However, in related technologies, users still face significant efficiency bottlenecks when building, reproducing, and sharing complex workflows. Specifically, during the process construction phase, different types of functional units (such as data processing units and logic control units) differ in design and operation. When users combine these units to implement complete business logic, they need to adopt inconsistent operating methods for different units, which increases the complexity of process configuration and the possibility of errors. Summary of the Invention

[0004] This application provides a method for building visual workflows to solve the problems of discontinuous and fragmented data processing flows, single business scenarios, and lack of flexible arrangement and reuse, thereby improving the convenience and automation level of workflow construction.

[0005] Firstly, this application provides a method for constructing a workflow, applied to a visual editing system. The method includes: providing standardized node units to the user in a visual interface, wherein each standardized node unit follows a unified encapsulation standard. The encapsulation standard defines the standardized node unit as including type metadata declaring input and output port data types, core logic for executing atomic functions, and a dependency list declaring the runtime environment; receiving a user's operation to establish a connection from the output port of a first working node to the input port of a second working node; obtaining the output data type of the first working node's output port and the required input data type of the second working node's input port; determining whether the output data type is compatible with the required input data type; if incompatible, retrieving at least one bridging node from a preset node library, wherein the bridging node's input data type is compatible with the first working node's output data type, and its output data type is compatible with the second working node's required input data type; and automatically inserting a bridging node between the first and second working nodes to establish a data flow from the first working node to the second working node via the bridging node.

[0006] The above embodiments provide standardized nodes that follow a unified encapsulation standard for all functional units (including data processing, logic control, etc.), ensuring that each node unit has a consistent structure and interface definition at the levels of type metadata, core logic, and dependency list. This eliminates the need for users to learn and apply different operation methods for different types of units when dragging and configuring on the visual interface, thus reducing the cognitive load when building workflows. Furthermore, when a user attempts to connect two nodes, this application automatically obtains and determines whether the data types between the ports are compatible. If incompatibility is detected, it retrieves and automatically inserts one or more suitable bridging nodes from a preset node library. This simplifies the complex process of manually diagnosing incompatibility, finding data conversion tools, and reconnecting into a single connection action. This automated processing method reduces the number of manual interventions required by users when dealing with data format mismatch issues, improving the smoothness and efficiency of the workflow construction process, thereby addressing the efficiency bottlenecks encountered in building complex data processing workflows mentioned in related technologies.

[0007] In conjunction with some embodiments of the first aspect, in some embodiments, the encapsulation standard performs hierarchical data type declarations on the type metadata of each standardized node unit. The hierarchical data type declarations include: a basic type layer: defining the basic type of data at the programming language level; a semantic type layer: defining the business meaning or domain concept of data above the basic type layer; and an attribute constraint layer: attaching specific formats, units, or constraints to the semantic type.

[0008] The above embodiments introduce hierarchical data type declarations into the type metadata of standardized node units, dividing data types into three levels: basic types, semantic types, and attribute constraints. When determining compatibility between nodes, the system can perform deeper matching beyond basic programming language types (such as strings and integers). This refined judgment capability can proactively identify mismatches that exist only at the business logic or physical unit level during the workflow construction phase. Furthermore, when the system detects incompatibility, because it can accurately locate the specific level at which the mismatch occurs (e.g., whether it's inconsistent units or conflicting business concepts), it can use this precise information as a retrieval condition to perform a more targeted search in the node library, thereby improving the accuracy and applicability of the found bridging nodes and enhancing the intelligence and construction efficiency of automatic data flow connections.

[0009] In conjunction with some embodiments of the first aspect, in some embodiments, the step of determining whether the output data type is compatible with the required input data type specifically includes: comparing the hierarchical data type declarations of the output port of the first working node and the input port of the second working node layer by layer according to a preset priority order, with the priority order being attribute constraint layer > semantic type layer > basic type layer; during the comparison process, if all levels match, it is determined to be compatible; if a mismatch occurs at any level, the comparison is immediately stopped and it is determined to be incompatible, and the level where the first mismatch occurs is recorded as the corresponding incompatible type.

[0010] The above embodiments refine the compatibility judgment steps. By setting a priority order of "attribute constraint layer > semantic type layer > basic type layer" and adopting a strategy of comparing layer by layer and stopping upon encountering a mismatch, the efficiency of the judgment process is improved. This is because for nodes that do not match at the highest priority level, such as business attributes or units, the system does not need to further check their semantics or basic types, reducing unnecessary computational overhead. More importantly, by recording the level at which the first mismatch occurs when the comparison is stopped, the system obtains a precise result regarding the cause of the incompatibility. For example, the system can distinguish whether the connection failure stems from a unit mismatch (attribute layer problem) or because the data represents a completely different business object (semantic layer problem). This qualitative judgment result provides precise guidance for subsequent automatic insertion of bridging nodes, allowing the system to perform more targeted filtering based on the recorded "incompatibility type" when retrieving bridging nodes, thereby improving the accuracy of automatically finding the most suitable conversion node.

[0011] In conjunction with some embodiments of the first aspect, in some embodiments, if incompatible, the step of retrieving at least one target bridging node from a preset node library specifically includes: if incompatible, performing an initial search in the node library based on the incompatibility type, the hierarchical data type declaration of the output port of the first working node, and the hierarchical data type declaration of the input port of the second working node as combined search conditions; if multiple bridging nodes are retrieved, automatically selecting the bridging node corresponding to the preferred target as the target bridging node according to a preset evaluation strategy and a preset preferred target; if no bridging node is retrieved, initiating a composite bridging path search to obtain a bridging link, and using the bridging link as the target bridging node.

[0012] The above embodiments optimize the retrieval steps for bridging nodes. By combining incompatible types with hierarchical data types of the source and target ports as search criteria, the search scope is precisely limited. When multiple search results exist, a preset evaluation strategy automatically selects the best result, standardizing the bridging selection process, improving workflow performance certainty, and avoiding suboptimal configurations introduced by improper manual selection. Finally, when no directly available nodes are found, a composite bridging path search is initiated to automatically construct a "bridging link," thereby enabling the handling of complex multi-step transformations and improving the problem of users having to manually try and fail or being unable to solve complex transformation requirements.

[0013] In conjunction with some embodiments of the first aspect, in some embodiments, if no bridging node is found, a composite bridging path search is initiated to obtain a bridging link, and the bridging link is used as the target bridging node. Specifically, this includes: if no bridging node is found, performing the following operations: using the output port of the first working node as the initial starting point and the input port of the second working node as the final ending point, searching the node library for a bridging link consisting of two or more nodes that can connect the starting point and the ending point; generating an empty composite bridging node, loading all nodes arranged sequentially in the bridging link into the composite bridging node; within the composite bridging node, automatically creating data connections according to the searched order, sequentially connecting the nodes to construct an internal data processing link; after constructing the internal data processing link, determining the composite bridging node as a logical whole as the target bridging node.

[0014] The above embodiments, by setting incompatible source and target ports as the start and end points of path search respectively, and searching for a bridging link composed of multiple nodes in the node library, enable the system to handle complex multi-step transformations. This improves upon the limitations of related technologies where the lack of direct transformation tools leads to automation interruptions and necessitates manual intervention. Furthermore, this application generates an empty composite bridging node, loads the searched node sequence into it, and automatically completes the sequential concatenation of internal nodes. This encapsulation operation abstracts a complex processing logic composed of multiple underlying nodes into a single logical node with cohesive functionality and a clear interface. This enhances the readability and maintainability of the workflow diagram, eliminating the need for users to concern themselves with the internal details of the transformation process and reducing the cognitive burden and potential errors associated with manually orchestrating complex local processes. Ultimately, this complete closed loop from path discovery to automatic encapsulation transforms the multi-step data processing task, which previously required manual analysis and construction by domain experts, into a background operation autonomously completed by the system. This improves the automation and intelligence of workflow construction, allowing users to focus more on the business logic itself rather than the technical implementation details of data transformation.

[0015] In conjunction with some embodiments of the first aspect, in some embodiments, the method further includes: upon receiving a user instruction, determining a selected sub-workflow on the workflow canvas, consisting of multiple standardized node units; analyzing the topology of the sub-workflow, identifying the data input boundaries and data output boundaries between the sub-workflow and external connections; creating a custom node object, and creating corresponding input ports according to the data input boundaries, and corresponding output ports according to the data output boundaries; encapsulating the complete internal logic of the sub-workflow into the internal processing logic of the custom node object; and storing the encapsulated custom node object in a custom node library after associating it with a user-specified identifier for subsequent direct invocation.

[0016] The above embodiments provide a method for encapsulating existing workflow fragments into reusable units. By encapsulating user-selected sub-workflows into custom nodes with clearly defined input and output ports based on their data boundary analysis results, a means of solidifying repetitive logical fragments is provided, improving the problem of users having to repeatedly build the same node sequence in different projects. Simultaneously, this encapsulation operation abstracts complex local topologies into individual nodes, directly improving the visualization clarity of the workflow's main logic and alleviating the difficulty in understanding and maintaining large workflows due to numerous nodes. Furthermore, storing the encapsulated custom nodes in a node library makes them reusable and distributable assets, promoting the accumulation and sharing of team knowledge, and improving overall development efficiency and standardization by establishing an extensible node library.

[0017] In conjunction with some embodiments of the first aspect, in some embodiments, the encapsulation standard further includes dynamic type declarations: the standardized node unit contains one or more configuration parameters, and the hierarchical data type declaration of at least one output port is associated with the value of the configuration parameter; the association is implemented through a preset mapping rule, and when the user changes the value of the configuration parameter, the hierarchical data type declaration of the corresponding output port is automatically updated.

[0018] The above embodiments enhance node flexibility through dynamic type declarations. By establishing mapping rules between node configuration parameters and output port data type declarations, individual nodes can dynamically adjust their output specifications based on user configuration. This design improves the redundancy problem caused by developing multiple versions of nodes for minor feature adjustments through functional aggregation. Simultaneously, the automatic update mechanism for output port data types allows the system to perform pre-validation during the connection construction phase. Compared to discovering type mismatches at runtime, this proactively avoids connection errors and improves the accuracy of workflow construction. Encapsulating complex data type changes within nodes provides users with a more business-semantic interface. Users express their needs through configuration parameters, rather than remembering specific node versions, which lowers the barrier to entry and reduces mental burden, allowing them to focus more on business process design itself.

[0019] In a second aspect, embodiments of this application provide a visual editing device, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the visual editing device to perform the method described in the first aspect and any possible implementation thereof.

[0020] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a visual editing device, cause the visual editing device to perform the method described in the first aspect and any possible implementation thereof.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a visual editing device, cause the visual editing device to perform the method described in the first aspect and any possible implementation thereof.

[0022] Understandably, the visualization editing device provided in the second aspect, the computer program product provided in the third aspect, and the computer storage medium provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0023] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. This application simplifies the complex operation of manual diagnosis and conversion required by users into an automatic background data stream repair process by automatically retrieving and inserting one or more bridging nodes when data incompatibility between nodes is detected. This improves the problem of frequent interruptions in workflow construction caused by data format mismatch and enhances orchestration efficiency and smoothness.

[0024] 2. This application achieves modular reuse of complex logic by encapsulating user-selected sub-workflows into custom nodes with standard inputs and outputs and storing them in a node library. This improves the inefficiency of users having to repeatedly build similar processes in different projects, while also enhancing the readability and maintainability of large workflow diagrams.

[0025] 3. By introducing a hierarchical data type declaration and a dynamic node type declaration mechanism, this application makes incompatibility judgment and bridging node retrieval more accurate on the one hand, and gives individual nodes the ability to dynamically change output specifications according to configuration on the other hand, which improves the node library redundancy problem and lowers the user's usage threshold, allowing them to focus more on the business logic itself. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of a visual interface in an embodiment of this application; Figure 2 This is a flowchart illustrating a workflow construction method in an embodiment of this application; Figure 3 This is a flowchart illustrating an automatic bridging node method in an embodiment of this application; Figure 4 This is a schematic diagram of the physical device structure of a visual editing device in the embodiments of this application. Detailed Implementation

[0027] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0028] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0029] To facilitate understanding, the application scenarios of the embodiments of this application are described below.

[0030] In modern scientific research and engineering, visual workflow orchestration platforms are widely used to simplify the design of data analysis processes. These platforms allow users to graphically construct data processing pipelines by dragging and dropping functional "nodes" and connecting them.

[0031] However, the existing technologies are inefficient at handling data type incompatibility issues between nodes. For example, when a node that outputs CSV text needs to connect to a node that requires numerical input, current platforms typically only display an error message, forcing users to manually diagnose the problem, find and insert one or more transformation nodes to align the data formats. This process not only disrupts the workflow but is also time-consuming and error-prone when faced with complex multi-step transformations, severely impacting orchestration efficiency.

[0032] This application provides an intelligent workflow construction method. By standardizing and encapsulating nodes, the system can deeply understand the data contracts of each node. When data type incompatibility is detected, the system no longer passively reports an error, but actively and automatically retrieves and inserts appropriate "bridging nodes" to complete the data transformation. This internalizes tasks that originally required manual user intervention into seamless background automation, allowing users to focus more on the business logic itself.

[0033] To facilitate understanding of the technical solution of this application, its core user operation flow is first presented. In an ideal scenario, users can combine multiple standardized nodes compatible with different data types into a complete workflow simply through intuitive drag-and-drop and connection operations.

[0034] Specifically, taking a business scenario where users need to calculate the error based on two sets of recorded data as an example, the workflow construction and execution method under this ideal situation includes the following steps: The system provides users with a node library containing various standardized node units through a visual interface. Please refer to [link / reference]. Figure 1 This is a schematic diagram of the visual interface in an embodiment of this application. Each node unit encapsulates a basic algorithm or business logic (e.g., addition, finding the maximum value, coordinate transformation, error calculation, etc.) as its core logic. In this scenario, the node library at least includes: a "Data Source A" node for loading the first set of data; a "Data Source B" node for loading the second set of data; and a "Calculate Error" node, whose core logic is to receive the two sets of data and calculate the difference.

[0035] After receiving a drag-and-drop operation from the user, the system instantiates three nodes on the workflow canvas. Specifically, the system first receives the user's instruction to drag the "Data Source A" node from the node library to the canvas, thereby creating an instance of "Data Source A" on the canvas. Subsequently, in the same manner, in response to the user's drag-and-drop operation, instances of the "Data Source B" node and the "Calculation Error" node are created on the canvas in sequence.

[0036] After receiving a user's connection request, the system performs a compatibility check and establishes a data flow connection. In this ideal scenario, the user drags a connection line from the output port of the "Data Source A" node instance onto the visualization canvas and connects it to the first input port of the "Calculation Error" node instance (e.g., labeled "Input Data 1"). During this process, the system automatically verifies the data type of the connection port in real time in the background. Since the output of "Data Source A" ("numerical array") is compatible with the input requirements of "Calculation Error" ("numerical array"), the connection is confirmed as valid. Therefore, the user will see the connection line smoothly attached to the target port on the interface, and a clear data flow path is established. Internally, the corresponding data link is also created. Next, the system responds to the user's operation of connecting the "Data Source B" node instance and the "Calculation Error" node instance using the same pre-check and connection establishment process, creating a second data link.

[0037] After receiving the user's execution command, the system executes the workflow in topological order. Upon receiving the execution command, the system first executes the "Data Source A" and "Data Source B" nodes in parallel, causing them to output two sets of recorded data respectively. These two sets of data are then transmitted to the corresponding input port of the "Calculate Error" node through the established connection. Finally, the "Calculate Error" node executes its internal error calculation algorithm and outputs the final error result from its output port, completing the entire data analysis and processing.

[0038] The above embodiments visualize the process of building a data processing workflow as drag-and-drop and connection operations for the required processing nodes, thereby improving the convenience and efficiency of data processing.

[0039] Furthermore, to ensure the platform's scalability to adapt to different application scenarios, the standardized node unit encapsulation standard provided in this application has good openness. The core logic of the node model is not limited to internally fixed simple algorithm indicators (such as addition, subtraction, multiplication, division, statistical methods, etc.), it also supports the calling and encapsulation of external computing resources.

[0040] Specifically, this encapsulation standard supports the creation of the following types of extension nodes: Script invocation nodes, for example, can be created as a "Python script execution" node. The core logic of this node is a script interpreter invoker that receives data from upstream nodes as input parameters, executes the user-specified Python script file, and outputs the script's execution result. The data types of its input and output ports are uniformly declared by the encapsulation standard, thus seamlessly integrating into the entire workflow system.

[0041] Similarly, for the external library interface node, a "DLL function call" node can be created. The core logic of this node is used to load dynamic link libraries (DLLs) or shared objects (.so) and call the specified functions within them, thereby achieving integration with high-performance or legacy code libraries written in compiled languages ​​such as C++ and Fortran.

[0042] In this way, users or developers can quickly encapsulate existing algorithm assets or custom complex business logic into node models that conform to the unified standards of this application, enriching the platform's functional ecosystem and enabling it to flexibly and efficiently respond to data processing and analysis needs from different professional fields without modifying the core framework of the system.

[0043] The above embodiments illustrate an ideal workflow. However, in practical applications, the increasing number of nodes and varying data specifications often lead to data incompatibility. For example, a node that outputs CSV text cannot directly use the data from an analysis node that only requires floating-point numbers in a specific unit (such as Fahrenheit).

[0044] This incompatibility can disrupt workflow construction, forcing users to manually locate and insert transformation nodes, severely impacting efficiency. To address this pain point, this application provides an intelligent automatic data flow repair mechanism, which will be described in detail below with reference to the accompanying drawings.

[0045] Please see Figure 2 This is a flowchart illustrating a workflow construction method in an embodiment of this application.

[0046] S201. Provide users with standardized node units in the visual interface. Each standardized node unit follows a unified encapsulation standard. The encapsulation standard defines the type metadata of the standardized node unit, including the declaration of input port and output port data types, the core logic for executing atomic functions, and the list of dependencies required by the runtime environment.

[0047] In this context, a standardized node unit represents the smallest functional execution entity in the workflow. It is designed as an independent, reusable component to perform a specific data processing or logic control task. Type metadata represents data used to describe the characteristics of the data itself, and in this application, it specifically refers to the declaration of the data types flowing through the node input / output ports. The dependency list is a list that explicitly declares the external software libraries, specific versions of compilers, or hardware environments necessary for the core logic to run.

[0048] Specifically, the system first loads a pre-defined node library containing multiple node definition files that adhere to a unified encapsulation standard. The system parses these files one by one, strictly following the encapsulation standard to extract the type metadata, core logic references, and dependency lists for each node. Subsequently, based on this extracted information, the system generates a corresponding graphical icon for each node in the component panel of the visual interface, associating it with the node's name, functional description, and other information for users to drag and drop. This step establishes a unified, machine-readable "identity profile" for all functional units in the workflow (whether data processing, logic control, or model training). This standardized abstraction is the foundation for all subsequent intelligent operations. It enables the system to have a comprehensive understanding of node behavior and requirements during the workflow construction phase, laying a solid foundation for the automated orchestration and intelligent assistance of the entire workflow through pre-defined standardized constraints.

[0049] In some embodiments, the encapsulation standard performs hierarchical data type declarations on the type metadata of each standardized node unit. The hierarchical data type declarations include: basic type layer: defining the basic type of data at the programming language level; semantic type layer: on top of the basic type layer, defining the business meaning or domain concept of the data; attribute constraint layer: attaching specific formats, units or constraints to the semantic type.

[0050] The essence of the above embodiment is a "standardized definition" process executed during the system design and node development phases. It is triggered when developers need to create a new node unit in the node library or upgrade an existing node. Specifically, when developers build a node such as "Get Real-Time Weather," their "Temperature" output port must be defined according to this hierarchical declaration: First, the base type layer is determined to be float, as it is a numerical value. Next, at the semantic type layer, it is defined as Temperature to distinguish it from other numerical values ​​such as "price" or "length." Finally, in the attribute constraint layer, it is explicitly stated that the temperature unit returned by the API is Celsius, i.e., the additional constraint {"unit": "Celsius"}. This step produces a structured, machine-readable, and highly information-rich type metadata, upgrading the type concepts in traditional workflows (such as "string") into a multi-dimensional model that includes physical form, business logic, and specific specifications.

[0051] In other embodiments, the encapsulation standard also includes dynamic type declarations: the standardized node unit contains one or more configuration parameters, and the hierarchical data type declaration of at least one output port is associated with the value of the configuration parameter; the association is implemented through a preset mapping rule, and when the user changes the value of the configuration parameter, the hierarchical data type declaration of the corresponding output port is automatically updated.

[0052] The above embodiment is a "responsive type adjustment" mechanism that takes effect in real time during the workflow design phase. Its trigger condition is that a user interacts with the configuration parameters of a node containing dynamic type declarations on the workflow editing interface, causing a change in its value. Specifically, taking a "Data Transformation Service" node as an example, this node may have a configuration parameter called "Target Format," with possible values ​​of "JSON" and "XML." The node's developer defined a mapping rule in the encapsulation standard: when the "Target Format" parameter value is "JSON," the hierarchical data type declaration of its output port is {baseType: string, semanticType: JSON_String}; when the value is "XML," the type declaration is automatically updated to {baseType: string, semanticType: XML_String}. When the user switches the node's "Target Format" from "JSON" to "XML" on the canvas, the system immediately captures this change event, queries the preset mapping rule, obtains the new type declaration, and updates it to the metadata of the node's output port. This step ensures that subsequent compatibility checks (S204) are always based on the node's latest and most accurate output contract, thereby guaranteeing the real-time nature and accuracy of connection validity assessment. The innovation of this application lies in transforming the node's "data contract" from a static specification into a dynamic "living contract" that is synchronized with the node's own state in real time. This enhances the expressive power of individual node templates and improves the reusability and flexibility of the node library.

[0053] S202, Receive the user's operation to establish a connection from the output port of the first working node to the input port of the second working node.

[0054] In this connection operation, the first working node and the second working node are two standardized node unit instances designated as upstream and downstream of the data flow, where the first working node represents the source of the data flow and the second working node represents the destination of the data flow.

[0055] This step is triggered when the user actively executes a complete node connection operation on the canvas of the visual interface. Its application scenario is when a user is visually orchestrating a workflow and wants to use the processing result of one node as input data for another. Specifically, this step is implemented through the event listening mechanism of the graphical user interface. The system's front-end event loop continuously monitors the user's input behavior. When it detects a "press" event starting at an output port, accompanied by a series of "drag" events, and finally a "release" event detected on an input port, the system parses this series of events into a complete connection operation. During this process, the system captures and records four key identifiers involved in the operation: the unique identifier of the first working node, the identifier of its selected output port, the unique identifier of the second working node, and the identifier of its selected input port.

[0056] S203. Obtain the output data type of the output port of the first working node and the required input data type of the input port of the second working node.

[0057] This step is executed immediately after S202, as a direct preceding operation to the subsequent judgment step (S204). Specifically, this step is an internal data query and retrieval process within the system. The system uses the four key identifiers captured in S202 (first worker node ID, output port ID, second worker node ID, and input port ID) to query the internal data model (as shown in the figure object or state tree) representing the current workflow. It locates the corresponding node object based on the first worker node ID, then finds the corresponding port structure within that object based on the output port ID, and reads the predefined, complete type metadata structure from it; this is the "output data type". Similarly, the system performs a similar operation to obtain the type metadata of the specified input port of the second worker node; this is the "required input data type". This step provides accurate, complete, and structured input data for subsequent compatibility judgments.

[0058] S204. Determine whether the output data type is compatible with the required input data type.

[0059] This step is executed immediately after the data preparation in S203, and its result directly determines the direction of subsequent processes. Specifically, this step takes the two types of metadata objects obtained in S203 as an input pair and passes them to an internal compatibility evaluation engine. The core function of this engine is to logically evaluate the input data type pair according to a set of predefined, abstract compatibility judgment criteria, and finally output a Boolean result (i.e., "compatible" or "incompatible"). This set of judgment criteria defines the system's complete interpretation of the concept of "compatibility," acting as a black box that encapsulates all the specific comparison logic. This step produces a clear, machine-executable decision basis to guide the system to the next step. It transforms the implicit judgment knowledge in the developer's mind into an explicit evaluation model that the system can execute. Through automated review of data metadata, it fundamentally ensures the robustness of the workflow, which is a key innovation for achieving truly intelligent, configuration-free data flow.

[0060] S205. If incompatible, at least one bridging node is retrieved from the preset node library, wherein the input data type of the bridging node is compatible with the output data type of the first working node, and its output data type is compatible with the required input data type of the second working node.

[0061] This step is executed after the connection is determined to be incompatible, but before the final result is fed back to the user. Specifically, this step is an automated solution discovery process in the system background. When S204 determines incompatibility, the system uses the source output data type (denoted as Type_A) and the target input data type (denoted as Type_B) obtained in S203 as input to the retrieval task. The system then traverses every node in the preset node library. For any candidate node in the library (denoted as Node_C), the system obtains its own input data type (Type_C_in) and output data type (Type_C_out). Then, the system calls the compatibility evaluation logic defined in S204 twice: first, it checks whether Type_A and Type_C_in are compatible, and second, it checks whether Type_C_out and Type_B are compatible. Only when both of these checks result in "compatible" is the candidate node Node_C confirmed as a valid bridging node and added to the final result list. This step defines an automated, semantic-based "data intermediary" discovery mechanism. The system no longer passively relies on users to manually find and insert transformation nodes. Instead, through a deep understanding of data contracts, it proactively reasones and builds solutions that can bridge the data gap, improving the efficiency and intelligence of workflow construction.

[0062] S206. Automatically insert a target bridging node between the first working node and the second working node to establish a data flow from the first working node to the second working node via the bridging node.

[0063] This step is executed immediately after the S205 solution confirmation and is the final step in the entire automated connection repair process. Specifically, this step first creates a brand new node instance in the workflow's logical model based on the target bridging node template selected in S205 and assigns it a unique ID. Then, the system performs a connection redirection operation: it retrieves references to the output port of the first worker node and the input port of the second worker node, and removes any potential, unsuccessful connection states between them. Afterward, the system creates two new connection objects: the first connection object associates the output port of the first worker node with the compatible input port of the newly created bridging node; the second connection object associates the compatible output port of the bridging node with the input port of the second worker node. These changes are committed to the workflow's global state manager and may simultaneously trigger a redraw of the user interface, allowing the user to visually see a new node being inserted and the connection lines being automatically redrawn on the canvas. This step enables the workflow topology to "self-heal." It internalizes a task that requires analysis, judgment, and manual operation into a seamless, instantaneous automated behavior of the system. This not only simplifies user operations but also fundamentally guarantees the correctness and consistency of the repair process. It is an effective technology for achieving higher-level "intent-driven" workflow modeling.

[0064] In other embodiments, the method further includes: upon receiving a user instruction, determining a selected sub-workflow on the workflow canvas, consisting of multiple standardized node units; analyzing the topology of the sub-workflow, identifying the data input and output boundaries between the sub-workflow and external connections; creating a custom node object, and creating corresponding input ports based on the data input boundaries and corresponding output ports based on the data output boundaries; encapsulating the complete internal logic of the sub-workflow into the internal processing logic of the custom node object; and storing the encapsulated custom node object in a custom node library after associating it with a user-specified identifier for subsequent direct invocation.

[0065] This step is triggered when the user actively selects one or more nodes and issues a wrapper command in the workflow editing interface. Its application scenario is when a user constructs a node combination with specific business significance that may be reused in multiple projects, and wants to solidify it into an independent, reusable functional module to simplify current and future workflow design. Specifically, after receiving the user command, the system first obtains a list of IDs of the selected nodes. Then, the system performs a boundary analysis: it traverses all connections (edges) in the main workflow, checking the source and target nodes of each connection. If the source node of a connection is not in the selected set, but the target node is, then the corresponding input port of the target node is identified as part of the "data input boundary." Conversely, if the source node is in the set, but the target node is not, then the corresponding output port of the source node is identified as part of the "data output boundary." After determining all boundary ports, the system creates a new "custom node object" and, based on the boundary analysis results, generates corresponding input and output ports for this new object, inheriting its data type. The system then serializes the complete topology of the selected sub-workflow (including internal nodes and their configurations, and internal connections) and stores it as the "internal processing logic" of the custom node object. After the user names this new node, the system stores its complete definition (including port, name, and internal logic) in the custom node library. The direct technical effect of this step is to abstract and solidify a complex, localized flowchart structure into a single node with a clear interface and cohesive functionality, improving the readability, maintainability, and modular reusability of the workflow.

[0066] In Embodiment 1 above, the overall process description of the workflow construction and execution method provided in this application was given. This process outlines the complete framework of the system from receiving connection operations and determining compatibility to automatically inserting bridging nodes.

[0067] To further clarify how the system achieves intelligent problem diagnosis and solution generation in the two core steps of "determining compatibility" (S204) and "retrieving bridging nodes" (S205), the following will refer to the appendix. Figure 3 This provides a more specific and preferred implementation of these two key steps, thus constituting a more detailed embodiment.

[0068] The following provides a more detailed description of the process of the method provided in this implementation. Please refer to [link / reference]. Figure 3 This is a flowchart illustrating an automatic bridging node method in an embodiment of this application.

[0069] S301. According to the preset priority order, the hierarchical data type declarations of the output port of the first working node and the input port of the second working node are compared layer by layer, with the priority order being attribute constraint layer > semantic type layer > basic type layer.

[0070] This step is executed before any logical connection is established between the ports of any two nodes, serving as the entry point for the entire compatibility assessment process. Specifically, this step first retrieves the complete hierarchical data type declaration objects for both the source and target ports. Then, strictly adhering to the principle of "attribute constraint layer priority," it extracts and compares the constraint objects of both sides. For example, if the source port is declared as {unit: "Celsius"} and the target port is declared as {unit: "Celsius"}, then this layer is considered a match. If one side declares a unit while the other does not, or if the units declared by both sides are inconsistent (e.g., "Celsius" vs. "Fahrenheit"), then this layer is considered a mismatch. Only when the highest priority layer is completely matched will the comparison process move down to the next level, the "semantic type layer," comparing the semanticType fields of both sides (e.g., "Temperature" vs. "Temperature"). Similarly, only when the semantic layer also matches will the final comparison be made to the baseType field of the lowest-level "base type layer" (e.g., "float" vs. "float"). This step provides a clear, hierarchical comparison result for subsequent steps.

[0071] S302. If all levels match during the comparison process, the system is considered compatible.

[0072] S303. If a mismatch occurs at any level, the comparison is immediately stopped and the level is determined to be incompatible. At the same time, the level at which the first mismatch occurs is recorded as the corresponding incompatibility type.

[0073] The trigger condition for this step is that during the comparison process of S301, any comparison function at any level returns a "mismatch" result. Specifically, when S301 starts, the system first compares the highest priority "attribute constraint layer". Assuming the source port requires the unit to be "Celsius" while the target port requires the unit to be "Fahrenheit", this level is determined to be a "mismatch". At this point, S303 is immediately triggered, and the system performs two core actions: First, it suspends the entire comparison process, no longer checking whether their semantic type layers or basic type layers are consistent, which greatly improves the judgment efficiency; second, it records the identifier of the "attribute constraint layer", forming a diagnostic result of incompatibility type ATTRIBUTE_CONSTRAINT_MISMATCH. This result not only indicates a connection failure but also precisely points out the reason for the failure. If the attribute constraint layer matches, the comparison enters the semantic type layer. If a mismatch occurs at this point (e.g., one outputs "user age", the other requires "user points"), then S303 is also triggered, but the recorded incompatibility type will be SEMANTIC_TYPE_MISMATCH. The system no longer simply knows "they don't match," but precisely knows "they don't match because of unit issues." This allows it to find a bridging node that can perform "unit conversion," which is an innovation of the traditional workflow error handling mechanism.

[0074] S304. If incompatible, the node database is initially searched based on the incompatible type, the hierarchical data type declaration of the output port of the first working node, and the hierarchical data type declaration of the input port of the second working node as combined search conditions.

[0075] The trigger condition for this step is that S303 determines that the two ports are incompatible and successfully generates the incompatible type. Specifically, assume that S303 determines the incompatible type to be ATTRIBUTE_CONSTRAINT_MISMATCH, the source port type is declared as {semanticType: 'temperature', constraints: {unit: 'Celsius'}}, and the target port type is declared as {semanticType: 'temperature', constraints: {unit: 'Fahrenheit'}}. The system will construct a combined search condition as follows: {requirement: attribute conversion, input: {semantic: temperature, constraint: Celsius}, output: {semantic: temperature, constraint: Fahrenheit}}. Subsequently, the system uses this condition to perform a search in the node library. The bridging nodes in the node library, such as a "unit conversion" node, will have metadata indicating that its function is "attribute conversion" and that its internal logic supports the conversion from "Celsius" to "Fahrenheit" under the "temperature" semantic. The search algorithm will match this metadata, thus returning the "unit conversion" node as a candidate result. This step establishes an automated information flow from "problem diagnosis" to "solution retrieval." Traditional workflows, when a connection fails, only provide a vague error message, completely shifting the cognitive burden of finding a solution to the user. This application, however, upgrades a passive error message system into a proactive, context-aware problem-solving engine by directly transforming the structured diagnostic information (incompatible types, source / target types) generated by the S303 into precise, machine-executable combined search criteria. This "symptomatic treatment" retrieval mechanism allows the system to simulate expert problem-solving approaches, lowering the user's barrier to entry and operational complexity, and is one of the core technologies for achieving "intelligent workflow orchestration."

[0076] S305. If multiple bridging nodes are found, the bridging node corresponding to the preset evaluation strategy and the preset preferred target will be automatically selected as the target bridging node according to the preset evaluation strategy and the preset preferred target.

[0077] This step is triggered when the S304 search result set contains two or more candidate bridging nodes. Its application scenario is when the system has found multiple repair solutions and needs to make a "selection of the best" decision. Specifically, suppose S304 found two bridging nodes for the incompatibility problem of "Celsius to Fahrenheit conversion": Node A is a locally implemented FastConverter, which is fast but has floating-point precision; Node B is a PreciseApiConverter, which calls an external high-precision meteorological API, is slightly slower but has double-precision precision. At this point, the system will load a preset evaluation strategy and a preferred target. If the preferred target is "performance priority," the evaluation strategy will prioritize "execution latency," and the system will give FastConverter a high score for its low latency, ultimately selecting FastConverter as the target bridging node. Conversely, if the preferred target is "data quality priority," the evaluation strategy will place more emphasis on the "data precision" dimension, thus selecting the more precise PreciseApiConverter. This step introduces intelligent decision-making capabilities and high configurability into the automated linking process of the workflow. Traditional toolchains, even those offering multiple options, often require manual selection by the user, disrupting the automation process. This application establishes a decision-making framework that decouples strategy and intent by separating the "evaluation strategy" from the "optimization objective." This enables the system to do more than just mechanically repair connections; it allows for optimal choices that meet pre-defined requirements based on different business contexts (e.g., speed in development environments versus stability and cost in production environments) and user preferences, thus improving the quality and flexibility of automated orchestration.

[0078] S306. If no bridging node is found, initiate a composite bridging path search to obtain the bridging link and use the bridging link as the target bridging node.

[0079] Specifically, consider an incompatible scenario: the source port outputs a CSV-formatted string containing meteorological data, such as "city, temp_c, humidity\nbeijing, 22, 0.4", while the target port requires a JSON object containing only temperature information in Fahrenheit, such as {"temperature_f": 71.6}. S304's initial search may not find an "all-around" node capable of simultaneously performing "CSV parsing," "field extraction," "unit conversion," and "format encapsulation," thus failing the search. At this point, S306 is activated, and the composite bridging path search begins. It uses the source type (CSV string) as the starting point and the target type (Fahrenheit temperature JSON) as the endpoint, searching for a reachable path in the node library. The search process might proceed as follows: 1) Find a "CSV parser" node, which converts a CSV string into a structured data array; 2) Find a "field selector" node, which extracts the `temp_c` field from the structured data; 3) Find the "unit conversion" node from the previous example, converting Celsius to Fahrenheit; 4) Find a "JSON wrapper" node, wrapping the converted values ​​into the target JSON format. Ultimately, the system obtains a bridging link consisting of these four nodes in sequence: [CSV parser -> field selector -> unit converter -> JSON wrapper]. This link is logically considered as a single "target bridging node," which can be inserted into the workflow. This step achieves a shift from "retrieving existing solutions" to "automatically synthesizing new solutions." Traditional systems in such scenarios would return the task to the user. This application, however, treats the node library as a "functional component graph," transforming the problem into a path-finding problem in graph theory. This approach expands the system's automation capabilities and scope, representing a decisive technological innovation for achieving highly intelligent and "zero-code" workflow orchestration.

[0080] Meanwhile, in some preferred embodiments, S306 further includes the following steps: S3061. Using the output port of the first working node as the initial starting point and the input port of the second working node as the final ending point, search the node library for a bridging link consisting of two or more nodes that can connect the starting point and the ending point.

[0081] Specifically, the system takes the data type declarations of the initial starting point and the final endpoint as input to the graph search algorithm. For example, the starting point might be a "CSV format string" and the endpoint might be a "JSON object containing Fahrenheit temperature". The search algorithm starts from the vertex "CSV format string" and traverses the capability graph of the node library. It finds a "CSV parser" node that can convert the starting data into a "structured object array", thus extending the path forward one step. Next, the algorithm starts from the new vertex "structured object array" and finds a "field extractor" node that can output "Celsius value". The path extends again. This process iterates continuously, exploring all possible combinations of capabilities until the data type at the end of an exploration path perfectly matches the final endpoint. Ultimately, the algorithm returns an ordered sequence of nodes like [CSV parser -> field extractor -> unit converter -> JSON wrapper], which is the bridging link. This step successfully identified a feasible solution path composed of multiple atomic capabilities, defining a goal-driven, capability-map-based path search that enables the system to simulate the thinking of human experts when solving complex problems: breaking down large problems into smaller steps, finding suitable tools for each step, and finally connecting them into a complete solution.

[0082] S3062. Generate an empty composite bridge node and load all nodes in the bridge link arranged in sequence into the composite bridge node.

[0083] The trigger condition for this step is that S3061 successfully returns a valid bridging link. Specifically, assume that the bridging link returned by S3061 is [CSV parser, field selector, unit converter]. The system first performs an operation similar to newCompositeBridgeNode(), generating an empty composite node instance, such as CompositeNode_A. Then, the system traverses the link: for the "CSV parser", the system instantiates a CSVParser object and adds it as a child node to the internal list of CompositeNode_A; simultaneously, it instantiates a FieldSelector object and adds it to the list in sequence; finally, it instantiates a UnitConverter object and adds it in sequence as well. After this step, CompositeNode_A contains three ordered but not yet connected child node instances. This step materializes an abstract, identifier-based solution blueprint (bridging link) into a structured, memory-based object containing concrete node instances (composite bridge node), providing the physical basis for the next step of internal link construction. It hides the complex, multi-step repair logic from the main workflow, keeping the main workflow topology simple and stable, and improving readability and maintainability.

[0084] S3063. Within the composite bridging node, data connections are automatically created according to the search order, and the nodes are connected in series to build an internal data processing link.

[0085] This step is triggered when S3062 completes the instantiation and loading of all child nodes. Specifically, the system obtains an ordered list of child node instances loaded by S3062 within the composite bridge node, such as [Instance_CSVParser, Instance_FieldSelector, Instance_UnitConverter]. The system starts a loop, iteratively processing adjacent node pairs starting from the first node in the list. For the first pair of nodes (Instance_CSVParser, Instance_FieldSelector), the system identifies the former's main output port (carrying the parsed structured data) and the latter's main input port. Then, the system automatically creates a data connection, binding these two ports together. This means that when Instance_CSVParser finishes execution and produces output, its result data is automatically routed to the input of Instance_FieldSelector. Next, the system processes the next pair of nodes (Instance_FieldSelector, Instance_UnitConverter), connecting their ports in the same way. This process continues until the connection between the second-to-last node and the last node in the list is established. At this point, a complete internal data processing chain is built. This step activates isolated node instances within a composite node into a coherent data processing pipeline, enabling end-to-end execution. It achieves "runtime programmatic construction" of the workflow topology. In related technologies, workflow connections are typically manually dragged and dropped by the user during the design phase; even sub-processes have their internal connections pre-defined. This application breaks through this limitation by using a solution dynamically derived from an algorithm (bridging links) to automatically execute the "connection" operations that originally required manual intervention at runtime.

[0086] S3064. After constructing the internal data processing link, the composite bridging node is determined as a logical whole as the target bridging node.

[0087] The trigger condition for this step is that S3063 successfully constructs the internal data processing link. Its application scenario is that after a complex solution is programmatically assembled, it needs to be "packaged" and "standardized" so that it can be used by upper-layer systems as a standard, plug-and-play component. Specifically, after completing the internal connections, the system performs an "interface abstraction" operation on the composite node. The system identifies the start point (the input port of the first child node) and the end point (the output port of the last child node) of the internal link, and "promotes" or "proxies" these two ports as the composite bridge node's own unique external input and output ports. Subsequently, the system marks the internal state of the composite node instance as "completed" or "sealed," formally designates it as the "target bridge node," and then returns the reference to this node to the caller (i.e., S305). At this point, from the perspective of the main workflow, it no longer knows about the multiple steps such as CSV parsing and field extraction internally; it only sees a black box named "target bridge node," which can receive a CSV string and output a JSON object containing Fahrenheit temperature. This step solidifies and abstracts a temporary, multi-part, complex structure into a single, behaviorally defined, and interface-standardized workflow component, achieving a "dynamic ontological upgrade" of the node and completing a creation "from scratch." It doesn't call an existing sub-process, but rather synthesizes a completely new functional unit—one that didn't exist at the design time—in real time based on the specific problem. This ability to dynamically generate and encapsulate new functional primitives at runtime transforms the system from a fixed toolset into an intelligent engine capable of creating new tools based on needs. This represents a breakthrough in adaptability and intelligence compared to existing workflow engines.

[0088] The visualization editing device in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference]. Figure 3 This is a schematic diagram of the physical device structure of a visual editing device in the embodiments of this application.

[0089] It should be noted that, Figure 3 The structure of the visual editing device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0090] like Figure 3As shown, the visual editing device includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 302 or programs loaded from storage section 308 into Random Access Memory (RAM) 303, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 303. CPU 301, ROM 302, and RAM 303 are interconnected via bus 304. Input / output (I / O) interface 305 is also connected to bus 304.

[0091] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including hard disks, etc.; and communication section 309 including network interface cards such as LAN (Local Area Network) cards, modems, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0092] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0093] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0094] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0095] Specifically, the visualization editing device in this embodiment includes a processor and a memory. The memory stores a computer program, and when the computer program is executed by the processor, it implements the workflow construction method provided in the above embodiment.

[0096] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the visualization editing device described in the above embodiments; or it may exist independently and not assembled into the visualization editing device. The storage medium carries one or more computer programs that, when executed by a processor of the visualization editing device, cause the visualization editing device to implement the workflow construction method provided in the above embodiments.

[0097] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0098] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0099] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method of constructing a workflow, characterized by, The method is applied to a visual editing system, and comprises the following steps: providing standardized node units to a user on a visual interface, wherein each of the standardized node units follows a unified packaging standard, and the packaging standard defines that the standardized node units comprise type metadata for declaring data types of input ports and output ports, core logic for executing atomic functions, and a dependency list for declaring requirements of a running environment; receiving a user operation of establishing a connection from an output port of a first work node to an input port of a second work node; obtaining an output data type of the output port of the first work node and a required input data type of the input port of the second work node; determining whether the output data type is compatible with the required input data type; if not, retrieving at least one target bridge node from a preset node library, wherein the input data type of the target bridge node is compatible with the output data type of the first work node, and the output data type of the target bridge node is compatible with the required input data type of the second work node; automatically inserting the target bridge node between the first work node and the second work node, and establishing a data flow from the first work node to the second work node via the bridge node.

2. The method of claim 1, wherein, The packaging standard performs hierarchical data type declaration on the type metadata of each standardized node unit, and the hierarchical data type declaration comprises: a basic type layer for defining a basic type of data at a programming language level; a semantic type layer for defining a business meaning or a domain concept of data above the basic type layer; an attribute constraint layer for adding specific formats, units or constraint conditions to the semantic type.

3. The method of claim 2, wherein, The step of determining whether the output data type is compatible with the required input data type comprises: comparing the hierarchical data type declarations of the output port of the first work node and the input port of the second work node layer by layer according to a preset priority order, wherein the priority order is the attribute constraint layer > the semantic type layer > the basic type layer; if all layers are matched, it is determined that the output data type is compatible with the required input data type; if a mismatch occurs in any layer, the comparison is immediately stopped, it is determined that the output data type is incompatible with the required input data type, and the layer in which the mismatch first occurs is recorded as a corresponding incompatible type.

4. The method of claim 3, wherein, The step of retrieving at least one target bridge node from a preset node library if the output data type is incompatible with the required input data type comprises: if the output data type is incompatible with the required input data type, performing a primary search in the node library based on the incompatible type, the hierarchical data type declaration of the output port of the first work node and the hierarchical data type declaration of the input port of the second work node as combination search conditions; if multiple bridge nodes are searched, automatically selecting a bridge node corresponding to a preset preferred target as the target bridge node according to a preset evaluation strategy and the preset preferred target; if no bridge node is searched, starting a composite bridge path search to obtain a bridge link, and taking the bridge link as the target bridge node.

5. The method of claim 4, wherein, If no bridge node is retrieved, a composite bridge path search is initiated, a bridge link is obtained, and the bridge link is taken as the target bridge node, specifically comprising: If no bridge node is retrieved, the following operations are performed: Search for a bridge link consisting of two or more nodes in the node library, which can connect the starting point and the ending point, taking the output port of the first worker node as the initial starting point and the input port of the second worker node as the final ending point; Generate an empty composite bridge node, and load all nodes in the bridge link in sequence into the composite bridge node; In the composite bridge node, automatically create data connections according to the sequence obtained by searching, sequentially connect the nodes, and build an internal data processing link; After building the internal data processing link, determine the composite bridge node as the target bridge node as a whole.

6. The method of claim 1, wherein, The method further comprises: After receiving a user instruction, determine a selected sub-workflow consisting of multiple standardized node units on the workflow canvas; Analyze the topology of the sub-workflow, and identify the data input boundary and the data output boundary connected to the outside of the sub-workflow; Create a custom node object, and create a corresponding input port according to the data input boundary and a corresponding output port according to the data output boundary; Encapsulate the complete internal logic of the sub-workflow into the internal processing logic of the custom node object; After associating the custom node object with a user-specified identifier, store it in the custom node library for subsequent direct calling.

7. The method of claim 2, wherein, The encapsulation standard further comprises a dynamic type declaration: The standardized node unit contains one or more configuration parameters, and the hierarchical data type declaration of at least one output port is associated with the value of the configuration parameter; The association is achieved through a preset mapping rule, and when the user changes the value of the configuration parameter, the hierarchical data type declaration of the corresponding output port is automatically updated.

8. A visual editing device, characterized by The visual editing device comprises one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code comprises computer instructions, and the one or more processors invoke the computer instructions to enable the visual editing device to perform the method of any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions run on the visual editing device, the visual editing device performs the method of any one of claims 1-7.

10. A computer program product, characterised in that, When the computer program product runs on the visual editing device, the visual editing device performs the method of any one of claims 1-7.

Images