Low-code full-link observability and debugging system

Abstract

The application discloses a low-code full-link observable and debugging system, and relates to the field of computers.The system comprises a breakpoint adaptive setting module, a recording module, a breakpoint execution module and a visual management module.The breakpoint adaptive setting module is used for adaptively selecting a node for breakpoint insertion based on the structural topology of a changed subgraph and the attribute information of the node when it is detected that a user performs a change operation on a node logic graph.The breakpoint execution module is used for triggering breakpoint interception, pausing the code execution process and performing a debugging operation at the breakpoint position when the low-code engine executes to the breakpoint.The recording module is used for recording code execution logs generated during the operation of the low-code engine.The visual management module is used for differentially rendering the execution state and the debugging state of the node in the first code execution process in combination with the system load.The application can improve the efficiency of low-code application debugging and reduce development costs.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a low-code end-to-end observable and debuggable system. Background Technology

[0002] Low-code development is a development model distinct from traditional code development. Business and technical personnel, even those with no programming knowledge or only basic programming skills, can leverage low-code platforms to develop and implement required business functions, modules, and subsystems. This model lowers the technical barrier for enterprises, saves time in business implementation, reduces system investment costs, and increases the flexibility of business changes.

[0003] The application of low-code platforms currently has significant limitations. For example, during each code iteration and debugging process, developers still need to manually set debugging breakpoints, which results in high manual operation costs and low overall debugging efficiency. Summary of the Invention

[0004] This application provides a low-code end-to-end observability and debugging system that can improve the efficiency of low-code application debugging and reduce development costs.

[0005] Firstly, this application provides a low-code, end-to-end observable and debuggable system, including: The breakpoint adaptive setting module is used to extract a modified subgraph from the node logic graph based on the user's change operation when a change operation is detected in the node logic graph, and to adaptively select nodes in the modified subgraph to insert breakpoints based on the structural topology of the modified subgraph and the attribute information of the nodes; wherein, the node logic graph is visualized by a low-code editor on the first code; The breakpoint execution module is used to trigger breakpoint interception when the low-code engine reaches a breakpoint, pausing the execution flow of the first code and performing debugging operations at the breakpoint location; The recording module is used to record the code execution logs generated during the operation of the low-code engine; The visualization management module is used to render the execution and debugging status of nodes in the first code execution process in a differentiated manner based on system load.

[0006] In one optional implementation, the breakpoint adaptive setting module is specifically used for: Identify the change node corresponding to the change operation; The minimum connected subgraph formed by the changed node and its associated nodes is extracted from the node logic graph to obtain the changed subgraph.

[0007] In one optional implementation, the breakpoint adaptive setting module is specifically used for: If this change operation triggers a change in the graph structure logic, then the affected nodes involved in this change operation are determined based on the changed subgraph, and the affected nodes are included in the affected node set. If the total number of incoming and outgoing edges contained in any of the affected nodes in the set of affected nodes is greater than a preset threshold, or the logic complexity of the affected node meets a preset condition, or the affected node is an important type of node, then the affected node is selected for breakpoint insertion.

[0008] In one optional implementation, the change operation of the trigger graph structure logic includes adding nodes, deleting nodes, and modifying the logical relationships between nodes.

[0009] In an optional implementation, the visualization management module is further configured to: In response to a user-triggered entry into debug mode, the selected breakpoint is displayed in the node logic diagram with a preset dynamic entry effect before debugging is performed.

[0010] In an optional implementation, the system further includes a breakpoint editing module, the breakpoint editing module being used for: In response to the user's removal operation of the adaptively inserted breakpoint in the node logic graph, delete the breakpoint configuration on the corresponding node; And / or, in response to a breakpoint addition operation initiated by the user in the node logic graph, add a breakpoint configuration to the target node.

[0011] In one optional implementation, the visualization management module is specifically used for: When the system is under low load, the first dynamic effect is used to render the executed nodes, the default static effect is used to render the state of the unexecuted nodes, and the second dynamic effect is used to render the nodes triggered by breakpoint debugging. When the system is under high load, static differentiated visual effects are used to render executed nodes, non-executed nodes, and nodes triggered by breakpoint debugging.

[0012] In one optional implementation, the system further includes a rollback module, the rollback module being used to: When a user is detected to perform a rollback trigger operation on the node logic graph, the execution state of the first code is rolled back to the historical execution state corresponding to the target historical node based on the execution log of the executed node recorded by the recording module.

[0013] The low-code end-to-end observability and debugging system provided in this application has the following beneficial effects: By providing a visually editable node logic diagram, the system automatically extracts the corresponding changed subgraph when a change operation is detected. It then adaptively selects nodes and inserts breakpoints based on the subgraph's topology and node attribute information. This enables automatic breakpoint placement for business logic change scenarios, eliminating reliance on professional developers and avoiding issues like missed or redundant breakpoints caused by non-professionals. Furthermore, the system combines real-time load-differentiated rendering of the execution and debugging status of each node during code execution. Through adaptive visual displays, users can intuitively grasp the debugging progress, distinguish various node states, and dynamically adjust rendering strategies based on system load. This ensures effective visual interaction during debugging while effectively controlling front-end rendering overhead, balancing debugging convenience with system performance. Attached Figure Description

[0014] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0015] Figure 1 A schematic diagram of the structure of a low-code end-to-end observable and debuggable system provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the generation process of the change subgraph involved in the low-code end-to-end observability and debugging system of this application embodiment; Figure 3 This is a schematic diagram of the change sub-diagrams corresponding to different change types involved in the low-code end-to-end observability and debugging system of this application embodiment. Detailed Implementation

[0016] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0017] To facilitate understanding of the technical content of this application, the technical terms involved in this application are explained.

[0018] Low-code: Low-code is a software development methodology that uses a visual programming interface to quickly create applications. Low-code platforms provide basic functions such as visual data definition and page building. Depending on requirements, users can perform visual or text-based logic writing, associate data fields, bind event logic, and orchestrate business processes.

[0019] Debugging, also known as "debugging," refers to the process of finding and fixing errors and defects in a program during software development. Through debugging, developers can discover and resolve problems more quickly, improving software quality and stability.

[0020] Breakpoints: In code logic, breakpoints are intentionally placed points where execution pauses for debugging purposes. When the program reaches a breakpoint, it pauses execution to allow developers to check the program's state, view variable values, and examine stack information, etc.

[0021] Node: In this application, a node refers to a node that exists in the node logic diagram. The node corresponds to a component of the program code. Different nodes can be used to execute different running logic. For example, one node can make a function call, while another node can make an assignment, etc.

[0022] Low-code development platforms, with their ability to quickly build applications using graphical orchestration, visual modeling, and minimal coding, have been widely adopted in enterprise systems, industrial internet, and business process automation. In low-code development, users drag, connect, and configure parameters of logical nodes through a visual editor to create a logic node diagram that represents the business process. This eliminates the need to focus on underlying code details, significantly lowering the development threshold and improving delivery efficiency.

[0023] When business users or non-technical personnel modify the low-code logic diagram, debugging and verification are still required. Traditional debugging methods heavily rely on technical personnel, who manually insert static breakpoints, or business users manually set breakpoints on the node logic diagram displayed in the editor. However, since business users are not professionals, manual insertion can easily lead to problems with the debugging scope being too large or too small: too large a scope will introduce a large number of irrelevant nodes, resulting in high system resource consumption and low debugging efficiency; too small a scope will fail to cover the change-related links, making it difficult to discover potential defects. At the same time, after each code iteration or logic change, breakpoint setting, debugging triggering, and result confirmation must be manually repeated, which is cumbersome and repetitive, making it difficult to form a standardized and automated debugging process, seriously affecting the iteration efficiency and development experience of low-code applications.

[0024] To address at least one of the aforementioned technical problems, embodiments of this application provide a low-code, end-to-end observability and debugging system. Please refer to... Figure 1 The low-code end-to-end observable and debuggable system includes a breakpoint adaptive setting module, a breakpoint execution module, a logging module, and a visualization management module.

[0025] The adaptive breakpoint setting module is used to extract the modified subgraph from the node logic graph based on the user's change operation when a change operation is detected in the node logic graph. Then, based on the structure topology of the modified subgraph and the attribute information of the nodes, it adaptively selects nodes in the modified subgraph to insert breakpoints. The node logic graph is visualized by a low-code editor using the first code.

[0026] The breakpoint execution module is used to trigger breakpoint interception when the low-code engine reaches a breakpoint, pausing the execution flow of the first code and performing debugging operations at the breakpoint location.

[0027] The logging module records code execution logs generated during the low-code engine's operation. Specifically, the logging module writes the code execution log data to the database via an asynchronous thread, avoiding blocking the main execution flow.

[0028] The visualization management module is used to render the execution and debugging status of nodes during the first code execution process in a differentiated manner based on system load.

[0029] Among them, the low-code editor is a visual editing tool for low-code development scenarios, used to visually arrange the first code and display the code execution logic in the form of a node logic diagram.

[0030] The breakpoint adaptive setting module is used to monitor the user's operation behavior in the low-code editor. When it detects that the user has made a change to the node logic graph, such as adding a node, deleting a node, modifying node parameters, or modifying node logical relationships, it identifies the node corresponding to the change operation and then extracts the minimum connected subgraph of the changed node and its associated nodes from the node logic graph to obtain the changed subgraph.

[0031] As an example, such as Figure 2 As shown, Figure 2 (a) in the diagram represents the node logic diagram before the change. Assuming nodes B and C are deleted and nodes A and D are connected, the resulting changed sub-diagram is as follows: Figure 2 As shown in (b) of the diagram.

[0032] Optionally, when the breakpoint execution module adaptively selects nodes in the changed subgraph to insert breakpoints based on the topology change characteristics of the changed subgraph, the steps performed include: If this change operation triggers a logical change in the graph structure, then the affected nodes involved in this change operation are determined based on the changed subgraph, and the affected nodes are included in the affected node set. If the total number of incoming and outgoing edges contained in any affected node in the set of affected nodes is greater than a preset threshold, or the logic complexity of the affected node meets a preset condition, or the affected node is an important type of node, then the affected node is selected for breakpoint insertion.

[0033] The changes triggered by these operations include adding nodes, deleting nodes, and modifying logical relationships between nodes. Modifying node parameters alone does not trigger a change in the logical structure of the graph. If a node is added, the added node and its downstream neighbors are added to the set of affected nodes. If a node is deleted, the upstream and downstream neighbors of the deleted node are added to the set of affected nodes. If a logical relationship between nodes is modified, the nodes associated with that logical relationship are added to the set of affected nodes. As an example, such as Figure 2 As shown, Figure 2 (a) in comparison to Figure 2 If node addition occurs in (b) of the above, then the affected nodes include B, C, and D. Figure 2 (b) in comparison to Figure 2 If node deletion occurs in (a) of the above, then the affected nodes include A and D; Figure 2 (c) compared to Figure 2 If (a) there are no changes such as adding or deleting nodes, but there are changes such as modifying the logical relationship of nodes, then the affected nodes include A, B, C, and D.

[0034] Specifically, the total number of incoming and outgoing edges of a node is defined as the sum of the number of incoming edges and the number of outgoing edges of that node; the built-in logical complexity of a node is quantitatively evaluated based on the number of expressions contained in the node, the number of internal conditional branch judgments, the level of logical nesting, and the number of serial execution steps.

[0035] Then, iterate through each affected node in the set of affected nodes. If any of the following conditions are met, the affected node is identified as a risk node, and a breakpoint insertion operation is performed: (1) The total number of incoming and outgoing edges of a node is greater than a preset threshold. (2) The number of expressions in a node is greater than the preset expression threshold, or the number of conditional branch judgments, the level of logical nesting, or the number of serial execution steps are greater than the corresponding preset threshold. (3) The influencing node is a preset important node, that is, a node that is in the core link of the business process and carries the core business logic.

[0036] Understandably, breakpoints are used to pause program execution and view node variables and running status. After topology changes or node changes occur in the process, hub nodes where multiple links intersect are prone to data transmission and branch jump anomalies; setting breakpoints can help troubleshoot link failures. At the same time, nodes with complex internal logic are more prone to calculation errors; breakpoints can be used to verify the internal operation process. Furthermore, if a core business node malfunctions, it can cause overall business interruption; setting breakpoints on it can capture the fault in time and reduce the impact on business.

[0037] Optionally, the code execution log data includes the main execution log and node execution log, and is configured with a structured error code system: (1) The main execution log records the execution number, engine ID, total time, request parameters, overall status and global error code of the engine call; (2) Node execution log, which records the input snapshot, output snapshot and calculation process corresponding to the execution of each node; among them, the input snapshot includes the parameters before the node execution, dataset summary, previous results, current row data and stored in JSON format, the output snapshot includes result set sample, SQL statement, number of affected rows, generated ID and stored in JSON format, and the calculation process is only recorded in debug mode; (3) The structured error code system adopts a category-number encoding format. Different error codes correspond to different abnormal scenarios, and error context data in JSON format is recorded synchronously.

[0038] Taking a single order addition engine call as an example, the main log records: json { "run_no":"2032429971013554178", "function_name":"Order Addition Engine", "total_time":156, "status":0, "input_params":"{\"orderId\":1001,\"amount\":250.0}" } Node execution log recording (: json { "step_index":2, "execute_name":"New Order", "input_snapshot":"{\"params\":{\"orderId\":1001,\"amount\":250.0},\"datasets\":{},\"currentRow\":null}", "output_snapshot":"{\"generatedIds\":

[10086] ,\"affectedRows\":1}", "sql_text":"INSERTINTOorders(id,amount)VALUES(10086,250.0)", "cost_time":45, "status":0 } If a unique key conflict occurs, an error log will be generated: json { "status":1, "error_code":"DAT-01", "error_msg":"Unique key conflict", "error_context":"{\"constraint\":\"uk_order_no\",\"value\":\"ORD001\"}" }

[0039] Optionally, the visualization management module is also used to: in response to a user-triggered entry into debug mode, display adaptively selected breakpoints in the node logic diagram with a preset dynamic entry effect before debugging is performed. By highlighting the adaptively generated breakpoints with dynamic effects when debug mode is started, users can intuitively see the debugging range of the breakpoints adaptively inserted by the system.

[0040] Based on this, users can perform editing operations on the node logic diagram, such as removing or adding breakpoints that are adaptively inserted.

[0041] Therefore, the system can further include a breakpoint editing module. This module can respond to a user's removal operation of an adaptively inserted breakpoint in the node logic graph, deleting the breakpoint configuration on the corresponding node; and / or, responding to a user's breakpoint addition operation in the node logic graph, adding a breakpoint configuration to the target node. By supporting manual addition and deletion of breakpoints on top of the system's adaptive breakpoint insertion, it balances automation capabilities with the need for flexible manual adjustments, adapting to diverse debugging scenarios.

[0042] The visualization management module can use any one or more combinations of node borders, icons, colors, and dynamic effects to achieve differentiated visual displays, allowing users to intuitively grasp the debugging progress and accurately distinguish the status of various nodes.

[0043] Optionally, the implementation method for the visualization management module to differentiate the execution status and debugging status of executed nodes during code execution may include: When the system is under low load, the first dynamic effect is used to render the executed nodes, the default static effect is used to render the state of the unexecuted nodes, and the second dynamic effect is used to render the nodes triggered by breakpoint debugging. When the system is under high load, static differentiated visual effects are used to render executed nodes, non-executed nodes, and nodes triggered by breakpoint debugging.

[0044] In this embodiment, the system disables dynamic visual effects under high load to reduce front-end resource consumption and prevent dynamic rendering from further increasing system operating pressure; under low load, dynamic effects are enabled to intuitively distinguish between node execution status and breakpoint debugging status, effectively improving the interactive experience of troubleshooting. The system load status can be determined based on CPU utilization, memory utilization, etc., and this application does not limit it.

[0045] Optionally, the system also includes a rollback module, which is used to: when a user performs a rollback trigger operation on the node logic graph, roll back the execution status of the first code to the historical execution status corresponding to the target historical node based on the execution log of the executed node recorded by the recording module.

[0046] The rollback trigger operation can include the following actions: clicking the rollback button in the debug toolbar, selecting the target historical node to initiate a rollback command, or specifying the rollback step number. Specifically, the system parses the user's rollback operation command to determine the target historical node: if the user specifies a specific node to roll back to, that node is taken as the target historical node; if the user specifies the rollback step number, the system matches the historical nodes corresponding to the number of steps in reverse order according to the execution order stored in the recording module as the target historical node. Then, the system calls the recording module to extract the historical execution status corresponding to the target historical node from the execution log based on the unique identifier of the target historical node, including: the variable data of the node, the execution context, the code execution location, and the node execution result.

[0047] Based on the extracted historical execution state, the code execution engine performs a reset operation: it rolls the code execution pointer back to the execution position of the target historical node, restores all variable snapshots (inputs, outputs, internal variables) corresponding to the target historical node, resets the execution context environment, and clears the execution cache and running flags of all nodes after the target historical node.

[0048] Simultaneously, the visualization management module updates the rendering of the node logic diagram based on the execution status after rollback, resetting nodes after the target historical node to an unexecuted state to restore the execution / debugging state of the target historical node. In this way, the system supports rapid rollback of the debugging process, accurately restoring the historical execution context without repeating the process, and synchronously linking with the visualization interface, significantly improving the efficiency and flexibility of breakpoint debugging.

[0049] The low-code end-to-end observable and debuggable system provided in this application has the following beneficial effects: By providing a visually editable node logic diagram, the system automatically extracts the corresponding changed subgraph when a change operation is detected. It then adaptively selects nodes and inserts breakpoints based on the subgraph's topology and node attribute information. This enables automatic breakpoint placement for business logic change scenarios, eliminating reliance on professional developers and avoiding issues like missed or redundant breakpoints caused by non-professionals. Furthermore, the system combines real-time load-differentiated rendering of the execution and debugging status of each node during code execution. Through adaptive visual displays, users can intuitively grasp the debugging progress, distinguish various node states, and dynamically adjust rendering strategies based on system load. This ensures effective visual interaction during debugging while effectively controlling front-end rendering overhead, balancing debugging convenience with system performance.

[0050] It should be noted that each block in the block diagrams of this application may represent a module, program segment, or part of code, which contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the figures. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions. The modules described in the embodiments of this application may be implemented in software or hardware. The names of modules do not, in some cases, constitute a limitation on the unit itself.

[0051] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A low-code, end-to-end observable and debuggable system, characterized in that, include: The breakpoint adaptive setting module is used to extract a modified subgraph from the node logic graph based on the user's change operation when a change operation is detected in the node logic graph, and to adaptively select nodes in the modified subgraph to insert breakpoints based on the structural topology of the modified subgraph and the attribute information of the nodes; wherein, the node logic graph is visualized by a low-code editor on the first code; The breakpoint execution module is used to trigger breakpoint interception when the low-code engine reaches a breakpoint, pausing the execution flow of the first code and performing debugging operations at the breakpoint location; The recording module is used to record the code execution logs generated during the operation of the low-code engine; The visualization management module is used to render the execution and debugging status of nodes in the first code execution process in a differentiated manner based on system load.

2. The low-code end-to-end observable and debuggable system as described in claim 1, characterized in that, The breakpoint adaptive setting module is specifically used for: Identify the change node corresponding to the change operation; The minimum connected subgraph formed by the changed node and its associated nodes is extracted from the node logic graph to obtain the changed subgraph.

3. The low-code end-to-end observable and debuggable system as described in claim 2, characterized in that, The breakpoint adaptive setting module is specifically used for: If this change operation triggers a change in the graph structure logic, then the affected nodes involved in this change operation are determined based on the changed subgraph, and the affected nodes are included in the affected node set. If the total number of incoming and outgoing edges contained in any of the affected nodes in the set of affected nodes is greater than a preset threshold, or the logic complexity of the affected node meets a preset condition, or the affected node is an important type of node, then the affected node is selected for breakpoint insertion.

4. The low-code end-to-end observable and debuggable system as described in claim 3, characterized in that, The changes to the trigger graph structure logic include adding nodes, deleting nodes, and modifying the logical relationships between nodes.

5. The low-code end-to-end observable and debuggable system as described in claim 1, characterized in that, The visualization management module is also used for: In response to a user-triggered entry into debug mode, the selected breakpoint is displayed in the node logic diagram with a preset dynamic entry effect before debugging is performed.

6. The low-code end-to-end observable and debuggable system as described in claim 5, characterized in that, The system also includes a breakpoint editing module, which is used for: In response to the user's removal operation of the adaptively inserted breakpoint in the node logic graph, delete the breakpoint configuration on the corresponding node; And / or, in response to a breakpoint addition operation initiated by the user in the node logic graph, add a breakpoint configuration to the target node.

7. The low-code end-to-end observable and debuggable system as described in claim 1, characterized in that, The visual management module is specifically used for: When the system is under low load, the first dynamic effect is used to render the executed nodes, the default static effect is used to render the state of the unexecuted nodes, and the second dynamic effect is used to render the nodes triggered by breakpoint debugging. When the system is under high load, static differentiated visual effects are used to render executed nodes, non-executed nodes, and nodes triggered by breakpoint debugging.

8. The low-code end-to-end observable and debuggable system as described in claim 1, characterized in that, The system also includes a rollback module, which is used for: When a user is detected to perform a rollback trigger operation on the node logic graph, the execution state of the first code is rolled back to the historical execution state corresponding to the target historical node based on the execution log of the executed node recorded by the recording module.

Images