An execution method and device of a low-code platform front-end and back-end debugging node

Abstract

The application discloses a kind of low-code platform front-end and back-end debugging node execution method and device.The method comprises: obtaining the running state of front-end and back-end debugging node to obtain debugging enable identifier;Combining debugging enable identifier, logic identifier, node identifier and secondary structure breakpoint mapping table verification to obtain breakpoint enable state;Based on breakpoint enable state, conditional breakpoint expression and execution context evaluation to obtain expression verification result;Integrate expression verification result and core information to generate pause context object;Pause context object is packaged to obtain standardized pause event according to uniform message protocol;Standardized pause event is transmitted through corresponding message channel and target recovery instruction is obtained;Based on target recovery instruction, front-end and back-end debugging event is recovered and path converges, and consistent debugging result is obtained.The application guarantees the transparency of underlying adaptation difference, reduces the cognitive burden of developer and the complexity of platform implementation, supports cross front-end and back-end complete call link debugging, and guarantees consistent debugging experience.

Description

Technical Field

[0001] This application relates to the field of low-code platform debugging technology, and in particular to an execution method and apparatus for front-end and back-end debugging nodes of a low-code platform. Background Technology

[0002] With the widespread adoption of low-code platforms, their front-end and back-end logic run in browser JavaScript environments and Java server environments, respectively. Debugging, as a core element in ensuring development efficiency, is becoming increasingly urgent. However, the fundamental differences between the underlying operating mechanisms of the front-end and back-end make it difficult for traditional debugging solutions to achieve both uniformity and adaptability.

[0003] Current low-code platform debugging methods are mostly designed for independent single environments, lacking a unified standard for the execution flow, message format, and event handling logic of front-end and back-end debugging nodes. The front-end relies on asynchronous Promise mechanisms, while the back-end uses synchronous blocking queues, requiring developers to master two sets of debugging logic and switch between different tools, resulting in a heavy cognitive burden. Simultaneously, inconsistent transmission protocols and data structures for debugging events hinder efficient aggregation of front-end and back-end debugging information, leading to a fragmented user experience with scattered session, variable, and call stack displays in the debugging interface. These issues not only increase the platform's implementation complexity but also severely impact the accuracy and convenience of debugging.

[0004] Therefore, how to achieve consistency in execution flow, message protocol, and event aggregation, reduce the operational costs for developers, support cross-front-end and back-end full-link debugging, and ensure a consistent debugging experience are urgent problems to be solved in this field. Summary of the Invention

[0005] In view of this, the execution method for front-end and back-end debugging nodes of a low-code platform provided in this application embodiment can ensure transparency of underlying adaptation differences, reduce the cognitive burden on developers and the complexity of platform implementation, support debugging of the complete front-end and back-end call chain, and ensure a consistent debugging experience. The execution method and apparatus for front-end and back-end debugging nodes of a low-code platform provided in this application embodiment are implemented as follows:

[0006] This application provides an embodiment of an execution method for front-end and back-end debugging nodes in a low-code platform, comprising:

[0007] Obtain the running status of the front-end and back-end debugging nodes, and obtain the debugging enable flag based on the running status;

[0008] The debug enable flag, current logic flag, node flag and the breakpoint mapping table of the secondary structure are matched and verified to obtain the breakpoint enable status;

[0009] The breakpoint enable status, conditional breakpoint expression, and current execution context are evaluated to obtain the expression verification result;

[0010] The expression validation result and the core information of the current execution environment are integrated and processed to obtain a pause context object;

[0011] The pause context object is adapted and encapsulated to match the structure and data specifications of the unified messaging protocol to obtain a standardized pause event.

[0012] The standardized pause event is bound to the corresponding message channel for transmission processing to obtain the target recovery command;

[0013] The target recovery command and front-end and back-end debugging events are recovered and their paths are converged to obtain consistent debugging results.

[0014] In some embodiments, the step of matching and verifying the debug enable identifier, current logic identifier, node identifier, and breakpoint mapping table of the secondary structure to obtain the breakpoint enable status includes:

[0015] Obtain the status of the debug enable flag; if the debug enable flag is in an inactive state, obtain the invalid breakpoint enable status.

[0016] Alternatively, if the debugging enable flag is enabled, perform a matching query on the current logical flag and the first-level key of the breakpoint mapping table of the secondary structure to obtain the secondary node flag corresponding to the current logical flag and the breakpoint configuration association set.

[0017] The node identifier, the secondary node identifier, and the breakpoint configuration association set are precisely matched to obtain the target breakpoint configuration information.

[0018] If the target breakpoint configuration information is empty or the target breakpoint configuration information is in an inactive state, an invalid breakpoint enable state is obtained.

[0019] Alternatively, if the target breakpoint configuration information is not empty and the target breakpoint configuration information is in an enabled state, a valid breakpoint enabled state is obtained.

[0020] In some embodiments, the evaluation of the breakpoint enable state, the conditional breakpoint expression, and the current execution context to obtain the expression verification result includes:

[0021] The validity of the breakpoint's enabled state is obtained. If the breakpoint's enabled state is invalid, the invalid expression validation result is obtained.

[0022] Alternatively, if the breakpoint is enabled and in a valid state, the type of the target breakpoint configuration information is determined to obtain the breakpoint type identifier.

[0023] When the breakpoint type is identified as a non-conditional breakpoint type, a valid expression validation result is obtained;

[0024] Alternatively, if the breakpoint type is identified as a conditional breakpoint, the conditional breakpoint expression and the current execution context are substituted into the conditional operation to obtain the conditional operation result.

[0025] If the result of the conditional operation is false, an invalid expression verification result is obtained;

[0026] Alternatively, if the result of the conditional operation is true, a valid expression verification result is obtained.

[0027] In some embodiments, the process of integrating the expression validation result and the core information of the current execution environment to obtain a pause context object includes:

[0028] Obtain the status of the expression validation result. If the expression validation result is invalid, obtain an invalid pause context object.

[0029] Alternatively, if the expression validation result is valid, collect the core information of the current execution environment;

[0030] The core information is integrated, and the integrated core information is subjected to field integrity and format compliance verification to obtain an effective pause context object.

[0031] In some embodiments, the adaptation and encapsulation of the pause context object with the structure and data specifications of the unified messaging protocol to obtain a standardized pause event includes:

[0032] Obtain the state of the pause context object; if the pause context object is in an invalid state, obtain an invalid standardized pause event.

[0033] Alternatively, if the pause context object is in a valid state, the pause context object can be adapted to the structure of the unified messaging protocol to obtain an initial adaptation message.

[0034] The initial adaptation message and the data specification are subjected to consistency verification to obtain the verification result;

[0035] If the verification result is unsuccessful, an invalid standardized pause event is obtained;

[0036] Alternatively, if the verification result is successful, a valid standardized pause event is obtained.

[0037] In some embodiments, the process of restoring and merging the target recovery command and front-end / back-end debugging events to obtain a consistent debugging result includes:

[0038] The status of the target recovery command is obtained; if the target recovery command is invalid, an invalid debugging result is obtained.

[0039] Alternatively, if the target recovery instruction is in a valid state, the target recovery instruction can be adapted to the current execution flow state to obtain the execution recovery result;

[0040] The front-end and back-end debugging events are converted into standardized debugging events.

[0041] The standardized debugging events are associated with the unified front-end service components to obtain basic debugging results;

[0042] Obtain cross-platform call path information, and fuse the execution recovery result, the basic debugging result, and the cross-platform call path information to obtain a consistent debugging result.

[0043] In some embodiments, the core information includes at least one of the following: execution session identifier, logic identifier, node identifier, variable snapshot, call stack, source identifier, timestamp, pause reason, and session name.

[0044] This application provides an execution device for a low-code platform front-end and back-end debugging node, comprising:

[0045] The acquisition module is used to acquire the running status of the front-end and back-end debugging nodes and obtain the debugging enable identifier based on the running status;

[0046] The processing module is used to perform matching and verification processing on the debug enable flag, current logic flag, node flag and the breakpoint mapping table of the secondary structure to obtain the breakpoint enable status;

[0047] The processing module is also used to evaluate the breakpoint enable status, the conditional breakpoint expression, and the current execution context to obtain the expression verification result;

[0048] The processing module is also used to integrate the expression validation result and the core information of the current execution environment to obtain a pause context object;

[0049] The encapsulation module is used to adapt and encapsulate the pause context object with the structure and data specifications of the unified messaging protocol to obtain a standardized pause event.

[0050] The processing module is also used to bind and transmit the standardized pause event with the corresponding message channel to obtain the target recovery instruction;

[0051] The processing module is also used to perform recovery and path aggregation processing on the target recovery command and front-end and back-end debugging events to obtain consistent debugging results.

[0052] The computer device provided in this application includes a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements the method described in this application.

[0053] The computer-readable storage medium provided in this application embodiment stores a computer program thereon, which, when executed by a processor, implements the method described in this application embodiment.

[0054] This application provides a method and apparatus for executing front-end and back-end debugging nodes in a low-code platform. The method obtains a debugging enable flag by acquiring the running status of the front-end and back-end debugging nodes; verifies the breakpoint enable status by combining the debugging enable flag, logic flag, node flag, and a secondary structure breakpoint mapping table; obtains an expression verification result based on the breakpoint enable status, conditional breakpoint expression, and execution context evaluation; integrates the expression verification result with core information to generate a pause context object; encapsulates the pause context object according to a unified message protocol to obtain a standardized pause event; transmits the standardized pause event through a corresponding message channel and obtains a target recovery instruction; and restores and converges the front-end and back-end debugging events based on the target recovery instruction to obtain a consistent debugging result. This ensures transparency of underlying adaptation differences, reduces the cognitive burden on developers and the complexity of platform implementation, supports debugging across the entire front-end and back-end call chain, guarantees a consistent debugging experience, and solves the technical problems raised in the background art. Attached Figure Description

[0055] 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 or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 A schematic diagram illustrating the implementation flow of an execution method for a low-code platform front-end and back-end debugging node provided in an embodiment of this application;

[0057] Figure 2 A schematic diagram illustrating the implementation process of obtaining the breakpoint enable status provided in an embodiment of this application;

[0058] Figure 3 This is a schematic diagram of the structure of an execution device for a low-code platform front-end and back-end debugging node, provided in an embodiment of this application. Detailed Implementation

[0059] 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, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0060] The following description of some technologies involved in the embodiments of this application is provided to aid understanding and should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, some descriptions of well-known functions and structures are omitted in the following description.

[0061] Figure 1 This is a schematic diagram illustrating the implementation flow of an execution method for a low-code platform front-end and back-end debugging node provided in an embodiment of this application, including steps 101 to 107. Wherein, Figure 1 This is merely one execution order shown in the embodiments of this application, and does not represent the only execution order of a low-code platform's front-end and back-end debugging nodes. Where the final result can be achieved, Figure 1 The steps shown can be performed in parallel or in reverse order.

[0062] Step 101: Obtain the running status of the front-end and back-end debugging nodes, and obtain the debugging enable flag based on the running status.

[0063] In this embodiment, the current running status of the front-end debugging node and the back-end debugging node are first obtained, and the status of being in debug mode is determined by detecting a preset isDebugging flag. If the running status detection result indicates that debugging is not enabled, an unenabled debugging enable flag is generated; if the detection result indicates that debugging is enabled, an enabled debugging enable flag is generated. The debugging status detection logic for the front-end JavaScript environment and the back-end Java environment is implemented independently, but the semantics of the flag results are completely consistent, used for unified judgment in subsequent steps.

[0064] Step 102: Perform a matching and verification process between the debug enable flag, the current logic flag, the node flag, and the breakpoint mapping table of the secondary structure to obtain the breakpoint enable status.

[0065] In this embodiment, after obtaining the debug enable flag, a matching verification is performed based on the debug enable flag, the current logic flag, the node flag, and the breakpoint mapping table of the secondary structure. If the debug enable flag is not enabled, an invalid breakpoint enable state is directly generated, the subsequent debugging process is terminated, and the execution of the next business node is directly initiated.

[0066] If the debugging enable flag is enabled, the breakpoint mapping table of the second-level structure is queried. Using the current logical identifier as the first-level key, a match query is performed in the breakpoint mapping table to obtain the second-level node identifier corresponding to the logical identifier and the breakpoint configuration association set. Then, based on the current node identifier, a precise match is performed in the second-level association set to check if the corresponding target breakpoint configuration information exists. If no target breakpoint configuration information is found, or if the found target breakpoint configuration information is in an disabled state, an invalid breakpoint enable state is generated, the current debugging process is terminated, and execution proceeds to the next business node. If the found target breakpoint configuration information is not empty and is in an enabled state, a valid breakpoint enable state is generated, and subsequent debugging steps continue.

[0067] Step 103: Evaluate the breakpoint enable status, conditional breakpoint expression, and current execution context to obtain the expression verification result.

[0068] In this embodiment, based on the obtained breakpoint enable status, the conditional breakpoint expression is evaluated in conjunction with the current execution context. If the breakpoint enable status is invalid, an invalid expression validation result is directly generated, the debugging process is terminated, and the execution of the next business node begins.

[0069] If the breakpoint is enabled, the type of the target breakpoint configuration information is first determined. If the determination result is a non-conditional breakpoint type, a valid expression validation result is directly generated; if the determination result is a conditional breakpoint type, the conditional breakpoint expression is substituted into the current execution context for evaluation. If the evaluation result is false, an invalid expression validation result is generated, the debugging process is terminated, and the execution of the next business node begins; if the evaluation result is true, a valid expression validation result is generated, and the debugging process continues.

[0070] Step 104: Integrate the expression validation results and the core information of the current execution environment to obtain the pause context object.

[0071] In this embodiment, the core information of the current execution environment is integrated and processed based on the expression validation result. If the expression validation result is invalid, an invalid pause context object is generated, and the debugging process is terminated.

[0072] If the expression validation result is valid, then complete core information of the current execution environment is collected, including the execution session identifier, logic identifier, node identifier, variable snapshot, call stack, source identifier (labeled as frontend or backend), timestamp, pause reason, and session name. The collected core information is then structured and integrated to ensure that each information item corresponds to a pre-defined field position in a unified data structure, with no missing core fields and field types and semantics conforming to a unified definition. Finally, a valid pause context object is generated. The core information fields collected by the frontend JavaScript environment and the backend Java environment are completely consistent to ensure the uniformity of subsequent message processing.

[0073] Step 105: Adapt and encapsulate the pause context object with the structure and data specifications of the unified messaging protocol to obtain a standardized pause event.

[0074] In this embodiment, the obtained pause context object is adapted and encapsulated with the structure and data specifications of the unified messaging protocol. If the pause context object is invalid, an invalid standardized pause event is generated.

[0075] If the pause context object is valid, adaptation processing is performed according to the unified messaging protocol. The top-level structure of the unified messaging protocol includes a `type` field and a `payload` field. The `type` field identifies the message type; here, it is set to `debug:paused` to indicate the execution of a pause event. The `payload` field carries the message content; here, the valid pause context object is used as the specific content of the `payload` field, forming the initial adaptation message. A consistency check is performed between the initial adaptation message and the data specifications of the unified messaging protocol to ensure that the names, types, and semantics of each field in the pause context object completely match the unified data structure definition. After successful check, a valid standardized pause event is generated. This event format remains consistent across the front-end and back-end environments and can adapt to subsequent transmission through different message channels.

[0076] Step 106: Bind the standardized pause event to the corresponding message channel for transmission processing to obtain the target recovery command.

[0077] In this embodiment, a valid standardized pause event is bound to a corresponding message channel for transmission. The backend Java environment and the frontend JavaScript environment select the corresponding transmission method according to their underlying mechanisms: the backend debugging node sends the standardized pause event to the NodeService via an HTTP POST request, and simultaneously uses the take() operation of the blocking queue to synchronously block the current business thread and enter the debugging pause waiting state; the frontend debugging node sends the standardized pause event to the Runtime backend via a Socket.IO message, and then the Runtime backend forwards it to the NodeService, and simultaneously uses the await method of Promise to asynchronously suspend the current execution flow and enter the debugging pause waiting state.

[0078] During the debugging pause waiting state, this embodiment supports dynamic modification of variable values ​​when debugging is paused, as well as dynamic switching of call stack frames and context synchronization operations. Developers can complete debugging operations such as variable state adjustment and full call chain execution status checks during this period without terminating the current debugging process or restarting the debugging task.

[0079] When the Designer frontend issues a recovery instruction (including five types: continue, stepOver, stepInto, stepOut, and interrupt), the backend wakes up the waiting thread through the offer() operation of the blocking queue. The frontend resumes the execution flow by calling the resolve() function of the Promise. The debug node receives the recovery instruction and verifies its validity. After successful verification, the target recovery instruction is obtained.

[0080] Step 107: Perform recovery and path aggregation processing on the target recovery command and front-end and back-end debugging events to obtain consistent debugging results.

[0081] In this embodiment, front-end and back-end debugging events are restored and their paths are converged based on the target restoration command. If the target restoration command is invalid, an invalid debugging result is generated.

[0082] If the target recovery instruction is valid, the corresponding recovery operation is executed according to the instruction type. When a continue instruction is received, execution continues to the next breakpoint; when a stepOver, stepInto, or stepOut instruction is received, a temporary breakpoint is set and execution continues; when an interrupt instruction is received, the current logic execution is terminated, and the execution recovery result is obtained.

[0083] Simultaneously, debugging events from both the front-end and back-end are aggregated. Back-end debugging events are forwarded via NodeService to the DebugService component in the Designer front-end through WebSocket; front-end debugging events are forwarded via Runtime back-end and NodeService to the DebugService component in the Designer front-end through WebSocket. After being forwarded by NodeService, debugging events from both sources are converted into standard events conforming to a unified message protocol. The DebugService component manages them uniformly, displaying debugging sessions, variables, and call stacks through the same data source and a single set of UI components. Furthermore, by leveraging a unified call stack frame data structure and execution session identifier, call information across front-end and back-end business processes is linked and integrated to form a complete cross-platform call path. Finally, the execution recovery results, uniformly displayed debugging information, and cross-platform call path information are merged to obtain consistent debugging results covering the unified debugging scenario across both the front-end and back-end.

[0084] This application's embodiments construct a unified execution model for front-end and back-end debugging nodes in a low-code platform, defining a standardized seven-step execution process. This ensures complete alignment of debugging logic between the front-end JavaScript environment and the back-end Java environment, shielding the differences in underlying operating mechanisms (asynchronous Promise / synchronous blocking queues) and achieving a unified debugging process. Through a progressive design of status flags → verification results → context objects → standardized events → recovery instructions → consistent results, it ensures seamless connection between front-end and back-end debugging stages, avoiding process breaks or logical conflicts. It provides a foundational framework for subsequent unified message protocols and unified event aggregation, reducing the overall implementation complexity of the platform's debugging functions. Simultaneously, it eliminates the need for developers to distinguish between front-end and back-end debugging operation logic, significantly reducing cognitive burden. Covering the entire chain from debugging initiation to result output, it supports end-to-end debugging across front-end and back-end business processes, improving the efficiency and accuracy of problem localization.

[0085] In the above Figure 1 Based on the above, this application embodiment also provides a schematic diagram of the implementation process for obtaining the breakpoint enable status, as shown below. Figure 2 As shown. Includes steps 201 to 205:

[0086] Step 201: Obtain the status of the debug enable flag. If the debug enable flag is not enabled, obtain the invalid breakpoint enable status.

[0087] In this embodiment, the status of the debug enable flag is obtained. The debug enable flag is generated by the detection result of the debugging node's running status in the previous steps. Its semantics are completely consistent in the front-end and back-end environments. It is only used to indicate whether the current state is in debug mode. The determination basis is the system's preset isDebugging flag status.

[0088] Step 202: When the debugging enable flag is enabled, perform a matching query on the first-level key of the breakpoint mapping table of the current logical flag and the second-level structure to obtain the second-level node flag corresponding to the current logical flag and the breakpoint configuration association set.

[0089] In this embodiment, the breakpoint enabling status is initially determined based on the status of the debug enabling flag. If the obtained debug enabling flag is in an inactive state, it means that debug mode is not currently enabled, and there is no need to perform subsequent breakpoint configuration-related verification. The result is an invalid breakpoint enabling status, and the subsequent steps of the current debug node are terminated, directly entering the execution process of the next business node.

[0090] Step 203: Perform precise matching processing on the node identifier, secondary node identifier, and breakpoint configuration association set to obtain the target breakpoint configuration information.

[0091] In this embodiment, if the debugging enable flag is in an enabled state, a first-level matching query of the secondary structure breakpoint mapping table is executed. The platform's preset secondary structure breakpoint mapping table is retrieved. The first-level key of this mapping table is the logical ID, and the second-level key is the node ID. The structure definition of the mapping table is completely consistent in the front-end and back-end environments, ensuring the uniformity of the query logic. Using the current logical identifier corresponding to the current debugging node as the query basis, a precise matching query is performed with the first-level key of the secondary structure breakpoint mapping table to obtain the secondary node identifier corresponding to the current logical identifier and the breakpoint configuration association set. The breakpoint configuration association set contains complete breakpoint configuration information corresponding to all secondary node identifiers under this logic.

[0092] Step 204: If the target breakpoint configuration information is empty or the target breakpoint configuration information is in an inactive state, an invalid breakpoint enabled state is obtained.

[0093] In this embodiment, node identifiers are precisely matched to obtain target breakpoint configuration information. Using the node identifier of the current debugging node as the query condition, a precise match is performed with the obtained secondary node identifiers and the breakpoint configuration association set to determine whether there is target breakpoint configuration information that completely corresponds to the current node identifier.

[0094] Step 205: If the target breakpoint configuration information is not empty and the target breakpoint configuration information is in an enabled state, a valid breakpoint enabled state is obtained.

[0095] In this embodiment, the breakpoint activation status is ultimately determined based on the target breakpoint configuration information. If no corresponding target breakpoint configuration information is found after matching, or if the found target breakpoint configuration information is in an inactive state, it indicates that the current node has no valid breakpoint configuration, resulting in an invalid breakpoint activation status. The current debugging process terminates, and execution proceeds directly to the next business node. If corresponding target breakpoint configuration information is found after matching, and the target breakpoint configuration information is in an activated state, it indicates that the current node has a valid breakpoint, resulting in a valid breakpoint activation status. Subsequent debugging steps, such as evaluating conditional breakpoint expressions, will continue.

[0096] It should be noted that when the front-end JavaScript environment and the back-end Java environment execute this method, the only difference lies in the storage medium of the breakpoint mapping table (front-end local storage, back-end server storage) and the underlying implementation of the query interface. However, this difference is completely masked by the adaptation layer and does not affect the execution logic of each step or the determination result of the breakpoint enable status, thus ensuring the consistency of the front-end and back-end verification results.

[0097] This application embodiment achieves accurate querying of breakpoint configurations by using a two-level structure breakpoint mapping table (logical ID as the first-level key and node ID as the second-level key), ensuring consistency in breakpoint matching rules between the front-end and back-end, and avoiding false or missed breakpoint triggering due to differences in query logic. Through layered verification logic of debugging enable flag → logical flag matching → node flag matching → breakpoint status determination, invalid scenarios are filtered layer by layer, reducing unnecessary debugging overhead and improving the efficiency of breakpoint determination. A clear trigger mechanism for invalid breakpoint enable status → termination of the debugging process is established to avoid interference from invalid breakpoints on business execution and ensure the smoothness of business processes. The front-end and back-end verification logic is completely unified; only the differences between the underlying storage and query interfaces are masked by the adaptation layer, ensuring the consistency of breakpoint enable status determination results and providing a reliable preliminary basis for subsequent expression evaluation.

[0098] In some embodiments, the breakpoint enable state, conditional breakpoint expression, and current execution context are evaluated to obtain an expression verification result, including: obtaining the validity of the breakpoint enable state; and obtaining an invalid expression verification result if the breakpoint enable state is invalid.

[0099] Specifically, the breakpoint enable status obtained in the preceding steps is obtained. The breakpoint enable status is only used to indicate whether there is a valid breakpoint in the current node. The semantics are completely consistent in the front-end and back-end environments. Its source is the matching and verification results of the debug enable flag, logic flag, node flag and secondary structure breakpoint mapping table. There are only two states: valid or invalid.

[0100] Furthermore, when the breakpoint is enabled and in an effective state, the type of the target breakpoint configuration information is determined to obtain the breakpoint type identifier.

[0101] Specifically, a preliminary determination is made based on the validity of the breakpoint's enabled status. If the obtained breakpoint enabled status is invalid, it means that there are no valid breakpoints in the current node. There is no need to perform subsequent conditional breakpoint expression evaluation operations; the invalid expression verification result is obtained directly. At this time, the current debugging process terminates, and the execution process of the next business node is directly entered.

[0102] Furthermore, when the breakpoint type is identified as a non-conditional breakpoint type, a valid expression validation result is obtained.

[0103] Specifically, if the breakpoint is enabled and active, the type of the target breakpoint configuration information is determined. The target breakpoint configuration information is the complete breakpoint configuration corresponding to the current node matched in the previous steps, and its type field is clearly marked as either a conditional breakpoint or a non-conditional breakpoint. The definition and determination criteria for breakpoint types are completely consistent in the front-end and back-end environments.

[0104] Furthermore, when the breakpoint type is identified as a conditional breakpoint, the conditional breakpoint expression is substituted with the current execution context to obtain the conditional operation result.

[0105] Specifically, subsequent processing is performed based on the result of the breakpoint type identifier. If the obtained breakpoint type identifier is determined to be a non-conditional breakpoint type, it means that the current breakpoint does not need to meet any additional conditions to trigger a pause, and no expression evaluation operation is required. A valid expression verification result is obtained directly, and subsequent debugging steps such as capturing the execution context will continue.

[0106] Furthermore, if the conditional operation result is false, an invalid expression validation result is obtained.

[0107] Specifically, if the obtained breakpoint type is determined to be a conditional breakpoint, the evaluation process of the conditional breakpoint expression is initiated. The pre-defined conditional breakpoint expression in the target breakpoint configuration information is substituted into the execution context of the current debug node for calculation. The evaluation rules and syntax parsing logic of the expression are completely unified in the front-end and back-end environments. Only the underlying environment for performing the evaluation operation (JavaScript engine, Java Virtual Machine) differs. This difference is masked by the adaptation layer and does not affect the consistency of the evaluation logic.

[0108] Furthermore, if the conditional operation result is true, a valid expression verification result is obtained.

[0109] Specifically, the final determination is made based on the result of the conditional operation. If the result of the conditional breakpoint expression after being substituted into the current execution context is false, it means that the breakpoint triggering condition has not been met. In this case, an invalid expression verification result is obtained, the current debugging process terminates, and the execution of the next business node is directly initiated. If the result is true, it means that the breakpoint triggering condition has been met. In this case, a valid expression verification result is obtained, and subsequent debugging steps such as capturing the execution context and sending a pause event will continue.

[0110] It should be noted that the core steps and judgment logic are completely consistent when executing this method in the front-end JavaScript environment and the back-end Java environment. The only differences are in the storage format of the execution context and the underlying engine implementation of expression evaluation. However, these differences do not affect the judgment criteria of the expression validation results, ensuring that the front-end and back-end can obtain semantically consistent expression validation results.

[0111] This application's embodiments achieve fine-grained control over breakpoint triggering by distinguishing between the evaluation logic of conditional breakpoints and non-conditional breakpoints. The debugging process only proceeds when preset conditions are met, avoiding meaningless execution pauses and improving the targeting of debugging. It unifies the evaluation rules and judgment criteria for conditional expressions on the front-end and back-end, ensuring semantic consistency of expression validation results even with different underlying evaluation engines (JavaScript engine / Java Virtual Machine), avoiding logical deviations during cross-environment debugging. It continues the progressive logic of invalid results → termination of debugging, further filtering scenarios that do not meet the triggering conditions, reducing the impact of the debugging process on business execution, and balancing debugging needs with execution efficiency. It clarifies the correlation between expression validation results and subsequent context collection, ensuring that resource-intensive context capture operations are only performed when conditions are met, optimizing system resource usage.

[0112] In some embodiments, the expression validation result and the core information of the current execution environment are integrated and processed to obtain a pause context object, including: obtaining the status of the expression validation result, and obtaining an invalid pause context object if the expression validation result is invalid.

[0113] Specifically, the status of the expression validation result is obtained and preliminarily determined. The expression validation result is generated by the evaluation of the breakpoint activation status, conditional breakpoint expression, and current execution context in the previous steps. The semantics are completely consistent across the front-end and back-end environments, with only two states: valid or invalid. If the obtained expression validation result is invalid, it means that the breakpoint triggering condition is not met. There is no need to carry out subsequent core information collection and integration operations. An invalid pause context object is directly obtained, and the current debugging process terminates, directly entering the execution process of the next business node.

[0114] Furthermore, if the expression validation result is valid, core information about the current execution environment is collected.

[0115] Specifically, if the expression validation result is valid, then the core information of the current execution environment is collected. Following the preset unified data structure (PausedContext), all core information is comprehensively collected, including fields such as execution session identifier, logic identifier, node identifier, variable snapshot, call stack, source identifier (labeled as frontend or backend), timestamp, pause reason, and session name. The core information fields collected by the frontend and backend environments are completely consistent. Only due to differences in the underlying runtime environment, the information acquisition interface (frontend JavaScript API, backend Java interface) and storage format differ. This difference is masked by the adaptation layer and does not affect the integrity and consistency of the information, ensuring that all collected core information corresponds to the preset fields of the unified data structure.

[0116] Furthermore, the core information is integrated, and the integrated core information is subjected to field integrity and format compliance verification to obtain an effective pause context object.

[0117] Specifically, core information is integrated and validated to generate a pause context object. First, according to the pre-defined field mapping relationships of the unified data structure, each collected core information item is integrated one by one to form an initial context information set, ensuring that the information arrangement conforms to the unified specifications. Then, the context information set undergoes field completeness and format compliance validation: field completeness validation confirms that key core fields such as execution session identifier, logic identifier, and node identifier are not missing, avoiding impact on subsequent debugging operations due to incomplete information; format compliance validation verifies that the type and semantics of each field are completely consistent with the unified data structure definition, such as the storage format of variable snapshots and the hierarchical structure of the call stack, all conforming to the pre-defined standards, ensuring complete consistency between the front-end and back-end validation rules. If the integrated core information passes the above two validations, a valid pause context object is obtained. This object's format remains consistent across the front-end and back-end environments and can be directly used for subsequent adaptation and encapsulation of the unified message protocol. If the validation fails, it indicates that core information is missing or the format is abnormal. In this case, an invalid pause context object is obtained, the current debugging process terminates, and execution proceeds directly to the next business node.

[0118] This application embodiment collects core information of the execution environment according to a unified data structure, ensuring the integrity and format uniformity of fields in the front-end and back-end pause context objects, laying the foundation for cross-environment message transmission and information display; through field integrity and format compliance verification, it avoids problems such as subsequent message encapsulation failure and debugging information display disorder caused by missing information or abnormal format, improving the reliability of debugging data; it clarifies the trigger logic of valid expression verification result → collection of core information, avoiding resource waste in invalid scenarios and optimizing system performance; the unified configuration of source identifier (frontend / backend) provides a basis for source differentiation when subsequent event aggregation, while not affecting the overall uniformity of context objects, taking into account both differentiated identification and standardized management.

[0119] In some embodiments, the structure and data specifications of the pause context object are adapted and encapsulated to obtain a standardized pause event, including: obtaining the state of the pause context object, and obtaining an invalid standardized pause event if the pause context object is in an invalid state.

[0120] Specifically, the state of the pause context object is obtained. The context object is generated by integrating and verifying the expression validation results and the core information of the execution environment in the previous steps. Its semantics are completely consistent in the front-end and back-end environments, and it only has two states: valid or invalid. It serves as the basis for preliminary judgment in subsequent adaptation and encapsulation operations.

[0121] Furthermore, when the pause context object is in a valid state, the pause context object is adapted to the structure of the unified messaging protocol to obtain the initial adapted message.

[0122] Specifically, the validity of the standardized pause event is initially determined based on the state of the pause context object. If the obtained pause context object is invalid, it means that there is no compliant execution context information at present. No further adaptation and encapsulation operations are required, and an invalid standardized pause event is directly obtained. At this time, the current debugging process terminates, and the execution process of the next business node is directly entered.

[0123] Furthermore, consistency verification is performed on the initial adaptation message and data specifications to obtain the verification results.

[0124] Specifically, if the pause context object is in a valid state, it is adapted to the structure of the unified messaging protocol. According to the preset unified messaging protocol definition, all debug messages adopt a unified top-level structure of a `type` field + a `payload` field. The `type` field identifies the message type, and the `payload` field carries the core message content. During adaptation, the `type` field is explicitly set to `debug:paused` to indicate a pause event. The valid pause context object is completely filled into the `payload` field, ensuring that all core fields such as the execution session identifier, logic identifier, and node identifier are fully carried, thus obtaining the initial adapted message. The adaptation logic of the front-end and back-end is completely consistent; only the different field reading methods caused by differences in the underlying environment are masked by the adaptation layer, without affecting the structural uniformity of the initial adapted message.

[0125] Furthermore, if the verification result is unsuccessful, an invalid standardized pause event is obtained.

[0126] Specifically, consistency checks are performed on the data specifications of the initial adaptation message and the unified messaging protocol to obtain the check results. The core of the data specification check is to verify whether the pause context object carried by the payload field in the initial adaptation message has completely consistent field names, data types, and semantic definitions with the unified data structure. For example, the format of the execution session identifier, the hierarchical structure of the call stack, and the storage specifications of variable snapshots must all conform to the preset unified standards. The front-end and back-end use the exact same check rules to ensure the consistency of the check results.

[0127] Furthermore, if the verification result is successful, a valid standardized pause event is obtained.

[0128] Specifically, a final standardized pause event is generated based on the verification results. If the verification result fails, it means that the initial adaptation message does not meet the requirements of the unified message protocol. In this case, an invalid standardized pause event is obtained, the current debugging process terminates, and the execution of the next business node proceeds directly. If the verification result passes, it means that the initial adaptation message fully complies with the unified specification. In this case, a valid standardized pause event is obtained. The format of this event is consistent in the front-end and back-end environments and can be directly adapted to the corresponding message channels (front-end Socket.IO, back-end HTTPPOST) for transmission, ensuring the consistency of subsequent forwarding and processing logic.

[0129] This application's embodiments achieve standardized encapsulation of pause context objects based on a unified messaging protocol (type field + payload field), eliminating format differences between front-end and back-end debugging messages and ensuring smooth message forwarding across middleware layers (NodeService / Runtime backend). Through data specification consistency verification, it ensures that the encapsulated standardized pause events conform to a unified data structure definition, avoiding front-end parsing failures or display anomalies due to inconsistencies in field names, types, and semantics. It clarifies the association logic between invalid pause context objects and invalid standardized pause events, filtering unqualified messages at the source and reducing the consumption of network resources and processing nodes by invalid message transmission. Standardized pause events can directly adapt to the corresponding message channels of the front-end and back-end, simplifying the adaptation cost of message transmission and improving the transmission efficiency and stability of debugging messages.

[0130] In some embodiments, this method also includes a mechanism for dynamically modifying variable values ​​when debugging is paused, the specific implementation process of which is as follows:

[0131] This mechanism allows direct modification of variable values ​​within the current execution context during debug pause and waiting states. This enables developers to test the impact of different variable states on business processes without restarting debug or terminating the current pause state, further improving debugging efficiency and flexibility. Specifically, the Designer frontend's DebugService component provides the `setVariable` method, which accepts three core parameters: the execution session identifier (`executionId`), the variable name (`name`), and the new variable value (`value`). The variable name uses a dotted path format, supporting precise modification of nested object attributes. For example, the format `root.child1.child2.xxx` can locate the target sub-attribute within a nested object, adapting to variable adjustment needs in complex business scenarios. When this method is executed, a `debug:setVariable` debug command is generated and sent to the backend NodeService. The payload of this command includes the execution session identifier (`executionId`), the action identifier (`action`, with a fixed value of `setVariable`), the data body (containing the variable name and the new variable value), and the `waitForResponse` response waiting flag, ensuring the synchronization of frontend and backend command interactions.

[0132] After receiving the `debug:setVariable` debugging command, the backend uses the `handleDebugAction` method of `DebugExecutionManager` to receive and identify the `SET_VARIABLE` action type, and forwards it to the `DebugEventHandler` component to handle the corresponding variable modification request. The backend uses a `CompletableFuture` mechanism to synchronously wait for a response, ensuring the atomicity of the variable modification operation and avoiding variable state conflicts and data inconsistencies in a multi-threaded environment. After the variable modification is complete, the backend encapsulates the updated variable value using a unified message protocol and returns it to the `DebugService` component of the `Designer` frontend. Upon receiving this, the frontend synchronously updates the variable display content in the `VariableViewer`, completing the entire closed-loop process of variable modification. The modified variable value will take effect in subsequent execution flows.

[0133] Meanwhile, this mechanism sets up a dual-type security and permission verification mechanism to avoid runtime errors caused by unauthorized modifications and ensure the stability of the debugging process: The first layer is variable type verification. The front-end VariableViewer component obtains the type information of the current variable through variableDefinitions and uses the isBasicType function to determine whether the variable is a basic type such as string, number, or boolean. Only variables of basic types are allowed to be edited, while variables of complex object types are set to read-only by default. The second layer is stack frame permission verification. Variable editing permission is only granted when the currently active stack frame is the top-level stack frame, i.e., the isTopFrame property is true. Variables of non-top-level stack frames are set to read-only by default to prevent users from accidentally modifying variable data in historical stack frames and to ensure the security of debugging execution.

[0134] In some embodiments, this method also includes a dynamic switching of call stack frames and a context synchronization mechanism, the specific implementation process of which is as follows:

[0135] This mechanism allows developers to switch between viewing variable information and execution locations corresponding to different call stack frames during the debugging pause and waiting state. This enables them to fully inspect the execution status of any node in the call chain, achieving end-to-end debugging information traceability and overcoming the limitation of traditional debugging methods that can only view the context of the current execution location. In specific implementation, the DebugService component uses the activeCallFrameIndex structure to store the index of the currently active stack frame corresponding to each execution session. This structure is a Map.<string,number> The format is as follows: the key is the execution session identifier `executionId`, and the value is the index number of the currently active stack frame, enabling independent management of stack frame states across multiple debug sessions. When a debug node pauses execution or a `handlePausedEvent` event is triggered, `DebugService` automatically sets the active stack frame index of the corresponding execution session to the top-level position of the call stack, i.e., `callFrames.length - 1`, displaying the context information of the latest execution position by default, which aligns with developers' typical debugging habits. `DebugService` also provides the `setActiveCallFrame` method, allowing developers to switch to any valid stack frame. During method execution, a boundary check is performed on the input parameter `frameIndex` to ensure the index value is within the valid range of the call stack array, preventing index out-of-bounds exceptions.

[0136] This mechanism enables synchronized operation of the entire stack frame switching process: When a user clicks on a target stack frame in the CallStackViewer, the handleFrameClick callback function is triggered. This function first calls the debugService.setActiveCallFrame method to update the active stack frame index of the corresponding execution session, and simultaneously triggers the debug:callFrameChanged event to broadcast the stack frame switching action. Then, the openBreakpoint method is called to automatically navigate to the location of the logic identifier (logicId) and node identifier (nodeId) corresponding to the stack frame, so that the designer interface synchronously displays the logical graph position corresponding to the current stack frame. This achieves synchronized operation between call stack switching and the designer view, eliminating the need for developers to manually search for the corresponding logical nodes.

[0137] This mechanism also ensures synchronized updates to the variable view: the VariableViewer component continuously listens for the `debug:callFrameChanged` event. When a stack frame change is detected, it automatically updates the currently displayed variable information. Specifically, it obtains the `CallFrame` object of the currently active stack frame using the `getActiveCallFrame` method, reads the corresponding stack frame's variable snapshot stored in that object, and renders it to ensure that the variable information completely matches the context of the currently selected stack frame. Furthermore, for non-top-level stack frames, the VariableViewer component displays a "Variables in the current stack are read-only" message, disabling variable editing permissions and retaining only viewing capabilities to prevent accidental user actions.

[0138] In addition, this mechanism optimizes the display of the call stack: the CallStackViewer component displays the call stack list in reverse order, with the most recently executed call stack frame displayed at the top of the list. Each stack frame item displays the corresponding logicId and the current execution position information. At the same time, the isActive property indicates the currently selected active stack frame, and the isTopFrame property indicates whether the current stack frame is the top-level execution stack frame, making it easier for developers to quickly identify the current debugging position and execution chain level, thus improving the convenience of debugging operations.

[0139] In some embodiments, the target recovery instruction and front-end / back-end debugging events are recovered and their paths are converged to obtain a consistent debugging result, including: obtaining the status of the target recovery instruction, and obtaining an invalid debugging result if the target recovery instruction is invalid.

[0140] Specifically, the status of the target recovery command is obtained. The target recovery command originates from the debug control command sent by the Designer frontend, including five types: continue, stepOver, stepInto, stepOut, and interrupt. It is triggered by the standardized pause event transmission in the preceding steps, and its status is divided into two types: valid and invalid. The validity is determined by whether the command format conforms to the unified message protocol and whether the command type is within the preset legal range. The semantics are completely consistent in the frontend and backend environments, and it serves as the preliminary judgment basis for subsequent processing.

[0141] Furthermore, if the target recovery instruction is in a valid state, the target recovery instruction is adapted to the current execution flow state to obtain the execution recovery result.

[0142] Specifically, the execution recovery result is obtained by adapting the target recovery instruction to its state. If the target recovery instruction is invalid, it means that the instruction has an abnormal format or an illegal type, and the recovery operation cannot be performed, resulting in an invalid debugging result. At this time, the current debugging process is terminated. If the target recovery instruction is valid, the instruction is adapted to the current execution flow state, and the corresponding recovery operation is performed according to the unified execution logic: when a continue instruction is received, the current execution block is released, and execution continues to the next breakpoint; when a stepOver, stepInto, or stepOut instruction is received, a temporary breakpoint is set according to the unified rules, and the execution flow is restored; when an interrupt instruction is received, the current logic execution is terminated directly, and the execution recovery result containing the execution state and instruction execution feedback is finally obtained. The front-end and back-end only differ in the underlying recovery mechanism (the back-end wakes up the thread through the blocking queue offer() operation, and the front-end restores the execution flow through the Promiseresolve() function), but the semantics and format of the execution recovery result are completely consistent.

[0143] Furthermore, the front-end and back-end debugging events are format-converted to obtain standardized debugging events.

[0144] Specifically, front-end and back-end debugging events undergo format conversion to obtain standardized debugging events. These events are transmitted via different paths: back-end debugging events are sent to the NodeService via an HTTP POST request from the Runtime backend, while front-end debugging events are sent to the Runtime backend via a Socket.IO message from the Runtime frontend, and then forwarded to the NodeService by the Runtime backend. Upon receiving both types of events, the NodeService performs format conversion according to a unified message protocol, ensuring that all events use a top-level structure of a type field + payload field. The event type identifiers (such as debug:paused, debug:resumed) and the core data carried by the payload field (such as pause context, resume context) all conform to a unified data structure definition, eliminating the original format differences between front-end and back-end events, ultimately resulting in standardized debugging events with a unified structure and consistent semantics.

[0145] Furthermore, standardized debugging events are associated with unified front-end service components to obtain basic debugging results.

[0146] Specifically, standardized debug events are associated with a unified front-end service component to obtain basic debug results. The standardized debug events, after format conversion, are forwarded via WebSocket to the DebugService component in the Designer front-end. This component serves as the unified management entry point for front-end and back-end debug events, using the same data source to store debug event information. A single set of UI components renders and displays debug sessions, variable snapshots, call stacks, and other content. All paused sessions are presented in the same list, variable information is displayed through a unified variable viewer, and the call stack is presented through a unified call stack viewer, eliminating the need to distinguish event sources and ultimately yielding basic debug results with a unified display format.

[0147] Furthermore, cross-platform call path information is obtained, and the execution recovery result, basic debugging result, and cross-platform call path information are fused together to obtain consistent debugging results.

[0148] Specifically, cross-platform call path information is acquired and fused to obtain consistent debugging results. A unified execution session identifier (executionId) and call stack frame (CallFrame) data structure is used to associate call information from front-end and back-end debugging events. When a business process involves a front-end calling a back-end, the executionId is used to associate the node information initiating the call from the front-end with the information of the called node in the back-end. Based on the unified CallFrame structure, a complete cross-platform call path is formed, clearly defining the call hierarchy and execution order. This cross-platform call path information is then fused with the execution recovery results and basic debugging results, supplementing the call chain dimension information in the basic debugging results. This ensures that the debugging results include execution status, displayed data, and a complete cross-platform call trajectory, ultimately resulting in consistent debugging results that cover the unified front-end and back-end debugging scenario, are complete in information, and provide a consistent user experience.

[0149] This application embodiment unifies the front-end and back-end execution recovery logic, ensuring consistency in the execution results of recovery instructions even with different underlying wake-up mechanisms (blocking queue offer() / Promiseresolve()), thus avoiding execution state confusion during cross-environment debugging. It standardizes and unifies front-end and back-end debugging events through NodeService, providing a prerequisite for subsequent unified aggregation and simplifying the processing logic of front-end service components. A unified front-end service component (DebugService) enables centralized management and display of debugging information, allowing developers to view front-end and back-end debugging sessions, variables, and call stacks on a single interface without switching tools, improving the consistency of the debugging experience. Based on a unified execution session identifier (executionId) and call stack frame (CallFrame) data structure, it integrates cross-front-end and back-end call path information, achieving complete cross-platform call chain visualization, solving the problem of broken cross-front-end and back-end links in traditional debugging, and significantly improving the efficiency of problem localization in complex business processes.

[0150] While this application provides the method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive labor. The order of steps listed in this embodiment is merely one possible execution order among many and does not represent the only execution order. In actual device or client product execution, the methods shown in this embodiment or the accompanying drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0151] like Figure 3 As shown in the illustration, this application also provides an execution device 300 for front-end and back-end debugging nodes of a low-code platform. The device includes:

[0152] The acquisition module 301 is used to acquire the running status of the front-end and back-end debugging nodes and obtain the debugging enable identifier based on the running status.

[0153] The processing module 302 is used to perform matching and verification processing on the debug enable flag, the current logic flag, the node flag and the breakpoint mapping table of the secondary structure to obtain the breakpoint enable status.

[0154] The processing module 302 is also used to evaluate the breakpoint enable status, conditional breakpoint expression and the current execution context to obtain the expression verification result.

[0155] The processing module 302 is also used to integrate and process the expression validation result and the core information of the current execution environment to obtain a pause context object.

[0156] The encapsulation module 303 is used to adapt and encapsulate the structure and data specifications of the pause context object and the unified message protocol to obtain a standardized pause event.

[0157] The processing module 302 is also used to bind and transmit standardized pause events with corresponding message channels to obtain target recovery instructions.

[0158] The processing module 302 is also used to perform recovery and path aggregation processing on the target recovery command and the front-end and back-end debugging events to obtain consistent debugging results.

[0159] Some modules in the apparatus described in this application can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, classes, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0160] The apparatus or module described in the above embodiments can be implemented by a computer chip or physical entity, or by a product with a certain function. For ease of description, the above apparatus is described by dividing it into various modules according to their functions. When implementing the embodiments of this application, the functions of each module can be implemented in one or more software and / or hardware. Of course, a module that implements a certain function can also be implemented by combining multiple sub-modules or sub-units.

[0161] The methods, apparatus, or modules described in this application can be implemented in a computer-readable program code manner. The controller can be implemented in any suitable manner, such as a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of a memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code manner, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included within it for implementing various functions can also be considered as structures within the hardware component. Alternatively, the device used to implement various functions can be viewed as either a software module that implements the method or a structure within a hardware component.

[0162] This application also provides an apparatus, the apparatus comprising: a processor; a memory for storing processor-executable instructions; wherein, when the processor executes the executable instructions, it implements the method described in this application.

[0163] This application also provides a non-volatile computer-readable storage medium storing a computer program or instructions thereon, which, when executed, enables the method described in this application embodiment to be implemented.

[0164] Furthermore, in the various embodiments of the present invention, each functional module can be integrated into a processing module, or each module can exist independently, or two or more modules can be integrated into a single module.

[0165] The aforementioned storage media include, but are not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Cache, Hard Disk Drive (HDD), or Memory Card. The memory can be used to store computer program instructions.

[0166] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary hardware. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product, or it can be embodied in the process of data migration. The computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, mobile terminal, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0167] The various embodiments described in this specification are presented in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. All or part of this application can be used in numerous general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, mobile communication terminals, multiprocessor systems, microprocessor-based systems, programmable electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices, etc.

[0168] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit this application. 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 or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of this application.

Claims

1. A method for executing front-end and back-end debugging nodes in a low-code platform, characterized in that, include: Obtain the running status of the front-end and back-end debugging nodes, and obtain the debugging enable flag based on the running status; The debug enable flag, current logic flag, node flag and the breakpoint mapping table of the secondary structure are matched and verified to obtain the breakpoint enable status; The breakpoint enable status, conditional breakpoint expression, and current execution context are evaluated to obtain the expression verification result; The expression validation result and the core information of the current execution environment are integrated and processed to obtain a pause context object; The pause context object is adapted and encapsulated to match the structure and data specifications of the unified messaging protocol to obtain a standardized pause event. The standardized pause event is bound to the corresponding message channel for transmission processing to obtain the target recovery command; The target recovery command and front-end and back-end debugging events are recovered and their paths are converged to obtain consistent debugging results; The process of matching and verifying the debug enable flag, current logic flag, node flag, and breakpoint mapping table of the secondary structure to obtain the breakpoint enable status includes: Obtain the status of the debug enable flag; if the debug enable flag is in an inactive state, obtain the invalid breakpoint enable status. Alternatively, if the debugging enable flag is enabled, perform a matching query on the current logical flag and the first-level key of the breakpoint mapping table of the secondary structure to obtain the secondary node flag corresponding to the current logical flag and the breakpoint configuration association set. The node identifier, the secondary node identifier, and the breakpoint configuration association set are precisely matched to obtain the target breakpoint configuration information. If the target breakpoint configuration information is empty or the target breakpoint configuration information is in an inactive state, an invalid breakpoint enable state is obtained. Alternatively, if the target breakpoint configuration information is not empty and the target breakpoint configuration information is in an enabled state, a valid breakpoint enabled state is obtained. The process of restoring and merging the target recovery command and front-end / back-end debugging events to obtain consistent debugging results includes: The status of the target recovery command is obtained; if the target recovery command is invalid, an invalid debugging result is obtained. Alternatively, if the target recovery instruction is in a valid state, the target recovery instruction can be adapted to the current execution flow state to obtain the execution recovery result; The front-end and back-end debugging events are converted into standardized debugging events. The standardized debugging events are associated with the unified front-end service components to obtain basic debugging results; Obtain cross-platform call path information, and fuse the execution recovery result, the basic debugging result, and the cross-platform call path information to obtain a consistent debugging result.

2. The method according to claim 1, characterized in that, The evaluation process of the breakpoint enable state, conditional breakpoint expression, and current execution context to obtain the expression verification result includes: The validity of the breakpoint's enabled state is obtained. If the breakpoint's enabled state is invalid, the invalid expression validation result is obtained. Alternatively, if the breakpoint is enabled and in a valid state, the type of the target breakpoint configuration information is determined to obtain the breakpoint type identifier. When the breakpoint type is identified as a non-conditional breakpoint type, a valid expression validation result is obtained; Alternatively, if the breakpoint type is identified as a conditional breakpoint, the conditional breakpoint expression and the current execution context are substituted into the conditional operation to obtain the conditional operation result. If the result of the conditional operation is false, an invalid expression verification result is obtained; Alternatively, if the result of the conditional operation is true, a valid expression verification result is obtained.

3. The method according to claim 1, characterized in that, The process of integrating the expression validation result and the core information of the current execution environment to obtain a pause context object includes: Obtain the status of the expression validation result. If the expression validation result is invalid, obtain an invalid pause context object. Alternatively, if the expression validation result is valid, collect the core information of the current execution environment; The core information is integrated, and the integrated core information is subjected to field integrity and format compliance verification to obtain an effective pause context object.

4. The method according to claim 1, characterized in that, The process of adapting and encapsulating the pause context object with the structure and data specifications of the unified messaging protocol to obtain a standardized pause event includes: Obtain the state of the pause context object; if the pause context object is in an invalid state, obtain an invalid standardized pause event. Alternatively, if the pause context object is in a valid state, the pause context object can be adapted to the structure of the unified messaging protocol to obtain an initial adaptation message. The initial adaptation message and the data specification are subjected to consistency verification to obtain the verification result; If the verification result is unsuccessful, an invalid standardized pause event is obtained; Alternatively, if the verification result is successful, a valid standardized pause event is obtained.

5. The method according to claim 3, characterized in that, The core information includes at least one of the following: execution session identifier, logic identifier, node identifier, variable snapshot, call stack, source identifier, timestamp, pause reason, and session name.

6. An execution device for front-end and back-end debugging nodes of a low-code platform, characterized in that, include: The acquisition module is used to acquire the running status of the front-end and back-end debugging nodes and obtain the debugging enable identifier based on the running status; The processing module is used to perform matching and verification processing on the debug enable flag, current logic flag, node flag and the breakpoint mapping table of the secondary structure to obtain the breakpoint enable status; The processing module is also used to evaluate the breakpoint enable status, the conditional breakpoint expression, and the current execution context to obtain the expression verification result; The processing module is also used to integrate the expression validation result and the core information of the current execution environment to obtain a pause context object; The encapsulation module is used to adapt and encapsulate the pause context object with the structure and data specifications of the unified messaging protocol to obtain a standardized pause event. The processing module is also used to bind and transmit the standardized pause event with the corresponding message channel to obtain the target recovery instruction; The processing module is also used to perform recovery and path convergence processing on the target recovery command and the front-end and back-end debugging events to obtain consistent debugging results; The processing module is further configured to perform matching and verification processing on the debug enable flag, current logic flag, node flag, and breakpoint mapping table of the secondary structure to obtain the breakpoint enable status, wherein: Obtain the status of the debug enable flag; if the debug enable flag is in an inactive state, obtain the invalid breakpoint enable status. Alternatively, if the debugging enable flag is enabled, perform a matching query on the current logical flag and the first-level key of the breakpoint mapping table of the secondary structure to obtain the secondary node flag corresponding to the current logical flag and the breakpoint configuration association set. The node identifier, the secondary node identifier, and the breakpoint configuration association set are precisely matched to obtain the target breakpoint configuration information. If the target breakpoint configuration information is empty or the target breakpoint configuration information is in an inactive state, an invalid breakpoint enable state is obtained. Alternatively, if the target breakpoint configuration information is not empty and the target breakpoint configuration information is in an enabled state, a valid breakpoint enabled state is obtained. The processing module is further configured to perform recovery and path convergence processing on the target recovery command and front-end / back-end debugging events to obtain consistent debugging results, wherein: The status of the target recovery command is obtained; if the target recovery command is invalid, an invalid debugging result is obtained. Alternatively, if the target recovery instruction is in a valid state, the target recovery instruction can be adapted to the current execution flow state to obtain the execution recovery result; The front-end and back-end debugging events are converted into standardized debugging events. The standardized debugging events are associated with the unified front-end service components to obtain basic debugging results; Obtain cross-platform call path information, and fuse the execution recovery result, the basic debugging result, and the cross-platform call path information to obtain a consistent debugging result.

7. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 5.

Images