Positioning path construction method and page anomaly positioning method

Abstract

Embodiments of the present specification provide a positioning path construction method and a page exception positioning method, wherein the positioning path construction method comprises: obtaining an original page description file of a business page, and configuring design identification information corresponding to each page component node in the business page in the original page description file to obtain a target page description file; constructing a node positioning unit corresponding to each page component node according to the target page description file; generating a node positioning path corresponding to each page component node based on the node positioning unit, wherein the node positioning path is obtained by sequentially splicing the node positioning unit corresponding to the page component node and the node positioning path corresponding to the parent node of the page component node; and adding the node positioning path corresponding to each page component node to a page running instance of the business page, wherein the node positioning path is used for running exception positioning of the business page.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of page anomaly location technology, and particularly to a method for constructing a location path and a method for locating page anomalies. Background Technology

[0002] With the development of computer and internet technologies, low-code platforms play a crucial role in software development. During the design phase, they rely on a page designer to generate page description files. These files typically use JSON format to construct a tree-like private structure, fully recording core elements such as the page root node, child page container nodes, low-code component nodes, basic component nodes, and event configuration nodes. During runtime, the low-code runtime engine parses this description file, instantiates page nodes and component nodes, and ultimately renders an interactive business page. When user actions such as button clicks, tab switching, or form submissions are triggered, the engine executes logic based on the page structure and event configuration, and reports the execution results or exception information to the logging system. In simple page scenarios, the logic identifiers, action names, or exception stack traces in the logs can still help locate problems. However, as the business page structure becomes more complex, problems become significantly more prominent. Complex pages generally contain multi-layered nested child page containers, reused low-code component resources, and a large number of basic components. For example, a customer management page and a contract management page may both reference the same "Contact Query Area" low-code component, and both components may contain a "Query Button." If the query fails, the logs only record a general logical identifier and a simplified stack trace, making it impossible for investigators to identify the specific page from which the error originated. This necessitates repeating the operation to reproduce the problem and tracing it layer by layer, significantly increasing diagnostic costs. Therefore, an effective solution is urgently needed to address these issues. Summary of the Invention

[0003] In view of this, embodiments of this specification provide a method for constructing a location path. One or more embodiments of this specification also relate to a location path construction apparatus, a page anomaly location method, a page anomaly location apparatus, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0004] According to a first aspect of the embodiments of this specification, a method for constructing a location path is provided, comprising: Obtain the original page description file of the business page, and configure the design identification information corresponding to each page component node in the business page in the original page description file to obtain the target page description file; Construct node positioning units corresponding to each component node of the page based on the target page description file; Based on the node positioning unit, a node positioning path is generated for each page component node. The node positioning path is obtained by concatenating the node positioning unit corresponding to the page component node and the node positioning path corresponding to the parent node of the page component node in sequence. Add the node location path corresponding to each page component node to the page running instance of the business page, wherein the node location path is used for locating running anomalies of the business page.

[0005] According to a second aspect of the embodiments of this specification, a method for locating page anomalies is provided, comprising: Obtain the original page description file of the business page, and configure the design identification information corresponding to each page component node in the business page in the original page description file to obtain the target page description file; Based on the target page description file, construct the node location path corresponding to each page component node, and add the node location path corresponding to each page component node to the page execution instance of the business page; When an interaction event is triggered for the business page, the target node location path corresponding to the interaction event is determined by accessing the running instance of the page; The location information of the event trigger page corresponding to the interactive event is determined based on the target node positioning path.

[0006] According to a third aspect of the embodiments of this specification, a location path construction apparatus is provided, comprising: The acquisition module is configured to acquire the original page description file of the business page, and configure the design identification information corresponding to each page component node in the business page in the original page description file to obtain the target page description file; The construction module is configured to construct node positioning units corresponding to each component node of the page based on the target page description file; The generation module is configured to generate node positioning paths corresponding to each page component node based on the node positioning unit, wherein the node positioning path is obtained by concatenating the node positioning unit corresponding to the page component node and the node positioning path corresponding to the parent node of the page component node in sequence. The module is configured to add the node location path corresponding to each page component node to the page running instance of the business page, wherein the node location path is used for locating running anomalies of the business page.

[0007] According to a fourth aspect of the embodiments of this specification, a page anomaly location device is provided, comprising: The file acquisition module is configured to acquire the original page description file of the business page, and configure the design identification information corresponding to each page component node in the business page in the original page description file to obtain the target page description file; The path building module is configured to build the node location path corresponding to each page component node according to the target page description file, and add the node location path corresponding to each page component node to the page execution instance of the business page; The access instance module is configured to determine the target node location path corresponding to the interaction event by accessing the running instance of the page when an interaction event is triggered for the business page. The information determination module is configured to determine the location information of the event triggering page corresponding to the interactive event based on the target node's location path.

[0008] According to a fifth aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, they implement the steps of the above-mentioned location path construction method or page abnormal location method.

[0009] According to a sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of the above-described location path construction method or page anomaly location method.

[0010] According to a seventh aspect of the embodiments of this specification, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described location path construction method or page anomaly location method.

[0011] The location path construction method provided in this embodiment aims to achieve accurate location of any problem in a low-code platform, eliminating the problem of inaccurate location due to identical identifiers. It first obtains the original page description file of the business page and configures the design identifier information corresponding to each page component node in the original page description file to obtain the target page description file. This involves embedding special identifier information in the page description file for subsequent path construction. Then, based on the target page description file, node positioning units corresponding to each page component node are constructed. Based on these node positioning units, node positioning paths corresponding to each page component node are generated. The node positioning paths are obtained by sequentially concatenating the node positioning units corresponding to the page component nodes and the node positioning paths corresponding to the parent nodes of the page component nodes. Finally, the node positioning paths corresponding to each page component node are added to the page execution instance of the business page. These node positioning paths are used for locating runtime anomalies in the business page. By constructing node positioning paths and adding them to the page execution instance for runtime anomaly location, the method can accurately locate the location of runtime anomalies in the business page, eliminating the difficulty in location due to identical identifiers and effectively improving the efficiency of problem solving during the page development phase. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating a location path construction method provided in one embodiment of this specification; Figure 2 This is a flowchart of a page anomaly location method provided in one embodiment of this specification; Figure 3 This is a flowchart illustrating the process of a page anomaly location method provided in one embodiment of this specification. Figure 4 This is a schematic diagram of a positioning path construction device provided in one embodiment of this specification; Figure 5 This is a schematic diagram of the structure of a page anomaly location device provided in one embodiment of this specification; Figure 6 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0013] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0014] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0015] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0016] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0017] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0018] A Low-Code Development Platform (LCDP) is a digital tool platform that supports visual application development. Its core feature is that it enables the rapid completion of the entire lifecycle of an application by using only a small amount of code or even no code, through graphical drag-and-drop and parameterized configuration.

[0019] This specification provides a method for constructing a location path. One or more embodiments of this specification also relate to a location path construction apparatus, a page anomaly location method, a page anomaly location apparatus, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0020] In practical applications, within the runtime environment of a low-code platform, business pages consist of a tree structure comprised of a root node, child page container nodes, low-code component nodes, ordinary component nodes, and event configuration nodes. When the page structure is complex and involves multiple levels of nesting, existing technologies cannot establish a unique mapping between the running instance of a page and the specific nodes that make up the page when runtime exceptions occur. Specifically, the exception information recorded by the log system only includes logical identifiers, action names, or local component descriptions, lacking a complete context of the page hierarchy and component instances. This makes it difficult to accurately identify the specific location of the error source during problem localization, affecting system maintainability and fault diagnosis efficiency. For example, in a financial business system, both the customer information page and the loan application page reuse the same "Customer Basic Information Entry" low-code component resource. This component contains multiple field input boxes and a submit button, and its save logic is bound to the submit event. When a user triggers a submit operation on the customer information page, if the save logic fails, the log system only outputs the save logic identifier and the failure status, without recording the specific page location where the event was triggered. Because component resources are reused across multiple pages, and the page structure contains nested subpage containers and low-code component containers, the lack of a stable hierarchical source propagation mechanism at runtime makes it impossible for operations and maintenance personnel to distinguish whether the error originates from the customer information page or the submission operation on the loan application page. If this problem is not addressed, locating runtime anomalies will heavily rely on manual reproduction and layer-by-layer troubleshooting, which not only increases the complexity and time cost of fault diagnosis but may also prolong the duration of business interruptions. Therefore, an effective solution is urgently needed to address these issues.

[0021] In view of this, see Figure 1 , Figure 1 A flowchart of a location path construction method according to an embodiment of this specification is shown, which specifically includes the following steps.

[0022] Step S102: Obtain the original page description file of the business page, and configure the design identification information corresponding to each page component node in the business page in the original page description file to obtain the target page description file.

[0023] Step S104: Construct node positioning units corresponding to each component node of the page according to the target page description file.

[0024] Step S106: Generate node positioning paths corresponding to each page component node based on the node positioning unit. The node positioning path is obtained by sequentially concatenating the node positioning unit corresponding to the page component node and the node positioning path corresponding to the parent node of the page component node.

[0025] Step S108: Add the node location path corresponding to each page component node to the page running instance of the business page, wherein the node location path is used for locating the running anomaly of the business page.

[0026] The location path construction method provided in this embodiment can be applied to any type of page-related problem location scenario in low-code platforms, such as transaction pages, Q&A interaction pages, shopping pages, resource management pages, multimedia data interaction pages, etc. It is used to construct node location paths and add them to the page running instance for abnormal location. It can accurately locate the abnormal location of the business page and eliminate the problem of location difficulties due to identical identifiers, effectively improving the efficiency of problem solving during the page development stage.

[0027] Specifically, a business page refers to the application interface built by the page designer in a low-code platform and ultimately presented to the user for interaction. This page typically consists of multiple configurable and interactive elements, carrying specific business functions. The original page description file (OPF) is a structured file generated by the page designer during the business page design phase. It is usually stored in formats such as JSON and records information such as the page's initial structure, component configuration, event bindings, and logic configuration. This file is the foundation for building the business page. Page component nodes are the basic elements that make up the business page, such as the page root node, child page container nodes, low-code component nodes, basic component nodes, and event configuration nodes. Each node represents an identifiable part of the page structure. Design identification information refers to the unique identifier assigned to each page component node during page design. This identifier is assigned during the design phase and is used to uniquely identify and reference specific page component nodes in the page description file, forming the basis for building the location path. The target page description file is the page description file obtained after configuring the design identification information based on the original page description file. This file contains the design identification information of all page component nodes, providing necessary data for subsequent runtime location.

[0028] Correspondingly, a node positioning unit refers to the smallest logical unit used to uniquely identify a node, constructed based on the design identification information and other relevant attributes of the nodes that make up the page. It is a fundamental component of the node positioning path. A node positioning unit can be used to describe a page structure node or an event triggering node, and its structure can be shown in Table 1 below: Table 1

[0029] Correspondingly, a node positioning path refers to a complete path starting from the root node of the business page, following the page structure hierarchy, and formed by sequentially concatenating the node positioning units corresponding to each page component node. This path uniquely identifies the position of any page component node within the entire page structure. A page runtime instance refers to the actual running state of the business page in memory after it has been loaded, parsed, and instantiated in the low-code runtime engine, allowing for user interaction and logic execution. All page component nodes and their associated positioning paths exist within this instance. Runtime exception localization refers to the process of quickly and accurately determining the specific page component node, component instance, and its hierarchical position within the page structure when an error or exception occurs during the execution of the business page, using information such as the node positioning path.

[0030] Based on this, the original page description file of the business page is first obtained, and the design identification information corresponding to each page component node in the business page is configured in the original page description file to obtain the target page description file. In one implementation, when saving the page file, the page designer can assign a unique string as design identification information to each identifiable element in the page (e.g., a text box, a button, or a data table). This identification information is directly written into the corresponding node structure of the original page description file. For example, a simple page may contain a root node, a form container node, and a submit button node. During the configuration process, "root_page_id" can be assigned to the root node, "form_container_id" to the form container node, and "submit_button_id" to the submit button node. This identification information is embedded in the JSON structure of the original page description file to form the target page description file. The design identification information can consist of a node identifier plus a random number of digits, or other rules can be set; this embodiment does not impose any limitations on this.

[0031] Furthermore, node positioning units corresponding to each page component node are constructed based on the target page description file. As one implementation, when the low-code runtime engine loads the target page description file and instantiates the page nodes, it can generate a node positioning unit for each page component node. This node positioning unit can be a simple string containing node type and design identifier information, such as "NodeType:DesignID". For example, for the submit button node mentioned above, its node positioning unit could be constructed as "Button:submit_button_id". This approach ensures that each node has a recognizable, basic positioning identifier at runtime.

[0032] Based on this, node positioning paths are generated for each page component node using node positioning units. Each node positioning path is obtained by sequentially concatenating the node positioning units corresponding to the page component node and the node positioning paths corresponding to its parent node. Specifically, during page instantiation, each node, when constructing its own positioning path, first obtains the positioning path already constructed by its parent node, and then appends its own node positioning unit to the parent node's path. For example, if the root node's positioning path is "123", and the form container node's parent node is the root node, its positioning path will be "123 / 456". The submit button node's parent node is the form container node, and its positioning path will be "123 / 456 / 789". This hierarchical concatenation method ensures that each node has a complete and unique path from the page root node to itself.

[0033] Finally, the node location path corresponding to each page component node is added to the page runtime instance of the business page. This node location path is used for locating runtime exceptions on the business page. As one implementation, when the page runtime engine instantiates a page component node, the complete node location path generated for that node can be stored as an attribute directly in the runtime object corresponding to that node. When a runtime exception occurs on the page, such as the failure of an event logic execution in a component, the system can directly read the stored node location path from the runtime object of the component that encountered the exception. This path can then be logged for subsequent exception investigation.

[0034] For example, consider an "Order Management" page containing a main order list area, a nested "Product Details" subpage container, and a reused "Inventory Query" low-code component within that subpage container. This "Inventory Query" component itself contains a "Query" button. When user A operates the "Query" button within the "Inventory Query" component on the "Product Details" subpage of the "Order Management" page, if the query logic malfunctions, traditional methods might only record "Query logic failed" or "Inventory Query component error," making it difficult to determine which specific "Inventory Query" component instance is affected and which subpage it resides in. To address this, this embodiment first obtains the original page description file during the design phase of the "Order Management" page. In this file, unique design identifiers are configured for the root node of the "Order Management" page, its internal "Product Details" subpage container node, the "Inventory Query" low-code component node, and the "Query" button node. For example, the root node is assigned "abc," the subpage container is assigned "def," the low-code component is assigned "ghi," and the button is assigned "jkl." These identification information are written into the original page description file to generate the target page description file.

[0035] Next, when the "Order Management" page is loaded and instantiated in the low-code runtime engine, the system constructs node positioning units for each page component node based on the target page description file. For example, the positioning unit corresponding to the "abc" node might be "Root:abc", the positioning unit corresponding to the "def" node might be "Container:def", the positioning unit corresponding to the "ghi" node might be "LowCode:ghi", and the positioning unit corresponding to the "jkl" node might be "Button:jkl".

[0036] Subsequently, the system generates hierarchical node positioning paths based on these node positioning units. First, the positioning path for "abc" is its own positioning unit. Then, the positioning path for "def" is "Root:abc / Container:def". The positioning path for "ghi" is "Root:abc / Container:def / LowCode:ghi". Finally, the positioning path for "jkl" is "Root:abc / Container:def / LowCode:ghi / Button:jkl". These complete node positioning paths are then added to the page runtime instance of the "Order Management" page as an attribute of the runtime object of each page's constituent nodes. When user A clicks the "Query" button and its internal logic fails, the runtime engine can directly read its complete node positioning path from the runtime object of the "Query" button. This path is logged, for example: "An exception occurred at Root:abc / Container:def / LowCode:ghi / Button:jkl". By following this path, investigators can immediately and accurately determine that the anomaly occurred in the "Inventory Inquiry" component within the "Product Details" subpage of the "Order Management" page, rather than in a button with the same name on other pages or components, thus achieving precise location of the operational anomaly.

[0037] In summary, by constructing node location paths and adding them to the page running instance for runtime exception location, the location of runtime exceptions on the business page can be accurately located, eliminating the difficulty in location due to identical identifiers, and effectively improving the efficiency of problem solving during the page development stage.

[0038] Furthermore, in complex business scenarios, page structures often contain various types of nodes. Without a systematic classification and labeling standard for these nodes, the subsequent node location paths will have ambiguity in hierarchical relationships, resource ownership, and logical connections, making accurate anomaly location difficult. Therefore, in this embodiment, configuring the design identifier information corresponding to each page component node in the business page in the original page description file to obtain the target page description file includes: The process involves identifying multiple page component nodes corresponding to the business page, including a page root node, a subpage container node, a low-code component node, a basic component node, and an event configuration node; generating design identification information for each of the page root node, the subpage container node, the low-code component node, the basic component node, and the event configuration node; configuring the design identification information into the original page description file; and generating a target page description file based on the configuration results.

[0039] Specifically, the root node is the top-level node of the entire page, representing the overall structure of the page. Subpage container nodes are used to host and manage nested subpages or modules, enabling page modularity and reusability. Low-code component nodes refer to reusable components with specific business functions built through a low-code platform, such as data query areas and form submission areas. Basic component nodes are the basic UI elements that make up the page, such as buttons, input boxes, text, and images. Event configuration nodes link user interaction behavior with backend logic, defining the operations that components should perform when specific events are triggered. Classifying these different types of nodes provides a clear structural basis for subsequent identifier generation and path construction. When the page designer parses the original page description file, it can automatically identify and classify the root node, subpage container nodes, low-code component nodes, basic component nodes, and event configuration nodes according to predefined node type rules (e.g., by tag name, attribute, or specific structural pattern). Alternatively, in the page designer, when users drag and drop or configure page elements, the system automatically categorizes the created elements into one of the above five node types based on user operations and records their type information.

[0040] Correspondingly, independent design identification information can be generated for each type of node, aiming to ensure that each node has a traceable and unique "ID number" within a specific scope in the page description file. This identifier can be a string, hash value, or other unique code, and its purpose is to distinguish different nodes in the page structure without considering runtime instances, especially when there are nodes of the same type or reused components. Globally unique identifiers (GUIDs / UUIDs) can be used as design identification information to ensure the uniqueness of nodes throughout the entire system. Alternatively, locally unique identifiers can be generated by combining information such as node type, node name, and parent node path hash value to ensure uniqueness within the current page or component structure. For example, for the page root node, an identifier based on the page ID can be generated; for the child page container node, an identifier based on its index in the parent node and the child page template ID can be generated; for low-code component nodes, an identifier based on the component ID and its position in the parent node can be generated; for basic component nodes, an identifier based on its type and unique index in the parent node can be generated; and for event configuration nodes, an identifier based on the component identifier it is bound to and the event type can be generated. This embodiment is not limited in any way.

[0041] Based on this, by finely classifying and identifying the nodes that make up the page, a solid foundation is laid for the subsequent construction of node positioning units and node positioning paths. The design identifier of the page root node establishes the starting point of the entire page; the design identifiers of child page container nodes and low-code component nodes solve the problem of hierarchical differentiation in nested structures; the design identifiers of basic component nodes enable accurate identification of the smallest interaction unit; and the design identifiers of event configuration nodes closely associate logical trigger points with the page structure. This systematic identifier configuration enables the runtime engine to clearly identify the source, hierarchy, and function of each component when processing page instances. Thus, in the event of an exception, it can construct an accurate node positioning path based on this design identifier information and the parent node path, ultimately achieving precise location of the specific page position.

[0042] It's important to note that when the same page or low-code component is referenced in multiple locations, its internal nodes can still retain the same design-time unique identifier. This is because multiple instances are generated at runtime, and a single design-time unique identifier cannot be directly used as a globally unique runtime identifier. It must be combined with the parent's complete location path to distinguish the specific trigger source. Therefore, design identifier information is unaffected by this. When a regular component is located inside a low-code component, the regular component's design-time unique identifier is unique within that low-code component's structure. When a low-code component is referenced and instantiated by a page, the runtime distinguishes the specific trigger point through the outer page source, the low-code component source, and the internal regular component's design-time unique identifier. Simultaneously, when an event is bound to a regular component or a low-code component, the system records the event identifier, event name, the design-time unique identifier of the node it belongs to, and the corresponding logical identifier. Event configurations do not replace component nodes independently but are appended to the complete location path as trigger units after the component node.

[0043] For example, suppose a business page contains a root node, which nests a child page container node. The child page container node contains a low-code component node, which in turn contains a basic component node (e.g., a button), and this button is bound to an event configuration node. First, in the page designer, when the user completes the page design and is ready to save, the system traverses the page's DOM structure or its corresponding JSON description file. The system will identify: the page root node (e.g., the root node of the entire page or the top-level node). ); subpage container node (e.g., one used to load subpages) <iframe>(Or custom components); low-code component nodes (e.g., a custom component instance named "User Query Component"); base component nodes (e.g., a "Query" button inside the "User Query Component"); event configuration nodes (e.g., the onClick event of the "Query" button). The system then generates design identifier information for each of these nodes. For example, for the page root node, the system can generate an identifier such as page_root_12345; for the subpage container node, it can generate an identifier such as subpage_container_abcde; for the low-code component node, it can generate an identifier such as lowcode_comp_user_query_fghij; for the base component node (button), it can generate an identifier such as base_comp_button_query_klmno; and for the event configuration node (onClick event), it can generate an identifier such as event_config_onclick_pqrst. These identifiers can remain unique within the current page or component structure. Finally, the system adds these generated design identifiers as new attributes to the corresponding node objects in the original page description file. After completing the identifier configuration for all nodes, the system saves this updated file as the target page description file. This target page description file now contains all the necessary metadata, enabling the runtime engine to construct precise node location paths based on this identifier information. This allows the system to trace back to the specific page component node even if an anomaly occurs during page execution.

[0044] In summary, by refining the classification and identification configuration of various nodes in the business page, a structured foundation is laid for the subsequent construction of high-precision positioning paths. Clearly defining the five core node types—page root node, subpage container node, low-code component node, basic component node, and event configuration node—allows for the logical decomposition of the complex page tree structure, ensuring that each component has a unique and traceable identity in the page's running instance.

[0045] Based on this, when existing low-code platforms configure design identification information into the original page description file to obtain the target page description file, if there is a lack of effective verification and repair mechanisms, the generated page description file may have structural errors or missing configurations, which in turn affects the construction of subsequent node positioning units and the accuracy of the positioning path.In this embodiment, configuring the design identifier information into the original page description file and generating the target page description file based on the configuration result includes: The design identifier information is configured into the original page description file to obtain an intermediate page description file; the intermediate page description file is validated using a page designer; if the intermediate page description file passes validation, it is used as the target page description file; if the intermediate page description file fails validation, it is repaired according to a preset file repair strategy to obtain the target page description file.

[0046] Specifically, design identification information is configured into the original page description file to obtain an intermediate page description file. The aim is to embed pre-generated design identification information, used to uniquely identify each page component node in the business page, into the original page description file of the business page. The original page description file is typically stored in JSON, XML, or other structured data formats, describing the page's structure, components, attributes, and events. Through configuration operations, design identification information is added as new attributes or fields to the corresponding page component nodes, thus forming an intermediate page description file containing this identification information. This process can be implemented through automated scripts, page designer interface operations, or API calls. For example, the DOM tree or JSON structure of the original page description file can be traversed, and an attribute named `designId` can be inserted into each node (such as the page root node, child page container node, low-code component node, basic component node, and event configuration node), assigning it a unique value. Another implementation is that in the page designer, when the user drags or configures a component, the system automatically generates and associates a design identification information for that component and writes it to the corresponding position in the page description file.

[0047] Accordingly, the intermediate page description file is validated using the page designer. The purpose of this step is to ensure that the intermediate page description file, after configuring the design identifier information, conforms to the predetermined structural specifications and business logic requirements. As a visual editing tool, the page designer usually has a powerful built-in validation engine. The validation process may include, but is not limited to: checking the uniqueness of the design identifier information to ensure that there are no duplicate identifiers on the same page; verifying the existence or correct format of key fields (such as resource identifiers and type information); checking whether the parent-child node relationship is reasonable to avoid isolated nodes or circular references; and verifying whether the event binding points to valid components or logic. For example, the validation engine can parse the intermediate page description file, construct its internal data model, and then compare it one by one against the preset validation rule set.Another approach is to automatically execute a series of predefined schema validations or custom rule checks when the page designer saves, to ensure the integrity and consistency of the file.

[0048] Accordingly, if the intermediate page description file fails verification, the intermediate page description file is repaired according to a preset file repair strategy to obtain the target page description file. This step aims to enable the system to automatically or semi-automatically correct the intermediate page description file when it fails verification, so that it meets the specifications. The preset file repair strategy can be customized according to specific error types. For example, for duplicate design identification information, a unique identifier can be automatically regenerated; for missing required fields, a default value can be inserted or the user can be prompted to manually fill it in; for unreasonable parent-child relationships, the structure can be adjusted or abnormal nodes can be deleted. For example, the repair strategy can be a rule engine containing multiple repair rules, each rule corresponding to a common verification failure situation. When verification fails, the engine will automatically match and execute the corresponding repair rule according to the error report. Another implementation is that the system provides an interactive repair interface to show the user the specific location and reason for the verification failure and provide repair suggestions. After the user confirms, the system performs the repair operation until the file passes verification.

[0049] Based on this, by introducing a structured verification and repair process, the high quality and usability of the business page description file after configuring design identification information are ensured. First, after obtaining the original page description file of the business page, the system will configure the corresponding design identification information for each page component node in the business page, thereby generating an intermediate page description file. This step is the basis for the subsequent construction of node positioning paths, which gives each locatable element in the page a unique identity. On this basis, in order to avoid errors that may be introduced during manual or automated configuration, this solution uses the page designer to strictly verify the intermediate page description file. The page designer can identify and report potential problems in terms of file structure, identifier uniqueness, field integrity, etc. This verification mechanism is a key link to ensure data quality. It can promptly detect and prevent non-compliant page description files from entering the subsequent processing flow. If the verification result shows that the intermediate page description file fully complies with the preset specifications, the file is directly adopted as the target page description file, thereby ensuring the efficiency of the process. However, in the case of failure to pass the verification, this solution does not simply terminate the process, but further introduces a preset file repair strategy. This strategy can automatically or semi-automatically correct intermediate page description files based on the specific error type. For example, it can automatically correct duplicate identifiers, add missing fields, or adjust unreasonable structures.Through this closed-loop repair mechanism, even if anomalies occur during configuration, the system can self-recover and ultimately obtain a compliant target page description file. Through the synergistic effect of the above verification and repair, this solution effectively solves the structural errors or configuration gaps that may exist in page description files in traditional methods, significantly improving the completeness, accuracy, and robustness of the target page description file. This provides a solid and reliable data foundation for subsequently constructing node positioning units corresponding to each page component node based on the target page description file, and generating node positioning paths corresponding to each page component node based on these node positioning units. In particular, when page component nodes include various complex types such as page root nodes, subpage container nodes, low-code component nodes, basic component nodes, and event configuration nodes, this mechanism ensures that the design identification information of all nodes is correctly configured and verified, thereby guaranteeing that the final generated node positioning paths accurately reflect the hierarchy and identity of page elements, providing precise evidence for locating operational anomalies in business pages.

[0050] For example, suppose a low-code platform is processing a complex business page, which contains a root node, multiple subpage container nodes, several low-code component nodes (such as a "user list" component and a "data filter" component), basic component nodes (such as buttons and input boxes), and event configuration nodes. First, the system obtains the original page description file of the business page, which may be a tree structure in JSON format. During the configuration of design identification information, the system traverses this JSON tree. For example, for the root node, the system adds a "designId": "pageRoot_123" attribute to it; after completing the configuration of identification information for all nodes, an intermediate page description file is generated. Subsequently, the page designer validates this intermediate page description file. For example, the designer's built-in validation rules check whether two different nodes are assigned the same designId (uniqueness check); if the validation finds, for example, that due to a copy-paste operation, an input box in the "user list" component and an input box in the "data filter" component unexpectedly have the same designId, the validation will fail. If this validation fails, the system will trigger a preset file repair strategy. This strategy may automatically detect duplicate designIds and automatically regenerate a new, unique designId for one of the duplicate input fields. After the repair is complete, the system will validate the file again. If the validation passes this time, the repaired intermediate page description file is confirmed as the final target page description file. Otherwise, the intermediate page description file is directly used as the target page description file.

[0051] In summary, by introducing a page designer to verify the intermediate page description file, various anomalies in the design identification information configuration process can be detected and corrected in a timely manner, such as duplicate identifications, missing key information, or unreasonable structures.

[0052] In specific implementation, when the root node of the page serves as the top-level entry point for the entire business page, the key challenge in achieving end-to-end anomaly localization lies in accurately extracting and integrating key identification information from the original page description file to construct a location unit that uniquely identifies the root node's position, thereby providing a stable and accurate benchmark for the subsequent generation of the entire page hierarchy path. In this embodiment, when the page component node is the page root node, the construction of the node location unit corresponding to the page root node includes: Obtain the root node design identifier information, root node resource identifier information, root node type information, and root node name information corresponding to the root node of the page from the target page description file; generate a node positioning unit corresponding to the root node of the page based on the root node design identifier information, root node resource identifier information, root node type information, and root node name information; wherein, the generation of the node positioning path corresponding to the root node of the page includes: generating the node positioning path corresponding to the root node of the page according to the node positioning unit corresponding to the root node of the page.

[0053] Specifically, the page root node is the top-level component of the business page and the starting point of the entire page structure tree, carrying the page's basic attributes and global configuration. As the parent node of all other page component nodes (such as child page container nodes, low-code component nodes, basic component nodes, and event configuration nodes), it is the starting point and anchor point for constructing the page hierarchy positioning path. In low-code platforms, the page root node typically corresponds to the root element of the top-level JSON object or XML document in the page description file, representing a complete business page instance.

[0054] Accordingly, the root node design identifier is a unique identifier assigned to the page root node during the page design phase. It is used to uniquely identify a specific page root node instance during design and runtime, and can be distinguished even when reused across multiple pages or environments. This identifier can be a globally unique string or an ID automatically generated by the designer and unique across the entire platform. The root node resource identifier is a unique identifier of the underlying resource (such as a page template or page module) associated with the page root node. It is used to identify the resource type or template on which the page root node is based, helping to distinguish different types of pages or page templates. This identifier can be a string pointing to a page template ID, page module ID, or the path / name of a specific page resource file.The root node type information describes the specific type or category of the page's root node. It distinguishes different types of root nodes, such as a regular business page, a pop-up page, or a page with a specific function. This type information can be a predefined enumeration value or a string representing the page component type. The root node name information is the user-friendly or display name of the page's root node. It provides a readable identifier for the page, helping users or developers understand the page's business meaning. It is typically a string, such as "Customer Management Page" or "Order Details Page."

[0055] Accordingly, generating the node positioning unit corresponding to the page root node refers to combining the obtained root node design identifier information, root node resource identifier information, root node type information, and root node name information to form a structured data unit. This unit is the unique "business card" of the page root node in the entire positioning system, laying the foundation for subsequent path concatenation. This information can be encapsulated into a JSON object or serialized into a specific string format. Generating the node positioning path corresponding to the page root node means that since the page root node is the starting point of the hierarchical structure, its node positioning path is its own node positioning unit. As the starting point of the entire page positioning path, it provides the foundation for the path concatenation of all subsequent child nodes. The node positioning unit corresponding to the already generated page root node can be directly used as its node positioning path.

[0056] Based on this, firstly, when loading a business page, the system parses the preprocessed target page description file. This file already contains the design identification information of the page root node and all its child nodes. For the page root node, the system accurately extracts its unique design identification information, resource identification information, type information, and name information from this file. These information together constitute a multi-dimensional identity code, ensuring that even in complex scenarios with multiple page instances or component reuse, the root node of the current business page can be uniquely and accurately identified. Subsequently, the system integrates these extracted information to generate a structured node positioning unit. Since the page root node is the starting point of the entire page hierarchy, its own node positioning path is composed of its corresponding node positioning unit. This process establishes a solid starting point for business page path tracing, providing a reliable anchor point for the generation of node positioning paths for all subsequent child page containers, low-code components, and basic components. In this way, the entire page execution instance can establish a clear and traceable hierarchical index from the root node to each level of child nodes, thereby effectively solving the problem of ambiguous path positioning caused by the lack of a unified root node identifier in complex page structures, and providing accurate contextual information for subsequent execution anomaly location.

[0057] For example, when the low-code runtime engine loads a business page named "Customer Management Page", it first reads the root node information of the page from the target page description file (e.g., a JSON file). Assuming that the JSON file contains description information corresponding to the root node, the runtime engine will subsequently obtain the following information: root node design identifier information is page_crm_dashboard_123, root node resource identifier information is template_business_page_v1, root node type information is BUSINESS_PAGE, and root node name information is Customer Management Page. Based on this information, the system will generate a node positioning unit corresponding to the page root node. For example, it can be encapsulated as an internal data structure or a serialized string. Since the page root node is the starting point of the entire page, its node positioning path is its own node positioning unit. Subsequently, when the page runtime instance is initialized, the node positioning path corresponding to the page root node is recorded inside the page runtime instance as the basis for concatenating all subsequent child node positioning paths. For example, when a child page container or low-code component is instantiated, it will be able to obtain the positioning path of the root node and add its own positioning unit on this basis, thereby constructing a complete positioning path from the page root node to itself.

[0058] In summary, by integrating root node design identifier information, root node resource identifier information, root node type information, and root node name information, the uniqueness and identifiability of the page root node in a complex low-code environment are ensured. This solves the problem of ambiguous path positioning caused by the lack of a unified root node identifier in traditional solutions, laying a solid foundation for the hierarchical positioning system of the entire business page. Based on this, the positioning path of all subsequent child nodes can be accurately traced starting from the page root node, greatly improving the accuracy and efficiency of page operation anomaly positioning, enabling investigators to quickly determine the specific page instance and hierarchical location where the error occurred, especially when the same low-code component resource is reused in multiple pages or multiple locations, effectively distinguishing the real trigger source.

[0059] Furthermore, when processing the generation of positioning paths for non-page root nodes, due to the complexity of the page structure and the existence of multiple nesting layers, how to accurately and efficiently obtain the positioning paths of the parent page constituent nodes and effectively associate them with the positioning units of the current non-page root nodes to ensure the integrity and accuracy of the positioning paths is a technical challenge faced by the current solution.In this embodiment, the generation of the node location path corresponding to any non-page root node includes: Determine the parent page component node corresponding to the non-page root node; determine the node positioning path corresponding to the parent page component node from component attribute information, runtime context information, dependency injection information, or scheduling context information using preset path acquisition rules; concatenate the node positioning unit corresponding to the non-page root node and the node positioning path corresponding to the parent page component node according to the page access order to obtain the node positioning path corresponding to the non-page root node.

[0060] Specifically, determining the parent page component node corresponding to a non-page root node aims to clarify the direct superior node of the current non-page root node in the page hierarchy. In business pages built on low-code platforms, pages are typically presented as tree structures, and each node (such as a child page container, low-code component, basic component, etc.) has a unique parent node (except for the page root node). Determining the parent node is the foundation for constructing a complete hierarchical positioning path, establishing the association between the current node and the upper-level structure. During page runtime, when a non-page root node is instantiated, its parent node instance can be passed as a parameter to the constructor or initialization method of the child node. The child node can directly obtain a reference to the parent node from these parameters, thereby determining its parent page component node. Alternatively, the page description file itself contains the hierarchical relationship of nodes. When parsing the page description file, a tree structure in memory can be constructed, and the parent page component node of any given non-page root node can be determined by traversing this structure or querying the parent pointer of the node.

[0061] Accordingly, the node location path corresponding to the parent page component node is determined from component attribute information, runtime context information, dependency injection information, or scheduling context information through preset path acquisition rules. This step is crucial for obtaining the location path already constructed by the parent node. Since the parent node may be instantiated and managed in different runtime environments (such as inside the component, runtime engine, dependency management system, or event scheduler), a set of preset rules is needed to guide the system to accurately extract the node location path of the parent node from these different information sources. This ensures that the location information of the parent node can be reliably obtained even in complex and dynamic page structures. The preset path acquisition rules can be defined as a series of search strategies. For example, first, try to find the attribute named "parentLocationPath" in the component attribute information of the current node; if not found, check whether there is a path associated with the parent node ID in the runtime context information; furthermore, the path acquisition service provided by the parent node instance in the dependency injection container can be queried; finally, the path information related to the parent node can be searched in the event scheduling context. As another implementation, a unified path acquisition interface or method can be bound to the parent page component node when it is instantiated.When a child node needs to obtain the location path of its parent node, it directly calls this interface or method. Internally, this interface or method extracts and returns the constructed node location path from its own component properties, runtime context, dependency injection, or scheduling context, based on the parent node's type and runtime environment.

[0062] Accordingly, the node positioning unit corresponding to the non-page root node and the node positioning path corresponding to the parent page component node are concatenated according to the page access order to obtain the node positioning path corresponding to the non-page root node. This step combines the local positioning information (node ​​positioning unit) of the current non-page root node with the complete hierarchical positioning information (node ​​positioning path) of its parent node to form a complete and unique node positioning path for the current node. The page access order usually refers to the hierarchical order from the page root node to the current node. This concatenation method ensures that the positioning path can accurately reflect the position of the node in the page structure. The concatenation operation can be implemented by string concatenation. For example, the node positioning path of the parent page component node is used as a prefix, then a separator (such as " / " or "") is added, and finally the node positioning unit corresponding to the non-page root node is connected. For example, if the parent path is "root / container1" and the positioning unit of the current node is "componentA", then the concatenated path is "root / container1 / componentA". Concatenation can also be achieved by constructing a list or array to represent the components of the path, with the path elements of the parent node first and the positioning unit elements of the current node last. The list elements are then concatenated into a string when a string representation of the path is needed.

[0063] Based on this, when a non-root node in a business page is instantiated, the system first accurately identifies its direct parent page component node. This identification process is the foundation for constructing hierarchical positioning paths, clarifying the subordinate relationship of the current node in the entire page tree structure. Subsequently, in order to obtain the complete positioning information of the parent node, the system intelligently extracts the node positioning path corresponding to the parent page component node from multiple information sources according to a set of preset path acquisition rules. These information sources include component attribute information, runtime context information, dependency injection information, or scheduling context information. This multi-dimensional and multi-channel acquisition strategy ensures that even when the parent node is in different lifecycle stages or managed by different mechanisms, its positioning path can be obtained accurately. For example, the parent node may pass its positioning path as a component attribute of the child node, or register it in the runtime context for the child node to query, or provide it to the child node through a dependency injection mechanism.Once the node location paths of the parent page's constituent nodes are obtained, the system concatenates the node location unit corresponding to the current non-root node with the node location path of its parent node, following the page access order. This concatenation method is not a simple string concatenation, but follows the hierarchical logic from the page root node to the current node, ensuring that the final generated node location path is a complete, unique identifier that accurately reflects the current node's position in the entire page structure. Through this progressive, level-by-level concatenation method, each non-root node can have a location path containing information about all its ancestor nodes. This scheme, combined with the basic location path construction method, provides a robust mechanism for constructing location paths for non-root nodes by introducing two key steps: "determining parent page constituent nodes" and "multi-source path acquisition rules." It enables stable transmission and construction of complete hierarchical source information even when running on low-code platforms, even when facing multi-layered nested child page containers, low-code components, or basic components. This mechanism ensures that each component instance carries its "identity card" within the page, allowing for precise tracing of the specific page location during subsequent anomaly detection.

[0064] For example, suppose a business page contains a "Customer Management" subpage container, which in turn contains a "Contact Query Area" low-code component, and the "Contact Query Area" component contains a "Query Button" basic component. When the "Query Button" is clicked, its corresponding node positioning path needs to be generated. First, when the "Customer Management" subpage container is instantiated, it generates and saves its own node positioning path based on the positioning path of its parent node (e.g., the page root node) and its own node positioning unit, for example: " / 123 / 456". Next, when the "Contact Query Area" low-code component is instantiated, it is a non-page root node. The system will determine that its parent page component node is the "Customer Management" subpage container. Then, the system will obtain the node positioning path corresponding to the parent page component node " / 123 / 456" by reading the attributes passed from the "Customer Management" subpage container from its component attribute information during the initialization process of the "Contact Query Area" component through preset path acquisition rules, for example, during the initialization process of the "Contact Query Area" component, by reading the attributes passed from the "Customer Management" subpage container from its component attribute information. Subsequently, the system will concatenate the node positioning unit (e.g., "789") of the "Contact Query Area" component with the node positioning paths corresponding to the parent page's constituent nodes, according to the page access order, to obtain " / 123 / 456 / 789" as the node positioning path of the "Contact Query Area" component. Finally, when the "Query Button" basic component is instantiated, it is also a non-page root node. The system will determine its parent page constituent node as the "Contact Query Area" low-code component.Similarly, the system retrieves the location path according to preset path rules. For example, it queries the runtime context information of the "Query Button" component to find the location path associated with the "Contact Query Area" component ID, obtaining the node location path corresponding to the parent page component node " / 123 / 456 / 789". Finally, the system concatenates the node location unit of the "Query Button" component itself (e.g., "369") with the obtained node location path corresponding to the parent page component node according to the page access order, obtaining " / 123 / 456 / 789 / 369" as the node location path of the "Query Button" component. Through the above process, each non-page root node can dynamically construct its complete, hierarchical node location path at runtime and add it to the page runtime instance of the business page for subsequent anomaly location.

[0065] In summary, by clearly defining the parent-child node relationship and utilizing a multi-source information acquisition mechanism, the accurate acquisition of the location path of the parent page's constituent nodes is ensured, avoiding the loss or confusion of path information caused by complex page structures or component reuse. Simultaneously, concatenation according to the page access order ensures the integrity of the node location path and the clarity of the hierarchical logic. This enables the generation of a unique and traceable location path for each non-page root node even when facing multi-layered nested component structures on a low-code platform. Consequently, in the event of a runtime exception, the specific page level and component instance can be accurately located, greatly improving the efficiency and accuracy of troubleshooting and solving the problem of traditional logs being unable to distinguish the true trigger source and the disconnect between error records and page sources.

[0066] Furthermore, during page operation, the parent page's constituent nodes may not have completed initialization, resulting in the inability to obtain accurate node location paths corresponding to the parent page's constituent nodes in a timely manner. This leads to delays or missing node location paths for non-page root nodes, affecting the real-time performance and accuracy of abnormal location. Therefore, in this embodiment, the method further includes: If the parent page component node has not completed the initialization operation, an initial node positioning path is constructed based on the node positioning unit corresponding to the non-page root node; if the parent page component node has completed the initialization operation, the initial node positioning path is updated based on the node positioning path corresponding to the parent page component node to obtain the node positioning path corresponding to the non-page root node.

[0067] Specifically, when a non-page root node needs to generate its location path, if its parent page component nodes have not yet been initialized, that is, the complete node location path corresponding to the parent page component nodes is not yet available, this solution provides a mechanism to ensure that the non-page root node can still obtain a basic and usable location identifier.Specifically, a node positioning unit containing only its own information can be generated using only the design identifier, resource identifier, type information, and name information of the non-page root node, and this unit can be used as the initial node positioning path for that node. Alternatively, in addition to the node positioning unit of the non-page root node itself, a temporary index in the current rendering context (e.g., its position in a dynamic list) or a temporarily generated unique identifier (e.g., a UUID) can be combined to construct a temporary but sufficient initial node positioning path to distinguish the non-page root node. This approach avoids the gaps in positioning information caused by the delayed initialization of parent page component nodes, ensuring that non-page root nodes have a basic positioning identifier at any runtime. Once the parent page component nodes have completed their initialization, their corresponding complete node positioning paths can be obtained. At this point, this solution triggers an update mechanism to correct and improve the initial node positioning path previously constructed for the non-page root node. In practical implementation, the system can listen for the initialization completion event of the parent page's component nodes. Once this event is triggered, it immediately obtains the node positioning path corresponding to the parent page's component node and concatenates it with the node positioning unit of the non-page root node itself, thereby generating a complete, hierarchical node positioning path corresponding to the non-page root node. Alternatively, the system can use periodic checks or asynchronous callbacks to periodically check whether the parent page's component nodes have been initialized and obtain their node positioning paths. If initialized, the above update operation is performed. This dynamic update mechanism ensures that the node positioning path corresponding to the non-page root node can smoothly transition from a basic temporary identifier to a precise final node positioning path containing complete hierarchical information, thus adapting to asynchronous loading and dynamic rendering scenarios of page components.

[0068] Based on this, the problem of constructing positioning paths caused by the difference in the initialization sequence of page component nodes is solved by introducing a dynamic update mechanism. When constructing the node positioning path corresponding to each page component node, for non-page root nodes, their node positioning path usually needs to depend on the node positioning path corresponding to their parent page component node. However, in complex business pages, especially in scenarios using asynchronous loading or dynamic rendering technology, the parent page component node may not have completed initialization, resulting in its node positioning path being temporarily unavailable. To address this challenge, this solution first constructs an initial node positioning path using the node positioning unit of the non-page root node itself when the parent page component node has not completed initialization. Although this initial node positioning path does not contain complete hierarchical information, it provides an immediate and basic positioning identifier for the non-page root node, ensuring that the non-page root node still has traceability when the parent page component node is not yet ready.Subsequently, when the parent page's component nodes complete their initialization and their corresponding node location paths become available, this solution updates the previously constructed initial node location paths based on the node location paths corresponding to the parent page's component nodes. Specifically, the system obtains the complete node location path corresponding to the parent page's component nodes and concatenates it with the node location units of the non-page root nodes according to the page access order, thereby obtaining a complete, hierarchical node location path corresponding to the non-page root nodes. This phased construction and dynamic correction method not only ensures the integrity of the node location paths in complex nested structures but also achieves a smooth transition from initial generation to precise refinement of the node location paths through real-time monitoring of the initialization state. This ensures that even if the initialization of the parent page's component nodes is delayed, the node location paths corresponding to the non-page root nodes can still be accurately constructed, effectively improving the reliability of anomaly location in dynamic loading scenarios. In this way, this solution, combined with the above-mentioned solution that uses preset path acquisition rules to determine the node location path corresponding to the parent page component nodes from component attribute information, runtime context information, dependency injection information, or scheduling context information, ensures that the node location path corresponding to non-page root nodes can be accurately and timely constructed and updated regardless of when the parent page component nodes are initialized. This avoids the problem of missing sources caused by asynchronous loading, thus providing more stable and comprehensive support for locating abnormal operation of business pages.

[0069] For example, a list contains multiple identical "product card" components, each containing a "buy button". These "buy buttons" may have the same design identifier information during design. At runtime, when a "buy button" needs to construct a node positioning path, if its parent "product card" has not yet been fully initialized, the "buy button" can first construct an initial node positioning path based on its own node positioning unit. Once the parent "product card" has been initialized and its node positioning path (which may contain an instance number or key value to distinguish different card instances) is available, the initial node positioning path of the "buy button" will be updated, thus obtaining a complete node positioning path containing instance differentiation information. This approach ensures that even in complex scenarios where parent page component nodes are asynchronously loaded or multiple instances are dynamically generated, each non-page root node can obtain an accurate and unique node positioning path.

[0070] In summary, by constructing the initial node positioning path when the parent page component nodes have not been initialized, it is ensured that non-page root nodes have a basic positioning identifier at any time, thus avoiding a gap in positioning information.Furthermore, once the parent page's constituent nodes have completed initialization, a dynamic update mechanism refines the initial node location path into a precise path containing complete hierarchical information, thereby ensuring the accuracy and completeness of the node location path.

[0071] In addition, for multiple running instances generated by dynamic rendering, conditional rendering or loop rendering, the system allows multiple instances to contain the same design-time unique identifier; at runtime, they are distinguished by the complete location path, instance number or instance key value stored in each instance, so as to avoid mistakenly interpreting the design-time identifier as the runtime globally unique identifier.

[0072] In actual business scenarios, when a user triggers a specific component event, relying solely on the static node location path often makes it difficult to directly associate it with the dynamic event execution context. This results in the inability to accurately map the event trigger point to the page hierarchy in real time when an abnormality occurs in the component event, making it difficult to quickly locate which event logic on which page component node has a problem. Therefore, in this embodiment, after the step of adding the node location path corresponding to each page component node to the page execution instance of the business page is executed, the method further includes: When a component event is triggered for the business page, the triggering page component node corresponding to the component event is determined, and the node positioning path corresponding to the triggering page component node is read in the page running instance; the event positioning unit corresponding to the component event and the node positioning path corresponding to the triggering page component node are concatenated according to the page access order to obtain the event positioning path; the event positioning path is written into the logical context information corresponding to the component event, wherein the event positioning unit includes the event identifier information, event name information, component design identifier information, and binding logic identifier information corresponding to the component event.

[0073] Specifically, component events refer to specific behaviors triggered when a user interacts with interactive elements on the page (such as buttons, input boxes, drop-down menus, etc.) during the runtime of a business page, or when the component's own state changes. For example, when a user clicks a button, a "click event" is triggered; when a user enters text in an input box and loses focus, a "loss of focus event" or a "value change event" is triggered. Component events can also be triggered internally by the system, such as a "data loading complete event" triggered when data loading is complete, or an "initialization complete event" triggered when component initialization is complete.

[0074] Accordingly, a triggering page component node refers to a page element in the business page that directly triggers a component event. For example, if a user clicks a button, then the button itself is a triggering page component node.If an event is triggered by a change in the value of an input field, then that input field is the triggering page component node. Identifying the triggering page component node is a crucial step in establishing the relationship between events and the page structure; it specifies the exact "location" where the event occurs.

[0075] Accordingly, the page access order refers to the agreed-upon rules for constructing the positioning path, following the hierarchical structure and logical relationships of page elements, from the root node to the child nodes level by level. Typically, this order is from parent node to child node, from container to its internal components, or according to the DOM tree structure rendered by the page. It can also be a specific access path preset according to business logic; for example, in multi-layered nested components, a specific access path can be defined from the outer container to the inner component. This order ensures that the generated positioning path is unique and readable, clearly reflecting the position of the event within the page structure.

[0076] Accordingly, the event location unit is the smallest set of information used to uniquely identify a component event, and it contains the attribute information of the event itself. This unit includes event identifier information, event name information, component design identifier information, and binding logic identifier information. The event identifier information is used to uniquely identify an event type, such as "click", "change", "submit", etc. The event name information is a descriptive name of the event, such as "query button click event" or "user input box value change event". The component design identifier information indicates the unique identifier of the component to which the event belongs at design time, such as the design time ID of a button component. The binding logic identifier information indicates the unique identifier of the business logic bound to the event, such as "query contact logic" or "submit form logic". The event location unit separates the logical attributes of the event from the page structure, so that the event itself can be independently identified and located.

[0077] Accordingly, logical context information refers to the carrier used to store and transmit relevant data, status, and environmental information during the execution of business logic. This information can be a data structure, such as a hash table or object, used to store context data in key-value pair form. It can also be a thread-local variable or a storage space for the request scope, ensuring the isolation and transmission of context information in a specific execution flow. By writing the event location path into the logical context information, it can be ensured that the original triggering position of the event can always be traced during subsequent logic execution, exception handling, and logging.

[0078] Based on this, by dynamically capturing the triggering of component events during the operation of the business page, and combining the pre-built page component node positioning path, an accurate event positioning path is generated in real time, thereby solving the technical problem of difficulty in distinguishing the source of events in complex business pages.Specifically, based on the node location paths corresponding to each page component node already added to the page execution instance of the business page, when any component event occurs in the business page, the system first identifies the triggering page component node that directly triggered the event. This identification process ensures a direct association between the event and a specific element in the page structure. Subsequently, the system reads the node location path corresponding to the triggering page component node from the page execution instance. This path is the unique identifier of the node in the entire page hierarchy, and it already contains all parent information from the page root node to the triggering node. Building upon this, to integrate the event's attributes into the location path, the system constructs an event location unit. This event location unit contains event identifier information, event name information, component design identifier information, and binding logic identifier information. This information collectively describes the event's type, name, its component, and associated business logic. Next, the system concatenates this event location unit with the previously read node location path corresponding to the triggering page component node, according to a preset page access order. This concatenation method ensures the hierarchy and completeness of the event location path. It not only specifies the exact page node where the event occurred but also includes the event's detailed attributes. Ultimately, the generated event location path is written into the logical context information corresponding to the component's event. In this way, no matter how complex the subsequent business logic is, or at what stage an exception occurs, the original trigger point of the event and its position in the page structure can be accurately traced using the event location path carried in the logical context information.

[0079] For example, suppose there is a product details page on an e-commerce platform, which includes an "Add to Cart" button. When a user clicks this button, a component event is triggered, and the corresponding business logic is executed. First, during the page design phase, the product details page is defined as a root node, which contains a product information display area (a subpage container node). This area contains a product operation low-code component node, and the "Add to Cart" button is a basic component node located inside this product operation low-code component node. Each node has been configured with unique design identifier information. During page runtime, based on the target page description file, the system constructs a node positioning unit for each page component node and generates a corresponding node positioning path. For example, the node positioning path for the "Add to Cart" button might be: "Product Details Page / Product Information Area / Product Operation Component / Add to Cart Button". This path has been added to the page runtime instance of the business page. When the user clicks the "Add to Cart" button, the system detects this component event. At this time, the system determines that the "Add to Cart" button is the triggering page component node.Subsequently, the system reads the node location path corresponding to the button from the page execution instance, namely "product details page / product information area / product operation component / add to cart button". Simultaneously, the system constructs an event location unit for this "click" event. This event location unit may contain: event identifier "click", event name "add to cart click event", component design identifier "add_to_cart_button_id", and binding logic identifier "addToCartLogic". Next, the system concatenates this event location unit with the read node location path according to the page access order. The concatenated event location path may be: "product details page / product information area / product operation component / add to cart button / click(addToCartLogic)". Finally, this complete event location path is written into the logical context information of the "add to cart" business logic.

[0080] In summary, by dynamically concatenating the event location unit with the location path of the page component node that triggered the event when a component event is triggered, accurate tracing from the static page structure to the dynamic event execution process is achieved. Reading the location path of the triggering page component node in the page running instance ensures that the accurate page hierarchy position at the time the current event occurs, effectively avoiding the ambiguity in location caused by component reuse or multi-level nesting. By concatenating the event location unit with the node location path using the page access order, a complete event location path is constructed. This process organically combines the logical attributes of the event with the physical location of the page, enabling subsequent anomaly analysis to directly locate the specific page node and its corresponding event logic.

[0081] In complex nested page structures, directly read node positioning paths may become unusable due to page state changes or complex hierarchical relationships, leading to event positioning path construction failures or inaccuracies, thereby affecting the accurate positioning of abnormal business page operation. Therefore, in this embodiment, after the step of reading the node positioning path corresponding to the trigger page component nodes in the page operation instance is executed, the method further includes: Determine whether the node positioning path corresponding to the component node of the triggering page meets the path usage conditions; if yes, execute the step of concatenating the event positioning unit corresponding to the component event and the node positioning path corresponding to the component node of the triggering page according to the page access order to obtain the event positioning path; if no, read the parent node positioning path of the parent node corresponding to the component node of the triggering page in the page running instance, and concatenate the parent node positioning path, the node positioning unit corresponding to the component node of the triggering page, and the event positioning unit corresponding to the component event according to the page access order to obtain the event positioning path.

[0082] Specifically, the above processing aims to evaluate the validity of the acquired node positioning paths. Path usage conditions may include, but are not limited to: checking whether the path string is empty, whether it contains a specific placeholder indicating an uninitialized or invalid state, whether the page component node instance pointed to by the path still exists in the page structure tree in the current runtime environment, whether its parent node chain is complete, or whether the path's hierarchical depth exceeds the preset maximum allowed value. By judging these conditions, the system can promptly identify whether the current node positioning path has become invalid or unusable due to page structure changes, node lifecycle status (such as being destroyed), or incomplete initialization, thereby providing a reliable basis for subsequent path splicing operations. When the node positioning path corresponding to the triggering page component node does not meet the usage conditions, this scheme provides a backtracking mechanism. Specifically, the triggering page component node usually maintains a reference to its direct parent node in the page runtime instance. The system can access the parent page component node through this reference and obtain its stored node positioning path from the parent page component node instance. Alternatively, the system can also traverse the page structure tree or component tree, search upwards from the triggering page component node for its parent node, and query the positioning path corresponding to that parent node. This approach aims to obtain a higher-level, more stable positioning foundation to compensate for the inadequacy of the current node path. After the backtracking mechanism is activated, how to reconstruct the complete event positioning path? The concatenation operation uses the parent node's positioning path as a base, and then appends the node positioning units of the triggering page's constituent nodes and the event positioning units corresponding to the component events in the order of page access (i.e., the top-down hierarchical relationship). For example, specific separators (such as forward slashes " / " or periods ".") can be used to connect these units, forming a logically continuous and complete path string. This concatenation method ensures that even if the complete path of the current node is unavailable, the system can still accurately reconstruct the context of the event's occurrence using its parent information and its own units.

[0083] Based on this, when a component event is triggered for a business page, the system first reads the node positioning path corresponding to the component node of the triggering page in the page running instance. Then, the system determines whether the path meets the preset path usage conditions. If the path meets the conditions, indicating that it is valid and usable, the system will concatenate the event positioning unit corresponding to the component event with the node positioning path corresponding to the component node of the triggering page according to the page access order, thereby directly obtaining the event positioning path. However, if the determination result is negative, i.e., the node positioning path corresponding to the component node of the triggering page does not meet the usage conditions, the system will not simply abandon the positioning, but will initiate an intelligent backtracking and reconstruction mechanism. At this time, the system will read the parent node positioning path of the parent node corresponding to the component node of the triggering page in the page running instance.This parent node positioning path is typically more stable and reliable because it represents a higher-level page structure. Based on this, the system concatenates the obtained parent node positioning path, the node positioning unit of the triggering page's constituent nodes, and the event positioning unit corresponding to the component event, according to the page access order, thereby reconstructing and obtaining the event positioning path. This hierarchical path completion strategy ensures that even in complex nested scenarios, if the underlying node path fails due to dynamic changes or initialization issues, the system can still accurately reconstruct the context of the event's occurrence using the parent path information and the current node's own positioning unit. In this way, the solution of this application effectively solves the problem of location interruption caused by missing or unavailable local paths, significantly improving the robustness and accuracy of abnormal location. In low-code platforms, even if the unique identifier of an internal node is repeated in multiple running instances, the real location can be distinguished by the complete path stored in each instance. Furthermore, when an event comes from a regular component within a low-code component, the complete location path stored in its own instance can be read first. If the path is missing, the method provided by its parent low-code component or parent container is called to obtain the parent's complete path and reconstruct its own complete path, avoiding the loss of specific reference locations while only recording the source of component resources.

[0084] For example, suppose a business page contains multiple nested low-code components. For instance, a root node of a page has a child page container, which in turn contains a low-code component, and this low-code component contains a base component, which has an event bound to it. When a user triggers the event on the base component, the system first attempts to obtain the node location path corresponding to the base component. For example, if the node location path of the base component becomes incomplete or invalid at runtime for some reason (e.g., the component has not been fully initialized or its parent container has been dynamically replaced), for example, the path string is "123 / 456 / 789 / null". In this case, the system will determine that the path does not meet the preset path usage conditions (e.g., the path contains a "null" placeholder). In this case, the system will not directly use this invalid path, but will trace upwards. It will read the direct parent node of the base component from the page running instance, that is, the parent node location path corresponding to the low-code component, assuming the path is "123 / 456 / 789". Subsequently, the system will obtain the node positioning unit of the basic component itself (e.g., "Button1"), and the event positioning unit corresponding to the triggered component event (e.g., "onClick").Finally, the system will concatenate the parent node location path "123 / 456 / 789", the basic component's node location unit "Button1", and the event location unit "onClick" according to the page access order, thus obtaining the complete event location path "123 / 456 / 789 / Button1 / onClick". In this way, even if there are problems with the initial path, the system can construct an accurate event location path through the backtracking mechanism.

[0085] In summary, by introducing a mechanism to determine the conditions for path usage, the validity of the node location path can be dynamically verified, thereby ensuring the reliability of the event location path construction. When the path does not meet the conditions, the system can intelligently backtrack to the location path of the parent node and reconstruct the complete event location path by combining the location unit of the current node, avoiding location interruption caused by the failure of a local path. This significantly improves the robustness and accuracy of locating abnormal business page operation, enabling troubleshooters to obtain accurate event trigger page location information, thereby greatly reducing the difficulty and time cost of problem troubleshooting.

[0086] Furthermore, existing location path construction methods may encounter extreme situations when performing abnormal location of business page operation, such as the parent node location path of the triggering page component node being unavailable, the node being in a destroyed state, or the upper-level link of the component event being missing. This results in the inability to obtain a complete event location path through conventional path concatenation methods, thus causing a lack of abnormal location information. In this embodiment, the method further includes: If the parent node location path of the parent node corresponding to the component node of the trigger page is unavailable, the component node of the trigger page is in a destroyed state, or the upper-layer link of the component event is missing, the trigger design identifier information, trigger logic identifier information, trigger event identifier information, and trigger page resource identifier information of the component node of the trigger page are obtained; a degraded event location path is generated based on the trigger design identifier information, the trigger logic identifier information, the trigger event identifier information, and the trigger page resource identifier information; and the degraded event location path is used as the event location path.

[0087] Specifically, when the system detects that the parent node positioning path of the parent node corresponding to the trigger page component node is unavailable, this may mean that the system cannot obtain a valid positioning path corresponding to the parent node of the trigger page component node when attempting to construct an event positioning path. This may be due to various reasons, such as the parent node not yet completing initialization, and its positioning path not yet being generated or registered; or the parent node experiencing an exception during runtime, resulting in the loss or corruption of its positioning path information. Another possibility is that the parent node may have been destroyed or removed from the page structure before the trigger page component node attempts to obtain its path, making its path information inaccessible.When a triggering page component node is in a destroyed state, this indicates that its lifecycle ended when the event was triggered; that is, the node has been removed from the page rendering tree or marked for recycling. In this case, the node may no longer hold complete runtime context information, including its own positioning unit or references to its parent nodes, thus rendering the conventional path construction mechanism ineffective. For example, when a user quickly switches pages or closes a pop-up, some components may be destroyed before the event processing is complete. When the upper-level link of a component event is missing, it means that the hierarchical relationship or context information chain between the triggering page component node and its root node is incomplete during event propagation or processing. For example, in some asynchronous operations or cross-component communication scenarios, the event may detach from its original page hierarchy, making it impossible to trace the complete parent-child relationship, thus making it impossible to construct the path by locating the parent node. Another situation is that due to program errors or exceptions, the internal data structure storing the hierarchical relationship is corrupted or inconsistent.

[0088] Accordingly, in any of the above-mentioned abnormal situations, the system will obtain the trigger design identification information of the trigger page component nodes. This information is used to uniquely identify the identity or type of the trigger page component nodes defined during design. It can be a globally unique ID, such as a universally unique identifier (UUID), or a string automatically generated by the designer that is unique throughout the entire application. In addition, it can also be a combined string of component type, module name, and custom name, used to distinguish and manage components during the design phase. At the same time, the system will also obtain trigger logic identification information, which is used to uniquely identify the specific business logic or event handling function associated with the trigger page component nodes. For example, it can be the name of the event handling function, such as "onSubmit" or "onClick", or a unique ID pointing to a specific logic flow or script. In low-code platforms, it can also be a unique identifier of the logic block configured by the user for a certain event during design. In addition, the system will also obtain trigger event identification information, which is used to uniquely identify the specific event type that occurs on the trigger page component nodes. For example, it can be a standard DOM event name, such as "click," "change," or "input," or a custom component event name, such as "onSelect" or "onConfirm." It can also be a predefined event enumeration value used to distinguish different types of user interactions or system behaviors. Finally, the system will also obtain the triggering page resource identifier information, which is used to uniquely identify the business page resource to which the triggering page's component nodes belong. For example, it can be the page's Uniform Resource Locator (URL) path, the page's unique ID, or the page file name.In multi-page applications, this information can clearly identify the specific page context in which the event occurred, and even if the component is reused in multiple pages, its source can be distinguished by this identifier.

[0089] Based on this, by introducing a degradation processing mechanism, it is ensured that the system can still provide effective location information when the abnormal location path construction link is interrupted or fails, thereby improving the robustness of abnormal location. Specifically, when a component event is triggered for a business page, the system first attempts to read the node location path corresponding to the component node of the triggering page in the page running instance. On this basis, this application further determines whether the node location path meets the path usage conditions. If it does not meet the conditions, or in more extreme cases, such as when the parent node location path of the parent node corresponding to the component node of the triggering page is unavailable, the component node of the triggering page is in a destroyed state, or the upper-level link of the component event is missing, the system no longer relies on the conventional path concatenation logic. At this time, the system will actively switch to the degradation processing mode. It will extract key metadata from the component node of the triggering page itself, including trigger design identification information, trigger logic identification information, trigger event identification information, and trigger page resource identification information. These are relatively stable attributes inherent to the node at design time and runtime, and these information can usually still be obtained even if its runtime context (such as the parent node path) is missing. Based on these directly obtained identification information, the system generates a degradation event location path. While this downgraded path may not be as detailed as the complete hierarchical path, it contains the core elements of the event and is sufficient to provide basic clues for location. Ultimately, the system uses this generated downgraded event location path as the event location path for the component event and writes it into the logical context information corresponding to the component event. In this way, even in abnormal scenarios such as unavailable parent node paths, destroyed nodes, or missing upper-level links, the system can avoid blind spots in problem location caused by the inability to construct a complete path. This mechanism complements the previous steps of judging path usage conditions and attempting to read the parent node's location path, together building a more robust event location path generation system. It ensures that, regardless of the situation, the event location path can be effectively generated and used for subsequent anomaly location and logging, thereby significantly improving the efficiency and accuracy of troubleshooting complex business pages.

[0090] It should be noted that when there are multiple layers of nested low-code components, each component instance saves the complete positioning path from the page root node to the current component during instantiation. In this way, even if the unique identifier of the internal node is repeated in multiple running instances, the real location can be distinguished by the complete path saved inside each instance.When an event originates from a regular component within a low-code component, the regular component does not directly rely on the page's global state. Instead, it prioritizes reading the complete location path stored within its own instance. If this path is missing, it calls methods provided by its parent low-code component or parent container to obtain the parent's complete path and reconstructs its own complete path, avoiding the loss of specific reference locations while only recording the component resource source. After appending the event location unit to its own complete location path, the current component writes this path into the log reporting parameters of this event trigger and continues to pass it into the logic execution context, ensuring that subsequent logic nodes, method calls, and exception handling can all read the same trigger source.

[0091] For example, suppose a user clicks a "Submit" button on a low-code business page. This button is a basic component node, and its parent page component node is a child page container node. When the event is triggered, the system attempts to obtain the event location path of the "Submit" button. However, for some reason, such as the user quickly switching pages after clicking the button, the child page container node is destroyed during the "Submit" event processing, or its corresponding parent node location path becomes unavailable due to an internal error. In this case, conventional path concatenation methods will not be able to obtain the complete event location path. The solution of this application will detect such anomalies, for example, by checking the validity of the parent node location path, or determining whether the triggering page component node ("Submit" button) is in a destroyed state. Once any of the above anomalies are detected, the system will initiate degradation processing. It retrieves key metadata from the "Submit" button itself, the triggering page node: for example, the unique ID assigned to the button at design time, such as "btn_submit_form_123" as the trigger design identifier; the identifier of the submission logic bound to the button, such as "submitOrderLogic" as the trigger logic identifier; the event type "click" as the trigger event identifier; and the unique identifier of the page where the button is located, such as " / order / createPage" as the trigger page resource identifier. The system combines this information to generate a degraded event location path, for example: " / order / createPage / btn_submit_form_123 / submitOrderLogic / click". Subsequently, the system uses this degraded event location path as the final event location path and writes it into the logical context information of the "Submit" button click event. In this way, even if the parent node path is missing, the logging system can still record this degraded path containing key information, providing important clues for subsequent anomaly investigation, such as clearly knowing which button on which page triggered which logic, even if the complete hierarchical structure is unknown.

[0092] In summary, by introducing a degradation processing mechanism, in the extreme case where the construction of the regular path fails, the key identification information of the constituent nodes of the triggering page can be obtained in a timely manner, and a degradation event location path can be generated based on this information. This ensures that even in abnormal scenarios, the system can still provide a usable location path containing core context information for component events, avoiding blind spots in problem location caused by missing paths. Therefore, this application significantly improves the robustness and accuracy of low-code platforms in abnormal location on complex business pages, enabling troubleshooters to obtain basic and crucial troubleshooting clues even when faced with incomplete runtime information, thereby improving the efficiency of fault diagnosis.

[0093] Furthermore, in complex business scenarios, existing location path construction methods may generate lengthy and repetitive path segments as page nesting deepens or component events are frequently triggered. This not only increases the burden of storage and transmission but may also lead to excessively deep path layers, making it difficult to quickly extract key location information during subsequent anomaly analysis or log recording, and even causing performance bottlenecks in path parsing. Therefore, in this embodiment, before the step of writing the event location path into the logical context information corresponding to the component event is executed, the method further includes: The event location path is deduplicated to obtain an initial event location path, and a path level detection is performed on the initial event location path. If the path level detection result determines that the initial event location path is greater than a preset path level limit, the initial event location path is truncated to obtain a target event location path. The target event location path is used as the event location path, and the step of writing the event location path into the logical context information corresponding to the component event is executed.

[0094] Specifically, before writing the event location path into the logical context information, the event location path is first deduplicated to obtain the initial event location path. The deduplication operation aims to eliminate duplicate or redundant path segments in the event location path, ensuring the simplicity and effectiveness of the path. In complex page structures, due to component reuse, nesting, or event bubbling mechanisms, the generated path may contain duplicate node information. The deduplication mechanism identifies and removes this redundant information, enabling the path to more accurately reflect the actual triggering location of the event. One implementation is to maintain a set of visited nodes or added path segments during the construction of the event location path. When attempting to add a new path segment, it is first checked whether it already exists in the set. If it does, the addition is skipped, thus avoiding duplication.Another approach is to post-process the event location path after its initial generation. For example, hash-based or string-matching methods can be used to identify and merge consecutive, semantically identical node descriptions in the path, or duplicate node information can be filtered out based on preset deduplication rules (such as a combination of unique identifiers, node types, and event identifiers during design) to ultimately form a concise initial event location path.

[0095] Subsequently, path hierarchy detection is performed on the initial event location path. Path hierarchy detection evaluates the depth or length of the initial event location path to determine whether it meets preset specifications or limitations. In practical applications, excessively long paths are not only difficult to read and analyze, but may also exceed the system's storage or processing capabilities. Therefore, path hierarchy detection is an important step in ensuring path availability and system stability. One implementation is to determine the hierarchy depth by calculating the number of nodes contained in the path after path generation or deduplication, and compare it with a preset hierarchy upper limit. Another implementation is to update the current path hierarchy count in real time when each component of the path (such as page, subpage, low-code component, ordinary component, event) is added, and perform detection after each update so that subsequent processing is triggered in a timely manner when the path reaches or exceeds the preset limit.

[0096] Based on the path hierarchy detection results, when it is determined that the initial event location path is greater than the preset path hierarchy limit, the initial event location path is truncated to obtain the target event location path. When the path hierarchy detection results indicate that the depth of the initial event location path exceeds the preset limit, it needs to be truncated to control the path length. The purpose of truncating is to ensure that the core location information of the path is not lost while conforming to system specifications. One implementation is to start from the end of the path (i.e., the node closest to the event trigger point), retain a certain number of nodes upwards, and retain the page root node, the nearest child page node, and the nearest low-code component node, while removing less critical nodes in the intermediate hierarchy, thereby forming a concise and representative target event location path. Another implementation is to define a set of priority rules, for example, to prioritize retaining event nodes, current component nodes, the nearest low-code component nodes, the nearest child page nodes, and the page root node, and then remove nodes starting from low-priority nodes according to the preset hierarchy limit until the path length meets the requirements. During truncating, a marker can be added to indicate that the path has been truncated.

[0097] Finally, the target event location path is used as the event location path, and the step of writing the event location path into the logical context information is executed.The target event location path, after deduplication, hierarchical detection, and truncation, is the standardized path ultimately used for anomaly localization and logging. Using this as the event location path and writing it into the logical context information ensures that all subsequent operations relying on this path (such as anomaly analysis and log queries) will use the optimized, efficient, and accurate path information. One implementation approach is to assign the generated and optimized event location path to the event object or related context variables during the event processing flow, allowing subsequent logical processing modules to directly access and use it. Another approach is to register or store the optimized target event location path in the current event's logical context information through a unified path management service or API, ensuring its accessibility and consistency throughout the entire event lifecycle.

[0098] Based on this, a path optimization mechanism is introduced to refine the generated event location path. Specifically, after a component event is triggered on a business page, and the event location path is obtained by concatenating the node location path corresponding to the component node of the triggering page and the event location unit corresponding to the component event, the system first performs a deduplication operation on the event location path to eliminate any redundant or duplicate node information, thereby obtaining an initial event location path. This deduplication process can effectively avoid path redundancy caused by component reuse, slot rendering, or event bubbling mechanisms, ensuring the simplicity of the path. Next, the system performs path hierarchy detection on the initial event location path to assess whether its depth exceeds the preset hierarchy limit. This detection mechanism aims to prevent the path from becoming too long due to excessive nesting, affecting the subsequent storage, transmission, and parsing efficiency. If the detection result shows that the hierarchy depth of the initial event location path exceeds the preset limit, the system will perform truncation processing on it. The truncation process, based on a preset strategy, retains key positioning information in the path (such as the page root node, the nearest child page node, low-code component nodes, the current component node, and event nodes) while removing less important intermediate levels, thus generating a target event positioning path that meets the length requirements and contains the core positioning context. Finally, the optimized target event positioning path is used as the final event positioning path and written into the logical context information corresponding to the component event. Through this series of optimization steps, this application ensures that the event positioning path written into the logical context information is concise, standardized, and efficient, thereby providing a high-quality data foundation for subsequent runtime anomaly localization. This optimization mechanism, combined with the aforementioned node positioning path generation and event positioning path concatenation mechanism, forms a complete closed loop from path construction to optimization. This enables the generation of accurate, concise, and easily analyzable event positioning paths even in complex business scenarios, including multi-level nesting and frequent event triggering, greatly improving the efficiency and accuracy of anomaly localization.

[0099] For example, suppose a business page contains multiple nested components, such as: page root node, subpage container A, low-code component B, basic component C, and button D. When a user clicks button D to trigger an event, the system first generates a preliminary event location path according to the aforementioned method, such as: page root node / subpage container A / low-code component B / basic component C / button D / click event. Before writing this event location path into the logical context information, a path optimization module will intervene. First, this module will deduplicate the path. For example, if, due to some rendering mechanism, low-code component B is repeatedly recorded in the path as page root node / subpage container A / low-code component B / low-code component B / basic component C / button D / click event, the deduplication mechanism will identify and remove the redundant low-code component B, restoring it to page root node / subpage container A / low-code component B / basic component C / button D / click event, thereby obtaining the initial event location path. Deduplication can be based on a combination of each node's unique design-time identifier, node type, and event identifier. Subsequently, the path optimization module will perform path hierarchy detection on the initial event location path. Assume the system's preset path hierarchy limit is 5 levels (excluding the event layer), and the current path, page root node / child page container A / low-code component B / base component C / button D, has a node hierarchy of 5 levels, which becomes 6 levels including the event layer. If the preset limit is based on node hierarchy, the path may have reached or exceeded the limit. If the detection result indicates that the path hierarchy exceeds the preset limit—for example, if the path is page root node / child page container A / low-code component B / base component C / nested component E / button D / click event, with a node hierarchy of 6 levels exceeding the 5-level limit—then truncation will be triggered. The truncation process uses a preset strategy to generate a target event location path. This path might retain the page root node, the nearest child page container node (child page container A), the nearest low-code component node (low-code component B), the current component node (button D), and the event node (click event), while removing the intermediate base component C and nested component E. The path might look like this: page root node / child page container A / low-code component B / button D / click event. During truncation, a marker like "..." or "[TRUNCATED]" can be added to the path to indicate that it has been optimized. Finally, this deduplicated and truncated target event location path is used as the final event location path and written into the logical context information of the button D click event.

[0100] In summary, by performing deduplication, hierarchical detection and truncation on the event location path before writing it into the logical context information, the problems of long event location paths, duplicate fragments and excessively deep hierarchies in complex business scenarios can be effectively solved.This solution ensures that the generated event location path is concise, standardized, and efficient, significantly reducing the burden on storage and transmission, and avoiding parsing performance bottlenecks caused by excessively long paths.

[0101] Furthermore, in existing low-code platforms, if the execution of events such as event triggering, condition judgment, method call, interface request, or result processing fails during component event execution, it is difficult to quickly and accurately locate the specific page location causing the exception using only the existing logical context information. This makes it difficult for troubleshooters to intuitively determine the physical location of the exception when faced with complex nested pages, increasing the difficulty of troubleshooting. Therefore, in this embodiment, after the step of writing the event location path into the logical context information corresponding to the component event is executed, the method further includes: If the component event fails to trigger during the event triggering phase, condition judgment phase, method call phase, interface request phase, or result processing phase, the event location path is read from the logical context information; and the page location information corresponding to the failed triggering of the component event is determined based on the event location path.

[0102] Specifically, the situation where a component event fails to trigger during the event triggering phase refers to the situation where a component event, when activated by user interaction or system commands, fails to successfully initiate its subsequent logic execution. For example, a button click event may fail to trigger due to front-end validation failure, insufficient permissions, or incorrect registration of the event listener. Another situation is that when the event is triggered, the event callback function fails to be called in time due to network latency or incomplete loading of front-end resources. The situation where the condition judgment phase fails to trigger refers to the situation where, during the execution of the event logic, a preset condition judgment node is encountered, but the condition is not met or the condition judgment logic itself is incorrect, causing the subsequent process to be unable to continue. For example, a form submission event fails to judge whether the user input is valid due to incorrect data format or non-compliance with business rules. Another example is that the condition judgment expression has a syntax error at runtime, resulting in the inability to obtain a judgment result. The situation where the method call phase fails to trigger refers to the situation where, when calling an internal method, external service method, or component API in the event logic, the method fails to execute successfully and return the expected result. For example, a data processing component calls a backend service interface to perform data calculation, but the backend service returns an error code or times out. Another scenario is that the called method's parameters are incorrect or the method itself has a runtime exception, causing the call to fail. The aforementioned unsuccessful triggering of the interface request phase refers to a situation where the event logic involves initiating an HTTP / HTTPS request or other form of network communication to the backend server, but the request fails to complete successfully. For example, a data query operation sends a request to the API gateway, but the request fails due to network interruption, server unresponsiveness, or authentication failure.For example, an incorrect URL or an inappropriate request body format can cause the server to refuse processing. The failure to trigger the result processing stage refers to situations where the event logic fails to display, store, or further process the result after all preceding steps have been completed and results have been obtained. For instance, after a data save operation returns a successful response from the backend, the frontend attempts to update the page UI or local cache, but fails due to an error in the UI update logic or insufficient local storage space. Another scenario is that an anomaly occurs in the data conversion or formatting operations included in the result processing logic, preventing the correct processing of the result.

[0103] Accordingly, the step of reading the event location path from the logical context information refers to the structure used to store and transmit data and metadata related to the current execution state during the component event execution process. This can be a map in memory, a thread-local variable (ThreadLocal), or a specially designed context object that accompanies the entire lifecycle of the event. Reading the event location path can be achieved by calling a specific method of the context object (e.g., getContext().get("eventLocationPath")). Another implementation is that, when the logical context information is designed as a stack structure, the event location path can be found and extracted by popping the top element of the stack or traversing the elements in the stack.

[0104] Accordingly, determining the page location information of the component event that failed to trigger based on the event location path refers to mapping the event location path to a specific, identifiable UI element or logical area in the business page by parsing the event location path. This can be done by matching the event location path with the page structure tree to locate the specific component instance. For example, the path root / container[id=1] / component[name=button_query] can be parsed as a component named "button_query" in the container with ID 1 under the root node of the page. Another implementation is that the system maintains a mapping table between the unique identifier of a page component instance and its instance object. When the event location path is obtained, the corresponding component instance can be found in the mapping table based on the key identifiers in the path (such as design identifier information, resource identifier information), thereby obtaining its specific location information on the page (such as DOM element ID, component level, parent-child relationship, etc.).

[0105] Based on this, by introducing an exception monitoring mechanism in multiple key lifecycle stages of component event execution, namely the event triggering stage, condition judgment stage, method call stage, interface request stage or result processing stage, the accurate capture of execution failure scenarios is achieved.When a component event fails to trigger at any of the aforementioned stages, the system can proactively extract a pre-built and stored event location path from the logical context information. This event location path is based on the original page description file of the business page. It configures the design identifier information corresponding to the page's component nodes, constructs node location units based on this information, and finally concatenates the location paths of the node location units and their parent nodes in sequence. This path contains complete hierarchical information from the page root node to the specific triggering node, thus accurately identifying the source of the event. By parsing this path, the system can directly map the specific physical location of the component event within the business page, i.e., the location information of the page where the trigger failed. This process deeply binds the abstract logical execution state with the specific page structure, allowing operations personnel to directly pinpoint the page hierarchy and component instance where the exception occurred without needing to reproduce the operation when facing complex component nesting and reuse scenarios. After the event is triggered, the runtime writes the complete event location path into the current logical execution context and associates it with the logical instance identifier, trigger time, input parameters, and call chain identifier. Each node in the logical flow can read this location path during execution. Regardless of whether the failure occurs at the start node, condition judgment node, method call node, API request node, or result processing node, the logs always carry the same trigger source, thus pinpointing the location of the page where the failure occurred. This mechanism effectively solves the problems of traditional logs failing to distinguish the actual trigger source and the disconnect between error records and page origins, significantly improving the efficiency and accuracy of fault diagnosis.

[0106] For example, suppose there is a "Submit Order" button in a customer management business page built on a low-code platform, and this button is bound to a component event. The logical flow of this component event includes: first, performing front-end form data validation (condition judgment stage), then calling the back-end API to create an order (interface request stage), and finally updating the page UI to display the order status (result processing stage). When the user clicks the "Submit Order" button, the system will first try to trigger the component event. If the front-end form data validation fails at this time (for example, required fields are not filled), the event will not be triggered successfully in the condition judgment stage. At this time, the system will read the pre-stored event location path from the logical context information of the current component event. For example, the path may be 123 / 456 / 789 / 369, where 123 represents the page root node, 456 represents the customer management page, 789 represents the order form component, and 369 represents the submit button. Based on the event location path 123 / 456 / 789 / 369 read, the system can accurately determine the location of the page where the unsuccessful trigger was "the submit button in the order form component of the customer management page".Even if the "Submit Order" button or its logic is reused in other pages or components, this unique event location path allows troubleshooters to immediately identify that the specific submit button on the customer management page caused the validation failure. For example, if the front-end form validation succeeds, but the API request to create an order fails due to network issues or back-end service anomalies, the event failed to trigger during the API request phase. Similarly, the system reads the same event location path from the logical context information and uses this to determine the page location where the event failed. In this way, regardless of at which stage the component event fails, the system provides clear and traceable page location information, greatly simplifying the troubleshooting process.

[0107] Furthermore, when the front-end logic calls a logic method, object method, dictionary method, connector method, or other front-end logic method, the system continues to pass the location path to the sub-call context, so that errors after cross-method calls can still be traced back to the original page trigger point. When the logic execution enters the asynchronous callback, scheduled task, message queue, event queue, or asynchronous request return stage, the system continues to save the location path through the closure context, task context, or call chain context to avoid source loss caused by asynchronous boundaries. When an event triggers multiple logic branches, each branch shares the same trigger source path, but records its own logic instance identifier and failure node. This can distinguish between "different failure branches under the same trigger source" and "the same logic failure under different trigger sources". When the logic is triggered by non-user operations, such as page initialization, data loading, component automatic verification, or component internal lifecycle trigger, the system uses the triggering component or trigger container as the current node, generates the corresponding location path, and records the event identifier as initialization, loading, verification, or lifecycle action.

[0108] In summary, by capturing unsuccessful cases at each key execution stage of component events (event triggering, condition judgment, method call, interface request, or result processing), and utilizing the event location path pre-built and stored in the logical context information, it is possible to accurately determine the page component node causing the anomaly and its hierarchical position in the page structure. This allows troubleshooters to directly pinpoint the specific UI element or logical area where the problem occurred without manually reproducing the operation or guessing the source of the anomaly, significantly improving the efficiency and accuracy of fault diagnosis. Especially when the same low-code component resource or the same logic is reused in multiple page locations, this solution can clearly distinguish the real trigger source, avoiding the difficulty of troubleshooting caused by ambiguous information, thereby improving the operation and maintenance efficiency and user experience of the low-code platform.

[0109] In specific implementation, during the execution of a component event, simply recording the location path often fails to fully reflect the true state of the event execution, especially in different scenarios of successful or failed event execution. The lack of a structured and differentiated logging mechanism makes it difficult for operations and maintenance personnel to quickly distinguish event execution results and obtain targeted anomaly diagnostic information when facing complex business logic. Therefore, in this embodiment, after the step of writing the event location path into the logical context information corresponding to the component event is executed, the method further includes: If the event logic of the component event executes successfully, the event location path and the event execution result corresponding to the component event are written to the page log. If the event logic of the component event fails to execute, the logical instance identifier, logical flow identifier, and event exception information corresponding to the component event are determined, and the event location path, logical instance identifier, logical flow identifier, and event exception information are written to the page log. The event exception information includes at least one of the following: failure node information, error code information, error message, exception type, exception stack, and execution time information.

[0110] Specifically, when the event logic of a component event executes successfully, the event location path and the corresponding event execution result of the component event are written to the page log. This technique aims to record the complete trajectory and result of the normal execution of the component event. When the logic code bound to a component event in a business page successfully completes its predetermined operation, the system not only records the precise location of the event in the page structure (event location path), but also records the final output or status of the logic execution (event execution result). This provides basic data for subsequent business auditing, performance analysis, and normal process tracing. As one implementation method, at the end of the event logic execution, a specific interface of the log recording module can be called to serialize the event location path and the success status code or processing result object returned by the logic and write them together into a preset page log file or log service. As another implementation method, a unified event processing framework can also be designed. In this framework, after the event logic is executed successfully, the event location path and the return value of the logic execution are automatically captured and encapsulated into structured log entries, which are then sent to the log collection system for persistent storage via a message queue.

[0111] Accordingly, if the execution of the event logic of a component event fails, the logical instance identifier information, logical flow identifier information and event exception information corresponding to the component event are determined, and the event location path, logical instance identifier information, logical flow identifier information and event exception information are written into the page log. This technical means focuses on providing richer and more diagnostically valuable exception information when the execution of the component event logic fails.When event logic fails to complete as expected, the system captures detailed contextual information leading to the failure, including the failed logic instance, its associated logic flow, and specific exception details. Combined with the event location path, this allows operations personnel to quickly pinpoint the specific component on the page that triggered the error and gain a deeper understanding of the business process and technical reasons for the error. One implementation approach is to set up an exception capture mechanism during event logic execution. Once an exception is captured, it retrieves the logic instance identifier and logic flow identifier from the current runtime context, and extracts the error code, error message, exception type, and exception stack trace from the exception object. This information is then formatted and written to the page log along with the event location path. Another implementation approach is to integrate an error monitoring and diagnostic module into the runtime engine of a low-code platform. When event logic execution fails, this module automatically intercepts the error and collects relevant logic instance identifier, logic flow identifier, and event exception information from the runtime environment according to predefined rules. This data is then associated with the event location path and reported through a unified log interface.

[0112] The event exception information includes at least one of the following: failure node information, error code information, error message, exception type, exception stack, and execution time information. This technical means clarifies the specific content of the exception information that needs to be recorded when the event logic execution fails. This information is crucial metadata for diagnosing and resolving problems. Failure node information indicates which specific step or component in the logic flow caused the failure; error code and error message provide a brief description of the nature of the error; exception type and exception stack are key for technicians to analyze the root cause; and execution time helps to assess performance bottlenecks or timeout issues. By including this information, the diagnostic value of the log is greatly enhanced. As one implementation method, when an exception is captured, the exception type, error message, and exception stack can be directly extracted from the exception object. For failure node information, error code, and execution time, they can be preset during the logic flow design or obtained at runtime by monitoring the execution status and timestamp of the logic flow. As another implementation method, a standardized exception information structure or class can be defined, which includes fields such as failure node information, error code information, error message, exception type, exception stack, and execution time information. When an exception occurs, these fields are filled in completely and written to the log as part of the event exception information.

[0113] Based on this, by configuring the design identification information corresponding to each page component node in the original page description file of the business page, and constructing node positioning units and node positioning paths based on this, these paths are finally added to the page running instance of the business page, thereby providing a basis for locating abnormal operation of the business page.Based on this, when a component event is triggered on a business page, the system can read the node location path corresponding to the triggering page's constituent nodes from the page's running instance, generate an event location path in conjunction with the event location unit, and finally write this path into the logical context information corresponding to the component event to achieve precise tracking of the event trigger source. To further improve the efficiency and accuracy of anomaly localization, this application's solution performs refined processing on the logical execution result of the component event after writing the event location path into the logical context information. Specifically, when the event logic of a component event executes successfully, the system writes the event location path and its corresponding event execution result into the page log. This mechanism ensures that all normally executed business operations and their results are fully recorded, providing reliable data support for subsequent business auditing, performance analysis, and normal process backtracking. For example, a successful form submission operation will not only include the event location path of the "submit button" in its log, but also the execution result such as "submission successful" or the returned business data ID, enabling investigators to clearly understand the normal flow of the business process. On the other hand, when the event logic of a component event fails to execute, this application's solution adopts a more detailed anomaly information recording strategy. At this point, the system will not only record the event location path, but also further determine the logical instance identifier information, logical flow identifier information and event exception information corresponding to the component event, and write these multi-dimensional data into the page log.

[0114] The event exception information is designed to include at least one of the following: failure node information, error code information, error message, exception type, exception stack, and execution time information. This design ensures that when logic execution fails, the logs not only clearly indicate which specific component on the page triggered the error (by locating the path through the event), but also deeply reveal the business context (logical instance identification information, logical flow identification information) and technical details (event exception information) where the error occurred. For example, when a data query logic fails, the logs will record the page component path that triggered the query, the unique logical instance ID of the query, the query logical flow ID to which it belongs, as well as the specific error code (such as "database connection failed"), error message, exception type, and detailed stack information. This comprehensive information recording method greatly enhances the diagnostic value of the logs, enabling operations and maintenance personnel to quickly locate the logical link that caused the failure from massive amounts of logs and accurately determine whether the error is caused by front-end data problems, back-end service exceptions, or logical configuration errors, thereby significantly reducing the difficulty of troubleshooting business logic errors in complex pages. Through the above mechanism, the solution in this application, while inheriting the ability of the event location path to accurately track the page position, further realizes differentiated and structured logging of event execution results.It deeply integrates event location paths with specific execution results or exception metadata, solving the problems of fragmented information and insufficient diagnostic information in traditional logging, and giving exception information clear source identification and logical correlation. This not only improves the efficiency of fault diagnosis in complex business scenarios, but also provides low-code platforms with more robust runtime monitoring and problem-solving capabilities.

[0115] For example, suppose there is a "Save Customer Information" button in a customer management business page built on a low-code platform. This button is bound to a logic flow named "SaveCustomerData". When the user clicks this button, a component event is triggered. First, after the event location path has been written into the logic context information, the system monitors the execution status of the "SaveCustomerData" logic flow. As a specific implementation, if the "SaveCustomerData" logic flow executes successfully, for example, the customer information is successfully saved to the database, and the logic flow returns a "save successful" status code or a newly generated customer ID, then the system will obtain the event location path corresponding to the "Save Customer Information" button (e.g., "Customer Management Page / Customer Details Area / Save Button"), and the event execution result returned by the logic flow (e.g., "status: success, customerId: CUST12345"). Subsequently, the system will write these two parts of information, namely the event location path and the event execution result, into the page log in a structured form.

[0116] On the other hand, if an error occurs during the execution of the "SaveCustomerData" logic flow, for example, due to network problems causing database connection failure, or due to incorrect data format of the user input causing validation failure, the system will capture the exception. In addition to obtaining the event location path corresponding to the "Save Customer Information" button, the system will further determine the detailed information related to this failed execution.This includes: logical instance identification information, such as a unique transaction ID, like "logicInstanceId": "TXN_20231027_001", used to identify the specific logical flow execution instance; logical flow identification information, i.e., the name or ID of the logical flow, such as "logicFlowId": "SaveCustomerData"; event exception information, which will be detailed exception data containing multiple dimensions, such as: failure node information, indicating which specific step or component in the logical flow caused the failure, such as "failedNode": "DatabaseSaveComponent"; error code information, a predefined error code, such as "errorCode": "DB_CONN_FAILED"; error message, a specific error description, such as "errorMessage": "Failed to connect to database: Connection timed out"; exception type, the type of exception captured, such as "exceptionType": "NetworkError"; exception stack, detailed program call stack information, used by technicians to locate code problems; execution time information, the time taken from the start of the logical flow to failure, such as "executionTimeMs": 1500. The system will write the event location path, logical instance identification information, logical flow identification information, and these detailed event exception information into the page log.

[0117] In summary, when the event logic of a component event executes successfully, the event location path and event execution result are written to the page log, ensuring that the system can completely record the normal trajectory of the business flow, providing basic data support for subsequent link tracing and behavior analysis. This allows operations and maintenance personnel to clearly understand the normal flow of the business process, facilitating business auditing and performance evaluation. When the event logic of a component event fails to execute, a multi-dimensional anomaly diagnosis model is constructed by introducing logical instance identification information, logical flow identification information, and event anomaly information including failure node information, error code information, error message, exception type, exception stack, and execution time information. This design not only clarifies the specific page location where the error occurred, but also binds the error to a specific business execution context through logical instance and logical flow identification, enabling operations and maintenance personnel to quickly locate the logical link that caused the failure from massive logs.

[0118] It should be noted that when a syntax error, reference error, type error or runtime error occurs when the front-end logical node calls a logical method, object method, dictionary method or linker method, the system retains the message and stack information in the real exception object to avoid only returning the execution failure status.When a low-code expression, parameter mapping, or conditional statement encounters an error at runtime, the system reports the logical node containing the failed expression along with its complete location path, allowing investigators to see both "which page location triggered the error" and "which logical node failed."

[0119] In actual operating environments, extreme situations may occur, such as page log reporting interface call failure, user token expiration, or network anomalies, resulting in the inability to successfully report critical anomaly information to the log system. This leaves troubleshooters facing the dilemma of being unable to trace the root cause of problems due to missing or incomplete logs when dealing with complex business page failures. In this embodiment, in the case where the event logic of the component event fails to execute, the following is also included: In the event of a failed call to the reporting interface of the page log, an invalid user token, or a network anomaly, the path summary information corresponding to the event location path is determined, as well as the event error information and the reporting failure information. The path summary information, the event error information, and the reporting failure information are used as the event anomaly information. The event anomaly information is then normalized to obtain the target event anomaly information. The target event anomaly information, the event location path, the logical instance identifier information, and the logical flow identifier information are written into the page log.

[0120] Specifically, the failure of the page log reporting interface call, the expiration of the user token, or the network anomaly refers to three typical failure scenarios that may be encountered when attempting to send log data to the remote log collection system during the operation of the business page. These are the conditions that trigger the subsequent fallback processing mechanism of this solution, indicating that the regular log reporting channel is blocked and alternative measures need to be taken to avoid the loss of abnormal information. For example, after the system attempts to call the log reporting interface, it can determine whether the reporting interface call has failed based on the HTTP status code returned by the interface (such as 5xx series errors), connection timeout exception, or specific business error code (such as authentication failure code). Alternatively, the runtime environment can determine whether the user token has expired by checking the validity period, signature, or server-side verification result of the authentication credentials (such as JWT token) of the current user session. Or, the application can determine whether there is a network anomaly by listening to changes in network connection status, capturing network request exceptions (such as SocketTimeoutException, UnknownHostException), or periodically attempting to connect to preset network endpoints.

[0121] Accordingly, the path summary information corresponding to the event location path refers to extracting key levels and identifiers from the complete event location path, but may omit redundant or unimportant details, so as to convey the core location information within a limited storage or display space.Its function is to provide lightweight yet still business-readable fault location information when log reporting is blocked, ensuring that a preliminary judgment of the problem can be made even if the complete path cannot be recorded. For example, the identifiers of the top-level (such as page name), bottom-level (such as event name), and key intermediate layers (such as low-code component name) can be extracted from the complete event location path and concatenated in a concise string format (such as "page A / component B / event C"). Alternatively, according to preset rules, the event location path can be hashed or encoded to generate a fixed-length unique identifier, which can be mapped back to the key part of the original path or used as an index for subsequent queries.

[0122] Accordingly, determining event error information and reporting failure information refers to comprehensively recording two dimensions of the fault: errors in the business logic itself and errors in the log reporting mechanism, providing dual clues for subsequent fault analysis. Event error information refers to the specific reasons for the failure of component event logic execution, such as error codes, error messages, exception types, and stack information. Reporting failure information refers to the reasons why log data failed to be successfully sent to the log system itself, such as network connection errors or authentication failures. For example, event error information can be directly extracted from captured exception objects, including the exception class name, error message string, and complete stack trace. Reporting failure information can be obtained from exception captures of log reporting interface calls, such as detailed information about IOException or AuthenticationException thrown by the network request library. Alternatively, the system can maintain a predefined error code and error message mapping table, and when event logic execution fails, look up the corresponding standardized error information based on the internal error type. Reporting failure information can be recorded as specific enumeration values ​​(such as NETWORK_UNAVAILABLE, AUTH_FAILED) and their associated system error descriptions.

[0123] Accordingly, the phrase "using path summary information, event error information, and reporting failure information as event exception information" refers to integrating the three types of information identified above into a unified event exception information structure that includes a multi-dimensional fault context. Its purpose is to ensure that, in the special case of log reporting failure, all available key diagnostic data can be encapsulated in a structured and comprehensive manner to prepare for subsequent processing. For example, these three types of information can be encapsulated into a JSON object or a custom data structure containing explicit fields (such as pathSummary, errorMessage, uploadFailureReason) to facilitate subsequent parsing and processing.

[0124] Accordingly, the standardization processing of event anomaly information refers to uniformly converting, cleaning, or adjusting the structure of the integrated event anomaly information to conform to preset log standards or data models. Its purpose is to improve the readability, parsability, and comparability of the anomaly information, facilitating analysis by automated tools and ensuring consistent quality of locally recorded anomaly information even in cases of anomaly reporting failure. For example, stack traces in the anomaly information can be truncated or filtered, removing unnecessary internal frame calls and retaining only key stack frames related to business logic. Simultaneously, sensitive information in error messages can be de-identified. Alternatively, error codes from different sources can be mapped to a unified error classification system, and standardized descriptive text can be generated for each error type.

[0125] Accordingly, the obtained target event anomaly information is event anomaly data that has been standardized and is ultimately used for recording and storage. It is the most optimized and complete anomaly diagnostic data that this solution can provide in the scenario of log reporting failure, and is used to replace the original logs that failed to be reported.

[0126] Accordingly, writing the target event exception information, event location path, logical instance identifier information, and logical flow identifier information into the page log means recording the specially processed exception information, along with the original event location path, logical instance identifier information, and logical flow identifier information, into the local page log. Here, "page log" typically refers to the client's (browser or application's) local storage, console output, or backup log file. Its function is to ensure that even if the remote logging system is unavailable, critical fault context information can be persisted or at least locally visible, providing developers with a final line of defense for troubleshooting. For example, this information can be written in structured JSON format to the browser's localStorage, IndexedDB, or the client application's local file system for batch reporting or offline analysis after network recovery. Alternatively, this information can be formatted and output to the browser's developer console (console.error()), or written to the client application's memory log buffer for immediate viewing and debugging.

[0127] Based on this, firstly, based on the aforementioned method, node positioning units corresponding to each page component node in the business page are constructed, and node positioning paths corresponding to each page component node are generated based on these units. These positioning paths are added to the page running instance of the business page, providing refined contextual information for subsequent anomaly localization.When the event logic of a component event fails to execute, the system attempts to write the event location path, logical instance identifier, logical flow identifier, and event exception information to the page log. However, this solution further considers the extreme case where log reporting itself may fail, such as a failed page log reporting interface call, an expired user token, or a network anomaly. In such specific cases of reporting failure, the system does not simply abandon recording but initiates a fallback mechanism. It proactively determines the path summary information corresponding to the event location path. This summary information is a concise representation of the complete path, providing crucial location clues with limited resources. Simultaneously, the system also determines the event error information (i.e., the detailed reason for the business logic failure) and the reporting failure information (i.e., the specific reason why the log failed to report). Subsequently, the system integrates this path summary information, event error information, and reporting failure information into new event exception information. To ensure the usability and consistency of this exception information in subsequent analysis, the system performs standardization processing, such as format unification, content filtering, or structural adjustment, to obtain the target event exception information. Ultimately, even if the regular reporting channel is blocked, the system will still write the standardized target event anomaly information, along with the original event location path, logical instance identifier information, and logical flow identifier information, to the local page log. This page log can be the client's local storage, console output, or a backup log file. In this way, this solution adds a layer of robustness to the basic anomaly logging mechanism. It ensures that even under extreme conditions such as network interruption or authentication failure, key fault context information (including a simplified location path, business error, and reporting failure reason) can be effectively captured and recorded, preventing the complete loss of problem location information due to log reporting link interruption. This significantly improves the reliability and completeness of anomaly diagnosis in complex business scenarios. This mechanism, combined with the aforementioned location path construction and event logging methods, forms a more robust anomaly location system, enabling troubleshooters to obtain the most complete diagnostic information possible when facing various faults.

[0128] For example, suppose there is a "Contact Query Area" low-code component in a "Customer Management Page" built on a low-code platform, which contains a "Query Button". When a user clicks the "Query Button" to trigger the query logic, if the logic fails to execute and the client's network connection is interrupted, the log cannot be reported to the remote log system. In this case, the system will first identify the network anomaly and trigger the fallback mechanism of this solution. The system will extract key information from the complete event location path (e.g., "Customer Management Page / My Customers Subpage / Contact Query Area / Query Button / Click Event") and generate a path summary, such as "Customer Management Page > Contact Query Area > Query Button".Suppose the query logic fails because the backend interface returns a "data validation failed" error code and error message, accompanied by relevant stack trace information; these constitute the event error information. Simultaneously, due to network interruption, the log reporting interface call throws a NetworkError exception, which constitutes the reporting failure information. The system integrates the aforementioned path summary information, event error information (such as error codes, error messages, and partial stack traces), and reporting failure information (such as NetworkError) into a structured event exception information object. For example, it might be a JSON object containing fields such as "pathSummary": "Customer Management Page > Contact Query Area > Query Button", "errorCode": "VALIDATION_FAILED", "errorMessage": "Incorrect contact information format", and "uploadFailure": "NetworkError: Failed to fetch". Subsequently, the system performs normalization processing on this JSON object; for example, truncating the stack trace information, retaining only the most relevant layers, and ensuring that the naming and types of all fields conform to preset standards, thereby obtaining the target event exception information. Ultimately, the system will write this standardized target event exception information, along with the original event location path, logical instance identifier information, and logical flow identifier information, into the client browser's localStorage or output it to the developer console.

[0129] In summary, by introducing a fallback mechanism for handling log reporting anomalies, the system's fault observability in extreme environments is significantly enhanced. When component event logic fails to execute and the regular log reporting path is blocked, the system can proactively identify and extract the path summary information, event error information, and reporting failure information corresponding to the event location path, and integrate and standardize them into target event anomaly information. This processing method ensures that even under network or permission restrictions, compressed and structured key diagnostic data can be written to local or backup log storage. By associating and recording the target event anomaly information with the event location path, logical instance identification information, and logical flow identification information, it ensures that during subsequent offline analysis or fault recovery, troubleshooters can completely reconstruct the link state at the time of the fault, effectively solving the problem of lost problem location information due to reporting link interruption, and improving the robustness of anomaly diagnosis in complex business scenarios. This allows troubleshooters to obtain sufficient information to locate the problem even if the log reporting channel is blocked in complex business pages, avoiding the dilemma of being unable to trace the root cause of the problem due to missing logs, thereby improving the efficiency and accuracy of fault troubleshooting.

[0130] Referring to Figure 2, Figure 2 shows a flowchart of a page anomaly localization method provided according to an embodiment of the present specification, which specifically includes the following steps.

[0131] Step S202: Acquire an original page description file of a service page, and configure design identification information corresponding to each page constituent node in the service page in the original page description file, so as to obtain a target page description file.

[0132] Step S204: Construct a node localization path corresponding to each page constituent node respectively according to the target page description file, and add the node localization path corresponding to each page constituent node to a page running instance of the service page.

[0133] Step S206: In response to an interaction event triggered for the service page, determine a target node localization path corresponding to the interaction event by accessing the page running instance.

[0134] Step S208: Determine event-triggered page position information corresponding to the interaction event according to the target node localization path.

[0135] In practical applications, error logs generated by conventional existing low-code platforms at runtime cannot be accurately associated with specific page positions, component instances and trigger sources due to complex page structures, frequent component reuse and deep nesting levels, making it difficult to efficiently locate running anomalies of service pages. For example, when both the customer management page and the contract management page reference the same "contact query area" low-code component, if the query logic fails, the log only records the logic identifier and error stack, and cannot distinguish which page position the error originates from; meanwhile, when the sub-page container, low-code component container and common components are nested in multiple layers, there is a lack of a stable layer source transmission mechanism at runtime, and when an error occurs in some logic nodes, only the execution failure state is returned, with insufficient real anomaly causes and stack information.

[0136] In response, this application proposes a page anomaly localization method, including obtaining the original page description file of the business page, configuring the design identifier information corresponding to each page component node in the original page description file to obtain the target page description file; constructing the node localization path corresponding to each page component node according to the target page description file, and adding the node localization path corresponding to each page component node to the page running instance of the business page; determining the target node localization path corresponding to the interaction event by accessing the page running instance when an interaction event is triggered for the business page; and determining the event triggering page location information corresponding to the interaction event according to the target node localization path. The core innovation of this embodiment is that by configuring unique design identifier information for each page component node during the page design stage, and constructing a full-link node localization path based on this, a mapping mechanism from page component nodes to running instances is established in the runtime environment, achieving the effect of accurately associating runtime anomalies with specific page locations and component instances.

[0137] Specifically, during the page design phase, after obtaining the original page description file, the system assigns design identification information to each page component node. For example, the page root node, child page container node, low-code component node, and button node are each assigned a unique string identifier to ensure that the node identity is traceable. At runtime, the low-code runtime engine loads the target page description file, generates node positioning units for each page component node, and concatenates them sequentially based on the parent node positioning paths to form a complete node positioning path. For example, the root node positioning path is "Root:root_page_id", its child node form container positioning path is extended to "Root:root_page_id / FormContainer:form_container_id", and the further child node button positioning path is "Root:root_page_id / FormContainer:form_container_id / Button:submit_button_id". This path is added to the page runtime instance as an attribute storage for the node runtime object.

[0138] When an interactive event is triggered, the system can directly obtain the target node location path by accessing the page running instance without re-parse the page structure.For example, when a user clicks the "Query" button in the "Inventory Query" component within the "Product Details" subpage of the "Order Management" page, if the query logic malfunctions, the system reads the full path "Root:order_page_root / Container:product_detail_container / LowCode:stock_query_component / Button:query_button" from the button's runtime object and uses this path to determine the page location information that triggered the event. This technical solution resolves the problem of error logging being disconnected from the page source in existing technologies, enabling logs to clearly indicate the specific level and instance of the exception, such as distinguishing different trigger sources in reusable component scenarios.

[0139] For example, when a field configuration error occurs within a low-code component, the component inherits the upper-level positioning path and appends its own positioning unit during the component initialization phase, forming a complete path from the page root node to the current component. When the field validation logic outputs a log, the system reads this path and appends it to the log content, enhancing the original console log of "Field type mismatch: customerName" to "Customer Management Page / My Customer Subpage / Contact Query Area: Field customerName type mismatch". Troubleshooters can directly determine the page location and component instance to which the error belongs without needing to reproduce the operation or investigate layer by layer, significantly improving the efficiency and accuracy of locating abnormalities in complex business pages.

[0140] In specific implementation, when the log system parses the location path and displays the corresponding content, the log receiving service saves the complete location path as a structured field. The stored field should support longer text and retain the original structured content to avoid only saving and displaying a summary. Subsequently, the log list displays a path summary column, using business names to connect pages, subpages, low-code components, ordinary components, and events, so that troubleshooters can see the main source of the error in the list. In addition, the log details display the complete location path, logical flow identifier, failure node, exception stack, input parameters, and output results. Each location unit in the location path can display the node type, node name, design-time unique identifier, and resource unique identifier. Furthermore, the log system supports retrieving error records by page, subpage, low-code component, ordinary component, event, or logical identifier. For example, it can filter errors of a certain low-code component resource in all referenced pages, or it can filter all errors under a certain page instance. For historical logs that do not carry a complete location path, the log system still displays them according to the original logical identifier, action name, or title to ensure compatibility with existing data. When there are incomplete or truncated path markers in the logs, the log details will clearly show this status and retain the most recent location information that has been collected to avoid misleading investigators.

[0141] It should be noted that for the content not described in detail in the page anomaly locating method provided in this embodiment, reference may be made to the same or corresponding descriptions in the above embodiments, and no redundant elaboration will be made herein in this embodiment.

[0142] The page anomaly locating method will be further described below with reference to Figure 3, taking the application of the page anomaly locating method provided in the present specification in a low-code platform as an example. Among them, Figure 3 shows a flowchart of a processing procedure of a page anomaly locating method provided in an embodiment of the present specification, which specifically includes the following steps.

[0143] In step S302, an original page description file of a service page is acquired, and a plurality of page constituent nodes corresponding to the service page are determined, where the plurality of page constituent nodes include a page root node, a sub-page container node, a low-code component node, a basic component node, and an event configuration node.

[0144] In step S304, design identification information is generated for each of the page root node, the sub-page container node, the low-code component node, the basic component node, and the event configuration node respectively.

[0145] In step S306, the design identification information is configured into the original page description file, and a target page description file is generated according to the configuration result.

[0146] In step S308, a node locating unit corresponding to each page constituent node is constructed according to the target page description file.

[0147] In step S310, a node locating path corresponding to each page constituent node is generated based on the node locating unit, where the node locating path is obtained by sequentially splicing the node locating unit corresponding to the page constituent node and the node locating path corresponding to the parent node of the page constituent node.

[0148] In step S312, the node locating path corresponding to each page constituent node is added to a page running instance of the service page, where the node locating path is used for running anomaly locating of the service page.

[0149] In step S314, in the case that a component event is triggered for a service page, a trigger page composition node corresponding to the component event is determined, and a node positioning path corresponding to the trigger page composition node is read in a page running instance.

[0150] In step S316, the event positioning unit corresponding to the component event and the node positioning path corresponding to the trigger page composition node are spliced according to the page access sequence to obtain an event positioning path.

[0151] In step S318, the event positioning path is written into the logical context information corresponding to the component event, wherein the event positioning unit includes event identification information, event name information, affiliated component design identification information and binding logic identification information corresponding to the component event.

[0152] In step S320, the trigger unsuccessful page position information corresponding to the component event is determined according to the event positioning path.

[0153] In the positioning path construction method provided in this embodiment, in order to realize accurate positioning for any problem in the low-code platform and avoid the problem of inaccurate positioning caused by identical identifiers, the original page description file of the service page can be obtained first, and design identification information corresponding to each page composition node in the service page is configured in the original page description file to obtain a target page description file; special identification information that can be used for subsequent path construction is embedded in the page description file, then a node positioning unit corresponding to each page composition node can be constructed according to the target page description file, on this basis, a node positioning path corresponding to each page composition node is generated based on the node positioning unit, and the node positioning path is obtained by sequentially splicing the node positioning unit corresponding to the page composition node and the node positioning path corresponding to the parent node of the page composition node; finally, the node positioning path corresponding to each page composition node can be added to the page running instance of the service page, wherein the node positioning path is used for running exception positioning of the service page. By constructing the node positioning path and adding it to the page running instance for running exception positioning, the running exception position of the service page can be accurately located, the problem of positioning difficulty caused by identical identifiers is eliminated, and the problem solving efficiency in the page development stage is effectively improved.

[0154] Corresponding to the above method embodiments, this specification further provides a positioning path construction apparatus embodiment. Figure 4 shows a schematic structural diagram of a positioning path construction apparatus provided in an embodiment of this specification.As shown in Figure 4, the apparatus comprises: an obtaining module 402, configured to obtain an original page description file of a service page, and configure design identification information corresponding to each page composition node in the service page in the original page description file to obtain a target page description file; a construction module 404, configured to construct a node positioning unit corresponding to each page composition node respectively according to the target page description file; a generation module 406, configured to generate a node positioning path corresponding to each page composition node respectively based on the node positioning unit, wherein the node positioning path is obtained by sequentially splicing the node positioning unit corresponding to the page composition node and the node positioning path corresponding to the parent node of the page composition node; an adding module 408, configured to add the node positioning path corresponding to each page composition node to a page running instance of the service page, wherein the node positioning path is used for running exception positioning of the service page.

[0155] In an optional embodiment, the step of configuring design identification information corresponding to each page composition node in the service page in the original page description file to obtain a target page description file comprises: determining a plurality of page composition nodes corresponding to the service page, wherein the plurality of page composition nodes include a page root node, a sub-page container node, a low-code component node, a basic component node, and an event configuration node; generating design identification information for the page root node, the sub-page container node, the low-code component node, the basic component node, and the event configuration node respectively; configuring the design identification information into the original page description file, and generating the target page description file according to a configuration result.

[0156] In an optional embodiment, the step of configuring the design identification information into the original page description file and generating the target page description file according to a configuration result comprises: configuring the design identification information into the original page description file to obtain an intermediate page description file; verifying the intermediate page description file by using a page designer; taking the intermediate page description file as the target page description file when the intermediate page description file passes verification; and repairing the intermediate page description file according to a preset file repair strategy when the intermediate page description file fails verification, to obtain the target page description file.

[0157] In an optional embodiment, when the page component node is the page root node, the construction of the node positioning unit corresponding to the page root node includes: Obtain the root node design identifier information, root node resource identifier information, root node type information, and root node name information corresponding to the root node of the page from the target page description file; generate a node positioning unit corresponding to the root node of the page based on the root node design identifier information, root node resource identifier information, root node type information, and root node name information; wherein, the generation of the node positioning path corresponding to the root node of the page includes: generating the node positioning path corresponding to the root node of the page according to the node positioning unit corresponding to the root node of the page.

[0158] In an optional embodiment, the generation of the node location path corresponding to any non-page root node includes: Determine the parent page component node corresponding to the non-page root node; determine the node positioning path corresponding to the parent page component node from component attribute information, runtime context information, dependency injection information, or scheduling context information using preset path acquisition rules; concatenate the node positioning unit corresponding to the non-page root node and the node positioning path corresponding to the parent page component node according to the page access order to obtain the node positioning path corresponding to the non-page root node.

[0159] In an optional embodiment, the method further includes: If the parent page component node has not completed the initialization operation, an initial node positioning path is constructed based on the node positioning unit corresponding to the non-page root node; if the parent page component node has completed the initialization operation, the initial node positioning path is updated based on the node positioning path corresponding to the parent page component node to obtain the node positioning path corresponding to the non-page root node.

[0160] In an optional embodiment, after the step of adding the node location path corresponding to each page component node to the page execution instance of the business page is executed, the method further includes: When a component event is triggered for the business page, the triggering page component node corresponding to the component event is determined, and the node positioning path corresponding to the triggering page component node is read in the page running instance; the event positioning unit corresponding to the component event and the node positioning path corresponding to the triggering page component node are concatenated according to the page access order to obtain the event positioning path; the event positioning path is written into the logical context information corresponding to the component event, wherein the event positioning unit includes the event identifier information, event name information, component design identifier information, and binding logic identifier information corresponding to the component event.

[0161] In an optional embodiment, after the step of reading the node location path corresponding to the trigger page component node in the page running instance is executed, the method further includes: Determine whether the node positioning path corresponding to the component node of the triggering page meets the path usage conditions; if yes, execute the step of concatenating the event positioning unit corresponding to the component event and the node positioning path corresponding to the component node of the triggering page according to the page access order to obtain the event positioning path; if no, read the parent node positioning path of the parent node corresponding to the component node of the triggering page in the page running instance, and concatenate the parent node positioning path, the node positioning unit corresponding to the component node of the triggering page, and the event positioning unit corresponding to the component event according to the page access order to obtain the event positioning path.

[0162] In an optional embodiment, the method further includes: If the parent node location path of the parent node corresponding to the component node of the trigger page is unavailable, the component node of the trigger page is in a destroyed state, or the upper-layer link of the component event is missing, the trigger design identifier information, trigger logic identifier information, trigger event identifier information, and trigger page resource identifier information of the component node of the trigger page are obtained; a degraded event location path is generated based on the trigger design identifier information, the trigger logic identifier information, the trigger event identifier information, and the trigger page resource identifier information; and the degraded event location path is used as the event location path.

[0163] In an optional embodiment, before the step of writing the event location path into the logical context information corresponding to the component event is executed, the method further includes: The event location path is deduplicated to obtain an initial event location path, and a path level detection is performed on the initial event location path. If the path level detection result determines that the initial event location path is greater than a preset path level limit, the initial event location path is truncated to obtain a target event location path. The target event location path is used as the event location path, and the step of writing the event location path into the logical context information corresponding to the component event is executed.

[0164] In an optional embodiment, after the step of writing the event location path into the logical context information corresponding to the component event is executed, the method further includes: If the component event fails to trigger during the event triggering phase, condition judgment phase, method call phase, interface request phase, or result processing phase, the event location path is read from the logical context information; and the page location information corresponding to the failed triggering of the component event is determined based on the event location path.

[0165] In an optional embodiment, after the step of writing the event positioning path into the logical context information corresponding to the component event is performed, the method further includes: in response to successful execution of the event logic of the component event, writing the event positioning path and the event execution result corresponding to the component event into a page log; in response to unsuccessful execution of the event logic of the component event, determining logical instance identification information, logical flow identification information and event exception information corresponding to the component event, and writing the event positioning path, the logical instance identification information, the logical flow identification information and the event exception information into the page log; wherein the event exception information includes at least one of failed node information, error code information, error message, exception type, exception stack and execution time consumption information.

[0166] In an optional embodiment, in the case that the event logic of the component event is not successfully executed, the method further includes: in the case that the reporting interface of the page log fails to be called, the user token is invalid or the network is abnormal, determining path summary information corresponding to the event positioning path, as well as determining event error information and reporting failure information; taking the path summary information, the event error information and the reporting failure information as the event exception information; performing normalization processing on the event exception information to obtain target event exception information; writing the target event exception information, the event positioning path, the logical instance identification information and the logical flow identification information into the page log.

[0167] The above is an illustrative solution of the positioning path constructing apparatus of this embodiment. It should be noted that the technical solution of the positioning path constructing apparatus and the technical solution of the positioning path constructing method described above belong to the same concept, and for the details not described in detail in the technical solution of the positioning path constructing apparatus, reference may be made to the description of the technical solution of the positioning path constructing method described above.

[0168] Corresponding to the above method embodiments, this specification further provides an embodiment of a page exception positioning apparatus, and Figure 5 shows a schematic structural diagram of a page exception positioning apparatus provided by an embodiment of this specification.As shown in Figure 5, the apparatus includes: a file obtaining module 502, configured to obtain an original page description file of a service page, and configure design identification information corresponding to each page constituent node in the service page in the original page description file to obtain a target page description file; a path constructing module 504, configured to construct a node positioning path corresponding to each page constituent node respectively according to the target page description file, and add the node positioning path corresponding to each page constituent node to a page running instance of the service page; an instance accessing module 506, configured to, when an interaction event is triggered for the service page, determine a target node positioning path corresponding to the interaction event by accessing the page running instance; an information determining module 508, configured to determine event trigger page position information corresponding to the interaction event according to the target node positioning path.

[0169] The above is a schematic solution of the page abnormality positioning apparatus according to this embodiment. It should be noted that the technical solution of the page abnormality positioning apparatus and the technical solution of the page abnormality positioning method described above belong to the same concept, and for the details not described in detail in the technical solution of the page abnormality positioning apparatus, reference may be made to the description of the technical solution of the page abnormality positioning method described above.

[0170] Figure 6 shows a structural block diagram of a computing device 600 provided according to an embodiment of the present specification. Components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and a database 650 is configured to store data.

[0171] The computing device 600 further includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. Examples of such networks include a public switched telephone network (PSTN, Public Switched Telephone Network), a local area network (LAN, Local Area Network), a wide area network (WAN, Wide Area Network), a personal area network (PAN, Personal Area Network), or a combination of communication networks such as the Internet.The access device 640 may include one or more of any type of wired or wireless network interfaces (e.g., network interface controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, and a Near Field Communication (NFC) interface.

[0172] In one embodiment of the present specification, the above components of the computing device 600 and other components not shown in Figure 6 may also be connected to each other, for example, via a bus. It should be understood that the structural block diagram of the computing device shown in Figure 6 is for illustrative purposes only, and is not a limitation on the scope of the present specification. Those skilled in the art may add or replace other components as needed.

[0173] The computing device 600 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smart watch, smart glasses, etc.) or other types of mobile devices, or a stationary computing device such as a desktop computer or a Personal Computer (PC). The computing device 600 may also be a mobile or stationary server.

[0174] The processor 620 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the foregoing positioning path construction method or page anomaly positioning method.

[0175] The above is an illustrative solution of a computing device according to this embodiment.It should be noted that the technical solution of this computing device belongs to the same concept as the technical solution of the above-mentioned location path construction method or page anomaly location method. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-mentioned location path construction method or page anomaly location method.

[0176] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described location path construction method or page anomaly location method.

[0177] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the above-described location path construction method or page anomaly location method. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the above-described location path construction method or page anomaly location method.

[0178] An embodiment of this specification also provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps of the above-described location path construction method or page anomaly location method.

[0179] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product belongs to the same concept as the technical solution of the above-mentioned location path construction method or page anomaly location method. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the above-mentioned location path construction method or page anomaly location method.

[0180] Specific embodiments of this specification have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0181] The computer instructions include computer program code, which may be in the form of source code, object code, executable file or some intermediate form, etc.The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0182] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this specification are not limited to the described order of actions, because according to the embodiments of this specification, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments of this specification.

[0183] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0184] The preferred embodiments disclosed above are merely illustrative of this specification. Optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described in this specification. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification.< / iframe>

Claims

1. A method for constructing a location path, characterized in that, include: Obtain the original page description file of the business page, and configure the design identification information corresponding to each page component node in the business page in the original page description file to obtain the target page description file; Construct node positioning units corresponding to each component node of the page based on the target page description file; Based on the node positioning unit, a node positioning path is generated for each page component node. The node positioning path is obtained by concatenating the node positioning unit corresponding to the page component node and the node positioning path corresponding to the parent node of the page component node in sequence. Add the node location path corresponding to each page component node to the page running instance of the business page, wherein the node location path is used for locating running anomalies of the business page.

2. The location path construction method according to claim 1, characterized in that, The step of configuring the design identifier information corresponding to each page component node in the business page in the original page description file to obtain the target page description file includes: The business page is identified as having multiple page component nodes, including a page root node, a subpage container node, a low-code component node, a basic component node, and an event configuration node. Design identification information is generated for the page root node, the child page container node, the low-code component node, the basic component node, and the event configuration node, respectively; Configure the design identifier information into the original page description file, and generate the target page description file based on the configuration result.

3. The positioning path construction method according to claim 2, characterized in that, The step of configuring the design identifier information into the original page description file and generating the target page description file based on the configuration result includes: Configure the design identification information into the original page description file to obtain an intermediate page description file; The intermediate page description file is validated using the page designer; If the intermediate page description file passes the verification, the intermediate page description file will be used as the target page description file. If the intermediate page description file fails verification, the intermediate page description file is repaired according to a preset file repair strategy to obtain the target page description file.

4. The location path construction method according to claim 1, characterized in that, When the page component node is the page root node, the construction of the node positioning unit corresponding to the page root node includes: Obtain the root node design identifier information, root node resource identifier information, root node type information, and root node name information corresponding to the root node of the page from the target page description file; Based on the root node design identifier information, the root node resource identifier information, the root node type information, and the root node name information, a node positioning unit corresponding to the page root node is generated; The generation of the node positioning path corresponding to the root node of the page includes: The node positioning path corresponding to the root node of the page is generated based on the node positioning unit corresponding to the root node of the page.

5. The positioning path construction method according to claim 4, characterized in that, The generation of the node location path corresponding to any non-page root node includes: Determine the parent page constituent nodes corresponding to non-page root nodes; The node location path corresponding to the parent page component nodes is determined by using preset path acquisition rules from component attribute information, runtime context information, dependency injection information, or scheduling context information. The node positioning unit corresponding to the non-page root node and the node positioning path corresponding to the parent page component node are concatenated according to the page access order to obtain the node positioning path corresponding to the non-page root node.

6. The positioning path construction method according to claim 5, characterized in that, Also includes: If the parent page component nodes have not completed the initialization operation, an initial node positioning path is constructed based on the node positioning unit corresponding to the non-page root node. When the parent page component nodes have completed the initialization operation, the initial node positioning path is updated according to the node positioning path corresponding to the parent page component nodes to obtain the node positioning path corresponding to the non-page root node.

7. The positioning path construction method according to any one of claims 1 to 6, characterized in that, After the step of adding the node location path corresponding to each page component node to the page execution instance of the business page is executed, the method further includes: When a component event is triggered for the business page, the triggering page component node corresponding to the component event is determined, and the node location path corresponding to the triggering page component node is read in the page running instance; The event location path is obtained by concatenating the event location unit corresponding to the component event and the node location path corresponding to the node of the triggering page according to the page access order. The event location path is written into the logical context information corresponding to the component event, wherein the event location unit includes the event identifier information, event name information, component design identifier information, and binding logic identifier information corresponding to the component event.

8. The positioning path construction method according to claim 7, characterized in that, After the step of reading the node location path corresponding to the constituent nodes of the trigger page in the page running instance is executed, the method further includes: Determine whether the node location path corresponding to the constituent nodes of the trigger page meets the path usage conditions; If so, perform the step of concatenating the event location unit corresponding to the component event and the node location path corresponding to the triggering page component node according to the page access order to obtain the event location path; If not, in the page running instance, read the parent node positioning path of the parent node corresponding to the trigger page component node, and concatenate the parent node positioning path, the node positioning unit corresponding to the trigger page component node, and the event positioning unit corresponding to the component event according to the page access order to obtain the event positioning path.

9. The positioning path construction method according to claim 8, characterized in that, Also includes: If the parent node location path of the parent node corresponding to the component node of the trigger page is unavailable, the component node of the trigger page is in a destroyed state, or the upper-layer link of the component event is missing, the trigger design identifier information, trigger logic identifier information, trigger event identifier information, and trigger page resource identifier information of the component node of the trigger page are obtained. Based on the trigger design identifier information, the trigger logic identifier information, the trigger event identifier information, and the trigger page resource identifier information, a degradation event location path is generated; The degradation event location path is used as the event location path.

10. The positioning path construction method according to claim 7, characterized in that, Before the step of writing the event location path into the logical context information corresponding to the component event is executed, the method further includes: The event location path is deduplicated to obtain an initial event location path, and the path hierarchy is detected for the initial event location path. If the initial event location path is determined to be greater than the preset path level limit based on the path level detection result, the initial event location path is truncated to obtain the target event location path. The target event location path is used as the event location path, and the step of writing the event location path into the logical context information corresponding to the component event is executed.

11. The positioning path construction method according to claim 7, characterized in that, After the step of writing the event location path into the logical context information corresponding to the component event is executed, the method further includes: If the component event fails to trigger during the event triggering phase, condition judgment phase, method call phase, interface request phase, or result processing phase, the event location path is read from the logical context information. The location information of the page where the component event failed to trigger is determined based on the event location path.

12. The positioning path construction method according to claim 7, characterized in that, After the step of writing the event location path into the logical context information corresponding to the component event is executed, the method further includes: If the event logic of the component event is executed successfully, the event location path and the event execution result corresponding to the component event will be written to the page log. If the execution of the event logic of the component event fails, determine the logical instance identifier information, logical flow identifier information and event exception information corresponding to the component event, and write the event location path, the logical instance identifier information, the logical flow identifier information and the event exception information into the page log; The event exception information includes at least one of the following: failure node information, error code information, error message, exception type, exception stack, and execution time information.

13. The positioning path construction method according to claim 12, characterized in that, If the event logic of the component event fails to execute, the following is also included: In the event of a failed call to the reporting interface of the page log, an invalid user token, or a network anomaly, determine the path summary information corresponding to the event location path, as well as the event error information and reporting failure information. The path summary information, the event error information, and the reporting failure information are used as the event exception information; The abnormal event information is processed in a standardized manner to obtain the abnormal information of the target event. Write the target event exception information, the event location path, the logical instance identifier information, and the logical flow identifier information into the page log.

14. A method for locating page anomalies, characterized in that, include: Obtain the original page description file of the business page, and configure the design identification information corresponding to each page component node in the business page in the original page description file to obtain the target page description file; Based on the target page description file, construct the node location path corresponding to each page component node, and add the node location path corresponding to each page component node to the page execution instance of the business page; When an interaction event is triggered for the business page, the target node location path corresponding to the interaction event is determined by accessing the running instance of the page; The location information of the event trigger page corresponding to the interactive event is determined based on the target node positioning path.

15. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 14.

16. A computer-readable storage medium, characterized in that, It stores computer-executable instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 14.

17. A computer program product, characterized in that, Includes a computer program or instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 14.

Images