Method and device for processing dynamic variables based on atlas topological relations

Abstract

This application provides a method and device for dynamic variable processing based on graph topology relationships, mainly used to solve the technical problem of illegal cross-scope references, which affects the stability of business processes and configuration efficiency. The method includes: obtaining the structure of a directed acyclic graph; traversing the directed acyclic graph structure and performing reachability analysis based on preorder connections to determine all nodes on the preorder path of the target node, forming an upstream node set; aggregating each node in the upstream node set to obtain candidate variables for reference by the target node; wherein, for composite type parameters containing nested structures, the candidate variables contain corresponding structured description information; based on the candidate variables containing structured description information, generating a dynamically accessible variable scope corresponding to the target node; within the dynamically accessible variable scope, providing a variable reference interface for the input items to be configured in the target node to display candidate variables and respond to selection operations for candidate variables.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and provides a method and device for processing dynamic variables based on graph topology relationships. Background Technology

[0002] In complex workflow orchestration scenarios, the transfer and sharing of data between different execution nodes is the core of achieving business logic automation.

[0003] In existing technologies, users are typically required to manually input variable names, or the system provides a flat list containing all output parameters within the current workflow for the user to select from. However, due to the lack of effective constraints on the execution order and logical connections between nodes, users are highly prone to making mistakes during configuration. For example, a user might reference a variable generated on its downstream path or parallel branch within a node.

[0004] From a logical perspective, such variables have not yet been generated at the time of execution of the current node, or are in an unreachable mutually exclusive logical path, and are logically considered unreachable data. This management method, lacking scope constraints, directly causes the workflow to trigger null pointer exceptions or other logical execution failures during actual runtime due to referencing data that has not yet been generated or is logically inaccessible, severely impacting the stability and configuration efficiency of the business process. Summary of the Invention

[0005] This application provides a method and device for processing dynamic variables based on graph topology relationships, which solves the technical problem of illegal cross-scope references leading to runtime null pointer exceptions, affecting the stability of business processes and configuration efficiency.

[0006] A dynamic variable processing method based on graph topological relationships, the method comprising:

[0007] Obtain the structure of a directed acyclic graph consisting of multiple functional nodes with logical connections;

[0008] When a variable reference trigger instruction for the target node is received, the directed acyclic graph structure is traversed, and reachability analysis based on the preceding connection is performed to determine all nodes on the preceding path of the target node, forming the upstream node set.

[0009] The predefined output parameters of each node in the upstream node set are aggregated to obtain candidate variables for the target node to reference; wherein, for composite type parameters containing nested structures, the candidate variables contain corresponding structured description information;

[0010] Based on the candidate variables containing the structured description information, the scope of dynamically accessible variables corresponding to the target node is generated;

[0011] Within the scope of the dynamically accessible variables, a variable reference interface is provided for the input items to be configured in the target node to display the candidate variables and respond to the selection operation for the candidate variables.

[0012] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, performs the steps of the method described above.

[0013] As can be seen, the solution provided in this application utilizes topology-based reachability analysis to dynamically limit the scope of visible variables for each node, ensuring that nodes can only reference data generated by preceding paths. This processing directly affects the generation of scopes, effectively solving the variable pollution and scope confusion problems caused by providing a global flat list, as mentioned in the background technology. Combined with the structured description definition of composite type parameters, the system can provide a reference interface, avoiding the tediousness and error-proneness of users manually writing code to extract deeply nested data. The final technical effect is: runtime null pointer exceptions caused by illegal cross-scope references are eliminated during the configuration phase; at the same time, type awareness and visual selection significantly reduce the configuration threshold for complex workflows, improving the accuracy and logical correctness of data transmission. Attached Figure Description

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

[0015] Figure 1 This is a flowchart illustrating a dynamic variable processing method based on graph topological relationships proposed in this application;

[0016] Figure 2 This is an example diagram of the structured structure in a dynamic variable processing method based on graph topology in one embodiment of this application;

[0017] Figure 3 This is a schematic diagram of the construction of a directed acyclic graph structure in a dynamic variable processing method based on graph topological relationships proposed in this application;

[0018] Figure 4 This is a schematic diagram illustrating the usage of the variable reference interface in a dynamic variable processing method based on graph topology relationships proposed in this application.

[0019] Figure 5 yes Figure 4A magnified view of region A in the middle;

[0020] Figure 6 yes Figure 4 A magnified view of region B in the middle. Detailed Implementation

[0021] 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.

[0022] Please refer to Figure 1 As shown, in one embodiment, this application provides a dynamic variable processing method based on graph topology relationships, used in a dynamic variable processing system based on graph topology relationships. The method includes the following steps:

[0023] S101. Obtain the directed acyclic graph structure consisting of multiple functional nodes with logical connections.

[0024] This step begins by constructing a basic logical foundation. The Directed Acyclic Graph (DAG) structure refers to the logical topology generated by the user through drag-and-drop, connection, or other methods within a visual canvas or workflow orchestration engine. In this structure, each functional node represents an independent business logic unit. For example, the "start node" serves as the data entry point, responsible for receiving initial data input from the user, such as user location or query keywords; the "interface node" is used to call external APIs, such as the store database of a food delivery platform, and return structured data; additionally, logical processing nodes (such as Agent nodes, database query nodes, etc.) may be included to execute specific business logic. The logical connections between nodes are represented by directional edges to indicate the direction of data flow or control flow, ensuring that the workflow has a clear execution order and avoids infinite loops.

[0025] S102. When a variable reference trigger instruction for the target node is received, the directed acyclic graph structure is traversed, and reachability analysis based on the preceding connections is performed to determine all nodes on the preceding path of the target node, forming an upstream node set.

[0026] During the workflow configuration phase, when the system receives a variable reference trigger instruction for a target node (such as a card display node used to render the UI), it initiates dynamic scope calculation. This variable reference trigger instruction typically refers to the user opening the target node's configuration panel in the visual interface and clicking the "Select Variable" button next to a configuration input item. At this point, the system performs reachability analysis based on preceding connections, utilizing the properties of a Directed Acyclic Graph (DAG) to trace upstream from the target node, retrieving all paths pointing to that node. Nodes on these paths are identified as legitimate source nodes, i.e., the set of upstream nodes.

[0027] In this embodiment, referencing variables in the configuration panel of the target node means, when configuring the business logic of the target node, selecting output parameters (variables) of defined metadata from other nodes (such as start nodes, interface nodes, and other upstream nodes) within the scope accessible to the target node in the workflow, and binding them to the configuration items of the target node as inputs or dependent data for its execution logic.

[0028] While performing topology reachability analysis, the system also filters out data that the current operator does not have permission to access based on data permission scope, to ensure that the generated candidate variable list is not only topologically reachable, but also meets the access requirements in terms of security permissions.

[0029] Typical application scenario example: Taking the "takeout store query workflow" as an example, its logical topology is as follows: Start node (responsible for receiving user location and query keywords) → Store query API node (used to call external interfaces to obtain store list and latitude and longitude information) → Card display node (i.e., the target node, responsible for rendering the store list UI). In this scenario, the card display node can reference all the standardized data produced by the preceding nodes through the variable reference interface.

[0030] This mechanism automatically masks nodes that are downstream of the target node or on parallel branches. For example, in the "Takeout Store Query Workflow," the card display node can only see data generated by the "Start Node" and the "Store Query API Node" that precede it, and cannot reference other unrelated branch variables that run parallel to it.

[0031] S103. Aggregate the predefined output parameters of each node in the upstream node set to obtain candidate variables for the target node to reference; wherein, for composite type parameters containing nested structures, the candidate variables contain corresponding structured description information.

[0032] The system extracts standardized data descriptions, or parameter metadata, from the upstream node set. These candidate variables include not only parameter names (e.g., "user location") but also their type, required fields, and purpose. For composite type parameters such as Object or Array, the structured description is presented as a schema definition in the form of a tree-like data dictionary. For example, if an API node outputs an array of "nearby stores," its structured description will define in detail the sub-fields contained in each "store object" within the array, such as "store name (String)," "rating (Number)," and "delivery fee (Number)." This deeply nested structure allows downstream nodes to accurately identify the parameter hierarchy without requiring users to manually write complex reference code (e.g., response.data.user.id).

[0033] S104. Based on the candidate variables containing the structured description information, generate the scope of the dynamically accessible variables corresponding to the target node.

[0034] The dynamically accessible variable scope, in a physical sense, is a pool of legitimate variables tailored to the target node. It is calculated in real-time based on the graph topology. If a user deletes an upstream node or changes a logical connection on the canvas, this scope will update accordingly. This scope ensures that the visibility of variables is strictly limited to logical reachability, shielding against illegal references from the configuration stage.

[0035] S105. Within the scope of the dynamically accessible variable, provide a variable reference interface for the input items to be configured in the target node, so as to display the candidate variables and respond to the selection operation for the candidate variables.

[0036] Specifically, the variable reference interface transforms the underlying abstract set of legal variables into a visual, interactive data binding entry point. As a concrete implementation scenario, this interface can manifest as a dropdown selection box or a sidebar list in a node configuration panel. Based on the dynamic scope and structured information generated in the preceding steps, this interface can implement the following interactive logic in practical applications:

[0037] First, as a visual operation entry point, this interface replaces the traditional handwritten code input method. Users do not need to remember or manually write the extraction path of upstream variables; they can simply click on the interface to complete the response selection operation, greatly reducing the operational threshold. Second, it presents a range-limited display of valid variables. Since this interface is provided within the scope of dynamically accessible variables, it only renders valid candidate variables on the preceding path of the target node. For invalid variables in downstream or parallel branches, the interface physically hides them, thus ensuring the validity of variable references at the source of interaction. Third, it provides an intuitive display based on structured information. Thanks to the structured descriptive information contained in the candidate variables, the interface does not display a disordered, flat list but rather intuitively reflects the hierarchical relationship of the data (e.g., clearly presenting the top-level object of the variable and its sub-attributes), improving the efficiency of users locating target data. Finally, based on the dynamic calculation attributes of the scope, when the upstream topology or output parameters change, the list of candidate variables displayed by this interface can be refreshed accordingly, ensuring that the user always selects the latest and most valid set of variables.

[0038] In this step, the system renders a visual interactive entry point, such as a cascading dropdown, in the configuration panel of the target node. This interface displays valid candidate variables in a hierarchical structure of the node → variable type → nested subfields. When the user expands the dropdown layer by layer and selects the target object (such as "store name"), the system responds to this operation by displaying the complete reference path in the form of a "tag" in the input field (such as ${A2.Nearby Stores List[].Store Name}), thereby completing the variable binding.

[0039] As can be seen, in this embodiment, by executing steps S101 to S105, the system utilizes topology-based reachability analysis in S102 to dynamically limit the visible variable range of each node, ensuring that nodes can only reference data generated by previous paths. This processing directly affects the generation of the scope in S104, effectively solving the variable pollution and scope confusion problems mentioned in the background art caused by providing a global flat list. Combined with the structured description definition of composite type parameters, the system can provide a reference interface, avoiding the tediousness and error-proneness of users manually writing code to extract deeply nested data. The final technical effect is: runtime null pointer exceptions caused by illegal cross-scope references are eliminated during the configuration phase; at the same time, type awareness and visual selection significantly reduce the configuration threshold of complex workflows, improving the accuracy and logical correctness of data transmission.

[0040] In one embodiment, in step S102, reachability analysis based on preorder links is performed. This application provides a specific implementation method, the implementation steps of which include:

[0041] S201. Retrieve each path pointing to the target node in the directed acyclic graph structure.

[0042] In this step, once the system identifies the target node that needs to be referenced by variables, it performs a reverse topological traversal of the constructed Directed Acyclic Graph (DAG) structure, using that target node as the endpoint. Since the edges of the DAG structure have a clear direction (representing the data flow), the system uses recursive algorithms or depth-first search (DFS) to retrieve all logical paths that ultimately reach the target node. For example, in complex business flows, there may be multiple paths (such as "start node -> node A -> target node" and "start node -> node B -> target node") pointing to the target node simultaneously. The system needs to exhaustively search these paths to ensure that no potential data sources are overlooked.

[0043] S202. Nodes on the path are identified as legitimate source nodes, and nodes on the downstream path or parallel branch path of the target node are blocked to ensure that the candidate variables are logically reachable.

[0044] In this step, the system categorizes nodes and performs access control based on the retrieved path results. A legitimate source node is one that is determined to be preceding the target node in the execution order, and whose output data has already been generated by the time the system reaches the target node. The system includes the variables generated by these nodes within its selectable range.

[0045] Meanwhile, the core logic of this embodiment lies in performing scope masking. Specifically:

[0046] Hides downstream path nodes: For example, if node C is located after the target node (i.e., the output of the target node is the input of node C), logically, node C has not yet run when the target node is executed, and its variables do not exist. The system will automatically hide such nodes in the variable selection list.

[0047] Hides parallel branch path nodes: In a workflow with conditional branches, if node D is on another branch that is mutually exclusive with the target node, or if the two have a common upstream but no direct or indirect sequential connection relationship, then the variables generated by the node are considered to be logically unreachable, and are also grayed out or hidden.

[0048] To make it easier to understand, let's take the "takeout store query workflow" as an example. If a user is configuring the "store query API node", the system will identify the "start node" in its preceding path as a legitimate source. At this time, the "card display node" (located downstream) used to display the results and another unrelated "weather query branch node" (located in a parallel branch) will be hidden, thus ensuring that the user can only see the truly usable variables.

[0049] As can be seen, in this embodiment, by executing S201 and S202, the system utilizes the topological characteristics of a directed acyclic graph to achieve topological scoping. By retrieving paths pointing to the target node and determining legitimate source nodes, the system can accurately identify the logical flow of data; and by shielding downstream and parallel branch nodes, the possibility of illegal references is forcibly eliminated during the configuration phase. This logical reachability verification directly solves the problem of users mistakenly referencing variables that have not yet been generated or are logically invisible due to the provision of a global flat list. Thus, runtime null pointer exceptions caused by data reference logic errors are avoided during the orchestration phase, significantly enhancing the stability and logical rigor of complex workflows.

[0050] In one embodiment, for structured description information, this application provides a configuration generation method based on a tree-like data dictionary, specifically including the following steps:

[0051] S301. Obtain the parameter metadata definition information for the functional node, which serves as a standardized data specification provided by the functional node to its downstream nodes.

[0052] The core purpose of this step is to establish a unified data specification protocol for the output of each node. When a user adds a node to the visualization canvas, the system will automatically pop up a parameter metadata configuration panel, guiding the user to define the output parameter rules for that node. Essentially, this allows the node to inform downstream nodes of the specifications of its output data in advance.

[0053] The parameter metadata is essentially data describing data, containing four key dimensions:

[0054] Parameter Name: A semantic identifier for the parameter, such as "user location" or "store name," to reduce the memory burden on configuration personnel. To lower the barrier to understanding, parameter names should be concise and semantically clear (e.g., using "user location" instead of "location" in the underlying code) to avoid confusion with other parameters and facilitate identification by non-technical orchestrators.

[0055] Parameter data type: Specifies the physical storage format of the data. In this embodiment, it is standardized to four types: String, Number, Object, and Array to ensure data compatibility between upstream and downstream nodes.

[0056] Required attribute: Marks whether this parameter is a necessary condition for the process to continue. If marked as "yes", an exception will be triggered if the data is empty during runtime.

[0057] Usage description information: Detailed supplement to the business meaning of the parameter, such as "used to filter takeout stores within 3 kilometers", to help subsequent users quickly understand the intent of the parameter.

[0058] Metadata definitions must explicitly define four key attributes for each output parameter: name (unique identifier), type (standardized format), required field (necessary condition for execution), and description (purpose description, such as "used to filter takeout stores within 3 kilometers").

[0059] As an example, the system only supports four standardized data types to ensure upstream and downstream compatibility: String (e.g., store name), Number (e.g., rating, price), Object (composite data with nested sub-attributes), and Array (a collection of data of the same type, such as a list of stores).

[0060] S302. If the parameter data type is a composite type that includes an object type or an array type, then the structured definition mode is enabled.

[0061] When the system recognizes that the parameter type is not a simple basic type (such as String or Number), but a composite type such as Object or Array, it will automatically trigger the structured definition mode. It's important to understand that a composite type refers to a complex data structure that internally contains several attribute branches or similar data sets. At this point, the system will pop up a visual editing panel (such as the "Object Structure Editing Panel"), guiding the user to define the internal details of the complex object in depth, rather than simply treating it as a black box of data.

[0062] S303. Obtain at least one level subfield and its corresponding subparameter metadata added for the composite type, and define the array elements contained in the array type as structured objects with subordinate relationships.

[0063] In the structured definition mode, at least one level of sub-fields and their corresponding sub-parameter metadata added for the composite type are obtained, and the array elements contained in the array type are defined as structured objects with subordinate relationships. Users can define the embedded attributes of the data layer by layer:

[0064] For Object types: Users can add subfields (such as "longitude" and "latitude") and configure metadata such as name and type for each. They can even add subfields under subfields to form multiple levels of nesting.

[0065] For Array types: The system will prompt the user to select the type of the array elements. If the element is of type Object, the system will define each array element as a sub-object with an independent structure. For example, in the "Nearby Stores List" array, each element is defined as a structured object containing fields such as "Store ID" and "Rating".

[0066] Specifically, such as Figure 2 As shown, for array type parameters, the system provides a dedicated structured definition entry point to achieve fine-grained control over the elements within the collection. Taking the "Nearby Stores List" parameter output by the "Store Query API Node" as an example, when the user selects "Array" as its data type in the configuration panel, the system will pop up an array element type selection box. If an instruction to select the object type for the array element is received, the "Settings" button will automatically appear on the right side of the parameter as a visual operation entry point.

[0067] After the user clicks the "Settings" button, the system enters the "Array Element Structure Editing Panel," guiding the user to configure the nested structure of the array elements hierarchically, thereby transforming the abstract collection data into a parsable tree model:

[0068] Define first-level subfields: Users add multiple parallel attributes to array elements in the editing panel and set their sub-parameter metadata one by one. For example:

[0069] Store ID: Set the data type to String, the required field to "Yes", and the description to "Unique Store Identifier";

[0070] Store Name: Set the data type to String, the required field to "Yes", and the description to "Store's publicly displayed name";

[0071] Store Information: Set the data type to the composite type Object, the required field to "Yes", and the description to "Detailed Store Information".

[0072] Define deeply nested subfields: For the "Store Information" Object type subfield mentioned above, users can recursively add subordinate fields (i.e., subfields) to achieve a complete definition of the deeply nested JSON structure:

[0073] Rating: Data type is Number, description is labeled "Store User Rating, 1-5 points";

[0074] Delivery fee: The data type is Number, and the description clearly states that the unit of measurement is "yuan";

[0075] Operating status: Data type is String, description is "Open / Closed".

[0076] S304. Generate the tree-structured data dictionary based on the hierarchical relationships between the subfields at each level.

[0077] The system automatically generates a tree-structured data dictionary based on the hierarchical logic defined in S303. This tree-structured data dictionary refers to a logical structure that represents the hierarchical relationship of data attributes, where the root node is the top-level parameter, branch nodes are intermediate-level objects, and leaf nodes are the final basic type fields. This dictionary structure can transform complex API return results (such as deeply nested JSON) into an intuitive, expandable visual directory.

[0078] Through the above multi-level recursive definition, the system ultimately generates a tree-structured data dictionary as shown in the figure. In this dictionary, the root node is "List of Nearby Stores," and its subordinate branches not only contain first-level store attributes (such as store ID) but also deeply nested business metrics (such as ratings and delivery fees). This structured descriptive information allows downstream nodes to directly access the underlying attributes of array elements through a visual interface, much like consulting a catalog, when referencing variables. This completely solves the pain point of existing technologies that require manually writing code (such as response.data.list[i].info.score) to extract deeply nested data.

[0079] As can be seen, in this embodiment, by executing S301 to S304, the system utilizes the metadata definition function to transform the originally scattered and ambiguous node outputs into the standardized data specification described in S301, thus solving the pain point of chaotic type matching in the prior art. Through the cascading definition logic of S302 and S303, the system can recursively capture the deep semantic structure within the composite data and ultimately generate the tree-like data dictionary shown in S304. This processing mechanism provides precise data navigation for downstream nodes, allowing users to directly select deep fields (such as "store list -> store information -> rating") through a visual tree-like list without having to manually write complex JSON parsing code. This not only significantly reduces the configuration threshold but also avoids data extraction failures caused by spelling errors in handwritten code or misunderstandings of type by forcing type definitions, significantly improving the accuracy of data referencing and development efficiency.

[0080] In one embodiment, this application provides a specific interaction method for executing cascading references through a variable reference interface. Executing variable references through the variable reference interface specifically includes the following steps:

[0081] S401. Display the top-level candidate variable list within the scope of the dynamically accessible variable in the first-level menu of the variable reference interface.

[0082] In this step, when a user triggers the select variable button next to the input item to be configured on the target node (such as the "store name display position" on a card display node), the system first renders the content of the first level through a variable reference interface (such as a cascading selector interaction device). The first-level menu refers to the initial display layer of the interactive interface, and its content is determined by the scope of dynamically accessible variables generated by the aforementioned topology analysis. In this menu, the system categorizes and lists items according to their respective nodes, for example, displaying the top-level entry points "Start Node" and "Store Query API Node." This categorized display method allows users to quickly locate a general range based on the data source, avoiding the inefficiency of blindly searching through massive flat lists.

[0083] S402. In response to the selection operation for the target composite type candidate variable, perform cascading expansion logic based on the tree-like data dictionary to display the corresponding subordinate level menu.

[0084] When a user selects a variable with a composite type (such as Object or Array) in the primary menu (e.g., selecting "Nearby Stores List"), the system captures this selection and triggers a cascading response. At this point, the system no longer needs to request backend data in real time, but instead directly retrieves a pre-generated tree-structured data dictionary.

[0085] The so-called cascading expansion logic refers to the system automatically calculating and rendering a list of subfields within a composite variable based on the hierarchical relationships in the dictionary. For example, since "Nearby Stores List" is defined as an array containing store objects, the system will automatically expand to a second-level menu to display "Array Elements (Object)"; if the user continues to click, it will further expand to a third-level menu to display subfields such as "Store Name" and "Rating". The entire process can be navigated step-by-step with mouse clicks, transforming abstract code paths into intuitive navigation paths.

[0086] S403. Determine the target reference object by locating the subordinate menu layer by layer, and bind the target reference object to the input item to be configured of the target node.

[0087] In this step, the user is visually guided to navigate through a cascading menu until they pinpoint the smallest unit of data they need (i.e., the target reference object, such as "store name"). Once the user clicks, the system performs a "binding" action, establishing a mapping between the complete logical access path of the subfield (such as a specific field index in the API node's output data) and the input parameters of the target node. This binding ensures that, during the actual workflow execution, the target node can accurately retrieve the corresponding value from the upstream node's output cache along this path.

[0088] As can be seen, in this embodiment, by executing S401 to S403, the system utilizes the cascading expansion logic in S402 to dynamically associate the top-level variable in S401 with the tree-like data dictionary in S304. This feature directly transforms the complex deep-structure data referencing process into a WYSIWYG visual navigation experience. Its benefits include: completely solving the problem of lacking structured referencing in traditional solutions. Moreover, users no longer need to remember or manually write any access code similar to response.data.list[0].name, greatly reducing the technical threshold for business orchestration and avoiding spelling or syntax errors caused by handwritten code from an interactive perspective. Simultaneously, the layer-by-layer positioning mode improves the positioning accuracy when processing ultra-large-scale JSON objects, making the cascading selection of complex data efficient and reliable.

[0089] In one embodiment, after binding the target reference object to the input item to be configured in the target node, this application provides a method for enhancing the transparency and stability of references through echoing and monitoring, specifically including the following steps:

[0090] S501. Display a path identifier at the input field to be configured, which reflects the complete reference path of the target reference object.

[0091] In this step, after the user selects the target variable using the cascading selector, the system doesn't simply fill in a static value in the configuration box; instead, it generates a semantic path identifier for display. This path identifier is typically represented physically as a highlighted tag. Specifically, this identifier fully reflects the logical access path of the variable throughout the entire graph topology. For example, if the user references the name field in the store list generated by interface node A2, the path identifier might be displayed as {A2.Nearby Store List[].Store Name}. This display method transforms complex code-level references (such as response.data.list[i].name) into readable path identifiers, allowing configuration personnel to instantly identify the source node, object hierarchy, and specific attribute name of the data, thus achieving semantic transparency of the reference logic.

[0092] S502. Establish a dynamic binding relationship between the input item to be configured and the source data corresponding to the target reference object.

[0093] The core of this step lies in establishing a low-level pointer-based association. The so-called dynamic binding relationship means that the system links the input items of the target node with specific schema nodes (i.e., source data definitions) in the metadata of the upstream node in the background, rather than simply copying text.

[0094] As an example, the system assigns a unique reference ID to each reference record and registers it in a global reference relationship table. This binding mechanism ensures that the target node can perceive the state of upstream variables in real time. As long as the workflow is not disrupted, regardless of how the upstream data is dynamically populated at runtime, the downstream node can accurately obtain the corresponding real-time value by following this binding path.

[0095] S503. Adjust the reference status of the input item to be configured in real time according to the structural changes of the source data.

[0096] This step provides a preventative error correction mechanism. In complex workflow iterations, the output structure of upstream nodes may change, for example, a developer might delete a field or rename an object property. Thanks to the dynamic binding established in S502, the system monitors the integrity of the source data structure in real time. Once a referenced source field is detected to have changed, has a type mismatch, or has been physically deleted, the system immediately triggers the reference state adjustment logic. Specific handling methods include, but are not limited to: marking the corresponding path identifier as invalid (e.g., turning it red or flashing) on ​​the configuration interface, outputting a warning signal indicating a synchronous change, or automatically attempting to find a new matching path based on semantic similarity.

[0097] As can be seen, in this embodiment, by executing S501 to S503, the system utilizes the path identifier echoing mechanism in S501 to solve the problem of high barriers to entry and easy errors in writing code manually in traditional processing, making complex nested references intuitive and easy to audit. Through the dynamic binding relationship established in S502, combined with the real-time state adjustment function in S503, this feature directly solves a core pain point: when the upstream data structure undergoes unexpected changes, traditional static references can cause the workflow to crash during runtime. Therefore, the processing method of this embodiment gives the system extremely strong structure awareness and reference robustness. During the configuration phase, users can clearly perceive the variable lineage; during the maintenance phase, the system can automatically identify and warn of invalid references, greatly reducing the operation and maintenance costs of long-link workflows and ensuring the continuous and stable operation of data flow in changing environments.

[0098] In one embodiment, when providing the variable reference interface, this application embodiment provides a type-aware intelligent filtering mechanism, which further includes executing type filtering logic, specifically including the following steps:

[0099] S601. Obtain the input data type required by the input item to be configured.

[0100] During workflow orchestration, when a user clicks on the variable reference interface next to a configurable input item in a target node (such as the "rating display position" of the "card display node"), the system first parses the admission protocol defined in the metadata for that input item.

[0101] The input data type refers to the data format specifications that a functional node must receive to complete specific business logic. Physically, it represents the physical specifications of the node's input port. For example, if the input item is used to perform numerical calculations or render star ratings, its defined input data type is typically Number; if it's used to display text descriptions, it's defined as String. This step provides a comparison benchmark for subsequent precise filtering.

[0102] S602. Compare the output data type corresponding to the candidate variable with the input data type.

[0103] After generating a dynamically accessible variable scope, the system iterates through all candidate variables within that scope. For each candidate variable, the system extracts its predefined output data type attributes from the upstream node's declaration phase.

[0104] The specific processing procedure is as follows: The system compares the target type required by the current input item with the source type held by the candidate variables one by one. This comparison process is not limited to top-level variables, but also delves into subfields within the Object or elements in the Array. For example, the system will determine whether the "delivery fee" field (Number) returned by the upstream API matches the current input field (Number). This automated comparison logic replaces manual judgment, solving the pain point in existing technologies where users find it difficult to intuitively determine whether the upstream variable type meets the requirements.

[0105] S603. Based on the comparison results, perform type-aware intelligent filtering or output a type conversion prompt signal.

[0106] Based on the compatibility comparison results, the system executes differentiated interactive controls in variable reference interfaces (such as cascading dropdowns):

[0107] Non-selectable state configuration: If the output data type of a candidate variable is completely incompatible with the type required by the input item (and cannot be converted), the system will configure the candidate variable and its subfields as non-selectable in the interface. This will manifest as the option being grayed out or hidden directly from the list. For example, when the input box requires a number, the system will automatically filter out upstream variables of type string.

[0108] Type Conversion Hint: As a preferred approach, for variables whose types do not match but support logical conversion (e.g., the input field requires Number, but the candidate variable is a String containing numeric characters), the system will output a type conversion hint signal while displaying the variable. This signal can be represented by an exclamation mark icon next to the option or floating text, prompting the user that automatic or manual type casting may be required after referencing the variable.

[0109] As can be seen, in this embodiment, by executing S601 to S603, the system utilizes the real-time comparison logic in S602 to transform the input constraints identified in S601 into dynamic interactive feedback in S603. This process introduces a type-aware dimension, making variable referencing no longer a simple name match, but a deep data specification verification. Intelligent error correction is achieved during the configuration phase. By automatically filtering variables that do not conform to the type, runtime errors in the workflow caused by data type mismatches (such as system crashes caused by passing strings into numerical calculation functions) are forcibly avoided at the interaction level. This not only significantly reduces the user's configuration error rate, but also improves the flexibility of variable referencing through the prompt conversion mechanism, further lowering the threshold and debugging cost of complex logic orchestration.

[0110] In one embodiment, the candidate variables are displayed in the variable reference interface. This application embodiment provides an enhanced interaction method based on the synchronous display of semantic annotation and descriptive information, specifically including the following steps:

[0111] S701. When displaying the candidate variable in the variable reference interface, the purpose description information in the parameter metadata definition information is displayed simultaneously.

[0112] The core of this step lies in making the configuration information contextually transparent. The so-called usage description information refers to the text description that is manually entered by the configuration personnel during the node output parameter definition stage (such as step S301) to explain the meaning of the data service.

[0113] In the specific processing, when a user opens the variable reference interface of the target node and browses the candidate variable list, the system not only displays the variable name but also simultaneously extracts and renders the corresponding usage description of the variable through floating windows, information bubbles, or sidebars. For example, when a user selects the "user location" variable, the interface will simultaneously display "the user's current latitude and longitude information, used to filter takeout stores within 3 kilometers." This synchronous display mechanism ensures that the user can obtain the original design intent of the variable in real time without having to return to the upstream node to view the configuration, greatly improving the efficiency of information transmission.

[0114] S702. Use the semantic parameter names to label the candidate variables and their corresponding subfields.

[0115] This step aims to replace obscure underlying code identifiers with semantic annotations. Semantic parameter names refer to unique identifiers with clear business meanings used when defining metadata. For example, using "user location" instead of "location", or "store name" instead of "name_01".

[0116] In the variable reference interface, the system not only semantically annotates top-level candidate variables but also recursively applies this annotation to all nested sub-fields. For example, under the composite variable "List of Nearby Stores," its internal structured sub-fields are clearly labeled as "Store ID," "Rating," and "Delivery Fee," rather than the JSONKey returned by the original API. Through this semantic hierarchical annotation, the system provides users with a data map that is highly aligned with business logic.

[0117] As can be seen, in this embodiment, by executing S701 and S702, the system introduces the non-technical metadata defined in S301 into the interaction interface of S105. Semantic naming solves the problem mentioned in the background art where users find it difficult to intuitively judge upstream variables; simultaneously, by synchronously displaying usage descriptions, it further eliminates ambiguity in data transmission across nodes. The specific effects are: significantly reducing the cognitive load on business orchestrators, enabling non-technical personnel to accurately locate the required deep data fields using intuitive business terminology. This not only avoids or reduces workflow logic errors caused by misusing variables with similar meanings but different functions (such as mistakenly using "distribution center location" as "user location"), but also significantly shortens the configuration and auditing cycle of complex business processes by improving the readability of variable selection.

[0118] In one embodiment, this application provides a real-time monitoring and early warning mechanism for ensuring data consistency in long-link workflows. Please refer to [link / reference]. Figure 2 The method also specifically includes the following steps:

[0119] S801. Monitor in real time the structural changes of the predefined output parameters of each node in the upstream node set.

[0120] In this step, the system establishes a metadata monitoring logic based on a publish-subscribe pattern or a heartbeat detection mechanism to track the lifecycle of variables defined by upstream nodes in a Directed Acyclic Graph (DAG) structure. The so-called structural change, in a physical sense, refers to any incompatible modifications made by upstream nodes to the tree-like data dictionary (Schema) they output in the parameter metadata configuration panel, including but not limited to renaming field names, changing data types (such as changing Number to String), and adjusting the paths of deeply nested attributes.

[0121] As an example, the system calculates a unique hash value for the standardized data specification generated for each functional node. When the orchestrator modifies the output definition of the start node or interface node, this hash value changes. By comparing the differences in hash values, the system can identify structural fluctuations in the upstream output parameters in real time. This real-time monitoring ensures that the system can detect potential failure risks at downstream references the instant upstream data changes.

[0122] S802. If it is detected that the source data structure corresponding to the target reference object has been changed or deleted, then output a synchronous change prompt message in the variable reference interface or at the input item to be configured.

[0123] In this step, the system performs precise risk location based on the monitoring results of S801. When the system identifies that a specific subfield (i.e., the target reference object) referenced by a downstream target node has been deleted at its source, or that its nesting level has been broken, it will immediately trigger the synchronization change prompt logic.

[0124] Specifically, the scenarios for outputting prompts include two dimensions:

[0125] The echo prompt at the input field to be configured: In the configuration panel of the target node, the path identifier (such as path label) that was originally displayed will change from a normal state to an abnormal state (such as turning into a red highlight or displaying a warning icon), and a text description will pop up (such as the reference source has been deleted or the type does not match) to intuitively inform the user that the reference has become invalid.

[0126] Dynamic updates within the variable reference interface: When the user reopens the cascading selector (variable reference interface), the system will re-render the list of valid variables in real time, removing, graying out, or marking up deleted or invalid variables to ensure that the user cannot select data that no longer exists.

[0127] As can be seen, in this embodiment, by executing S801 and S802, the system utilizes a real-time monitoring mechanism to break down the silos of configuration information between nodes and establish a reference-based tracing link. Through timely synchronization change prompts, it directly solves the core pain point of runtime null pointer exceptions caused by logically unreachable variable references. This provides an automated error prevention and correction barrier for complex workflow iterations.

[0128] It's worth noting that, especially for large projects, when upstream interfaces adjust their data structures, downstream configurers don't need to manually check each node one by one. The system can automatically locate the affected reference points and issue warnings. This significantly reduces the risk of workflow failures due to data source changes, greatly improving the system's stability during long-term operation and maintenance, as well as the debugging efficiency for developers.

[0129] In one embodiment, for a directed acyclic graph structure, this application embodiment specifically defines the types of functional nodes contained therein, specifically including the following steps:

[0130] S901 provides a start node, which serves as the data entry point for the workflow and receives initial input data.

[0131] In this step, the start node is the initial trigger point of the entire Directed Acyclic Graph (DAG) structure. Its primary responsibility is to define the external inputs required to start the workflow. The start node is considered the data entry point for the workflow, independent of any upstream node, and directly receives raw parameters from the user interface, triggers, or external callers. For example, in a "takeout store query workflow," the start node is responsible for receiving initial data input by the user, such as the user's "current location (latitude and longitude)" or "query keywords." This data serves as the "seed variables" for the entire process, providing the foundational material for the execution of subsequent nodes.

[0132] S902 provides an interface node for calling external interfaces to obtain structured return data.

[0133] In this step, the interface node acts as a bridge for the workflow to interact with the external world (such as third-party services, databases, or APIs). The interface node typically calls external APIs (such as map location interfaces, store database interfaces, etc.) via standard network protocols (such as HTTP / HTTPS). After the call is completed, the interface node receives and parses the raw information returned by the external system. The core function of the interface node is to transform unstructured or semi-structured external responses into the structured return data described in this application (such as a store list object), so that downstream nodes can accurately extract subfields through a cascading reference mechanism.

[0134] S903. Provide a logic processing node for executing business logic based on candidate variables of the upstream node set.

[0135] In this step, the logic processing nodes are responsible for further processing, judging, or transforming the acquired data. These nodes include, but are not limited to, Agent nodes (such as store recommendation agents), database query nodes, or custom script nodes. Their execution requires obtaining candidate variables as input from the upstream node set through a variable referencing interface. For example, a "store recommendation Agent node" might reference the "store list" variable returned by the interface node, combine it with the "query keywords" from the starting node, and use internal logic algorithms to filter out the three stores that best meet the user's needs. This type of node realizes the transformation from raw data to business decisions.

[0136] As can be seen, in this embodiment, the application decouples the functions and clarifies the responsibilities of the nodes in the directed acyclic graph. The functional nodes in the directed acyclic graph structure include start nodes, interface nodes, and logic processing nodes. S901 ensures the singularity and standardization of data sources, avoiding the chaos of initial data entry. S902 solves the source problem of complex object references by transforming external interface data into parsable structured output, providing a data carrier for the tree-like data dictionary. S903 achieves the closed loop of business logic by referencing upstream variables, ensuring the smooth flow of data between nodes of different properties. Thus, by dividing nodes into three core categories—entry, acquisition, and processing—the system establishes a clear data responsibility system. This not only makes the workflow topology easier to understand and maintain, but more importantly, combined with the variable management mechanism based on topology relationships, it enables different types of nodes to achieve precise collaboration within a unified variable scope, significantly reducing the error rate when configuring deeply nested data (such as JSON returned by APIs), and greatly improving the robustness of complex business process orchestration.

[0137] In one embodiment, the process of generating a tree-like data dictionary for the array type is described in this application embodiment, which provides a specific implementation method for defining complex data of collection class, specifically including the following steps:

[0138] S1001. In response to the selection operation for the array type, display the array element type selection box.

[0139] In this step, when a user specifies the basic data format of an output parameter (such as "Nearby Stores List") as Array in the parameter metadata configuration panel, the system recognizes that the parameter is a collection of similar data. Since the specific data formats stored within an array vary, the system will then trigger and display an "Array Element Type Selection Box." The array element type selection box is an interactive component used to define the physical specifications of individual data items within the collection. This selection box allows the user to specify whether each element in the array is a basic type (such as String or Number) or a composite type (such as Object).

[0140] This interactive step solves the problem of overly general descriptions of set data in existing technologies, providing a logical premise for subsequent precise analysis of the deep internal structure of arrays.

[0141] S1002. If an object type selection instruction for the array element type is obtained, a structured definition mode is enabled for the array element to define the subfields at each level inside the array element.

[0142] When structured definition mode is enabled, the system displays either the "Object Structure Editing Panel" or the "Array Element Structure Editing Panel". The left side of this panel displays a structure tree, such as... Figure 2 As shown, this displays the currently defined hierarchical structure; the right side is the "Subfield Configuration Area," used to input metadata for specific sub-parameters. During the definition of subfields, the system supports entering detailed business numerical references, such as: Longitude / Latitude: Type is Number, described as "the user's location's East longitude / North latitude (e.g., 120.1234, 30.5678)"; Rating: Type is Number, described as "1-5 points"; Delivery Fee: Type is Number, with the unit explicitly stated as "Yuan" in the description; Business Status: Type is String, described as "Open / Closed".

[0143] When a user selects an "Object" (object type) from the selection box, it means that each element in the array is not a single numerical value, but a complex entity containing multiple attributes. At this point, the system automatically activates a structured definition mode for this virtual hierarchy of array elements. The structured definition mode means that the system assigns array elements an independent set of schema attribute editing permissions, giving them a hierarchical relationship subordinate to the array parameters.

[0144] For example, in the "takeout store search" scenario, when the "nearby store list" is defined as an array with elements of Object, the system essentially creates a standardized data archive template for "each store." In structured definition mode, users can add specific attribute items to array elements just like defining independent Object parameters. The specific process includes: the user clicks the "Add Subfield" button to define first-level subfields for the array elements, such as "Store ID (String)," "Store Name (String)," and "Store Information (Object)." If the subfield itself is still a composite type, the system supports adding more subfields (such as "Rating" and "Delivery Fee"), thus forming a complete tree-like data dictionary. This recursive definition method ensures that even in multidimensional arrays or deeply nested lists, downstream nodes can accurately extract each piece of data using the path identifier {A2.Nearby Store List[].Store Name}.

[0145] As can be seen, in this embodiment, by executing S1001 to S1003, the system utilizes the element type selection mechanism in S1001 to transform the traditional flat array declaration into a structured definition with element awareness capabilities, as shown in S1002. This addresses the pain point of many complex objects (such as JSON returned by APIs) having deeply nested structures and making it difficult to intuitively determine their types. It also implements a penetrating reference for fields within a collection. By enabling a structured definition mode for array elements and supporting fine-grained configuration of sub-fields at each level, the system can transform object attributes within arrays, which were originally difficult to parse at the code level, into a visual tree-like dictionary. This allows users, when configuring downstream nodes, to accurately select specific fields within array elements with simple clicks, even when faced with complex API list results, without needing to manually write loops or index parsing code. This significantly lowers the configuration threshold for complex data structures and effectively improves the accuracy of data streams when processing large-scale collection data.

[0146] In one embodiment, the process of displaying the top-level candidate variable list in the first-level menu of the variable reference interface provides a display method based on topological hierarchy classification and explicit reminders of required fields, specifically including the following steps:

[0147] S1101. The candidate variables within the scope of the dynamically accessible variables are classified and displayed according to the node level and variable type in the upstream node set.

[0148] In this step, when rendering the variable reference interface (such as the drop-down selection box), the system abandons the traditional unordered flat listing method and instead introduces a multi-dimensional structured display logic. The so-called node hierarchy, in a physical sense, refers to the sequential position of each legitimate upstream node in the topological sorting or the division of business modules in a directed acyclic graph structure; the so-called variable type refers to the data specification (such as Object, String, Array, etc.) defined for that parameter in the metadata.

[0149] In the specific processing, when a user clicks to enter the variable reference entry, the system extracts all legal candidate variables within the scope of dynamically accessible variables and first groups them according to the node hierarchy of the data source. As an example, in the card display node configuration interface of the "Takeout Store Query Workflow," the drop-down box clearly divides the "Start Node A1" area and the "Store Query API Node A2" area. Subsequently, under each node group, the system further identifies or aggregates candidate variables based on their variable types, for example, explicitly marking "User Location" as an Object type and "Query Keyword" as a String type. The design principle is that by reconstructing the data structure, users can intuitively locate the target variable in the required format in the corresponding upstream node directory, following the workflow. The specific display format is not limited and can be adjusted according to actual interface requirements.

[0150] S1102. For candidate variables marked as required attributes, perform explicit annotation reminders in the variable reference interface.

[0151] This step aims to strengthen the binding constraints of key data during the configuration phase through visual interaction guidance. Required attributes refer to core data markers that are marked as essential for the workflow to continue execution or for the downstream node to render correctly when the output parameter metadata is defined in the upstream node. Explicit annotations refer to overlaying high-contrast visual recognition elements on variables with these attributes at the interface interaction level.

[0152] Specifically, while rendering the categorized display list, the system reads the required metadata for each candidate variable. If a variable is identified as having a required attribute of "yes" (e.g., "user location" or "store name"), the system automatically renders an explicit label next to the variable name, such as adding a red asterisk (*), bolding the text, or attaching a micro-label with the words "required." Conversely, if the attribute is "no" (e.g., optional "query keywords"), the display remains normal or the label is weakened. This mechanism has a wide range of applications, especially in complex API response results with dozens of optional parameters, which can greatly focus the user's attention.

[0153] As can be seen, in this embodiment, by executing S1101 and S1102, the system utilizes the node-level and variable-type classification mechanism in S1101 to transform the originally abstract and lengthy set of legal variables into a well-structured data directory. This allows users to quickly retrieve target variables based on business context, significantly improving the efficiency and accuracy of variable selection. Simultaneously, combined with the explicit labeling of required fields introduced in S1102, the system provides a powerful configuration guide from a visual interaction perspective. While reducing the cognitive load and operational threshold for configuration personnel, it also pre-emptively verifies process specifications, effectively preventing fatal errors such as null pointer exceptions or missing data in subsequent workflows due to users omitting key required fields from a vast amount of parameters, further ensuring the logical integrity of business orchestration.

[0154] In one embodiment, for data verification during the actual execution phase of a workflow, this application provides a runtime exception blocking method, which specifically includes the following steps:

[0155] S1201. During workflow execution, identify the required attributes corresponding to the referenced target object.

[0156] In this step, the system's operational state switches from the configuration and orchestration phase to the actual workflow runtime. Workflow runtime, in physical terms, refers to the execution cycle in which the directed acyclic graph structure is loaded by the computing engine and begins processing real business data. During this phase, when the computing engine schedules to the target node and prepares to inject actual data into its input items, the system first reads the parameter metadata of the target reference object (i.e., a specific field output by the upstream node) to which the input item is bound, and extracts the required attributes. As an example, these required attributes are assigned in the earlier metadata definition phase to mark whether the parameter is a necessary condition for the workflow to continue execution. For instance, in a food delivery store query scenario, the "user location" parameter or the "store name" field in the store list returned by the interface is usually marked as required because the lack of this core data would render subsequent card display or route planning meaningless.

[0157] S1202. If the required attribute is identified as yes and the data is empty, an exception prompt signal is triggered and the execution logic of the current node is interrupted.

[0158] After extracting the status of required attributes, the system performs null value validation on the data payload transmitted from upstream nodes in real time. When the system identifies that the required attribute of the target reference object is explicitly marked as yes, but the actual data it carries is empty (for example, the upstream interface call is abnormal and the structured field is not returned, or the front-end user has omitted the form field used as the starting point), the system will immediately trigger the security protection mechanism.

[0159] The specific processing procedure is as follows: The system first triggers an exception warning signal. This signal is not specifically limited; it can manifest as an alarm log outputting the node's location in the monitoring backend during workflow execution, or as a placeholder message "Critical data retrieval failed" displayed on the end-user presentation card. Next, the system forcibly interrupts the execution logic of the current node. This means the target node will be suspended or terminated, refusing to continue actions such as UI rendering, database writing, or initiating new downstream interface calls, thus strictly intercepting data anomalies within the current node.

[0160] The technical solution provided in this embodiment effectively prevents nodes lacking critical dependency data from being forcibly executed by introducing dual verification features for required attributes and empty data during workflow runtime, and by triggering prompt signals and interrupting logic when risks are identified. At the execution level, it completely avoids downstream node logic crashes, invalid empty page rendering, or unexpected null pointer exceptions caused by missing upstream critical data, thereby greatly improving the fault tolerance and system robustness of complex graph topology workflows in real business scenarios.

[0161] To facilitate understanding of the implementation process of the above embodiments, the following section will break down the specific scenarios and operations of variable referencing, using specific scenario examples (such as the workflow for querying takeout stores).

[0162] Taking the "Takeout Store Query Workflow" as an example (flow: Start node A1 → Store Query API node A2 → Card Display node B), node B is the "Card Display Node," whose core function is to render the store list UI. It needs to reference the output variables of A1 and A2. The following is the complete operation and explanation of "Reference variables in the configuration panel of node B":

[0163] 1. Preconditions (variables are already defined in metadata)

[0164] The starting node A1 has defined output variables: "User Location (Object, including longitude / latitude subfields)" and "Query Keyword (String)";

[0165] The store query API node A2 has defined output variables: "List of nearby stores (Array, including store name / rating / delivery fee subfields)" and "Query distance threshold (Number)";

[0166] The scope calculation logic has been pre-determined: the accessible scope of node B is "the workflow global scope + the local scope of A1 / A2", therefore node B can reference all output variables of A1 and A2.

[0167] 2. Detailed steps for referencing variables (within the configuration panel)

[0168] When a user opens the "UI Rendering Configuration Panel" of node B (card display node), the "Variable Reference" operation is divided into 3 steps, each of which intuitively demonstrates the core action of referencing:

[0169] ① Accessing the variable reference entry point:

[0170] Next to each configuration item in the panel that requires dynamic data (such as "Store Name Display Position", "Rating Display Position", "Delivery Fee Display Position"), there is a "Select Variable" button - this is the entry point for variable referencing. After clicking, a "List of Referenceable Variables" will pop up (the list is generated by the scope calculation logic and only displays variables that can be accessed by node B).

[0171] ② Select the variable to be referenced:

[0172] Taking the configuration of "Store Name Display Position" as an example, after clicking "Select Variable", the list displays the referenceable variables categorized by "Node Level + Variable Type":

[0173] plaintext

[0174] List of referable variables (scope evaluation results):

[0175] ├─Start Node A1

[0176] │├─User Location (Object)

[0177] ││├─Longitude (Number)

[0178] ││└─Latitude (Number)

[0179] │└─Search Keywords (String)

[0180] └─Store Query API Node A2

[0181] ├─ List of nearby stores (Array)

[0182] │└─Array element (Object)

[0183] │├─Store Name (String)

[0184] │├─Rating (Number)

[0185] │└─Delivery Fee (Number)

[0186] └─Query Distance Threshold (Number)

[0187] When a user selects "A2 → Nearby Stores List → Array Element → Store Name (String)", this action is the core step in variable referencing, binding the "Store Name" variable of A2 to the "Store Name Display Position" configuration item of node B.

[0188] ③ Confirm the reference and apply it:

[0189] After selection, the "Store Name Display Position" in the configuration panel will automatically display "{A2.Nearby Stores List[].Store Name}" (standardized reference identifier), indicating that the "Store Name" variable of A2 has been successfully referenced at this position; users can repeat this operation to reference the "Rating" and "Delivery Fee" variables of A2 to the corresponding display positions of node B respectively.

[0190] 3. The actual effect of variable referencing

[0191] If the scope calculation logic determines that a variable (such as a node C variable in another workflow) is not within the accessible scope of node B, then the variable will not appear in the list of referenceable variables, and the user will not be able to reference it, thus avoiding runtime errors caused by illegal cross-scope references. At runtime, node B will extract "store name / rating / delivery fee" from the output data of A2 based on the referenced variable and automatically render it into the UI card, realizing a closed loop of upstream variable → node B configuration → UI display.

[0192] As can be seen, the variable list refers to the set of all variables that a node (such as node B) can legally reference after scope calculation logic verification (such as topology traversal, permission verification, and type matching). These variables include metadata such as variable name, node, data type, and nesting structure. Rendering this list into a drop-down box essentially transforms the abstract set of legal variables into a visual and interactive variable selection entry point. Its core purpose is to allow users to quickly and accurately complete variable referencing operations in the node configuration panel (replacing manual input of variable names), ensuring the legality, accuracy, and ease of use of variable referencing from an operational perspective.

[0193] Taking the configuration scenario of "card display node B" in the "takeout store query workflow" as an example (node ​​B needs to reference the "nearby store list" variable of "store query API node A2"), the core uses of the drop-down box are reflected in four dimensions:

[0194] 1. Core Use 1: Serves as a visual entry point for variable referencing, reducing the operational threshold.

[0195] The dropdown list is the core interactive control for users to trigger variable references. When users need to bind variables to the configuration items of node B (such as "store name display position"), they do not need to manually enter the variable name (such as manually writing "A2. nearby store list [].store name"). They can simply click the dropdown list to see all the legal variables and complete the reference by clicking to select them, which greatly reduces the operation threshold for non-technical personnel (such as business orchestrators).

[0196] 2. Core Use 2: To enforce the scope of reference and ensure the legality of variable references.

[0197] The dropdown menu only renders the final list of valid variables. Illegal variables that are outside the scope of node B (such as node C variables from other workflows or temporary variables with undefined metadata) will not appear in the dropdown menu. This prevents users from selecting illegal variables from an interactive perspective and avoids workflow runtime errors (such as UI rendering failures or API call parameter errors) caused by cross-scope references or references to undefined variables.

[0198] 3. Core Use 3: Structured display of variable information to improve selection efficiency.

[0199] The dropdown list doesn't simply list variable names; instead, it renders a list of valid variables (with metadata annotations) according to a hierarchical structure: the node it belongs to, the variable type, and nested subfields, allowing users to quickly locate the target variable. An example is shown below:

[0200] [Card Display Node B - Store Name Display Drop-down Box]

[0201] ├─Start node A1 (required variable label)

[0202] │├─User Location (Object) → Longitude (Number)

[0203] │├─User Location (Object) → Latitude (Number)

[0204] │└─Search keywords (String, optional)

[0205] └─Store Query API Node A2 (Required Variable Label)

[0206] ├─ List of nearby stores (Array) → Store name (String)

[0207] ├─Nearby Stores List (Array) → Rating (Number)

[0208] ├─ Nearby Stores List (Array) → Delivery Fee (Number)

[0209] └─Query Distance Threshold (Number)

[0210] Users do not need to remember the node to which the variable belongs or the nested path. They can quickly find the store query API node A2 → nearby store list → store name by expanding the drop-down list, which improves the accuracy and efficiency of variable selection.

[0211] 4. Core Purpose 4: Real-time linkage and updates to ensure configuration timeliness.

[0212] If the metadata of the upstream node changes (e.g., A2 adds a "business status" variable or deletes a "query distance threshold" variable), or the scope calculation logic is adjusted (e.g., the accessible range of node B is reduced), the dropdown will re-render the "final list of valid variables" in real time: newly added valid variables are automatically added to the dropdown, and invalid / illegal variables are automatically removed, ensuring that users can only select the latest and most valid variables.

[0213] like Figures 3-6 As shown, Figures 3-4 This section demonstrates, using one scenario, the process of showcasing the workflow canvas and parameter metadata configuration panel, as well as the variable reference interface and binding effect of the target node.

[0214] Should Figure 3 The DAG structure construction in step S101 and the metadata configuration interface in step S301 are shown:

[0215] Directed Acyclic Graph Structure: The start node and the end node are connected by purple lines in the canvas, defining the logical flow.

[0216] Start Node Settings: The right panel displays the start node and its description, "Answering user questions about the image." Below it is "Input Parameter Settings," where users can define parameter names and types.

[0217] End Node Settings: The panel displays the end node, which includes "Output Parameter Settings" and below it are configuration items such as "Answer Content" and "Order Placement".

[0218] like Figure 4-6 As shown, Figure 5 and 6 for Figure 4 Enlarged view of the central area, this Figure 4 The presentation demonstrates a workflow orchestration scenario, highlighting the variable referencing interface in this application embodiment and its application on the target node.

[0219] Figure 4 This document displays the standardized tree-structured data dictionary, configuration panel, and variable references generated after step S304 of this application.

[0220] Node-level scope division: The diagram clearly distinguishes between "start node output parameters" and "store query API node output parameters." This reflects the system's topological classification of variables from different sources.

[0221] Structured representation of the Object / Array composite type:

[0222] Object definition: For example, "User Location" is defined as an Object, which includes "Longitude (Number, required)" and "Latitude (Number, required)". Figure 4 The document also shows specific numerical examples (such as 120.1234).

[0223] Array penetration definition: targeting the "list of nearby stores". Figure 4 The document displays an "array element (Object)" hierarchy, which is further nested within "store ID", "store name" and "store information (Object)".

[0224] Semantic metadata annotation: Each field synchronously displays the parameter name, data type, required status (such as "required", "optional"), and usage description (such as "unique identifier of the store" and "name of the store displayed to the outside world").

[0225] Users can accurately locate deep fields through a visual interface, solving the problem of lack of structured references.

[0226] DAG structure visualization: Canvas area A shows the start node and the end node, which are logically connected by a purple line.

[0227] Node configuration details: Canvas area B displays the node's "Input Parameter Settings" and "Output Parameter Settings" panels.

[0228] Start Node: The panel displays its description as "Answering user questions about images" and provides parameter names, parameter types (such as "Object" or "String" in the drop-down list), required switches, and description input boxes in "Input Parameter Settings".

[0229] End node: Shows its configuration for the output results, including the text box in "Answer Content" (entered "Order") and the "Stream Output" switch.

[0230] Figure 4 The document also demonstrates the interactive process of the user performing variable referencing and cascading selection at the target node (card node) in step S105.

[0231] Preceding reachability path: The purple arrows in the diagram show the flow from the start node through the card nodes to the end node. The system performs reachability analysis in step S201 based on this.

[0232] Variable reference interface and cascading path echo:

[0233] The "Card Settings" item in the "Card 001" panel on the right shows the selected variable path: "Apply 001 / List".

[0234] In the "Initiate Card Data Binding" and "Update Card Data Binding" areas, for the parameter name "text", the "Variable Value" input box on the right is the variable reference interface.

[0235] Event group configuration and dynamic binding:

[0236] The "Event Group Settings" below demonstrates the binding logic of the "Ordering" event. Its triggering events explicitly point to "Application 001 / Recommended Store List / When Ordering" and "Application 001 / Recommended Store List". This visually illustrates the cascading expansion logic of step S402 and the dynamic binding relationship of step S502, allowing users to complete complex data associations across nodes through visual clicks.

[0237] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0238] In one embodiment, a computer device is provided, wherein the processor of the computer device is used to provide computing and control capabilities, the computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of a dynamic variable processing method based on graph topology as described in any of the preceding embodiments.

[0239] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the above-described dynamic variable processing method based on graph topology relationships.

[0240] 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. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Furthermore, any references to memory, storage, user databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory.

[0241] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above.

[0242] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. 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 spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for processing dynamic variables based on graph topological relationships, characterized in that, The method includes: Obtain a directed acyclic graph structure consisting of multiple functional nodes with logical connections. The directed acyclic graph structure refers to the logical topology generated in a visualization canvas or workflow orchestration engine. When a variable reference trigger instruction for the target node is received, the directed acyclic graph structure is traversed, and reachability analysis based on the preceding connections is performed to determine all nodes on the preceding path of the target node, forming the upstream node set. The predefined output parameters of each node in the upstream node set are aggregated to obtain candidate variables for the target node to reference; wherein, for composite type parameters containing nested structures, the candidate variables contain corresponding structured description information; Based on the candidate variables containing the structured description information, the scope of dynamically accessible variables corresponding to the target node is generated; Within the scope of the dynamically accessible variables, a variable reference interface is provided for the input items to be configured in the target node to display the candidate variables and respond to the selection operation for the candidate variables; The structured description information is generated in the form of a tree-like data dictionary through the following configuration: Parameter metadata definition information for functional nodes is obtained, serving as a standardized data specification provided by the functional node to its downstream nodes; the parameter metadata definition information includes parameter name, parameter data type, required attributes, and usage description information; if the parameter data type is a composite type containing object types or array types, then a structured definition mode is enabled to obtain at least one level of sub-fields added for the composite type and their corresponding sub-parameter metadata, and the array elements contained in the array type are defined as structured objects with subordinate relationships; the tree-like data dictionary is generated based on the subordinate relationships between the sub-fields at each level. When performing variable referencing through the variable referencing interface, the process includes: displaying a top-level candidate variable list within the scope of the dynamically accessible variable in the first-level menu of the variable referencing interface; responding to the selection operation for the target composite type candidate variable, performing cascading expansion logic based on the tree-like data dictionary to display the corresponding subordinate level menu; determining the target reference object by locating the subordinate level menu layer by layer, and binding the target reference object to the input item to be configured of the target node.

2. The method according to claim 1, characterized in that, The execution of reachability analysis based on preorder joins includes: Retrieve all paths pointing to the target node in the directed acyclic graph structure; Nodes on the path are identified as legitimate source nodes, and nodes on the downstream or parallel branch paths of the target node are blocked to ensure that the candidate variables are logically reachable.

3. The method according to claim 1, characterized in that, After binding the target reference object to the input item to be configured in the target node, the method further includes: The path identifier, reflecting the complete reference path of the target reference object, is displayed at the input field to be configured. A dynamic binding relationship is established between the input item to be configured and the source data corresponding to the target reference object, so as to adjust the reference status of the input item to be configured in real time according to the structural changes of the source data.

4. The method according to claim 1, characterized in that, When providing the variable reference interface, type filtering logic is also included: Obtain the required input data type for the input item to be configured; Compare the output data type corresponding to the candidate variable with the input data type; Based on the comparison results, candidate variables that do not conform to the input data type are configured as unselectable in the variable reference interface, or for candidate variables that do not conform to the input data type but support data type conversion, the corresponding type conversion prompt signal is output.

5. The method according to claim 1, characterized in that, When displaying the candidate variables in the variable reference interface, the following is also included: The purpose description information in the parameter metadata definition information is displayed synchronously, and the candidate variables and their corresponding subfields are labeled using semantic parameter names.

6. The method according to claim 1, characterized in that, Also includes: Real-time monitoring of structural changes in the predefined output parameters of each node in the upstream node set; If it is detected that the source data structure corresponding to a target reference object referenced by a downstream target node has been changed or deleted, a synchronization change prompt message will be output in the variable reference interface or the input item to be configured.

7. The method according to any one of claims 1-6, characterized in that, The functional nodes in the directed acyclic graph structure include: The start node serves as the data entry point for the workflow and receives initial input data. Interface nodes are used to call external interfaces to obtain structured return data; And logic processing nodes, used to execute business logic based on candidate variables of the upstream node set.

8. A computer 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 computer program, it implements the steps of the method as described in any one of 1-7.

Images