A query configuration method and system

Abstract

The present disclosure provides a query configuration method and system, the method comprising: personalizing the basic query configuration template based on the context information of a first user to obtain a target query configuration template; parsing the target query configuration template into an executable structure through a policy-based rendering engine, and driving front-end component rendering to generate a target query interface according to the executable structure; in response to a query request initiated by the first user on the target query interface, assembling query parameters into a unified structure and initiating a query request to a target service; receiving a query result returned by the target service, normalizing the query result according to the result mapping rule of the basic query configuration template, and rendering and displaying the query result on the target query interface. The separation design of the configuration repository and the central field library realizes the large-scale reuse and fine control of the configuration, and the personalization of the query configuration is realized in combination with the static context and the dynamic context.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to a query configuration method and system. Background Technology

[0002] In enterprise software, especially in multi-tenant, frequently changing enterprise environments, efficient and flexible data querying is a core requirement. To improve development efficiency, configurability and low-code platforms are often used to build query interfaces. However, existing solutions have systemic technical shortcomings when dealing with complex enterprise scenarios, mainly manifested in the following ways: First, the design paradigm is misaligned, resulting in insufficient support for various scenarios. Existing platform architectures are mostly optimized for "form editing" scenarios, with their data flow and component models specializing in operations on single data entries. When applied to "query list" scenarios involving multi-condition assembly, pagination, sorting, and result set display, their inherent architecture struggles to support these processes, often requiring extensive secondary development to compensate, thus contradicting the initial goal of efficiency.

[0003] Second, the rigid configuration paradigm leads to reuse and maintenance challenges. The current mainstream "one page, one configuration" model results in a large amount of redundant configurations. The same business field needs to be defined repeatedly on different pages, making it difficult to ensure interaction consistency. Moreover, any change to any basic field will trigger a chain of modifications that affect the whole system, resulting in huge maintenance costs and a large scope of regression testing.

[0004] Third, the lack of dynamic adaptation capabilities makes it difficult to meet enterprise-level complexity. Existing solutions lack effective awareness of runtime context (such as tenants, roles, and data permissions), and cannot dynamically tailor and inject query configurations. To achieve differentiation, they can only rely on hard-coded or bloated conditional branches, which drastically degrades the readability and maintainability of the configuration. At the same time, the expressive power of standard query components is limited, making it difficult to support advanced business requirements such as fine-grained parameter mapping, complex linkages, and custom operators.

[0005] Fourth, the high degree of system coupling poses risks to integration and expansion. Platforms are typically tightly bound to specific technology stacks and backend protocols, leading to technology lock-in risks for enterprises. In heterogeneous service environments, the lack of a unified protocol adaptation layer necessitates frequent custom development to interface with different pagination and return structures, resulting in high integration costs.

[0006] Therefore, there is an urgent need in this field for an innovative query configuration scheme to systematically solve the above problems. Summary of the Invention

[0007] This application provides a query configuration method and system to solve the problems of poor configuration reusability, high maintenance costs, inability to flexibly adapt to multi-tenant and personalized scenarios, and tight coupling with heterogeneous backend services in the prior art.

[0008] Firstly, this disclosure provides a query configuration method, the method comprising: In response to the first user's trigger operation on the target query function item in the query interface, the basic query configuration template corresponding to the target query function item is obtained from the configuration repository; The basic query configuration template is personalized based on the context information of the first user to obtain the target query configuration template. The target query configuration template is parsed into an executable structure by a strategy-based rendering engine, and the front-end components are driven to render and generate the target query interface based on the executable structure. In response to the query request initiated by the first user on the target query interface, the input value of the query request is validated, normalized and assembled into query parameters with a unified structure, and a query request is initiated to the target service based on the query parameters with the unified structure. The system receives the query results returned by the target service, normalizes the query results according to the result mapping rules of the basic query configuration template, and renders and displays them on the target query interface.

[0009] According to a query configuration method provided in this disclosure, the configuration repository is used to store at least one query configuration template designed by the configurator. Each query configuration template includes at least a template name, a configuration identifier, a list of query fields, inter-field linkage rules, validation rules, and result mapping rules.

[0010] According to a query configuration method provided in this disclosure, the context information includes static context information and dynamic context information; the step of personalizing the basic query configuration template based on the context information of a first user to obtain a target query configuration template includes: obtaining a corresponding configuration coverage fragment from the coverage rule base based on the static context information, and overlaying and merging the basic query configuration template with the configuration coverage fragment to generate a primary query configuration template; and adjusting the primary query configuration template in real time based on the dynamic context information to generate a target query configuration template, wherein the real-time adjustment includes at least permission changes, interactive predictive optimization, and resource status adaptive routing.

[0011] According to a query configuration method provided in this disclosure, the real-time adjustment includes permission changes. The step of adjusting the primary query configuration template in real time based on the dynamic context information to generate a target query configuration template includes: listening to permission change event streams related to the first user during a first user session; when a permission change event stream is detected, performing invalidation processing on the event-related fields in the primary query configuration template, wherein the invalidation processing includes applying an invisible state, applying a disabled state, or directly removing the field.

[0012] According to a query configuration method provided in this disclosure, the real-time adjustment includes interactive predictive optimization. The step of adjusting the primary query configuration template in real time based on the dynamic context information to generate a target query configuration template includes: collecting the historical session behavior trajectory of a first user to form a historical behavior sequence; predicting the query intent of the first user based on statistical analysis of the historical behavior sequence; and optimizing the layout of query fields and / or filling in the values ​​of query fields according to the query intent.

[0013] According to a query configuration method provided in this disclosure, the real-time adjustment includes resource status adaptive routing. The step of adjusting the primary query configuration template in real time based on the dynamic context information to generate a target query configuration template includes: real-time monitoring of system resource status; when an abnormal system resource status is detected, automatically updating the routing path of subsequent query requests and restricting high-load query operations allowed to be executed in the primary query configuration template.

[0014] According to a query configuration method provided in this disclosure, the configuration coverage fragments include tenant coverage fragments, role coverage fragments, and user coverage fragments. The step of overlaying and merging the basic query configuration template with the configuration coverage fragments to generate a primary query configuration template includes: overlaying and merging the configuration coverage fragments with the basic query configuration template in order of priority to generate a primary query configuration template.

[0015] According to a query configuration method provided in this disclosure, the configurator includes: a drag-and-drop field panel for selecting standardized business fields as query fields from a central field library; an attribute panel for configuring the attributes of the query fields; and a linkage rule panel for defining the interaction logic between the query fields.

[0016] According to a query configuration method provided in this disclosure, a query configuration template is designed by a configurator, specifically including: in response to a second user's click operation on the configurator, displaying a configuration interface, the configuration interface displaying a field panel, an attribute panel, a linkage rule panel, and a design area; in response to the second user's operation of moving a target field from the field panel to the canvas area, determining the query field of the query configuration template; in response to the second user's input operation in the attribute panel, obtaining the attribute information of the query field; in response to the second user's input operation in the linkage rule panel, obtaining the linkage rule information of the query field; in response to the second user's save operation, saving the query configuration template in draft state to the configuration repository; and in response to the second user's publish operation, changing the status of the approved query configuration template from draft state to publish state.

[0017] Secondly, this disclosure also provides a query configuration system, the system comprising: The template acquisition module is used to retrieve the basic query configuration template corresponding to the target query function item from the configuration repository in response to the first user's trigger operation on the target query function item in the query interface. The personalized configuration module is used to personalize the basic query configuration template based on the context information of the first user to obtain the target query configuration template. The interface rendering module is used to parse the target query configuration template into an executable structure through a strategy-based rendering engine, and drive the front-end components to render and generate the target query interface based on the executable structure. The unified query module is used to respond to the query request initiated by the first user on the target query interface, to validate and standardize the input value of the query request and assemble it into query parameters with a unified structure, and to initiate a query request to the target service based on the query parameters with the unified structure. The results display module is used to receive the query results returned by the target service, normalize the query results according to the result mapping rules of the basic query configuration template, and render and display them on the target query interface.

[0018] In summary, the query configuration method and system disclosed herein, by introducing a separate design for the configuration repository and the central field library, combined with a static context layered overriding mechanism, achieves dual reuse at the field and template levels, fundamentally solving the problems of configuration redundancy and high maintenance costs. Through a dynamic context real-time processing mechanism, the system possesses the capabilities of real-time permission response, behavior prediction optimization, and adaptive resource scheduling, significantly improving system security, robustness, and user experience. The strategy-based rendering engine and pluggable strategy library decouple business logic from interaction implementation, greatly improving system scalability. The design of a unified parameter model and protocol mapping library completely decouples the front-end and back-end, enabling the system to adapt to various heterogeneous back-end services at low cost. Attached Figure Description

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

[0020] Figure 1 This is a flowchart illustrating a query configuration method provided in this disclosure; Figure 2 This is a flowchart illustrating a method for designing query configuration templates provided in this disclosure; Figure 3This is a flowchart illustrating a method for personalizing a basic query configuration template provided in this disclosure; Figure 4 This is a schematic diagram of the structure of a query configuration system provided in this publication. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0022] Figure 1 This is a flowchart illustrating a query configuration method provided in this disclosure. See also... Figure 1 The method includes: Step S11: In response to the first user's trigger operation on the target query function item in the query interface, obtain the basic query configuration template corresponding to the target query function item from the configuration repository.

[0023] Specifically, the target query function item refers to one of the entry points for different query functions provided to the user on the query page. The entry point for a query function can be displayed as a sub-menu corresponding to the navigation bar, such as the main navigation bar "Customer Management" with sub-menus like "All Customers" and "High-Value Customer Query," or it can be displayed as a toolbar, such as a query toolbar set on the query page based on the template names corresponding to each query configuration template in the configuration repository. This disclosure does not limit this. The triggering operation refers to the click operation on the target query function item, and each target query function item corresponds to and is bound to a query configuration template.

[0024] In some embodiments, the step of responding to a first user's triggering operation on a target query function item in the query interface, and obtaining a basic query configuration template corresponding to the target query function item from the configuration repository, specifically includes: Step S111: In response to the first user's trigger operation on the target query function item in the query interface, obtain the configuration identifier corresponding to the target query function item.

[0025] Step S112: Obtain the query configuration template corresponding to the configuration identifier from the configuration repository as the basic query configuration template based on the configuration identifier.

[0026] The configuration repository is used to store at least one query configuration template designed by the configurator. Each query configuration template includes at least a template name, a configuration identifier, a list of query fields, inter-field linkage rules, validation rules, and result mapping rules.

[0027] The template name refers to the name defined when creating each query configuration, such as "High-Value Customer Query", which is mainly used to intuitively understand the purpose of each query configuration template.

[0028] The configuration identifier is a unique identifier for the query configuration template. Generally, during the configuration design phase, the creator assigns a unique configuration identifier to each query configuration template, such as vip_customer_search. The system can quickly locate the corresponding query configuration template by reading the configuration identifier.

[0029] The query field list refers to all fields included in each query configuration template. Each field references a standard business field in the central field library, and its local attributes can be overridden at the template level. The central field library is used to store and manage the metadata of all business fields. The query field list is used to determine the query content that each query configuration template needs to present on the query page, such as fields like order number, order amount, and creation time, as well as fields like keywords, status, asset region cascading, and creation time.

[0030] The inter-field linkage rules refer to the business rules governing the dynamic dependencies between fields. They are typically described using the "event-condition-action" paradigm. For example, the asset region cascading corresponds to a three-level linkage of organization, city, and department. When the organization changes, the lower-level cities and departments need to be automatically refreshed.

[0031] The aforementioned verification rules are used to check the reasonableness of the input or selected values ​​corresponding to the query fields in each query configuration template, in order to ensure the smooth operation of the business process. These rules pertain to the business scenario. For example, they check whether the "order amount" meets the requirements of the "delivery method" and whether the "discount rate" falls within the authorized range of the "customer level".

[0032] The result mapping rules define a standard format for mapping query results to the target query page, serving as a key mechanism for decoupling front-end query logic from heterogeneous back-end services. The result mapping rules include at least declarative configuration of list data paths and total count paths.

[0033] Step S12: Based on the context information of the first user, the basic query configuration template is personalized to obtain the target query configuration template.

[0034] Specifically, it is understandable that traditional query configurations generally use fixed query templates to query and display data. However, as business scenarios change, fixed templates can no longer meet the diverse needs of users. If different query templates are set directly according to user needs, complex program code needs to be rewritten or modified. Therefore, this disclosure proposes a method for personalized processing based on basic query configuration templates. Without touching the core field definitions, the most appropriate query interface is customized for different business scenarios to meet the personalized needs of each business scenario.

[0035] The context information refers to the user information of the first user, and the context information includes static context information and dynamic context information.

[0036] The static context information refers to the attributes of the first user that remain basically unchanged during the query process. Generally, it is determined when the user logs into the system. The static information includes at least the tenant identity, role identity, and user identity. The tenant identity refers to the organization to which the first user belongs, the role identity refers to the responsibilities of the first user in the organization, and the user identity refers to the unique identifier of the first user in the system. For example, the tenant identity of the first user is XX Company, the role identity is Sales Manager, and the user identity is Zhang San.

[0037] The dynamic context information includes at least real-time permission change events, historical session behavior trajectories, and system resource status. This dynamic context information generally needs to be monitored in real time during the first user's query session.

[0038] The real-time permission change event refers to the immediate adjustment of a user's permissions during the first user query session. In other words, the user's data access permissions are adjusted in real time by the administrator or triggered by security policies. For example, the administrator revokes a user group's viewing permission for the "cost price" field in the background.

[0039] The historical session behavior trajectory refers to the query behavior of the first user over a period of time. The historical session behavior trajectory includes at least: query condition operations, query execution actions, or operations to adjust query results. For example, a user used the "Sales Order Analysis" query function in the past 10 minutes, selecting consumer electronics as the product category, East China as the region, and this month as the mentioned month.

[0040] The system resource status refers to the health and performance indicators of the underlying data sources and services of the system, including the status of the target data source and the status of the backend services. It is mainly used to judge the system stability and ensure that the query is performed normally. For example, when a company is conducting year-end settlement, a large number of financial staff execute complex report queries at the same time, which puts a huge pressure on the main database, making the system resource status tense.

[0041] Specifically, it can also be understood that the personalization of the basic query configuration template based on the context information of the first user to obtain the target query configuration template includes: obtaining the corresponding configuration coverage fragment from the coverage rule base based on the static context information, and overlaying and merging the basic query configuration template with the configuration coverage fragment to generate a primary query configuration template; and adjusting the primary query configuration template in real time based on the dynamic context information to generate the target query configuration template, wherein the real-time adjustment includes at least permission changes, interactive predictive optimization, and resource status adaptive routing.

[0042] Step S13: The target query configuration template is parsed into an executable structure by the strategy-based rendering engine, and the front-end component is driven to render and generate the target query interface according to the executable structure.

[0043] Specifically, it can be understood that after obtaining the target query configuration template, it needs to be further rendered and displayed, that is, the declarative query configuration is converted into a user-interactive query interface. The executable structure is an abstract syntax tree, and the strategy-based rendering engine is a runtime, rule-based interpreter and coordinator. The strategy-based rendering engine injects interactive logic into the interface by loading and executing predefined strategies from a pluggable strategy library. The pluggable strategy library is an independently stored, uniformly managed, dynamically loaded and executed collection of strategies. The predefined strategies include at least: component mapping strategy, linkage strategy, validation mounting strategy, and style layout strategy.

[0044] The component mapping strategy is used to automatically and accurately map the basic data type of a field to the most suitable UI interaction component. The linkage strategy uses the "event-condition-action" paradigm to describe the linkage logic between fields. That is, the linkage strategy responds to the "value change" interaction event of the source field and executes the condition judgment logic; if the judgment result is that the source field has a valid value, one or more actions are executed to change the state of other fields.

[0045] The validation mounting strategy dynamically assembles and mounts the corresponding validation functions to the front-end form instance based on the validation rules described in the target query configuration template. Validation functions include mandatory field validators and format matching validators.

[0046] The style layout strategy automatically generates an interface layout with good visual hierarchy and responsiveness based on the attribute information in the target query configuration template. That is, the style layout strategy reads information such as placeholders, arrangement order, and grouping information to drive the front-end layout component to render. The front-end layout can be Row, Col, Card, etc.

[0047] In the above method, through the coordinated operation of four strategies, the strategy-based rendering engine transforms static configuration data into a dynamic query interface with rich interactivity, rigorous validation, and a user-friendly layout. This strategy-based, pluggable architecture enables the system to maintain powerful functionality while possessing extremely high scalability and maintainability.

[0048] Step S14: In response to the query request initiated by the first user on the target query interface, the input value of the query request is validated, normalized and assembled into query parameters with a unified structure, and a query request is initiated to the target service based on the query parameters with the unified structure.

[0049] Specifically, it is understandable that due to the inherent protocol heterogeneity between the front-end query interface and the back-end data service, and the fact that the front-end can easily cause back-end service errors by sending unverified or incorrectly formatted parameters directly to the back-end, this disclosure proposes to construct parameters with a unified structure as an intermediate data structure to decouple the front-end interaction from the back-end protocol in order to achieve complete decoupling from the back-end. The front-end does not need to care about the differences in back-end interfaces, and does not need to modify the core query processing logic and interface components of the front-end when connecting to different back-end services. It only needs to add a set of conversion rules.

[0050] Specifically, it can be understood that step S14 includes the following steps: Step S141: In response to the query request initiated by the first user on the target query interface, the input value of the query request is validated.

[0051] In step S13, after obtaining the rendered target query interface, the first user can initiate a query request by entering or selecting a query item in the query field. Upon receiving the first user's query request, the input value needs to be validated, including but not limited to mandatory field validation, format validation, and logical validation. Mandatory field validation checks whether a required field already contains an input value. Format validation checks whether the application format corresponding to the field is correct, such as whether the value of the order amount field is a valid number greater than 0. Logical validation performs cross-field business logic validation, such as ensuring that the "end date" is not earlier than the "start date".

[0052] Step S142: If the verification is successful, the successful input values ​​are normalized and assembled into query parameters with a unified structure.

[0053] The normalization process includes at least: null value removal, date range splitting, keyword cleaning, or debouncing. Null value removal refers to identifying and removing leading and trailing spaces or empty strings to avoid sending meaningless query conditions to the backend. Date range splitting refers to splitting a single composite value into two independent query conditions. Keyword cleaning involves performing cleaning logic on the input text to remove special characters that may cause semantic confusion in the query. Debouncing involves introducing a short delay for frequently triggered input fields; the system does not immediately initiate a query request after each key press. Only after the user has stopped inputting for more than this delay is the final input value collected, normalized, and the query initiated.

[0054] Taking the three-level cascade of keywords (keyword), status (status), asset region (orgId), city (cityId), department (deptId), and creation time (createdAt) as an example, the first user entered "router" in the keyword field, selected "in use" and "under repair" for the status, selected 1001, 3101, and 5002 for the organization, city, and department respectively, and selected [2024-01-01, 2024-01-31] ​​for the creation time. Then, the input values ​​are normalized: the operator for the keyword field is "include", resulting in keywordLike="%router%"; the operator for the status field is "within...", resulting in statusIn="in_use, repair"; the three-level cascade of the asset region field is normalized to {1001, 3101, ...}. 5002}; After normalization, the creation time field is split into a start time createdAtStart="2024-01-01" and a end time createdAtEnd="2024-01-31".

[0055] Step S143: Initiate a query request to the target service based on the query parameters of the unified structure.

[0056] Specifically, the target service refers to the API interface of a backend service, such as a specific microservice API or an API from an external vendor. For the target service, firstly, the corresponding protocol conversion rules are retrieved from the protocol mapping library based on the target service's unique identifier. Then, a protocol converter is used to convert the unified query parameters into the specific input parameter format required by the target service according to the protocol conversion rules. This conversion includes field name mapping, operator mapping, data structure reorganization, and protocol command generation. Finally, the converted specific input parameters are used to initiate a query request to the configured service endpoint through the communication protocol and transmission method required by the target service.

[0057] Step S15: Receive the query results returned by the target service, normalize the query results according to the result mapping rules of the basic query configuration template, and render and display them on the target query interface.

[0058] Specifically, it can be understood that after the system sends a query request to the target service, the query results need to be processed and displayed to present the data to the user in a standardized manner. The result mapping rules include at least a declarative configuration of the list data path and the total count path, which are converted into a unified structure of {list, total, extra} according to the result mapping rules. The list field is defined as an ordered set used to hold the query result data records under the current pagination; the total field is defined as an integer value used to hold the total number of all records that meet the current query conditions, and its value is crucial for the correct calculation and rendering of the front-end pagination component; the extra field is defined as an optional key-value pair object used to hold extended metadata or auxiliary information that is not part of list and total but is related to the current query context. The design of this field provides the necessary system extensibility while maintaining the stability of the core data structure.

[0059] In some embodiments, the `extra` field can be used to transmit business status identifiers that affect front-end interaction logic. For example, an identifier that notifies the front-end interface that the current query result is in the export state, thereby triggering specific rendering logic. The `extra` field can also be used to transmit query context information or return additional information related to the query behavior itself, such as the identifier of the database copy actually used in this query, which facilitates subsequent auditing and diagnosis. The `extra` field can also maintain protocol neutrality. By uniformly including various additional information returned by different back-end services within the `extra` object, it effectively avoids polluting or frequently modifying the structure of the unified model due to the special return values ​​of individual services, ensuring the long-term stability of the core interaction protocol.

[0060] The above query configuration method, by introducing a separate design for the configuration repository and the central field library, combined with a static context layered overriding mechanism, achieves dual reuse at the field and template levels, fundamentally solving the problems of configuration redundancy and high maintenance costs. Through a dynamic context real-time processing mechanism, the system possesses real-time permission response, behavior prediction optimization, and resource adaptive scheduling capabilities, significantly improving system security and stability. The strategy-based rendering engine and pluggable strategy library decouple business logic from interaction implementation, greatly improving system scalability. The design of a unified parameter model and protocol mapping library completely decouples the front-end and back-end, enabling the system to adapt to various heterogeneous back-end services at low cost.

[0061] Figure 2This is a flowchart illustrating a method for designing query configuration templates provided in this disclosure. Query configuration templates are stored in a configuration repository, each designed by a second user using a query configurator. Since the design goal of the query configuration templates is not to meet all requirements but rather to establish immutable business semantics and a scalable structural framework, in order to achieve efficient reuse of the query configuration templates—that is, to ensure that each query configuration template in the configuration repository is a core and reusable template—this disclosure designs query configuration templates for different business scenarios. A query configuration template is designed for the most frequent and core business scenarios, and this template contains a minimal complete set of fields.

[0062] Business scenarios can be divided according to core business entities, such as customer list queries, product list queries, employee list queries, order list queries, contract list queries, work order list queries, invoice list queries, and expense report list queries. The core fields for customer list queries include customer name, customer status (potential / interested / completed), customer level, customer source, industry, creation time, and customer owner. The core fields for product list queries include product name, product category, product status, price range, and creation time. The core fields for employee list queries include name, employee ID, department, position, start date, and employee status (employed / departed). The core fields for order list queries include order number, order details, and order type. The core fields for querying the contract list include: status (pending payment / shipped / completed), order time, order amount, customer name, and recipient. For the contract list, the core fields include contract number, contract status (under review / effective / expired), contracted customer, contract amount, effective date, and expiration date. For the work order list, the core fields include work order title, work order status (pending / processing / closed), priority, creator, processor, and deadline. For the invoice list, the core fields include invoice number, invoice status (issued / voided), invoice date, amount, and buyer name. For the expense report list, the core fields include expense report number, claimant, claiming department, expense report status (pending approval / paid), expense amount, and submission time.

[0063] Business scenarios can also be categorized by user tasks, such as simple list queries, advanced search queries, to-do queries, and statistical analysis queries. Simple list queries are primarily used for quick location and daily viewing; for example, a "Quick Customer Query" template might only include customer name, customer status, and customer owner. Advanced search queries are used for complex filtering and precise location, meeting the needs of data analysis and in-depth investigation. For example, a "Customer Advanced Search" template requires adding over a dozen fields such as creation time range, last follow-up time, customer level, and industry to the simple list. To-do queries include "My Pending Approval Orders" and "My Pending Work Orders." Statistical analysis queries are used for decision support and business insights, with fields focusing more on time range, statistical dimensions (such as categorization by region or product line), and metrics. For example, the core fields of a "Sales Performance Analysis Query" template are statistical time range, sales department, product line, and customer region.

[0064] The design methodology for query configuration templates across different business scenarios is the same: the query configuration template is designed by the configurator. For details, refer to... Figure 2 The method for designing query configuration templates by the configurator, that is, the method for designing query configuration templates, specifically includes the following steps: Step S21: In response to the second user's click operation on the configurator, the configuration interface is displayed, which displays a field panel, an attribute panel, a linkage rule panel, and a design area.

[0065] Specifically, the configurator refers to a web tool for creating or editing query configurations, which can only be accessed by users with administrator privileges. When an administrator logs into the configurator, they can set different query configuration templates for different business scenarios to ensure that the query configuration template for each business scenario is a functionally cohesive business unit.

[0066] The second user refers to a user with configuration permissions. The configurator includes: a field panel for selecting standardized business fields from a central field library as query fields; an attribute panel for configuring the attributes of the query fields; and a linkage rules panel for defining the interaction logic between query fields.

[0067] The configuration interface displays a field panel, an attribute panel, a linkage rules panel, and a canvas area. The layout of the field panel, attribute panel, linkage rules panel, and design area is generally a classic three-panel design, with the field panel on the left, the attribute panel and linkage rules panel on the right, and the design area in the middle. However, other layouts can be adjusted according to the actual interface size, and this disclosure does not limit this.

[0068] The field panel displays standardized business fields from the central field library. In other words, all fields displayed in the field panel can be dragged and dropped from the central library, eliminating the need to repeatedly define the same field for different pages. Furthermore, when the metadata of a field changes, the query configuration template referencing that field will automatically change accordingly, achieving global effect from a single modification.

[0069] The canvas area is used to display the fields that the second user drags from the field panel. The second user can adjust the dragged fields in the canvas area and also view the layout effect in real time.

[0070] The attribute panel is used to configure detailed attributes of the target field in the canvas area specified by the second user, including but not limited to display attributes, behavior attributes, operation attributes, visibility attributes, required attributes, disabled attributes, or component attributes. Among them, the display attribute refers to the placeholder, sorting order, and grouping information of the field in the query configuration template; the behavior attribute refers to one of the operation behaviors of equal to, not equal to, or fuzzy matching corresponding to each operator drop-down box; the visibility attribute refers to whether the field is displayed by default in the query configuration template; the required attribute refers to whether the field is a required field in the query configuration template; and the component attribute is used to determine the component type corresponding to the field when it is rendered. The component type can be an input box, a drop-down selection box, a date picker, etc. For example, for a field whose basic data type is "date", it is necessary to further select whether to use a date picker or a month picker.

[0071] The linkage rules panel is used to define dynamic interaction behaviors between different fields. That is, when the value of a certain field changes, a series of predefined actions will be automatically triggered, thereby changing the state or data of other fields. For example, the field "Asset Region Cascade" corresponds to a three-level linkage of organization, city, and department. When the organization changes, the lower-level cities and departments need to be automatically refreshed.

[0072] Step S22: In response to the second user's operation of moving the target field from the field panel to the canvas area, determine the query field of the query configuration template.

[0073] Specifically, the target field is any field displayed in the field panel, and all fields displayed in the field panel are defined by the central field library. Alternatively, a user can directly select a field displayed in the field panel and drag it to the canvas area to select the query field.

[0074] The central field library stores and manages the metadata of all business fields, which includes the specific definitions of all business fields, including but not limited to field names, basic data types, default operators, dynamic data sources or enumeration values, and basic validation rules. Field names are the names of the fields; basic data types include String, Number, Date, and Enumeration; default operators refer to the restrictions on operators for each field; and basic validation rules refer to the basic validation methods for fields to ensure that the "legitimacy" of the value of each field is consistent everywhere, guaranteeing absolute data validity and global consistency.

[0075] For example, the metadata stored in the central field library for a certain field includes: field name "Customer Status", basic data type is enumeration, and enumeration values ​​are intention, transaction, and loss; default operator is that the field is allowed to use "equal to" or "belong to one of them", but not "greater than" or "less than"; basic validation rules, for example, the basic validation rule for the field "Order Amount" is that the field value, that is, the order amount, must be a number greater than zero.

[0076] More specifically, when dragging and dropping fields within the field panel, the "minimum complete set" principle must be followed. This means that the query fields for each query configuration target must meet two conditions: minimization and completeness. Minimization means including only the fields essential for completing the core task of the scenario, avoiding an overabundance of fields that leads to a complex interface. Completeness means that the combined query fields must cover more than 80% of the query requirements in the scenario. When designing query configuration templates for different business scenarios, the fields selected for the template can be chosen sequentially based on core identifiers, status and category, key time, important related information, and explicit exclusion. For example, when designing a "customer list query" template, the core is the customer. The core identifier fields must include at least customer ID and customer name. The status and category fields must include customer status, customer level, and customer source. The key time fields must include creation time and last follow-up time. Important related information refers to customer list related information, which can include the industry to which the field belongs and customer owner information. Explicit exclusions include annual sales revenue belonging to the analysis scenario and detailed addresses belonging to the details view.

[0077] Step S23: In response to the input operation of the second user in the attribute panel, obtain the attribute information of the query field.

[0078] Specifically, clicking on any query field in the canvas area allows you to set the attribute information for that query field in the properties panel. The attribute information for the query field includes, but is not limited to: display attributes, behavior attributes, operation attributes, visibility attributes, required attributes, disabled attributes, or component attributes.

[0079] Step S24: In response to the input operation of the second user on the linkage rule panel, obtain the linkage rule information of the query field.

[0080] Specifically, the linkage rule information of the query fields refers to the business rules of the dynamic dependency relationship between query fields. For example, the asset region cascading corresponds to the three-level linkage of organization, city, and department. When the organization changes, the lower-level cities and departments need to be automatically refreshed.

[0081] In some embodiments, the configurator further includes a result mapping rule configuration panel. After step S24, the method further includes: in response to the second user's input operation on the result mapping rule configuration panel, obtaining the result mapping rule for the query field. The result mapping rule configuration panel is used to receive declarative path extraction rules input by the user, and the result mapping rule includes defining the root path of the data list, the pagination information path, and specifying the value path of each output field in the data entry. The system uses a mapping testing tool to allow the user to verify the correctness of the mapping rules based on sample data, thereby generating a result mapping configuration that drives the unified normalization engine and is bound to a specific backend service protocol.

[0082] Step S25: In response to the second user's save operation, the query configuration template is saved to the configuration repository in draft state; in response to the second user's publish operation, the status of the approved query configuration template is changed from draft state to publish state.

[0083] Specifically, the query interface also has a save button. Clicking the save button will save the current configuration content as a query configuration template, and at the same time determine the template name and configuration identifier of the query configuration template. The template name is mainly used to intuitively understand the purpose of each query configuration template. It can be defined when saving the template or when creating a new template. For example, the template name is "High Value Customer Query" and the configuration identifier is vip_customer_search.

[0084] Each saved query configuration template is saved to the configuration repository in draft status. After testing and approval, a second user can publish the draft query configuration template by clicking the publish button. After publishing the query configuration template, a new version number is created, and its status is changed from draft to published. The published query configuration template is then available for front-end use. Through testing and approval, risk isolation and technical controllability of configuration changes are achieved. If a problem is found in a newly published query configuration template, the administrator can immediately roll back the system to the previous version or any previous version. In other words, versioning management further ensures smoothness and rollback capability in deployments.

[0085] The aforementioned method for designing query configuration templates achieves a fundamental innovation in enterprise-level query configuration through a collaborative architecture between a visual configurator and a central field library. The central field library atomically encapsulates business fields, ensuring semantic consistency across the platform and enabling "define once, reuse everywhere," eliminating configuration redundancy at its source and significantly reducing maintenance costs. The three-panel configurator supports the rapid construction of complex query scenarios through drag-and-drop operations and declarative rule configuration, greatly improving the response efficiency to diverse multi-tenant requirements. Version management provides complete historical traceability for configurations, supporting one-click rollback when query configuration templates encounter problems. This integrated version control and release review process makes configuration changes as controllable as code releases, perfectly balancing the convenience of low-code with the rigor of enterprise-level governance, providing core assurance for stable system operation.

[0086] Figure 3 This is a flowchart illustrating a method for personalizing a basic query configuration template, as provided in this publication. (Refer to...) Figure 3 The step of personalizing the basic query configuration template based on the context information of the first user to obtain the target query configuration template includes: Step S31: Based on the static context information, obtain the corresponding configuration coverage fragment from the coverage rule base, and overlay and merge the basic query configuration template with the configuration coverage fragment to generate a primary query configuration template.

[0087] Specifically, it is understood that the static information includes at least tenant identity, role identity, and user identity. The coverage rule base stores configuration coverage fragments bound to the static context information. The configuration coverage fragments include tenant coverage fragments, role coverage fragments, and user coverage fragments. After obtaining the static context information of the first user, the corresponding tenant coverage fragments, role coverage fragments, and user coverage fragments can be automatically loaded directly based on the first user's tenant identity and role identity.

[0088] Specifically, it can also be understood that tenants can disable irrelevant functions and set default values ​​that conform to their own business; enterprises can further refine the control of permissions and functions based on employee responsibilities on the basis of tenant customization; in addition, fine-tuning can be carried out at the user level, that is, providing temporary permissions or personalized interfaces for specific users to meet extreme personalized needs, while keeping permissions controllable.

[0089] For example, the basic query configuration template for "Advanced Customer Search" includes fields such as customer name, industry, credit rating, annual income, last contact time, and customer acquisition cost. However, Tenant A's business model primarily focuses on the financial industry and doesn't prioritize customer acquisition cost. Therefore, a tenant overlay segment, "Tenant A hides the customer acquisition cost field," is provided for Tenant A. Salesperson B, whose role is salesperson, can only see customers they created and doesn't require complex credit rating queries. Therefore, a role overlay segment, "Salesperson B of Tenant A is prohibited from using the credit rating field," is provided for Salesperson B. Salesperson B is a senior employee granted permission by the administrator to view "Customer Acquisition Cost" for analysis purposes. Therefore, a user overlay segment, "Show Customer Acquisition Cost Field," is provided for Salesperson B. When personalizing the process for Salesperson B, the system merges the basic query configuration template and the three overlay segments according to the priority order: User > Role > Tenant > Basic Query Configuration Template. The user overlay segment overrides the hidden customer acquisition cost field setting in the tenant overlay segment.

[0090] In some embodiments, the step of overlaying and merging the basic query configuration template with the configuration coverage fragments to generate a primary query configuration template includes: overlaying and merging the configuration coverage fragments with the basic query configuration template sequentially according to their priority to generate a primary query configuration template. The priority of the configuration coverage fragments is: user coverage fragment > role coverage fragment > tenant coverage fragment.

[0091] Step S32: Based on the dynamic context information, the primary query configuration template is adjusted in real time to generate the target query configuration template. The real-time adjustment includes at least permission changes, interactive predictive optimization, and resource status adaptive routing.

[0092] The initial query configuration template is a query configuration template that conforms to the user identity of the first user and the company's regulations. However, in the actual query process, each user's query habits are different. In order to make the query configuration template more closely match individual work habits, this disclosure proposes to further obtain dynamic context information for personalized optimization. The dynamic context information includes at least real-time permission change events, historical session behavior trajectories, and system resource status.

[0093] Specifically, it is understandable that the permission checks in the existing technology have permission blind spots. If the administrator revokes the permission of the first user during the use of the device, the first user can still operate on sensitive data on the page that the user has opened. In order to solve the security risks caused by the change of permissions over time, this disclosure can immediately and proactively disable or hide functions that the first user does not have permission to access on the current interface at the moment the administrator revokes the permission by listening to permission change events in real time.

[0094] When the dynamic context information includes real-time permission change events, the real-time adjustment includes permission changes. In this case, the step of generating a target query configuration template by real-time adjustment of the primary query configuration template based on the dynamic context information includes: Step a1: Listen for permission change event streams related to the first user during the first user session.

[0095] Specifically, the first user session refers to the query process of the first user. When the first user successfully accesses the system, the system will create the first session for him / her and establish a long-term subscription connection with the unified permission service center in order to receive fine-grained permission change events.

[0096] Step a2: When a permission change event stream is detected, invalidation processing is performed on the event-related fields in the primary query configuration template. The invalidation processing includes applying an invisible state, applying a disabled state, or removing them directly.

[0097] Specifically, the invalidation processing of event-related fields in the primary query configuration template can be performed according to preset strategies and security levels. For example, when the data sensitivity requirements are relatively low or the interface layout needs to be kept stable, the invisible state is applied; when it is necessary to clearly prompt the user that the field exists but is currently unavailable or the field is visible but cannot be interacted with, the disabled state is applied; when the data security requirements are extremely high, or the existence of the field itself is confidential, the field is directly removed.

[0098] Specifically, it can also be understood that users may not be able to or are unwilling to set overly precise conditions at the time of initial query. They generally tend to use broad query conditions for exploratory queries and then process the query results to gradually narrow down the scope. In order to avoid the information gap between the user's true query intent and the current query intent, the user's potential query intent can be predicted by collecting and analyzing the user's historical behavior trajectory, and the query prediction can be optimized based on the potential query intent.

[0099] When the dynamic context information includes historical session behavior trajectories, the real-time adjustment includes interactive predictive optimization. In this case, the real-time adjustment of the primary query configuration template based on the dynamic context information to generate the target query configuration template includes: Step b1: Collect the historical session behavior trajectory of the first user to form a historical behavior sequence.

[0100] The historical session behavior trajectory includes at least: query condition operations, query execution actions, and query result adjustment operations. Query condition operations refer to the user's actions of setting filter conditions for query fields on the query page before executing a query, including changing the selected value, input value, or operator of the field. For example, changing the input content of the "Customer Name" field or the operator of the "Customer Status" field from "equal to" to "not equal to". Query execution actions refer to the user's actions of triggering and interacting with the query, such as clicking the query button to initiate a query, or clicking the reset button to reset the query. Query result adjustment operations refer to further operations performed by the user on the results after the results list is rendered, including sorting and filtering operations. Sorting operations include arranging the "Last Follow-up Time" field in descending order of time, and filtering operations include selecting only "Internet" and "Fintech" for the "Industry" field.

[0101] Step b2: Based on the statistical analysis of the historical behavior sequence, predict the query intent of the first user.

[0102] The statistics include, but are not limited to, frequency statistics and association rule analysis. The query intent refers to the query strategy adopted by the first user to complete any query business, including the specific fields, operators and field values ​​used.

[0103] In some embodiments, the statistical analysis includes frequency statistics, which refers to calculating the frequency of occurrence of each field, operator, and specific value based on the historical behavior sequence. In this case, predicting the query intent of the first user based on the statistical analysis of the historical behavior sequence can be done by predicting the first user's query intent based on the frequency of field usage. For example, if the historical behavior sequence includes 100 sessions in the past 30 days where the first user used the query configuration template "Customer List," and if the usage frequency of the fields "Customer Level" and its value "VIP" is as high as 90% in these 100 sessions, and the usage frequency of "Last Follow-up Time" and its value "Last 7 Days" is as high as 90%, then it can be predicted that the first user's query intent is to view the follow-up status of the VIP customers they are responsible for in the last 7 days.

[0104] In other embodiments, the statistical analysis includes association rule analysis, which refers to analyzing the probability that different combinations of conditions for the first user will co-occur in the same query session based on the historical behavior sequence. In this case, predicting the first user's query intent based on the statistical analysis of the historical behavior sequence can be achieved by predicting the first user's query intent based on association analysis of condition combinations. For example, if there is an 85% probability that the field "Contract Amount" is greater than or equal to 1 million when the field "Industry" is finance, then it can be predicted that the first user's query intent is to filter high-value contracts.

[0105] Step b3: Based on the query intent, optimize the layout of the query fields and / or fill in the values ​​of the query fields.

[0106] The optimization of the layout of query fields, for example, for a salesperson user, the query intent indicates that there is a 90% probability that they will use the "customer name" and "last contact time" fields in this query, while there is only a 10% probability that they will use the "contract amount" field. At this time, the system will drive the front-end rendering engine to render the high-priority fields in the core area of ​​the first screen of the query form or the default expanded area, while placing the low-priority fields in the collapsed area or sorting them to the back.

[0107] The values ​​entered into the query fields are determined based on the query intent, and the predicted field values ​​are written into the corresponding fields in the query configuration template. For example, if the first user's query intent is predicted to be "to view the recent follow-up status of the VIP customers they are responsible for," then the "Customer Level" field is set to VIP, and the "Last Follow-up Time" field is set to the last 7 days. As another example, if it is predicted that the first user has an 85% historical probability of querying orders created in the "current week" during their first query on Mondays, then when the system detects that the current time is Monday and it is the first user's first session, a default value will be injected into the creation time field: the time range is [this Monday 00:00:00, current time]. The user does not need to manually select anything and can directly click to query.

[0108] In some embodiments, the dropdown fields of the query field can be asynchronously loaded in advance according to the query intent. If it is predicted that the first user is very likely to use the "Province" field when starting the query, the system can initiate an asynchronous data request to obtain the dropdown option list in advance when the query interface is loaded but the main business data request has not yet been initiated, thus completely eliminating the delay of the user waiting for data loading.

[0109] Specifically, it can also be understood that when a backend service becomes overloaded due to sudden traffic spikes or complex queries, continuing to send query requests to it will cause a surge in service response latency, and may even lead to service crashes, compromising system stability. Since the query process involves the frontend sending query requests to the backend service, which then executes the query against the target data source, this disclosure proposes monitoring the resource status of the target data source and the backend service, and implementing measures such as route switching or operational restrictions to prevent dangerous queries from being initiated at the source, thereby improving system stability.

[0110] When the dynamic context information includes system resource status, the real-time adjustment includes resource status adaptive routing. In this case, the real-time adjustment of the primary query configuration template based on the dynamic context information to generate the target query configuration template includes: Step c1: Monitor system resource status in real time.

[0111] The system resource status includes the status of the target data source and the status of the backend services. The target data source refers to the database system that persistently stores data, and the backend services refer to applications or microservices that encapsulate business logic and provide data access interfaces. Real-time monitoring of system resource status can be monitoring load metrics, such as database load, computing resource load, and the number of database connections, or monitoring service health status, such as service instance availability, network latency, and request-response latency.

[0112] Step c2: When an abnormal system resource status is detected, the routing path of subsequent query requests is automatically updated, and high-load query operations allowed in the primary query configuration template are restricted.

[0113] The abnormal states include load indicators exceeding preset thresholds or abnormal service health status, such as a system resource status abnormal when the database CPU load is greater than 85%. High-load query operations refer to queries with high computational complexity, wide data access scope, or poor execution plans, such as full table scans, multi-table joins, or large-scale data export operations. The routing path for updating subsequent query requests can automatically route all subsequent new, read-only query requests from the primary database to the read-only replica database. Restricting the high-load query operations allowed in the basic query configuration template can include hiding or disabling the "Export All Data" button, forcing users to use the more efficient "Precise Query," and prohibiting complex queries involving full joins of multiple tables.

[0114] The aforementioned method for personalizing basic query configuration templates achieves scalable reuse and fine-grained control of configurations through an architecture of basic templates and overlay fragments, fundamentally eliminating configuration redundancy and solving the challenges of large-scale management. Real-time monitoring of permission event streams ensures near real-time effectiveness of security policies, significantly improving system security. Accurate prediction of users' potential query intentions allows query configuration templates to closely match users' individual query habits, significantly improving user experience. An adaptive resource status routing mechanism enables the system to have load awareness and fault self-healing capabilities, effectively enhancing system robustness. Based on dual processing of static and dynamic contexts, on the one hand, static context preprocessing makes it possible to quickly generate differentiated configurations for thousands of tenants and roles at extremely low cost; on the other hand, the dynamic context processing mechanism gives the system the ability to respond to environmental changes in real time, predicting query intentions in advance and dynamically adjusting the interface, realizing a shift from "people finding functions" to "functions finding people," thus evolving the query interface from a static tool into an intelligent business assistant.

[0115] Figure 4 This is a schematic diagram of the structure of a query configuration system provided in this disclosure. See also... Figure 4 The system 400 includes: The template acquisition module 410 is used to retrieve the basic query configuration template corresponding to the target query function item from the configuration repository in response to the first user's trigger operation on the target query function item in the query interface. The personalized configuration module 420 is used to personalize the basic query configuration template based on the context information of the first user to obtain the target query configuration template. The interface rendering module 430 is used to parse the target query configuration template into an executable structure through a strategy-based rendering engine, and drive the front-end components to render and generate the target query interface according to the executable structure. The unified query module 440 is used to respond to the query request initiated by the first user on the target query interface, to verify and standardize the input value of the query request and assemble it into query parameters with a unified structure, and to initiate a query request to the target service based on the query parameters with the unified structure. The result display module 450 is used to receive the query results returned by the target service, normalize the query results according to the result mapping rules of the basic query configuration template, and render and display them on the target query interface.

[0116] For a detailed description of the query configuration system described above, please refer to the description of the relevant method steps in the above embodiments; repeated details will not be repeated. The embodiments of the query configuration method and system described above are merely illustrative. The "units" and "modules" used as separate components can be combinations of software and / or hardware that implement a predetermined function, and may or may not be physically separate. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0117] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this disclosure, and not to limit them; although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this invention.

Claims

1. A query configuration method, characterized in that, The method includes: In response to the first user's trigger operation on the target query function item in the query interface, a basic query configuration template corresponding to the target query function item is obtained from the configuration repository; the configuration repository is used to store at least one query configuration template designed by the configurator, and each query configuration template includes at least a configuration identifier and a query field list, wherein the fields in the query field list reference standard business fields in the central field library; The basic query configuration template is personalized based on the context information of the first user to obtain a target query configuration template; the context information includes static context information and dynamic context information; the personalization of the basic query configuration template based on the context information of the first user to obtain the target query configuration template includes: obtaining the corresponding configuration coverage fragment from the coverage rule base based on the static context information, and overlaying and merging the basic query configuration template with the configuration coverage fragment to generate a primary query configuration template; and adjusting the primary query configuration template in real time based on the dynamic context information to generate the target query configuration template, wherein the real-time adjustment includes at least permission changes, interactive predictive optimization, and resource status adaptive routing. The target query configuration template is parsed into an executable structure by a strategy-based rendering engine, and the front-end components are driven to render and generate the target query interface based on the executable structure. In response to the query request initiated by the first user on the target query interface, the input value of the query request is validated, normalized and assembled into query parameters with a unified structure, and a query request is initiated to the target service based on the query parameters with the unified structure. The system receives the query results returned by the target service, normalizes the query results according to the result mapping rules of the basic query configuration template, and renders and displays them on the target query interface.

2. The query configuration method according to claim 1, characterized in that, Each query configuration template also includes a template name, inter-field linkage rules, validation rules, and result mapping rules.

3. The query configuration method as described in claim 1, characterized in that, The real-time adjustment includes permission changes, and the real-time adjustment of the primary query configuration template based on the dynamic context information to generate the target query configuration template includes: Listen for permission change event streams related to the first user during the first user session; When a permission change event stream is detected, invalidation processing is performed on the event-related fields in the primary query configuration template. The invalidation processing includes applying an invisible state, applying a disabled state, or removing them directly.

4. The query configuration method as described in claim 1, characterized in that, The real-time adjustment includes interactive predictive optimization. The step of generating a target query configuration template by real-time adjustment of the initial query configuration template based on the dynamic context information includes: Collect the historical session behavior trajectory of the first user to form a historical behavior sequence; Based on statistical analysis of the historical behavior sequence, the query intent of the first user is predicted; Based on the query intent, optimize the layout of the query fields and / or fill in the values ​​of the query fields.

5. The query configuration method as described in claim 1, characterized in that, The real-time adjustment includes resource status adaptive routing, and the real-time adjustment of the primary query configuration template based on the dynamic context information to generate the target query configuration template includes: Real-time monitoring of system resource status; When an abnormal system resource status is detected, the routing path of subsequent query requests is automatically updated, and high-load query operations allowed in the primary query configuration template are restricted.

6. The query configuration method according to claim 1, characterized in that, The configuration coverage fragments include tenant coverage fragments, role coverage fragments, and user coverage fragments. The step of overlaying and merging the basic query configuration template with the configuration coverage fragments to generate a primary query configuration template includes: overlaying and merging the configuration coverage fragments with the basic query configuration template in order of priority to generate a primary query configuration template.

7. The query configuration method according to claim 2, characterized in that, The configurator includes: The field panel is used to select standardized business fields from the central field library as query fields. The properties panel is used to configure the properties of the query fields; The linkage rules panel is used to define the interaction logic between query fields.

8. The query configuration method according to claim 7, characterized in that, The configurator designs the query configuration template, which specifically includes: In response to a second user's click on the configurator, a configuration interface is displayed, which includes a field panel, an attribute panel, a linkage rule panel, and a canvas area. In response to the second user's operation of moving the target field from the field panel to the canvas area, the query field of the query configuration template is determined; In response to the input operation of the second user in the attribute panel, the attribute information of the query field is obtained; In response to the input operation of the second user on the linkage rules panel, the linkage rule information of the query field is obtained; In response to the second user's save operation, the query configuration template is saved to the configuration repository in draft state. In response to the second user's publish operation, the status of the approved query configuration template is changed from draft state to publish state.

9. A query configuration system, characterized in that, The system includes: The template acquisition module is used to respond to the first user's trigger operation on the target query function item in the query interface, and to obtain the basic query configuration template corresponding to the target query function item from the configuration repository; the configuration repository is used to store at least one query configuration template designed by the configurator, and each query configuration template includes at least a configuration identifier and a query field list, wherein the fields in the query field list reference standard business fields in the central field library; A personalized configuration module is used to personalize the basic query configuration template based on the context information of a first user to obtain a target query configuration template. The context information includes static context information and dynamic context information. The personalization of the basic query configuration template based on the context information of the first user to obtain the target query configuration template includes: obtaining the corresponding configuration coverage fragment from the coverage rule base based on the static context information, and overlaying and merging the basic query configuration template with the configuration coverage fragment to generate a primary query configuration template; and adjusting the primary query configuration template in real time based on the dynamic context information to generate the target query configuration template. The real-time adjustment includes at least permission changes, interactive predictive optimization, and resource status adaptive routing. The interface rendering module is used to parse the target query configuration template into an executable structure through a strategy-based rendering engine, and drive the front-end components to render and generate the target query interface based on the executable structure. The unified query module is used to respond to the query request initiated by the first user on the target query interface, to validate and standardize the input value of the query request and assemble it into query parameters with a unified structure, and to initiate a query request to the target service based on the query parameters with the unified structure. The results display module is used to receive the query results returned by the target service, normalize the query results according to the result mapping rules of the basic query configuration template, and render and display them on the target query interface.

Images