Automatic query method and device, electronic equipment and storage medium

Abstract

This invention provides an automatic query method, apparatus, electronic device, and storage medium. After simulating a user's population operation on a target query page for each component to be populated, the automatic query system reads back the latest state of each component from both the native DOM layer and the framework model layer, and then cross-validates it with the query request data. If the cross-validation passes, a transaction state record is generated, which triggers a multi-level stability check on the result display area of ​​the target query page after the search to confirm whether the search is complete. Upon confirmation of search completion, the pending search mark in the transaction state record is removed, and the transaction state in the record is updated to a stable state. Finally, the final query result is returned to the requester. This invention avoids search errors caused by outdated model components through cross-validation and ensures accurate search results are returned to the requester through multi-level stability checks, rather than loading intermediate states, old tables, or incorrectly judged empty results.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and more specifically, to an automatic query method, apparatus, electronic device, and storage medium. Background Technology

[0002] In component-based web pages such as enterprise back-end systems, data management systems, CRM (Customer Relationship Management) systems, ERP (Enterprise Resource Planning) systems, patent search systems, or contract search systems, the filtering and query areas are typically composed of Vue, React, Element, Ant Design, or similar component libraries. The visible input fields, hidden values, component-internal responsive models, pop-up options, validation states, and search request parameters on such pages may not share the same state source.

[0003] Existing automated query solutions typically only set the visible values ​​of the input boxes. The page may appear to have already entered the target filter conditions, but the component model is not updated. Subsequent search requests will still carry old parameters or empty parameters, resulting in search errors.

[0004] Furthermore, existing solutions typically separate the three actions of "filling in values," "searching," and "reading results": after filling in values, the caller needs to explicitly trigger the search; after the search, the table is read after a fixed delay or simply waiting for the loading to stop. If the caller misses the search step, the result reads the previous query result; if the result is still loading, rendering, or in the process of switching between empty states, the result reads may be an intermediate loading state, an old table, or a falsely judged empty result. Summary of the Invention

[0005] The purpose of this invention is to provide an automatic query method, apparatus, electronic device, and storage medium to improve the problems existing in the prior art.

[0006] The embodiments of the present invention can be implemented as follows: In a first aspect, the present invention provides an automatic query method for use in an automatic query system, the method comprising: Obtain the query requirement data for the current query task; Based on the query requirement data, at least one component to be populated is identified on the target query page; Based on the query requirement data and the component type of each component to be populated, the native DOM layer state and framework model layer state of each component to be populated are updated simultaneously to simulate the user's population operation on each component to be populated on the target query page. After reading back the latest state of each component to be populated from the native DOM layer and the framework model layer respectively, cross-validation is performed with the query requirement data. If the cross-validation passes, a transaction status record corresponding to the current query task is generated; Based on the transaction status record, after the search is triggered, multi-level stability detection is performed on the result display area of ​​the target query page to confirm whether the search is complete; Upon confirmation that the search is complete, the pending search mark in the transaction status record is removed, the transaction status flag in the transaction status record is updated to a stable state, and the final query result is returned to the requester of the current query task.

[0007] In an optional implementation, the query request data includes at least one specified field and its target value, and the target page context of the target query page; The step of determining at least one component to be populated on the target query page based on the query request data includes: Based on the context of the target page, the system redirects to display the target query page. Identify the filter area on the target query page; If the filter area is not fully expanded, an expansion operation is triggered, and after the filter area is fully expanded, a region status record of the filter area is generated. For each specified field, determine multiple candidate controls corresponding to the specified field in the filtering area, and generate a control attribute record for each candidate control; For each specified field, based on the control attribute record of each candidate control, the specified field and its target value, the component to be populated corresponding to the specified field is determined from multiple candidate controls.

[0008] In an optional implementation, the control attribute record includes multiple attribute dimensions; The step of determining the component to be populated corresponding to the specified field from multiple candidate controls based on the control attribute record of each candidate control, the specified field and its target value, includes: Each candidate control is traversed sequentially, and the semantic matching score between each attribute dimension of the candidate control and the specified field is calculated. The semantic matching scores are then weighted and summed to obtain the semantic matching degree corresponding to the candidate control. Determine the format matching degree between the target value format of the specified field and the control type of the candidate control; Based on the affiliation relationship between the candidate control and the filtering area, the relationship bonus degree corresponding to the candidate control is determined; The penalty score corresponding to the candidate control is determined based on whether there are semantic conflicts between the various attribute dimensions of the candidate control and whether the candidate control has contradictory container affiliation. The semantic matching degree, format matching degree, relational bonus degree and penalty score corresponding to each candidate control are summed to obtain the comprehensive matching score between the candidate control and the specified field. The candidate control with the highest overall matching score that exceeds the set score threshold is selected as the component to be populated for the specified field.

[0009] In an optional implementation, the query requirement data includes at least one specified field and its target value; The step of cross-validating the latest state of each component to be populated after reading back from the native DOM layer and the framework model layer with the query requirement data includes: For each component to be populated, the current DOM state of the component to be populated is read from the native DOM layer, and the network request triggered by the target query webpage after the population operation is completed is listened to in order to determine the current backend state of the component to be populated in the framework model layer. If the current DOM state and the current backend state of each component to be populated are consistent with the target value of the corresponding specified field, then the cross-validation is considered successful.

[0010] In an optional implementation, the step of generating a transaction status record corresponding to the current query task if the cross-validation passes includes: If the cross-validation passes, a successful validation record is generated for each component to be populated; Based on the successful verification record of each component to be populated, a transaction status record corresponding to the current query task is generated.

[0011] In an optional implementation, the step of performing multi-level stability checks on the result display area of ​​the target query page after triggering a search based on the transaction status record to confirm whether the search is complete includes: When the target to be searched in the transaction status record is true, locate the query button in the filter area corresponding to the region ID in the transaction status record. Initiate a click event on the query button to trigger a search, and simultaneously generate a search trigger record; Multi-level stability testing is performed on the result display area of ​​the target query page to confirm whether the search results are stable.

[0012] In an optional implementation, the step of performing multi-level stability checks on the result display area of ​​the target query page to confirm whether the search is complete includes: Monitor the loading mask within the result display area of ​​the target query page, the current search request in the network request queue, and changes in the result display area to perform multi-level stability detection; When the loading mask disappears, the current search request is completed, the result display area meets the search stability conditions, and the transaction status record and the search trigger record meet the version consistency conditions, the multi-level stability detection ends and the search is confirmed to be complete. The search stability condition is that at least one search result appears in the result display area or the search result display area is empty.

[0013] In an optional implementation, the step of performing multi-level stability checks on the result display area of ​​the target query page to confirm whether the search is complete further includes: If the multi-level stability detection fails and the number of times the search is triggered has not reached the maximum number of retries, return to the step of initiating the click event on the query button; When multi-level stability detection fails and the number of times the search is triggered reaches the maximum number of retries, a query failure message is directly returned to the requesting party.

[0014] Secondly, the present invention provides an automated search device for use in an automated query system, the device comprising: The task receiving module is used to obtain the query requirement data for the current query task; The component location module is used to determine at least one component to be populated on the target query page based on the query requirement data. The conditional population module is used to update the native DOM layer state and framework model layer state of each component to be populated based on the query requirement data and the component type of each component to be populated, so as to simulate the user's population operation on each component to be populated on the target query page. The population validation module is used to read back the latest state of each component to be populated from the native DOM layer and the framework model layer respectively, and then perform cross-validation with the query requirement data. The transaction record module is used to generate a transaction status record corresponding to the current query task if the cross-validation passes. An automatic search module is used to perform multi-level stability checks on the result display area of ​​the target query page after triggering a search based on the transaction status record, in order to confirm whether the search is complete. The task feedback module is used to remove the pending search mark from the transaction status record and update the transaction status flag in the transaction status record to a stable state when the search is confirmed to be completed, and return the final query result to the requester of the current query task.

[0015] Thirdly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory stores a software program, and when the electronic device is running, the processor executes the software program to implement the method described in the first aspect above.

[0016] Fourthly, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0017] Compared with existing technologies, embodiments of the present invention provide an automatic query method, apparatus, electronic device, and storage medium. The method involves: after obtaining the query requirement data for the current query task, first identifying at least one component to be populated on the target query page; then, based on the query requirement data and the component type of each component to be populated, simultaneously updating the native DOM layer state and the framework model layer state of each component to be populated to simulate a user's population operation on the target query page; then, reading back the latest state of each component to be populated from the native DOM layer and the framework model layer respectively, and performing cross-validation with the query requirement data; if the cross-validation passes, generating a transaction state record corresponding to the current query task; based on the transaction state record, after triggering a search, performing multi-level stability checks on the result display area of ​​the target query page to confirm whether the search is complete; upon confirmation of search completion, removing the pending search mark from the transaction state record, updating the transaction state in the transaction state record to a stable state, and returning the final query result to the requester of the current query task. This invention uses cross-validation to avoid search errors caused by outdated model components. Furthermore, by triggering searches through transaction status records and multi-level stability checks, it ensures that accurate search results are ultimately returned to the requester, rather than loading intermediate states, old tables, or empty results due to misjudgment. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is one of the flowcharts illustrating an automatic query method provided in an embodiment of the present invention.

[0020] Figure 2 This is a second flowchart illustrating an automatic query method provided in an embodiment of the present invention.

[0021] Figure 3 This is a schematic diagram of an automatic query device provided in an embodiment of the present invention.

[0022] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0024] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0025] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0026] Furthermore, the terms "first" and "second" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0027] It should be noted that, where there is no conflict, the features in the embodiments of the present invention can be combined with each other.

[0028] Existing automated query solutions include browser autofill solutions based on user behavior statistics, form filling solutions based on field transition probabilities, and solutions that restore form content through local caching after an H5 page crashes. These solutions all involve form filling or form state handling, focusing on predicting fields to fill, restoring already filled content, or improving the efficiency of ordinary form filling. However, most of them suffer from the following objective drawbacks: First, fixed selectors, input box numbers, or full-page label matching are prone to mis-targeting. The system's filter area may be collapsed, lazy-loaded, or interfered with by pop-ups, table edit boxes, hidden templates, and automated auxiliary panels; if the filter area is not identified and invalid controls are excluded first, the automated script may fill in the wrong controls.

[0029] Second, the displayed values ​​and the framework model values ​​may be inconsistent. Component-based controls often maintain the displayed input values, the component's internal model values, the hidden submission values, and the tag echo values ​​separately. Simply setting the DOM value or dispatching a normal event may only change the visible input box and cannot guarantee that the internal model of Vue, React, or the component library has been updated synchronously.

[0030] Third, controls such as dropdowns, multi-selects, cascading selections, and date ranges require component contracts. These controls typically involve popup layer mounting, option loading, label display, array models, start and end value models, or date format conversions. Ordinary clicks or text input may not necessarily trigger selection, validation, and change notifications within the component.

[0031] Fourth, the existing solution lacks a cross-validation mechanism after the data has been filled. Even if the script can read the visible values, it may not be able to verify whether the model values ​​are consistent with the target values. If the search continues to be triggered even though the model values ​​have not been updated, incorrect filtering conditions will be submitted to the backend, and it will be difficult to detect in a timely manner from the appearance of the page.

[0032] Fifth, there is a lack of a common state link between data entry, searching, and reading. Existing processes often cannot determine whether a field has been successfully bound, whether a search has been triggered after successful binding, whether the current result corresponds to the current filtering conditions, or whether the failure occurred during the location, binding, search, or stable reading phase.

[0033] Sixth, the result reading lacks stability testing. Existing technology simply waits for a fixed period of time or for a certain loaded element to disappear, and cannot accurately distinguish between old results, intermediate loading states, real empty results, and stable new results. It is easy to mistake incomplete rendering or old tables for the final output.

[0034] Based on the discovery of the aforementioned technical problems, the inventors, through creative labor, proposed the following technical solutions to solve or improve these problems. It should be noted that the deficiencies in the solutions of the prior art are all results derived by the inventors after practical experience and careful research. Therefore, the discovery process of the aforementioned problems and the solutions proposed in the embodiments of this application below should be considered contributions made by the inventors to this application during the inventive process, and should not be construed as technical content known to those skilled in the art.

[0035] Please refer to Figure 1 , Figure 1This is a flowchart illustrating an automatic query method provided in an embodiment of the present invention. The executing entity of this method can be an automatic query system, which can be a browser context, browser extension, automated execution node (i.e., automated execution script), test execution node (test execution script), or crawler node deployed and running on an electronic device. The electronic device can be, but is not limited to, a smartphone, smart tablet, personal laptop, personal computer, etc. Figure 1 The automated query method includes the following steps S1 to S6.

[0036] S1. Based on the query requirements data of the current query task, identify at least one component to be populated on the target query page.

[0037] In this embodiment, the query requirement data of the current query task is first obtained, and then, based on the query requirement data, at least one component to be populated is determined on the target query page.

[0038] Optionally, for an intelligent agent with data analysis capabilities and question-and-answer dialogue capabilities, the automatic query system of this application can be one of the tools that the intelligent agent can call.

[0039] In one alternative example, when an agent is automatically performing data analysis tasks according to a workflow, it can act as a requester and issue a query task to the automated query system when it needs to query relevant data. In another alternative example, during a dialogue with the agent, if query request data is extracted from user input, the agent can automatically invoke the automated query system and publish the extracted query request data to it. It should be noted that these examples are merely illustrative and are not intended to be limiting.

[0040] For example, the target query page may be a componentized query webpage of any of the following systems: enterprise back-end system, data management system, CRM system, ERP system, patent search system, or contract search system.

[0041] S2. Based on the query requirement data and the component type of each component to be populated, simultaneously update the native DOM layer state and framework model layer state of each component to be populated, so as to simulate the user's population operation on each component to be populated on the target query page.

[0042] In this embodiment, the component to be populated is a data input component, and its component type can be, but is not limited to, any one of the following: input box, selector, checkbox, date picker, time picker, and slider input. Based on the query request data and the component type of each component to be populated, the native DOM layer state and framework model layer state of each component to be populated are updated simultaneously to simulate the user's population operation on the target query page for each component to be populated, such as input operation, date selection operation, dropdown selection operation, etc.

[0043] S3. After reading back the latest state of each component to be populated from the native DOM layer and the framework model layer respectively, cross-validate it with the query requirement data.

[0044] In this embodiment, cross-validation is used to verify whether the latest state of each component to be populated in the native DOM layer and the framework model layer is consistent with the requirements of the query data.

[0045] S4. If the cross-validation passes, generate the transaction status record corresponding to the current query task.

[0046] In this embodiment, if the cross-validation passes, it indicates that each component to be populated has been synchronously updated in the native DOM layer and the framework model layer. Next, a transaction status record needs to be generated. This transaction status record includes the unique transaction ID of the current query task and the transaction operation data. The unique transaction ID distinguishes the current query task from other query tasks being executed by the automatic query system, ensuring that the search and the final read results are the correct ones required by the current query task.

[0047] S5. Based on the transaction status record, after triggering the search, perform multi-level stability detection on the result display area of ​​the target query page to confirm whether the search is complete.

[0048] In this embodiment, after a search is triggered based on the transaction status record, the search results are not read after a fixed period of time or after a loaded element disappears, as is done in existing technologies. Instead, multi-level stability checks are performed to confirm whether the search is complete.

[0049] S6. Upon confirming the completion of the search, remove the pending search mark from the transaction status record, update the transaction status flag in the transaction status record to a stable state, and return the final query result to the requester of the current query task.

[0050] In this embodiment, when the search is confirmed to be complete, the pending search mark in the transaction status record is removed and the transaction status flag in the transaction status record is updated to a stable state. This indicates that the current query task has been completed. Then, the final query result can be read from the latest result display area of ​​the target query page and returned to the requester of the current query task (e.g., an intelligent agent).

[0051] The automatic query method described in this invention involves an automatic query system that, after simulating a user's input operations on various components to be populated on a target query page, reads back the latest state of each component from both the native DOM layer and the framework model layer, and then cross-validates it with the query request data. If the cross-validation passes, a transaction state record is generated, which triggers a multi-level stability check on the result display area of ​​the target query page to confirm whether the search is complete. Upon confirmation of search completion, the pending search mark in the transaction state record is removed, and the transaction state in the record is updated to a stable state. Finally, the final query result is returned to the requester. This invention avoids search errors caused by outdated model components through cross-validation and ensures accurate search results are returned to the requester through multi-level stability checks, rather than loading intermediate states, old tables, or incorrectly judged empty results.

[0052] Current technologies for locating filter controls in componentized web pages generally employ full-page CSS (Cascading Style Sheets) selectors or XPath (XML Path Language) path matching. These methods lack a layered understanding of the page structure, easily misinterpreting edit boxes within table rows, temporary input fields in pop-ups, controls within automation panels, and even hidden template elements outside collapsed areas as controls to be filled.

[0053] Even when the filter area of ​​the target query page is in a collapsed state, or some fields are dynamically mounted using lazy loading, traditional solutions often skip the expansion operation because they cannot recognize the unready state of the area, resulting in subsequent traversal of controls in an empty container and ultimately returning an empty result or an error node.

[0054] In an optional implementation, in step S1 above, the query request data may further include at least one specified field and its target value, as well as the target page context of the target query page. Therefore, in Figure 1 Based on this, please refer to Figure 2 The implementation process of step S1 may include the following sub-steps S11 to S15.

[0055] S11. Based on the target page context, redirect to display the target query page.

[0056] In this embodiment, the target page context can be used to characterize the page environment required for the execution of the query task, including information such as URL (Uniform Resource Locator), routing parameters (such as browser window ID / tab ID), page loading status, and overall DOM tree snapshot. Therefore, based on the target page context, the target query page can be directly displayed.

[0057] S12. Identify the filtering area on the target query page.

[0058] In this embodiment, a filtering area that meets at least one of the following characteristics can be found on the target page query page: it contains multiple form items or input controls; it is located above a list, table, or data area; it contains buttons such as "Search", "Query", "Reset", and "Expand"; it has a form, filter, query, condition bar, or component container class name; or it has a stable topological proximity relationship with the result display area.

[0059] If the found filter area is in a fully expanded state, then proceed directly to step S14; otherwise, proceed to step S13.

[0060] S13. If the filtering area is not fully expanded, an expansion operation is triggered, and after the filtering area is fully expanded, a region status record of the filtering area is generated. The "not fully expanded" state indicates that the filter area includes at least one of the following: expand button, collapse panel, more conditions entry, lazy-loaded control, or no control attached.

[0061] In an optional example, the display, visibility, height, overflow, aria-expanded, or equivalent states of each control within the filtering area can be read from the DOM tree of the target query webpage. This, combined with the container boundary rectangle, the number of candidate controls, and changes in the DOM subtree, can determine whether a control is collapsed or not mounted. If an expand button, collapse panel, more condition entry, or lazy-loaded control exists, an expand operation can be triggered within the filtering area. The process can then wait for the newly added control to mount completely via an asynchronous callback using MutationObserver, changes in control visibility, component container stability, or polling conditions. This does not involve waiting for a fixed delay; rather, it uses the container state and DOM changes to determine whether the control is fully expanded.

[0062] After the filtering area is fully expanded, a region status record R_area is generated. This record includes the page context, filtering area identifier, whether it is expanded, whether it is mounted to the DOM, the number of candidate controls, the region boundary position, and the region data version number, thus defining a clear scope for all subsequent operations. Specifically, the region status record R_area can include the following fields ( / / the following content is for comments only): R_area = { / / Region status record PageContext, / / Page context FilterAreaID, / / Filter area identifier ExpandedFlag, / / A flag indicating whether to expand or collapse MountedFlag, / / Flag indicating whether the element is mounted to the DOM CandidateCount, / / Number of candidate controls AreaBoundary, / / Location of the area boundary (e.g., DOM coordinates or scroll position) AreaVersion / / Area data version number } Optionally, if locating the filtering area fails, the failure stage (i.e., locating the filtering area), a summary of the candidate containers, and the reason why it cannot continue can be output, and no further filling operation will be simulated.

[0063] S14. Determine multiple candidate controls in the filtering area and generate a control attribute record for each candidate control.

[0064] In this embodiment, multiple candidate controls corresponding to a specified field are determined in the filtering area, so that the traversal is only carried out within the filtering area, eliminating the interference caused by full-page traversal.

[0065] For example, within the filter area, after excluding elements that are invisible, disabled, have a size of zero, are located inside a table data row, are located outside a pop-up window, belong to the automation panel itself, or are not within the boundaries of the filter area, what remains are candidate controls.

[0066] The ControlEvidence property record can include the following property dimensions of the candidate control: (1) Field label: Used to record the semantic identifier associated with the control; (2) Control identifier: used to accurately locate specific nodes in the DOM tree; (3) Label text: Taken from the meaningful text declared in the attributes of an explicit label element or component; (4) Placeholder: from the placeholder attribute of the input box or equivalent prompt content; (5) Accessible name: derived from the aria-label, aria-labelledby, or title attribute; (6) Adjacent text: Visible text that is in front of, above, or immediately adjacent to the same form field as the charge; (7) Component class name and role: used to identify its front-end framework type and interaction mode; (8) Container relationship: Reflects the nesting level of controls within the filtering area; (9) Distance from the search button: This reflects the closeness of the control in terms of visual layout and functional logic; (10) Exclusion attributes such as visibility flag, disabled status, whether it is within the filter area, and whether it is inside the table.

[0067] S15. For each specified field, based on the control attribute record of each candidate control, the specified field and its target value, determine the component to be filled corresponding to the specified field from multiple candidate controls.

[0068] Existing technologies for identifying controls on web pages that correspond to specified fields typically rely on a single text feature for matching. For example, when the query field includes "applicant," they directly search for labels containing the text "applicant" or input boxes with the same placeholder. This approach ignores the diversity and contextual dependence of semantic expression in componentized web pages. The same business field may be represented as "applicant," "applying unit," "customer name," or "applicant entity" in different systems, or the control itself may not have an explicit label, but rather its purpose may be indirectly represented by aria-labels, adjacent descriptive text, or component class names. When multiple controls share similar text features, such as a "status" dropdown in a filter area and a "status" edit box in a table row, traditional methods lack the ability to determine the business context of the controls, easily leading to the misselection of non-target controls.

[0069] In this embodiment, for each specified field, the corresponding component to be filled can be found through multi-dimensional comprehensive decision-making. The search process may include the following sub-steps S151 to S156.

[0070] S151. Iterate through each candidate control in sequence, calculate the semantic matching score between each attribute dimension of the candidate control and the specified field, and perform a weighted summation of the semantic matching scores to obtain the semantic matching degree corresponding to the candidate control.

[0071] In this embodiment, for each candidate control, steps S151 to S155 need to be executed to obtain the comprehensive matching score between the candidate space and the specified field. During weighted summation, the weight coefficients of multiple attribute dimensions such as field label, control identifier, label text, and placeholders can be non-zero and can be preset according to the actual scenario (but generally not zero). For example, the label text has a higher weight than adjacent text, and the component class name has a higher weight under a specific framework. Apart from these, the weight coefficients of other attribute dimensions can all be zero.

[0072] S152. Determine the format matching degree between the target value format of the specified field and the control type of the candidate control.

[0073] The target value can be formatted as text, an enumeration, an array, a date range, or a hierarchical value. For example, when the target value is a date range, it can improve the format matching score between the specified field and date picker controls, while decreasing the format matching score between the specified field and plain text input controls; when the target value is a multi-option enumeration, it can enhance the format matching score of multi-select dropdown components or label selectors, while suppressing the format matching score of single-line text boxes. It should be noted that this example is merely illustrative and is not intended to be limiting.

[0074] S153. Based on the affiliation relationship between the candidate control and the filtering area, determine the relationship bonus degree corresponding to the candidate control.

[0075] In this embodiment, if a candidate control is located inside an identified filter area container, and is topologically close to it, has the same container hierarchy, and does not have cross-region nesting, then a higher relationship bonus can be assigned. Conversely, if it is visible on the page but is in an isolated context such as a pop-up window, table data row, or automation panel, then the relationship bonus can be assigned a value of zero or even negative. This allows the system to naturally distinguish between "filter-use controls" and "display / edit-use controls" without the need for manual annotation or hard-coded rules.

[0076] S154. Based on whether there are semantic conflicts among the various attribute dimensions of the candidate control and whether the candidate control has contradictory container affiliations, determine the penalty score corresponding to the candidate control.

[0077] Semantic conflict refers to multiple attributes pointing to different business meanings, such as a label text of "applicant" but adjacent text of "contract number," and a component class name of "table inline editor." Conflicting container affiliation refers to a control that, although within the DOM of the filtering area, is actually rendered at the bottom of the body via Teleport, or its event listener is bound to a parent container outside the filtering area. In either of these cases, a negative penalty score can be applied to lower the overall score and avoid misjudgment due to matching local features.

[0078] S155. Sum the semantic matching degree, format matching degree, relational bonus degree and penalty score corresponding to each candidate control to obtain the comprehensive matching score between the candidate control and the specified field.

[0079] S156. Select the candidate control with the highest comprehensive matching score that exceeds the set score threshold as the component to be filled for the specified field.

[0080] In this embodiment, for a specified field A, after determining the overall matching score between multiple candidate controls and the specified field A, the candidate control with the highest overall matching score that exceeds a set score threshold (e.g., 0.85) can be selected as the component to be populated corresponding to the specified field A. Furthermore, the overall matching score can be appended to the control attribute record of the component to be populated.

[0081] If the highest score among all the comprehensive matching scores does not reach the threshold, it means that there are not enough reliable controls in the current filtering area, and a location failure record will be output; if the difference between the highest score and the second highest score is lower than the preset conflict threshold, it means that there are multiple competing candidates, and it can jump to the pending review state, where the upper-level logic intervenes to make a decision, rather than randomly selecting or defaulting to the first item.

[0082] Current technologies for autofilling web page controls typically only write the `value` property to the input field and dispatch the `input` or `change` event. The implicit premise is that any change in the DOM layer's displayed value will synchronize the framework's internal model. This approach works generally in native HTML forms, but it has fundamental flaws in enterprise-level pages built with component libraries like Vue, React, Element, and Ant Design. For example, some dropdown components encapsulate the user's click behavior as a separate `onSelect` callback; simply modifying the `value` property will not trigger this callback. Another example is date range components, which require start and end values ​​to be passed in a specific format (such as a timestamp array); directly setting strings will cause the internal model to refuse to update. Yet another example is multi-select components, which require calling the `addItem` method for each item and waiting for the UI to stabilize; simple batch assignment cannot activate their linked validation logic. In these cases, if only DOM layer operations are performed, the page appears to be filled, but the model has not actually changed, leading to searches carrying old or empty parameters and thus obtaining incorrect search results.

[0083] Regarding step S2 above, in addition to triggering the native DOM layer display value update of each component to be populated based on the target value of each specified field in the query requirement data, this application will also trigger the framework model layer state update in combination with the component type.

[0084] For example, if any component to be populated is a plain text input control, this application does not simply set `element.value = targetValue`, but instead obtains the writer of the native `value` property from the prototype chain of the input element, and uses the native writer to set the input value, thereby avoiding the state misalignment caused by simply overriding the same property on the element instance; then, the bubbling `input`, `change`, keyboard completion and out-of-focus events are dispatched in sequence to ensure that the native listener, event delegation layer and framework reactive system all have the opportunity to perceive the change and respond to trigger the state update of the model framework layer.

[0085] For component-based input, dropdown, multi-select, or date range controls, component contract events or model updates need to be executed through the component adapter. For example, if any component to be populated is a dropdown control, its option panel needs to be expanded first, the option container needs to be mounted, the corresponding option needs to be located and selected based on the target value, and finally the component's agreed selection logic and change notification are triggered. If any component to be filled is a multi-select control, it is necessary to select each target item corresponding to the target value one by one, and observe whether the label set or model array changes as expected after each selection.

[0086] If any component to be populated is a date range control, the date range in the target value needs to be converted into a string, date object, timestamp, or array according to the expected format of the component, and then written into the input fields or model fields corresponding to the start and end values ​​respectively.

[0087] Optionally, if the target query page is oriented towards Vue, React, Element, Ant Design, or similar component systems, a component contract path that is equivalent to the user operation and does not depend on the exposure of internal instances can be prioritized. This could include triggering public interaction interfaces such as component option selection, date selection, tag display, change notification, focus loss validation, or pre-submission validation. The component context path is only an optional implementation: when the target page allows access to component instances, component proxy objects, binding contexts, virtual node contexts, event handling properties, or exposed methods, model updates or component-defined change entry points can be executed through this context. However, when the production environment cannot obtain the above context due to security policies or framework version limitations, writing the internal instance is not a necessary prerequisite. Instead, the approach reverts to the user-equivalent operation, component contract event, submission parameter observation, and component interaction display path, with the subsequent binding confirmation module determining whether model binding has truly been completed.

[0088] Thus, by strictly distinguishing control types and designing collaborative update strategies for the native DOM layer and the framework model layer, this application ensures that automatic filling is no longer limited to visual filling, but actually simulates the logical changes brought about by the complete operations of real users on various components.

[0089] Upon completion of updating the native DOM layer and framework model layer of each component to be populated, an update attempt record (SubmitAttempt) can be output for each component. This record includes: field label, target value, control type, whether native write was executed, whether native events were dispatched, whether a component adapter was used, component contract events, submission time, and attempted version. This update attempt record only indicates that the update has been completed, but does not guarantee that the update was successful.

[0090] After updating the native DOM layer and framework model layer of each component to be populated, a cross-comparison is required to verify whether the update is correct. That is, the implementation of step S3 above includes the following sub-steps S31 to S32.

[0091] S31. For each component to be populated, read the current DOM state of the component to be populated from the native DOM layer, and listen to the network request triggered by the target query webpage after the population operation is completed, so as to determine the current backend state of the component to be populated in the framework model layer.

[0092] In this embodiment, reading the current DOM state of a component to be populated from the native DOM layer means reading the content of the component to be populated, such as `input.value`, `textarea.value`, `select.value`, `innerText`, or the text of the tag node attached to the corresponding component, from the DOM tree based on the spatial identifier of the component to be populated. This reflects the interface performance visible to the user.

[0093] Determining the current backend state of a component to be populated at the framework model layer can be achieved by listening to network requests triggered by the target query webpage after the simulated population operation is completed. Specifically, it is possible to intercept XMLHttpRequest, Fetch, form submission, or equivalent asynchronous submission actions initiated by the target query webpage, and extract query parameters, request bodies, or candidate values ​​of submission parameters from them, which constitute the current backend state.

[0094] S32 If the current DOM state and the current backend state of each component to be populated are consistent with the target value of the corresponding specified field, then the cross-validation is deemed successful.

[0095] In this embodiment, if the current DOM state and the current backend state of each component to be populated are consistent with the target value of the corresponding specified field, then the cross-validation is considered successful. If any component to be populated does not match the three-way comparison, then the cross-validation is considered to have failed and the subsequent process is blocked.

[0096] The "consistency" here does not mean strict literal equality, but rather logical equivalence after normalization. For example, for date range fields, the DOM layer reads the string values ​​"2024-01-01" and "2024-12-31" from the two input boxes, and the backend status is parsed from the request parameters as `startDate=1704067200000&endDate=1735689600000`, and then the two are uniformly converted into a standardized time range before being compared with the target value; for multi-select fields, the DOM layer captures the set of selected tags, and the backend status is taken from the request parameters as `status[]=valid&status[]=invalid`, which is then sorted after deduplication and compared with the enumerated values ​​in the target value.

[0097] Existing technologies often directly proceed to the search trigger stage after completing the value input for web page controls and confirming the correctness of the displayed values, or completely delegate the decision-making power of whether to initiate a search to the calling program. This approach results in a lack of a unified state link between value input, search, and result retrieval. If the calling program misses the search step, it may mistakenly return the previous query result to the current task; or if multiple query tasks are executed concurrently, state confusion may occur. For example, task A may complete the value input but not search, while task B completes the value input and triggers the search, but task A ultimately reads the search result of task B. More importantly, when the value input operation is incorrect (e.g., the DOM layer has been updated but the framework model has not synchronized), the existing process cannot identify and intercept this, and the erroneous parameters will still be submitted to the backend with subsequent search actions, causing deviations in business logic that are difficult to trace.

[0098] In this application, after cross-validation is passed, a transaction status record corresponding to the current query task is generated as a unified link between value filling, searching, and result reading. This avoids misreading historical query results due to missed searches or confusion of search results from different query tasks. That is, the implementation process of step S4 above may include the following sub-steps S41 to S42.

[0099] S41. If cross-validation passes, generate a successful validation record for each component to be populated.

[0100] When cross-validation is successful, a BindingConfirmation record can be generated for each component to be populated. This record may include field label, target value, display value, model value, source of model value, whether the display layer matches, whether the model layer matches, confirmation version, and confirmation time.

[0101] If any component to be populated causes cross-validation to fail, a validation failure record for that component can be generated, including field label, target value, display value, model value, source of model value, whether the display layer matches, whether the model layer matches, the failure stage (such as display value comparison failure or model value comparison failure), reason for failure, confirmation version and confirmation time.

[0102] S42. Based on the successful verification record of each component to be populated, generate the transaction status record corresponding to the current query task.

[0103] In this embodiment, the generated transaction state record TxnState is a structured data entity, whose content may include fields such as state identifier (used to uniquely identify the current query task), page context, URL signature, filter area identifier, DOM tree version, set of modified fields, set of fields that have passed cross-validation, search mark, search trigger mark, network request observation mark, transaction state flag, state version, retry count, conflict reason, last state transition time, and last update time.

[0104] Among them, the searchable marker is used to indicate that there are currently filter changes that have been bound but have not yet triggered a search; the status version is incremented each time cross-validation passes, the DOM tree structure changes, the URL jumps, or a search is triggered, forming an immutable timestamp; the network request observation marker records the target request identifier or request queue snapshot that is expected to be captured in this search, providing a basis for comparison for subsequent stability detection.

[0105] Existing technologies typically use fixed delays or single-element disappearance checks to confirm result readiness after triggering a webpage search. For example, a 3-second wait might be set before loading a table, or a loading icon might be hidden. These approaches ignore the heterogeneity and uncertainty of result rendering in enterprise-level componentized pages. For instance, loading masks might not be correctly recognized due to style changes, the first row of a table might appear briefly and then disappear due to pagination redraws, empty result pages might lack clear indication, and there's a frame scheduling delay between network request completion and DOM update. More importantly, these waiting strategies are completely detached from the context of data entry, failing to distinguish whether the current search truly corresponds to the recently completed filtering criteria. If the page silently refreshes, a third-party script is injected, or the user manually interacts during the waiting period, mechanically executing the loading process can lead to incorrect result attribution.

[0106] In this application, the strategy of waiting for a fixed delay is abandoned. Instead, multi-level stability testing is performed to confirm the correctness and stability of the search results. That is, the implementation process of step S5 above may include the following sub-steps S51 to S53.

[0107] S51. When the target to be searched in the transaction status record is true, locate the query button in the filter area corresponding to the region ID in the transaction status record.

[0108] When the target to be searched in the transaction status record is true, the query button is first located in the filter area corresponding to the area ID (i.e. the filter area identifier) ​​in the transaction status record. This location process is based on multiple attributes such as button text, role attributes, submission type, topological proximity to the filter area, and visibility status to avoid accidentally selecting other buttons in the global navigation bar or pop-up window.

[0109] When multiple query buttons exist, prioritize the button that is closest to the current filter area and belongs to the same form or topology. If a query button is invisible, disabled, or cannot be determined, output a search failure record to explain the reason for the failure, and retain the transaction state record TxnState.

[0110] S52. Initiate a click event on the query button to trigger a search, and generate a search trigger record at the same time.

[0111] The generated SearchTrigger record goes beyond simply recording timestamps or button positions; it fully encapsulates a snapshot of the state at the moment of triggering, including state identifiers, filter area identifiers, trigger source (such as explicit search, automatic search before loading, or retries), multiple attribute dimensions of the search button, trigger time, DOM tree version, and network request observation markers. The network request observation markers are used to subsequently capture the completion signal of the target search request, while the DOM tree version is used to compare whether the page structure is consistent before and after rendering the results.

[0112] S53. Perform multi-level stability testing on the result display area of ​​the target query page to confirm whether the search results are stable.

[0113] In this embodiment, the method for performing multi-level stability detection can be: (1) Monitor the loading mask in the result display area of ​​the target query page, the current search request in the network request queue, and the changes in the result display area to perform multi-level stability detection; (2) When the loading mask disappears, the current search request is completed, the result display area meets the search stability conditions, and the transaction status record and the search trigger record meet the version consistency conditions, the multi-level stability detection ends and the search is confirmed to be complete.

[0114] Among them, loading masking refers to the phenomenon where a page may appear as a mask or overlay during web search, obscuring the page or displaying a spinning icon or a search message in the middle of the webpage.

[0115] The search stability condition is that at least one search result appears in the result display area, or the displayed search result is empty. The version consistency condition is that the status identifier, filter area identifier, and status version in the search trigger record and the transaction status record are all consistent.

[0116] Optionally, if at least one of the following occurs: detection timeout, the current search request remains incomplete, the result display area does not meet the search stability conditions, or the transaction status record and the search trigger record do not meet the version consistency conditions, then the multi-level stability detection is considered a failure. When the multi-level stability detection fails and the number of times the search is triggered has not reached the maximum number of retries, the step of initiating the click event on the query button is returned; when the multi-level stability detection fails and the number of times the search is triggered reaches the maximum number of retries (e.g., 3 times), a query failure message is directly returned to the requester.

[0117] For step S6 above, when the search is confirmed to be complete, the pending search flag in the transaction status record is removed, that is, the pending search flag in the transaction status record is reset from true to false, and the transaction status flag in the transaction status record is updated to a stable state, which indicates that the current query task has been completed.

[0118] Next, the final query results can be read from the latest results display area of ​​the target query page and returned to the requester of the current query task. Simultaneously, a StableReadRecord for the current query task can also be output, which includes: a status identifier, a set of stable conditions, a result summary, a hash of the result area content, a last data update timestamp, an empty state marker, a released searchable state version, and the read time.

[0119] During the execution of the current query task, this application generates region status records, control attribute records, location failure records, update attempt records, verification success records, verification failure records, transaction status records, search trigger records, and stable read records, which facilitates subsequent traceability of the task execution process.

[0120] It should be noted that the execution order of each step in the above method embodiments is not limited to that shown in the attached figures, and the execution order of each step shall be subject to the actual application situation.

[0121] For example, suppose the target query page is the search interface of a patent search system in the enterprise's backend. If the query data includes three specified fields and their target values: "Applicant: Zhang San", "Application Date: 2020.1.1-2026.6.30", and "Valid Status: Valid", then the process of executing the current query task can include the following stages: (1) Identify a container containing "Query", "Reset" buttons and multiple form items in the search interface of the patent search system. After determining that it is in a collapsed state, trigger the "Advanced Filter" entry and listen to the changes in the DOM subtree through MutationObserver. Wait for the new input box, drop-down box and date component to be mounted and output the area status record.

[0122] (2) Within the expanded filter area, collect candidate controls, discarding full-page scanning. For the "Applicant" field, find an input box whose label text, placeholder, and adjacent text all contain "Applicant", and the control is visible, not disabled, and not inside the table. The overall matching score meets the standard, so it is confirmed as the component to be filled in the "Applicant" field; for the "Valid Status" field, identify the drop-down component, whose form item label is "Valid Status", the component class name conforms to the Element Select feature, and it is located in the same filter area; for the "Application Date" field, locate the date range control.

[0123] (3) Synchronously update the native DOM layer and the framework model layer. For the "Applicant" input box, obtain the native value writer from the prototype chain and set the value to "Zhang San", and dispatch input, change, and blur events to ensure that the native listener and the framework responsive system perceive synchronously; for the "Valid Status" dropdown control, first expand the option panel, wait for the option container to mount, and then click the corresponding item according to the target text "Valid" to trigger the component selection logic; for the "Application Date" date range control, convert the target range into a timestamp array and write it into the start and end input boxes respectively.

[0124] (4) Perform cross-validation. For the “Applicant” input box, both the original input.value is read and the subsequent fetch request is listened to extract the parameter `applicant=Zhang San`; for the “Valid Status” drop-down box, both the selected label text is read and the hidden submission value or model array is verified; for the “Application Date” control, the displayed values ​​of the two input boxes and the model array are compared to see if they are consistent with the target range.

[0125] (5) If the cross-validation passes: If the consistency check of the three specified fields passes, the transaction state record TxnState will be generated, the search mark will be set to "true", and the current URL signature, DOM tree version and state version will be added.

[0126] (6) If the requester initiates an explicit search at this time, that is, locate the "Search" button in the filter area and click it; if the requester reads the result directly and detects that the search mark is true, it will automatically resend the search and clearly record the trigger source as "resend search before reading". Its SearchTrigger records the complete encapsulation state version and DOM snapshot to ensure traceability.

[0127] (7) Initiate multi-level stability checks: monitor whether the loading mask disappears, whether the target fetch request is completed, whether the first row of the result table appears, whether empty elements are mounted, whether the text hash of the result area remains consistent for three consecutive times, and strictly verify whether the current URL signature, DOM tree version and the snapshot saved in SearchTrigger are completely consistent. Only when all signals converge collaboratively is the search mark removed, the transaction state flag in TxnState moved to "stable state", and the true results of this filtering are output to the requester.

[0128] It should be noted that the examples above are merely illustrative and are not intended to be limiting.

[0129] In order to perform the corresponding steps in the above method embodiments and various possible implementations, an implementation of an automatic query device is given below.

[0130] Please see Figure 3 , Figure 3 A schematic diagram of the automatic query device provided in an embodiment of the present invention is shown. This automatic query device 200 is applied to an automatic query system and includes: The task receiving module 210 is used to obtain the query requirement data of the current query task; Component positioning module 220 is used to determine at least one component to be filled in on the target query page based on the query requirement data; The conditional fill module 230 is used to update the native DOM layer state and the framework model layer state of each component to be filled simultaneously according to the query requirement data and the component type of each component to be filled, so as to simulate the user's fill operation on each component to be filled on the target query page. The filling validation module 240 is used to read back the latest state of each component to be filled from the native DOM layer and the framework model layer respectively, and then perform cross-validation with the query requirement data. The transaction record module 250 is used to generate a transaction status record corresponding to the current query task if the cross-validation passes. The automatic search module 260 is used to perform multi-level stability detection on the result display area of ​​the target query page after triggering a search based on the transaction status record, so as to confirm whether the search is complete. The task feedback module 270 is used to remove the pending search mark from the transaction status record and update the transaction status flag in the transaction status record to a stable state when the search is confirmed to be completed, and return the final query result to the requester of the current query task.

[0131] Those skilled in the art will clearly understand that the component positioning module 220, condition filling module 230, filling verification module 240, transaction record module 250, automatic search module 260, and task feedback module 270 can be used to implement the above steps S1 to S6 respectively. For the sake of convenience and brevity, the specific working process of each module can be referred to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0132] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. The electronic device 300 includes a processor 310, a memory 320, and a bus 330, with the processor 310 connected to the memory 320 via the bus 330.

[0133] The memory 320 can be used to store software programs or firmware, for example, the software program or firmware corresponding to the automatic query device 200 described above. The processor 310 executes various functional applications and data processing by running the software program stored in the memory 320 to realize the automatic query method provided in the embodiments of the present invention.

[0134] The memory 320 may be, but is not limited to, RAM (Random Access Memory), ROM (Read Only Memory), FLASH (Flash Memory), PROM (Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electric Erasable Programmable Read-Only Memory), etc.

[0135] The processor 310 can be an integrated circuit chip with signal processing capabilities, capable of executing software programs, such as the software program corresponding to the aforementioned automatic query device 200. The processor 310 can be a general-purpose processor, including: CPU (Central Processing Unit), NP (Network Processor), SoC (System on Chip), etc.; it can also be: DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0136] Understandable. Figure 4 The structure shown is for illustrative purposes only; the electronic device 300 may also include components that are more advanced than those shown. Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown. Figure 4 The components shown can be implemented using hardware, software, or a combination thereof.

[0137] This invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the automatic query method disclosed in the above embodiments. The computer-readable storage medium can be, but is not limited to, various media capable of storing program code, such as a USB flash drive, portable hard drive, ROM, RAM, PROM, EPROM, EEPROM, FLASH, magnetic disk, or optical disk.

[0138] In summary, this invention provides an automatic query method, apparatus, electronic device, and storage medium. After obtaining the query requirement data for the current query task, at least one component to be populated is first identified on the target query page. Then, based on the query requirement data and the component type of each component to be populated, the native DOM layer state and the framework model layer state of each component to be populated are simultaneously updated to simulate the user's population operation on the target query page. Next, the latest state of each component to be populated is read back from the native DOM layer and the framework model layer, and cross-validated with the query requirement data. If the cross-validation passes, a transaction state record corresponding to the current query task is generated. Based on the transaction state record, after triggering a search, multi-level stability checks are performed on the result display area of ​​the target query page to confirm whether the search is complete. When the search is confirmed to be complete, the pending search mark in the transaction state record is removed, the transaction state in the transaction state record is updated to a stable state, and the final query result is returned to the requester of the current query task. This invention avoids search errors caused by outdated model components through cross-validation. Furthermore, by triggering searches through transaction status records and multi-level stability checks, it ensures that accurate search results are ultimately returned to the requester, rather than loading intermediate states, old tables, or empty results due to misjudgment.

[0139] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An automatic query method, characterized in that, The method, applied to an automated query system, includes: Obtain the query requirement data for the current query task; Based on the query requirement data, at least one component to be populated is identified on the target query page; Based on the query requirement data and the component type of each component to be populated, the native DOM layer state and framework model layer state of each component to be populated are updated simultaneously to simulate the user's population operation on each component to be populated on the target query page. After reading back the latest state of each component to be populated from the native DOM layer and the framework model layer respectively, cross-validation is performed with the query requirement data. If the cross-validation passes, a transaction status record corresponding to the current query task is generated; Based on the transaction status record, after the search is triggered, multi-level stability detection is performed on the result display area of ​​the target query page to confirm whether the search is complete; Upon confirmation that the search is complete, the pending search mark in the transaction status record is removed, the transaction status flag in the transaction status record is updated to a stable state, and the final query result is returned to the requester of the current query task.

2. The method according to claim 1, characterized in that, The query requirement data includes at least one specified field and its target value, and the target page context of the target query page; The step of determining at least one component to be populated on the target query page based on the query request data includes: Based on the context of the target page, the system redirects to display the target query page. Identify the filter area on the target query page; If the filter area is not fully expanded, an expansion operation is triggered, and after the filter area is fully expanded, a region status record of the filter area is generated. Multiple candidate controls are identified in the filtering area, and a control attribute record is generated for each candidate control; For each specified field, based on the control attribute record of each candidate control, the specified field and its target value, the component to be populated corresponding to the specified field is determined from multiple candidate controls.

3. The method according to claim 2, characterized in that, The control property record includes multiple property dimensions; The step of determining the component to be populated corresponding to the specified field from multiple candidate controls based on the control attribute record of each candidate control, the specified field and its target value, includes: Each candidate control is traversed sequentially, and the semantic matching score between each attribute dimension of the candidate control and the specified field is calculated. The semantic matching scores are then weighted and summed to obtain the semantic matching degree corresponding to the candidate control. Determine the format matching degree between the target value format of the specified field and the control type of the candidate control; Based on the affiliation relationship between the candidate control and the filtering area, the relationship bonus degree corresponding to the candidate control is determined; The penalty score corresponding to the candidate control is determined based on whether there are semantic conflicts between the various attribute dimensions of the candidate control and whether the candidate control has contradictory container affiliation. The semantic matching degree, format matching degree, relational bonus degree and penalty score corresponding to each candidate control are summed to obtain the comprehensive matching score between the candidate control and the specified field. The candidate control with the highest overall matching score that exceeds the set score threshold is selected as the component to be populated for the specified field.

4. The method according to claim 1, characterized in that, The query requirement data includes at least one specified field and its target value; The step of cross-validating the latest state of each component to be populated after reading back from the native DOM layer and the framework model layer with the query requirement data includes: For each component to be populated, the current DOM state of the component to be populated is read from the native DOM layer, and the network request triggered by the target query webpage after the population operation is completed is listened to in order to determine the current backend state of the component to be populated in the framework model layer. If the current DOM state and the current backend state of each component to be populated are consistent with the target value of the corresponding specified field, then the cross-validation is considered successful.

5. The method according to claim 1, characterized in that, The step of generating a transaction status record corresponding to the current query task if the cross-validation passes includes: If the cross-validation passes, a successful validation record is generated for each component to be populated; Based on the successful verification record of each component to be populated, a transaction status record corresponding to the current query task is generated.

6. The method according to claim 1, characterized in that, The step of performing multi-level stability checks on the result display area of ​​the target query page after triggering a search based on the transaction status record to confirm whether the search is complete includes: When the target to be searched in the transaction status record is true, locate the query button in the filter area corresponding to the region ID in the transaction status record. Initiate a click event on the query button to trigger a search, and simultaneously generate a search trigger record; Multi-level stability testing is performed on the result display area of ​​the target query page to confirm whether the search results are stable.

7. The method according to claim 6, characterized in that, The step of performing multi-level stability checks on the result display area of ​​the target query page to confirm whether the search is complete includes: Monitor the loading mask within the result display area of ​​the target query page, the current search request in the network request queue, and changes in the result display area to perform multi-level stability detection; When the loading mask disappears, the current search request is completed, the result display area meets the search stability conditions, and the transaction status record and the search trigger record meet the version consistency conditions, the multi-level stability detection ends and the search is confirmed to be complete. The search stability condition is that at least one search result appears in the result display area or the search result display area is empty.

8. An automated search device, characterized in that, The device, used in an automated query system, includes: The task receiving module is used to obtain the query requirement data for the current query task; The component location module is used to determine at least one component to be populated on the target query page based on the query requirement data. The conditional population module is used to update the native DOM layer state and framework model layer state of each component to be populated based on the query requirement data and the component type of each component to be populated, so as to simulate the user's population operation on each component to be populated on the target query page. The population validation module is used to read back the latest state of each component to be populated from the native DOM layer and the framework model layer respectively, and then perform cross-validation with the query requirement data. The transaction record module is used to generate a transaction status record corresponding to the current query task if the cross-validation passes. An automatic search module is used to perform multi-level stability checks on the result display area of ​​the target query page after triggering a search based on the transaction status record, in order to confirm whether the search is complete. The task feedback module is used to remove the pending search mark from the transaction status record and update the transaction status flag in the transaction status record to a stable state when the search is confirmed to be completed, and return the final query result to the requester of the current query task.

9. An electronic device, characterized in that, include: A memory and a processor, wherein the memory stores a software program, and the processor executes the software program to implement the method as described in any one of claims 1-7 when the electronic device is running.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1-7.

Images