A configuration query method, system and device based on a hierarchical template architecture

Abstract

The application relates to the technical field of cloud computing and data security, and provides a configuration query method and system based on a hierarchical template architecture and electronic equipment, aiming to improve the problem that template reuse and personalized configuration are difficult to be compatible in an existing configuration management system. The method part comprises the following steps: receiving a configuration query request for a target merchant; determining a target merchant template associated with the target merchant according to the configuration query request, and loading a template configuration structure corresponding to the target merchant template; obtaining personalized configuration customized by the target merchant for the template configuration structure; performing merging processing on the personalized configuration and the template configuration structure to obtain a complete configuration structure after merging; performing sorting processing on the complete configuration structure in a preset order to obtain a target sorting structure; loading corresponding configuration values of each configuration item in a target environment according to the configuration items contained in the target sorting structure; and filling the loaded corresponding configuration values into the target sorting structure to generate and return target configuration information.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a configuration query method, system, and device based on a layered template architecture. Background Technology

[0002] In large-scale enterprise systems, especially open platforms or SaaS (Software as a Service) systems serving multiple merchants, configuration management is a core cornerstone of system operation. With the rapid increase in system business complexity, configuration management typically faces severe challenges. Existing application system configuration structures often exhibit a flattened structure, making it difficult to clearly express complex hierarchical relationships. For example, in a financial business system encompassing multiple business stages such as pre-screening, registration and login, and credit granting, a flattened storage approach could result in hundreds or even thousands of configuration items. Simultaneously, different merchants need to reuse a large number of standardized basic configurations (such as interface addresses and timeout periods) when accessing the platform, while also exhibiting strong personalized customization requirements. Existing technologies either maintain a complete configuration for each merchant individually, leading to exponentially increasing maintenance costs, or use a single template, thus stifling merchants' personalized needs.

[0003] Therefore, there is an urgent need for a configuration processing solution that can effectively balance template reuse and merchants' personalized customization needs while ensuring a clear configuration structure. Summary of the Invention

[0004] This application provides a configuration query method, system, and electronic device based on a layered template architecture, aiming to improve the problem of incompatibility between template reuse and personalized configuration caused by the flat structure in existing configuration management systems.

[0005] In a first aspect, embodiments of this application provide a configuration query method based on a hierarchical template architecture, including: Receive configuration query requests for the application system business node configuration of the target merchant; The target merchant template associated with the target merchant is determined based on the configuration query request, and the template configuration structure corresponding to the target merchant template is loaded; wherein, the target merchant template is generated based on a preset combination of node templates; Obtain the personalized configuration customized by the target merchant for the template configuration structure; The personalized configuration and the template configuration structure are merged to obtain the merged complete configuration structure; Extract the template order information from the template configuration structure, and use the template order information as the basic sorting rule for the complete configuration structure; If personalized order information is detected in the personalized configuration, the template order information corresponding to the basic sorting rule is replaced with the personalized order information to update the target sorting rule. According to the target sorting rules, the multiple business stages contained in the complete configuration structure, the nodes contained in each business stage, and the configuration items contained in each node are sorted to obtain the target sorting structure. The loaded corresponding configuration values ​​are filled into the target sorting structure to generate and return the target configuration information.

[0006] Secondly, embodiments of this application provide a configuration query system based on a hierarchical template architecture, including: The request receiving module is used to receive configuration query requests for the application system business node configuration of the target merchant; The template loading module is used to determine the target merchant template associated with the target merchant based on the configuration query request, and load the template configuration structure corresponding to the target merchant template; The configuration acquisition module is used to acquire the personalized configuration customized by the target merchant for the template configuration structure; The merging processing module is used to extract template order information from the template configuration structure and use the template order information as the basic sorting rule for the complete configuration structure; if personalized order information is detected in the personalized configuration, the personalized order information is used to replace the corresponding template order information in the basic sorting rule to update the target sorting rule; according to the target sorting rule, the multiple business stages contained in the complete configuration structure, the nodes contained in each business stage, and the configuration items contained in each node are sorted to obtain the target sorting structure; The sorting module is used to sort the complete configuration structure according to a preset order to obtain the target sorted structure; The result generation module is used to load the corresponding configuration values ​​of each configuration item in the target environment according to the configuration items contained in the target sorting structure, and fill the loaded corresponding configuration values ​​into the target sorting structure to generate and return the target configuration information.

[0007] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the computer program to implement the configuration query method based on a hierarchical template architecture described in the first aspect above.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the configuration query method based on a hierarchical template architecture described in the first aspect above.

[0009] In one of the technical solutions provided in this application, a three-layered template architecture consisting of node templates, merchant templates, and merchant configurations is used to reconstruct the original flat configuration into a hierarchical model. Upon receiving a configuration query, the template configuration structure carrying the standardized business baseline is dynamically merged and sorted with the personalized configuration carrying the merchant's specific needs. This allows for precise filling of configuration values ​​in a specific target environment, solving the problems of redundant parameters and unclear hierarchy in flat configurations. Simultaneously, the configuration merging mechanism enables most merchants to directly reuse standard templates, with customization only required for a very small number of differentiated nodes. While ensuring an extremely clear and maintainable global configuration structure, it perfectly accommodates the customization needs of a massive number of merchants on the SaaS platform, resulting in an order-of-magnitude reduction in the overall maintenance cost of configuration changes and significantly improving the system's scalability and configuration retrieval efficiency. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram of the hierarchical configuration of a configuration query system based on a hierarchical template architecture provided in an embodiment of this application; Figure 2 This is a flowchart of a configuration query method based on a hierarchical template architecture provided in an embodiment of this application; Figure 3 This is a schematic diagram of the node module structure in a configuration query method based on a hierarchical template architecture provided in an embodiment of this application; Figure 4 This is a schematic diagram of the configuration merging process in a configuration query method based on a hierarchical template architecture provided in an embodiment of this application; Figure 5 This is a schematic diagram of the merchant template structure in a configuration query method based on a hierarchical template architecture provided in an embodiment of this application; Figure 6 This is a structural diagram of a configuration query system based on a hierarchical template architecture provided in an embodiment of this application; Figure 7 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0013] In one embodiment, a configuration query method based on a hierarchical template architecture is provided. This method is mainly applied to the hierarchical management and template reuse of complex configurations in large-scale distributed systems. As an example, it is particularly suitable for open platforms or SaaS systems targeting multiple merchants. In existing enterprise application systems, system configuration often involves multiple complex business stages such as pre-screening, registration and login, credit authorization, identity verification, transactions, and repayment. Traditional flat configuration management methods cannot clearly express this hierarchical relationship, resulting in extremely chaotic configuration management and high maintenance costs. At the same time, different merchants have strong personalized customization needs due to differences in business models, and existing technologies struggle to balance the contradiction between template reuse and personalized configuration.

[0014] In one embodiment, a configuration query scheme based on a hierarchical template architecture is provided. This scheme is suitable for hierarchical management and template reuse of complex configurations in large-scale distributed systems, especially for open platforms or SaaS (Software as a Service) systems targeting multiple merchants. For an example, please refer to [link to example]. Figure 1 As shown, Figure 1 The hierarchical template configuration management architecture system corresponding to this configuration query scheme adopts a three-layer template architecture in its overall design, namely: node template layer, merchant template layer and merchant configuration layer.

[0015] Specifically, the node template layer serves as the basic unit for configuration management, used to abstract and define business nodes and their configuration items. The node template layer includes node template 1 (e.g., for pre-screening - risk check), node template 2 (e.g., for registration - user verification), node template 3 (credit granting - limit calculation), and node template N.

[0016] The merchant template layer, based on a combination of node templates, defines the standard configuration structure for a specific type of merchant. The top-level merchant configuration layer, also based on merchant templates, allows merchants to personalize their configurations according to their business scenarios, resulting in the final, effective configuration data. The merchant template layer includes Merchant Template A (e.g., the standard configuration scheme), Merchant Template B (e.g., the customized configuration scheme), and Merchant Template N.

[0017] The merchant configuration layer is formed based on merchant templates. This includes merchant 1 configuration (e.g., based on merchant template A), merchant 2 configuration (e.g., based on merchant template A), and merchant 3 configuration (e.g., based on merchant template B).

[0018] In the actual configuration query process, when the system needs to obtain a merchant's complete configuration, it first loads the merchant template's configuration structure from the database based on the merchant's pre-associated template code. Next, the system loads the merchant's personalized configuration. Then, the system executes intelligent merging logic to merge the template configuration and personalized configuration, forming a complete configuration structure tree. Then, the system loads the specific configuration values ​​for each configuration item in different environments (such as testing, gray-scale, and production environments). Finally, the assembled complete configuration information (including configuration structure and configuration values) is returned to the caller. This bottom-up three-tier architecture and dynamic query merging process solves the technical problem of traditional flat configuration management methods failing to clearly express hierarchical relationships, leading to chaotic configuration management and high maintenance costs. For example, in complex financial business systems, a complete business process may contain dozens of business nodes, each with multiple configuration parameters. If traditional flat storage is used, the number of configuration items may reach hundreds or even thousands, making manual management and maintenance extremely difficult. This embodiment achieves logical clarity in the configuration structure through a three-tier architecture, making configuration management more intuitive, configuration relationships clearer, and significantly reducing the system's operational complexity. Below, in conjunction with specific embodiments and Figure 1 This application describes a configuration query method based on a hierarchical template architecture.

[0019] In one embodiment, such as Figure 2 As shown, a configuration query method based on a hierarchical template architecture is provided, which is applied to a configuration query system based on a hierarchical template architecture. The method includes the following steps: S10. Receive a configuration query request for the application system business node configuration of the target merchant; S20. Determine the target merchant template associated with the target merchant based on the configuration query request, and load the template configuration structure corresponding to the target merchant template; wherein, the target merchant template is generated based on a preset combination of node templates; S30. Obtain the personalized configuration customized by the target merchant for the template configuration structure; S40. Merge the personalized configuration and the template configuration structure to obtain the merged complete configuration structure; S50. Extract the template order information from the template configuration structure and use the template order information as the basic sorting rule for the complete configuration structure. S60. If personalized order information is detected in the personalized configuration, the corresponding template order information in the basic sorting rule is replaced with the personalized order information to update the target sorting rule. S70. According to the target sorting rules, sort the multiple business stages contained in the complete configuration structure, the nodes contained in each business stage, and the configuration items contained in each node to obtain the target sorting structure. S80. Based on the configuration items contained in the target sorting structure, load the corresponding configuration values ​​of each configuration item in the target environment; S90. Fill the loaded corresponding configuration values ​​into the target sorting structure, generate and return the target configuration information.

[0020] Specifically, in large-scale distributed systems, such as multi-merchant financial open platforms or SaaS systems, configuration management often faces challenges due to complex configuration structures and unclear hierarchical relationships. The method in this embodiment is primarily applied to the dynamic configuration loading stage during application system startup or business link initialization.

[0021] For steps S10 and S20, the system receives a configuration query request, which typically manifests as an interface call instruction carrying a unique merchant identifier (i.e., merchant ID) and a target environment identifier (such as pre-release, gray-scale, or production environment). Upon receiving the configuration query request, the system extracts the associated template code (template_code) from the underlying merchant configuration attribute table based on the merchant ID in the request. Using this template code, the system locates and loads the target merchant template associated with that target merchant from the database. This target merchant template is physically represented as a JSON-formatted data set, internally defining standardized business stages (such as pre-screening, registration / login, etc.), node hierarchies within each stage, and configuration item hierarchies within each node. In this embodiment, the generation of the aforementioned template configuration structure is not a simple stacking of flat parameters, but rather based on a pre-built combination of node templates. Node templates are the basic unit of configuration management, strictly defining all configuration items contained in the business node (such as the interface address api_url, timeout) through JSON format, and constraining the data type (such as string, integer) and mandatory attributes of the configuration items. Merchant templates combine these enabled node templates and inherit their configuration item definitions, building a standardized business configuration topology skeleton that includes stage codes, node codes, and configuration item key names, much like assembling building blocks. The principle behind this is to avoid the repetitive work of defining a complete basic data structure for each merchant through a reference reuse mechanism. It should be noted that in this hierarchical architecture, nodes are the core entities carrying configuration management. In physical terms and in microservice architecture, a node represents the smallest computational unit or microservice routing endpoint in the underlying business chain that executes a specific atomic business action. As a specific example, in a financial business system containing macro-level business stages such as pre-screening, registration and login, and credit granting, the pre-screening stage typically includes multiple independently executed business nodes such as risk checks and user verification. Each node encapsulates a set of highly cohesive configuration item parameters required to complete the atomic action (such as the API URL for calling external credit reporting agencies, the network communication timeout, etc.). The system decomposes the massive business flow into these fine-grained business nodes, aiming to achieve high cohesion and low coupling in complex business processes, allowing for flexible orchestration of underlying business capabilities.

[0022] For steps S30 and S40, the system retrieves the personalized configuration customized by the target merchant for the template configuration structure. This personalized configuration is represented in computer storage as an incremental JSON dataset stored under the `custom_configs` field. It signifies the merchant's differentiated customization of configuration items for specific nodes based on the standard template (such as overriding timeout parameters in the template or adding allowed new configuration items). After retrieving the template configuration and personalized configuration, the system executes a dynamic merging algorithm in memory. This merging process is implemented at the algorithm's underlying level as a differential patching process of a configuration tree: the system first loads the merchant's template configuration structure as the base, then loads the personalized configuration for comparison. For nodes and configuration items explicitly defined in the personalized configuration, the system truncates and overwrites the corresponding default definitions in the template using the personalized configuration's data pointer. For nodes and configuration items not defined in the personalized configuration, the system retains and uses the original data from the template configuration by default. Through this differential merging rule, the system dynamically assembles the merged complete configuration structure.

[0023] For steps S50-S70, the overwriting and patching operations of dictionary objects in memory often disrupt the original data traversal queue of the JSON parser, causing the configuration structure to fall into an iterative disordered state. In this embodiment, the system must strictly sort the complete configuration structure according to a preset order. Specifically, during the processing, the system first extracts the fixed template order information from the template configuration structure. As an example, this information includes the preset stage order at the business stage level, the node order at the node level, and the configuration item order at the configuration item level. The system directly uses this statically extracted template order information as the basic sorting rule for the complete configuration structure.

[0024] To provide merchants with ultimate flexibility in adjusting the order of business processes, if the personalized configuration explicitly includes merchant-defined personalized order information (e.g., the merchant wants to execute a certain review node earlier, thus passing in a node order weight with a smaller value), the system directly uses this personalized order information to forcibly replace the corresponding template order information in the basic sorting rules, thereby updating the target sorting rules to match the merchant's current intentions. Subsequently, according to the target sorting rules, the system performs top-down sorting processing on the multiple business stages contained in the complete configuration structure, the specific nodes contained in each business stage, and the underlying configuration items contained in each node, resulting in the final target sorting structure.

[0025] For steps S80 and S90, considering that the physical address and actual parameter values ​​of the same configuration structure differ significantly in different target environments (such as grayscale and production), strict isolation is required between environments to prevent mutual interference. The system extracts the stage code, node code, and configuration item key name from each configuration item in the target sorting structure, and concatenates these three elements according to preset rules to form a globally unique configuration code (e.g., "pre_screen_risk_check_api_url"). The system uses this unique configuration code and the target environment in the request as a composite primary key query condition to retrieve and accurately load the corresponding specific configuration value (such as a specific URL string) from the preset configuration value storage space. Subsequently, these loaded corresponding configuration values ​​are used as leaf node data and filled into the target sorting structure, completing the final assembly of the memory object. This generates target configuration information containing a complete hierarchical structure and environment values, which is then returned to the business caller.

[0026] As can be seen, this embodiment provides a configuration query method based on a hierarchical template architecture. By adopting a template configuration structure based on a combination of node templates and merchant templates, and dynamically merging and sorting the standard template configuration with the merchant's exclusive personalized incremental configuration when receiving a query, the configuration value is finally loaded and filled. This achieves on-demand merging, reloading, rendering, and distribution of the configuration structure. It breaks through the pain points of traditional flat configuration management methods, such as the difficulty in expressing hierarchical relationships and the chaos of maintaining massive parameters. While ensuring an extremely clear global configuration structure and high reusability of basic templates, it flexibly meets the personalized customization needs of different merchants on a large open platform, resulting in an order-of-magnitude reduction in the overall maintenance cost of single-point configuration changes and significantly improving the system's business expansion capabilities and the response efficiency of the configuration retrieval link.

[0027] Based on the above embodiments, in one embodiment, the template configuration structure is restructured dimensionally. Specifically, the template configuration structure is defined using a hierarchical relationship, which includes a business stage level, a node level, and a configuration item level. The template configuration structure includes stage information corresponding to multiple business stages, node information corresponding to multiple nodes included in each business stage, and configuration item information corresponding to multiple configuration items included in each node. The node information includes the node code of the corresponding node, which is used to reference a preset node template to determine the configuration item information included in the node. The configuration item information includes configuration item attributes inherited from the referenced node template and the display order of configuration items defined in the target merchant template.

[0028] For ease of understanding, the merchant templates mentioned in the embodiments of this application will be described first, such as... Figure 5 As shown, the appendix Figure 5The core merchant template configuration structure is shown, which strictly defines the physical storage form and three-dimensional logical topology of the configuration from top to bottom, as explained in detail below: Top-level object: The merchant template is at the top level. The merchant template consists of a template configuration and a template code. This level stores the configuration in JSON format and defines the hierarchical relationship between stages, nodes, and configuration items.

[0029] First level: Stage level.

[0030] The merchant template includes a hierarchical structure. Figure 5 Using a specific business flow as an example, the text sequentially illustrates phases 1 (pre_screen), 2 (register), 3 (credit), and up to phase N (...). The attributes of this level are strictly constrained as follows: phaseCode: phase code, phaseName: phase name, and phaseOrder: phase order.

[0031] Second level: Node level.

[0032] Each stage further includes node levels. Figure 5 The corresponding nodes are 1 (risk_check), 2 (user_verify), 3 (limit_calc), and up to N (...).

[0033] The attributes at this level are defined as: nodeCode: node code (referencing the node template) (this is the core pointer for implementing underlying template reuse), nodeName: node name, and nodeOrder: node order.

[0034] Third level: Configuration item level.

[0035] Each node ultimately contains the lowest level of configuration items. Figure 5 The document shows configuration item 1 (api_url), configuration item 2 (timeout), configuration item 3 (retry_count) up to configuration item N (...).

[0036] The attributes at this level include: key: the configuration item key name, and itemOrder: the configuration item order. It's important to note that this level does not store redundant data types; instead, it inherits the configuration item attributes from the node template.

[0037] Horizontal association module: sorting information.

[0038] Figure 5It also abstracts a common sorting information module, which includes phase order (phaseOrder), node order (nodeOrder), and configuration item order (itemOrder). Figure 5 The dashed and solid lines in the diagram clearly indicate that the sorting information is used for timing control at the stage level, node level, and configuration item level.

[0039] For example, as a specific example of a financial SaaS scenario, the top level of this configuration tree is the business stage level. The stage information it contains represents the macro-level business lifecycle, such as unique identifiers and Chinese names for stages like pre-screening, registration / login, or credit granting. Further parsing this data structure, each business stage has a corresponding node level. Node information represents the computational unit that executes the actual atomic business action; for example, the risk check node is specifically attached to the pre-screening stage. At the very bottom of this configuration tree, the leaf nodes, i.e., the configuration item level, contain configuration item information such as the interface address (api_url) and timeout, used for underlying network communication and computational control.

[0040] The node information within the aforementioned node hierarchy does not directly store redundant parameter definitions. Instead, it specifically includes a node code (nodeCode) for each corresponding node. This node code serves as a memory addressing pointer or database foreign key, directly initiating a reference to the enabled preset node templates in the upstream basic configuration library. Through this referencing action, the system can dynamically address and determine the set of valid configuration items that the business node should contain, without having to repeatedly hardcode these basic units in each merchant template.

[0041] Furthermore, this configuration item information first includes configuration item attributes directly inherited from the referenced preset node template. For example, as a concrete example, this includes the data type of the configuration item (limited to integer, string, or boolean), a description of the business dimension, and a "required" flag that determines whether the underlying validation logic is valid. Simultaneously, this configuration item information also includes the display order of configuration items (i.e., itemOrder) independently defined in the target merchant template. When assembling the merchant template, only the required configuration items need to be specified and assigned new sorting weights; that is, the rendering and layout order of this parameter on the front-end UI can be flexibly adjusted according to the merchant's own management console display requirements.

[0042] As can be seen, in this embodiment, the template configuration structure is defined by adopting a three-dimensional hierarchical relationship that includes business stages, nodes, and configuration items. Node codes are introduced into the node information to reference node templates in the form of pointers. At the same time, the inheritance of attributes and the independent definition of display order are implemented in the configuration item information. The complex and flattened configuration parameters are separated from the coupling of static data constraints and dynamic UI rendering through object-oriented attribute inheritance and local variable overriding mechanisms. This eliminates the blind spots in operation and maintenance caused by the disordered parameters, significantly reduces the physical storage volume of the target merchant template in the database and the manual assembly time, and gives the upper-level merchants great flexibility in interface display customization while avoiding repetitive configuration work.

[0043] In one embodiment, the preset node template includes a set of configuration item definitions, which includes the configuration item code, configuration item data type, and configuration item display order; the target merchant template is generated based on a combination of preset node templates, including: S101. Select the target node template from a number of pre-built node templates; S102. The target node template is referenced into the target merchant template through node coding, so that the target merchant template inherits the set of configuration item definitions defined in the target node template as configuration item information.

[0044] like Figure 3 As shown, the appendix Figure 3 It shows the most basic node template structure at the bottom layer, which is divided into four core modules, explained in detail below: Basic information about a node template (including basic attributes): This module contains global attribute definitions for nodes, including: template status, template name, template description, template code, and phase affiliation.

[0045] For basic attributes, the system has set strict rules: code serves as a unique identifier and cannot be modified after creation; phase represents the business phase it belongs to and is determined at creation (it cannot be tampered with without authorization); status represents the current enabled / disabled status of the template.

[0046] Configuration item definition: This module defines the specific set of parameters that a node possesses, including configuration item 1 (api_url), configuration item 2 (timeout), configuration item 3 (retry_count), and so on down to configuration item N (...). As an example, the configuration item definitions are stored in JSON format; each configuration item contains complete attributes and supports sorting and required fields at the rendering level.

[0047] Configuration item properties: For each of the above individual configuration items (such as api_url), its specific configuration item attributes are further defined. These attributes comprehensively describe the parameter characteristics, including: configuration item name (name), configuration item code (key), configuration item type (type), configuration item description (description), whether it is required to determine the form validation logic (required), and the configuration item order (itemOrder) that controls the front-end display position.

[0048] State Management: This module manages the lifecycle and security of node templates, specifically including: a reference verification mechanism, and two machine states: enabled (online) and disabled (offline). The system's state management logic is as follows: nodes in the enabled state can be referenced; nodes in the disabled state cannot be referenced (but historical references can be maintained); reference verification also prevents accidental operations (such as preventing accidental deletion of nodes already referenced by merchants). Further details on state management will be provided in subsequent embodiments and will not be elaborated upon here.

[0049] Building upon the above embodiments, this embodiment deconstructs the configuration item definition and inheritance logic of the node template. Specifically, the node template is the most atomic basic building block in the entire layered architecture. Its internal configuration item definition set is typically presented in serialized data formats such as JSON, similar to class attribute declarations in object-oriented programming. As a specific business scenario example, this set defines in detail all the parameter constraints required by the node, including not only configuration item encoding (e.g., defining the unique identifier api_url for the external interface address), configuration item data type (e.g., strictly limiting the data type of the timeout to integer, or limiting the state of a certain function switch to boolean), but also the display order of configuration items used to control the UI rendering layout of the front-end interface (e.g., itemOrder:1); preferably, this set can further include the Chinese name of the configuration item, a functional description, and a hard logical identifier indicating whether it is a required field, to ensure the completeness of the underlying business parameters.

[0050] In the actual workflow of building the target merchant template in the system, architects or business operations personnel do not need to manually write cumbersome configuration files from scratch. First, the system selects the target node template that meets the specific business requirements from a pre-built global node template library categorized by business stage. Then, instead of performing a full copy, the system uses node encoding to mount the target node template to the target merchant template as an external pointer reference. This allows the target merchant template to directly and dynamically inherit all configuration item definitions defined in the target node template and use them as its own configuration item information. In the configuration data of the merchant template actually serialized and written to disk, only the referenced node encoding, the required configuration item key names, and their relative order in the current template need to be maintained, eliminating the need for repeated definitions of detailed attributes such as data types, physical boundaries, and descriptive information.

[0051] As can be seen, in this embodiment, by constructing a set of configuration item definitions containing configuration item codes, strict data types, and display order in the atomic node template, and using the unique primary key reference of the node code to enable the merchant template to dynamically inherit these parameter definitions and attribute constraints upwards, the class attribute inheritance mechanism of object-oriented programming is introduced into the underlying structure of the configuration management of the distributed system. This approach significantly reduces the physical storage volume of the merchant template in the database and the manual assembly time from the perspective of data structure design, and avoids redundant attribute definitions between multiple templates. On the other hand, it prevents the downstream microservice deserialization parsing from crashing due to the upper-layer system or merchants arbitrarily issuing illegal data formats (for example, incorrectly filling in a string containing letters instead of an integer timeout time). This greatly enhances the type security and business operation robustness of the entire multi-merchant concurrent configuration data link.

[0052] Furthermore, in one embodiment, as Figure 4 As shown, step S40 involves merging the personalized configuration and the template configuration structure to obtain the merged complete configuration structure, including the following steps: S41. Traverse the business stages and nodes in the template configuration structure; S42. Perform node matching based on the node encoding. If a target node is detected in the personalized configuration, use the personalized node definition corresponding to the target node in the personalized configuration to override the template node definition corresponding to the target node in the template configuration structure. S43. Based on the key name of the configuration item, perform item matching. If a target configuration item is defined in the target node of the personalized configuration, use the personalized configuration item definition corresponding to the target configuration item in the personalized configuration to override the template configuration item definition corresponding to the target configuration item in the template configuration structure. S44. If a new personalized node or personalized configuration item that is not defined in the target merchant template is detected in the personalized configuration, then the personalized node or personalized configuration item is added to the complete configuration structure. S45. If it is detected that the corresponding node or configuration item is not defined in the personalized configuration, the corresponding template node definition or template configuration item definition in the template configuration structure shall be retained. S46. Integrate all node definitions and configuration item definitions determined after overwrite, add, and retain operations to obtain the merged complete configuration structure.

[0053] Based on the above embodiments, after receiving a query request, the system loads the merchant template basic configuration structure (i.e., the static standard skeleton) and the merchant-specific personalized configuration (i.e., the dynamic incremental dataset) in memory, respectively, based on JSON format. Then, it sequentially traverses each business stage and node in the template configuration tree to use as a benchmark for comparison.

[0054] During the scanning and comparison process, node-level comparisons are performed. The system extracts node codes from the template (such as `risk_check` representing risk checks) and performs character comparisons with the data in the personalized configuration. If the system probe detects that the target node is explicitly defined in the personalized JSON fragment uploaded by the merchant based on the node code, the pointer logic in the system memory will immediately perform blocking and overwriting operations, forcibly overwriting the basic node definition in the original template with the node definition in the personalized configuration. Subsequently, it further descends to the configuration item level, performing precise item matching based on the key name of the configuration item itself (such as `timeout` representing timeout). As a specific scenario example, suppose the basic template sets the default API call timeout to 3000 milliseconds, while the merchant, in pursuit of even faster response speeds, defines it as 1000 milliseconds in their incremental personalized configuration. Once the system matches the same key name, it will forcibly use this 1000-millisecond personalized configuration item definition to override the default definition in the template.

[0055] Furthermore, to ensure extreme flexibility in the business architecture, if the system detects during the matching process that a merchant has added personalized nodes (such as secondary verification nodes specific to local regulations) or unique configuration items that are not present in the original target merchant template within their authorized scope, the system will add these new structures and parameters to the complete configuration structure. Conversely, for the massive amount of remaining parameters not covered in the merchant's personalized configuration (such as standardized interface routing addresses, retries, and other basic settings), the system will automatically trigger a safety fallback mechanism when a match is not found, directly retaining and using the corresponding template node definitions or template configuration item definitions in the template configuration structure. Finally, the system re-serializes these precisely overwritten memory fragments, dynamically added extended fragments, and original basic fragments, merging them into a complete configuration structure tree for distribution and rendering.

[0056] As can be seen, in this embodiment, by traversing each level of the template configuration structure and performing precise matching based on node codes and configuration item key names, personalized precise overriding, addition and expansion, and basic retention of undefined items are executed respectively, ultimately integrating the merged complete configuration structure. This allows merchants to maintain and distribute only a very small number of incremental configuration data that differ from their own when accessing the system and customizing their businesses, without having to copy and store the entire system's massive configuration set. This reduces the database storage volume and network transmission overhead of merchant configuration files by several orders of magnitude. At the same time, it is completely transparent to upper-layer business callers. Under the premise of ensuring unified governance of the global configuration architecture of the SaaS platform and avoiding reinventing the wheel, it is extremely lightweight and perfectly meets the deep personalized customization needs of a large number of merchants.

[0057] Further, in one embodiment, the template order information includes the initial stage order, the initial node order, and the initial configuration item order; the personalized order information includes the personalized stage order, the personalized node order, or the personalized configuration item order; in step S70, according to the target sorting rules, the multiple business stages contained in the complete configuration structure, the nodes contained in each business stage, and the configuration items contained in each node are sorted to obtain the target sorting structure, including: S71. From the target sorting rules, parse out the target stage order determined by the personalized stage order or the initial stage order, the target node order determined by the personalized node order or the initial node order, and the target configuration item order determined by the personalized configuration item order or the initial configuration item order. S72. Based on the target phase sequence, sort the multiple business phases in the complete configuration structure into a first-level order; S73. Based on the target node order, perform a second-level sorting on the nodes under each business stage after the first-level sorting; S74. Based on the order of the target configuration items, perform a third-level sorting on the configuration items under each node after the second-level sorting to generate the target sorting structure.

[0058] Based on the above embodiments, after the system performs the configuration merging operation, the underlying layer often uses mapping data structures such as dictionaries or hashes to overwrite the differential data and insert incremental fragments. This dynamic assembly on physical memory usually results in the iteration sequence of element traversal being in an unordered state. In order to correct this disorder bias and meet the strong dependencies of business flow, the system must perform multi-level time-series rearrangement.

[0059] Specifically, the template order information includes the initial stage order, initial node order, and initial configuration item order, representing the default numerical ranking weights assigned to each level of elements during standard template modeling (for example, the system defaults to setting the phaseOrder for the pre-screening stage to 1 and the phaseOrder for the registration stage to 2 during modeling). Personalized order information, on the other hand, covers the personalized stage order, personalized node order, or personalized configuration item order additionally assigned by the merchant during targeted customization. As a specific business scenario example, a merchant might, due to special risk control requirements, want to place their uniquely added secondary verification node before the default risk check node, and thus assign a smaller personalized node order weight than the default value to this new node in the personalized configuration.

[0060] During actual reordering, the system determines the target order based on the personalized order specified by the merchant in the incremental customization. If the element is not customized, it automatically reverts to the system's preset initial order. The system determines a unique and accurate target stage order, target node order, and target configuration item order for all data. The system initiates the first-level sorting: based on the previously determined target stage order, the system reorders multiple business stages (such as pre-screening, registration, and credit granting) within the complete configuration structure. Next, the second-level sorting is executed: within each business stage after the first-level sorting, the system independently arranges the various computational nodes (such as risk check nodes and credit calculation nodes) attached to that specific stage according to the target node order. Finally, the third-level sorting is executed: within each node after the second-level sorting, the system sorts all basic configuration items (such as API address api_url, timeout, and retry count) within that node according to the target configuration item order. The memory data structure, which was originally scattered due to merging, is precisely fixed, thereby generating a target sorting structure that is absolutely stable in both topology and timing.

[0061] In this embodiment, a top-down three-level progressive sorting process is performed, from business stage and node to specific configuration parameters. While fully ensuring the platform's standard baseline, it gives merchants extreme flexibility to freely adjust the order of business processes across levels, eliminating the configuration sequence chaos that may be caused by incremental merging of JSON data. This not only ensures the regularity and high readability of massive configuration parameters displayed on the SaaS management console at the visual level, but also provides the business workflow engine with an absolutely strict and unambiguous basis for node execution timing, effectively preventing the risk of logical inversion and cascading failures caused by out-of-order execution of business nodes.

[0062] Furthermore, in one embodiment, step S80, namely loading the corresponding configuration value of each configuration item in the target environment according to the configuration items contained in the target sorting structure, includes the following steps: S81. Extract the stage code, node code, and key name of each configuration item in the target sorting structure. S82. According to the preset splicing rules, the extracted stage code, node code and key name are combined into a unique configuration code, which serves as a globally unique index for the specific configuration value of the mapping configuration item in different environments. S83. Using the unique configuration code and target environment as query conditions, retrieve the corresponding target configuration value from the preset configuration value storage space as the corresponding configuration value.

[0063] When the specific business execution flow reaches the final rendering and value retrieval stage, the system must determine the specific physical value of each abstract configuration item under different target environments (such as pre-release, canary release, production environment, etc.). At this time, the system first traverses the target sorting structure in memory and extracts the multi-dimensional context coordinates of the configuration item in the entire hierarchical topology tree: namely, the top-level phase code (phaseCode, for example, pre_screen representing the pre-screening stage), the middle-level node code (nodeCode, for example, risk_check representing the risk check node), and the bottom-level configuration item's own key name (configItemKey, for example, api_url representing the interface address).

[0064] The system combines the hierarchical codes of these three dimensions sequentially according to preset concatenation rules (the specific rules are not limited, but underscores "_" are preferred as natural semantic separators) to generate a unique configuration code in the format {phaseCode}_{nodeCode}_{configItemKey}. For example, the code obtained by concatenating the above example is pre_screen_risk_check_api_url. The generated combined string is not only a highly readable character identifier, but also a globally unique primary key index in the configuration value storage space (such as a distributed KV storage engine) that maps the specific configuration value of the configuration item in different environments.

[0065] The system uses the unique configuration code, along with the target environment tag carried in the current system request context, as a joint hash query condition to retrieve the corresponding target configuration value (such as the real domain name URL of the production environment or the corresponding millisecond-level integer timeout), and uses it as the corresponding configuration value for assembly and filling.

[0066] Specifically, in the preset configuration value storage space (such as a database or key-value storage engine), configuration values ​​are not stored in a flat manner, but rather possess environment isolation characteristics. The specific retrieval action is as follows: Composite primary key / composite condition mapping: When querying, the system uses the unique configuration code as the primary key and the target environment as the namespace or secondary index. The combination of these two forms a composite query condition, for example, the query logic is as follows: SELECTconfig_valueFROMconfig_storeWHEREconfig_code='pre_screen_risk_check_api_url'ANDenvironment='prod').

[0067] Since configuration values ​​for different environments are independent and do not affect each other, the system will enter the isolated storage area dedicated to that environment based on the input environment tag, or perform a match search within the data rows with environment tags. Based on the above combined conditions, the system retrieves the corresponding target configuration value (meaning the configuration value is stored in JSON string format). After retrieving the value, the system will also perform format matching. For example, if a timeout value for the production environment is found, the system will confirm that it conforms to the integer type defined in the basic template, and then use it as the final corresponding configuration value to populate the configuration structure. That is, the retrieval logic strongly binds a globally unique character identifier to the current running context environment, using it as a composite-dimensional hash index.

[0068] As can be seen, this embodiment extracts stage codes, node codes, and configuration item key names, and forcibly concatenates them according to preset rules to form a unique configuration code with strong semantic attributes. Then, it combines the target environment to perform multi-dimensional joint environment retrieval. On the one hand, the joint concatenation ensures the unique legitimacy of massive configuration items in the global scope from a multi-dimensional combination perspective, eliminating the catastrophic risks of namespace conflicts and cross-contamination of data from multiple environments. On the other hand, it enables development and operation personnel to quickly locate the exact stage and node position of the configuration item in the massive business chain based solely on the encoded string itself, greatly improving the efficiency of daily configuration management, fault diagnosis, and problem localization.

[0069] Furthermore, in one embodiment, both the preset node template and the target merchant template are configured with enabled and disabled states; the method also includes a configuration security protection step based on reference relationships: S201. Record the first reference relationship between the preset node template and the merchant template, and the second reference relationship between the merchant template and the merchant; S202. Based on the first reference relationship, if it is determined that the preset node template to be processed is referenced by any merchant template, the deletion command of the node template to be processed is intercepted. S203. Based on the second reference relationship, if it is determined that the merchant template to be processed is used by any merchant, then the deletion instruction of the merchant template to be processed is intercepted.

[0070] Specifically, in a multi-level pointer reference architecture, any destructive modification to the underlying template will trigger a chain reaction across the entire network. Therefore, both the default node templates and merchant templates are forcibly equipped with explicit lifecycle state identifiers in the underlying database model: online and offline. This state machine design aims to establish dynamic data isolation barriers. As an example, only node templates in the online state can be legally mounted by upper-level merchant templates; when an administrator switches a node template to the offline state, that template is marked as invisible in memory, thus blocking any newly created merchant templates from referencing it. However, to ensure the stability of existing online services, merchant templates that have already established references in historical operations can still continue to read the template data.

[0071] Based on this, the first reference relationship recorded by the system is a data table that maps the many-to-many mounting dependency between the upper-level merchant template and the lower-level node template; the second reference relationship is a data table that maps the binding relationship between real online merchant instances (identified by merchant ID) and merchant templates.

[0072] In actual operation and maintenance management processes, when a system administrator or automated operation and maintenance script attempts to send a low-level SQL forced command to delete a pending node template, the system quickly queries the first reference relationship table. If it determines that the current memory address or primary key of the pending node template is being referenced by a pointer to any merchant template, the system will classify the deletion operation as a high-risk illegal operation and directly intercept (block) the deletion command at the application layer. Simultaneously, it can throw an error message containing details of dependency conflicts to the front end. Similarly, at the merchant template level, if it is determined that the pending merchant template is currently being used by any online merchant service instance, the deletion command for that merchant template will also be intercepted without exception. Preferably, when performing a deactivation operation, the system can also provide a warning based on the above reference relationships to further reduce the risk of accidental operation.

[0073] As can be seen, this embodiment, by introducing online / offline state machines for nodes and merchant templates, and constructing a directed dependency graph at the underlying level that accurately records the first and second reference relationships, transforms the traditional passive defense of post-event error reporting into an active cascading security verification based on data dependency link detection. This eliminates the risk of single-point catastrophic failures such as large-scale instantaneous failure of online merchant configurations, front-end rendering white screens, or back-end null pointer parsing anomalies caused by human error or script-induced deletion of basic templates.

[0074] Furthermore, in one embodiment, before step S10, that is, before receiving the configuration query request for the target merchant, a configuration item preset step is also included: S301. Obtain the template code and configuration item key name of the configuration item to be created; perform format validation and global uniqueness validation on the template code and configuration item key name; S302. If both the template code and the configuration item key name meet the preset format restrictions and are unique globally, then the corresponding configuration item can be saved, and a globally unique configuration code for configuration query can be generated based on the template code and the configuration item key name.

[0075] Specifically, before any configuration data is officially entered into persistent storage (such as being written to a relational database) and queried by online businesses, when business architects or operations personnel attempt to enter new basic configuration data through the front-end management console, the system first obtains the key physical identifier fields of the configuration item to be created, such as the template code and the key name of the configuration item itself.

[0076] After obtaining the above identifiers, the system immediately calls the regular expression engine to perform format validation on these fields. As a specific scenario example, the system requires that identifier fields such as template encoding and configuration item key names must conform to specific regular expression logic (such as [a-zA-Z][a-zA-Z0-9_]), that is, they are strictly limited to starting with an English letter, and only letters, numbers and underscores are allowed afterward. Spaces, special punctuation marks or escape characters that are easy to cause ambiguity in parsing are absolutely prohibited.

[0077] Preferably, the system also imposes length restrictions on the physical storage boundaries of characters (e.g., forcing each encoded field to have a maximum length of no more than 64 characters) to prevent memory cache overflow. Simultaneously, the system background performs uniqueness collision detection in a globally shared hash table. Only when the template encoding and configuration item key name perfectly conform to the aforementioned preset format restrictions, and are not occupied by others in the global library (i.e., unique globally), will the system allow the persistent storage of these valid configuration items. Finally, based on these securely cleaned identifier fields, the system assembles and generates a globally unique configuration code for all subsequent configuration query actions and environment retrievals according to rules.

[0078] As can be seen, in this embodiment, by introducing strong format constraints based on regular expressions and global hash uniqueness in the pre-entry stage of configuration data, and only allowing saving and generating global configuration codes after verification, the backend JSON deserialization exception that may be caused by illegal special character injection is effectively intercepted from the data source.

[0079] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0080] This application also provides a configuration query system based on a hierarchical template architecture, which corresponds one-to-one with the configuration query method based on a hierarchical template architecture described above. Please refer to... Figure 6 The configuration query system includes: The request receiving module 61 is used to receive configuration query requests for the application system business node configuration of the target merchant; The template loading module 62 is used to determine the target merchant template associated with the target merchant based on the configuration query request, and load the template configuration structure corresponding to the target merchant template. Configuration acquisition module 63 is used to acquire the personalized configuration customized by the target merchant for the template configuration structure; The merging processing module 64 is used to merge the personalized configuration and the template configuration structure to obtain the merged complete configuration structure. The sorting module 65 is used to extract template order information from the template configuration structure and use the template order information as the basic sorting rule for the complete configuration structure. If personalized order information is detected in the personalized configuration, the personalized order information is used to replace the corresponding template order information in the basic sorting rule to update the target sorting rule. According to the target sorting rule, the multiple business stages contained in the complete configuration structure, the nodes contained in each business stage, and the configuration items contained in each node are sorted to obtain the target sorting structure. The result generation module 66 is used to load the corresponding configuration values ​​of each configuration item in the target environment according to the configuration items contained in the target sorting structure, fill the loaded corresponding configuration values ​​into the target sorting structure, generate and return the target configuration information.

[0081] For specific limitations regarding the configuration query system based on the hierarchical template architecture described above, please refer to the limitations of the configuration query method based on the hierarchical template architecture mentioned earlier, which will not be repeated here. Each module in the configuration query system based on the hierarchical template architecture described above can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0082] In one embodiment, an electronic device is provided, the internal structure of which can be shown as follows: Figure 7 As shown, the electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. When the computer program is executed by the processor, it implements the steps of the configuration query method based on the hierarchical template architecture described above.

[0083] In one embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the function of a configuration query system based on a hierarchical template architecture, or executes the steps of a configuration query method based on a hierarchical template architecture. To avoid repetition, these steps will not be repeated here.

[0084] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program implements the functionality of a configuration query system based on a hierarchical template architecture, or, when executed, implements the steps of a configuration query method based on a hierarchical template architecture. To avoid repetition, these steps will not be repeated here. Any references to memory, storage, database, or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory.

[0085] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such 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 application, and should all be included within the protection scope of this application.

Claims

1. A configuration query method based on a hierarchical template architecture, characterized in that, include: Receive configuration query requests for the application system business node configuration of the target merchant; The target merchant template associated with the target merchant is determined based on the configuration query request, and the template configuration structure corresponding to the target merchant template is loaded; wherein, the target merchant template is generated based on a preset combination of node templates; Obtain the personalized configuration customized by the target merchant for the template configuration structure; The personalized configuration and the template configuration structure are merged to obtain the merged complete configuration structure; Extract the template order information from the template configuration structure, and use the template order information as the basic sorting rule for the complete configuration structure; If personalized order information is detected in the personalized configuration, the template order information corresponding to the basic sorting rule is replaced with the personalized order information to obtain the target sorting rule. According to the target sorting rules, the multiple business stages contained in the complete configuration structure, the nodes contained in each business stage, and the configuration items contained in each node are sorted to obtain the target sorting structure. Based on the configuration items contained in the target sorting structure, load the corresponding configuration values ​​of each configuration item in the target environment; The loaded corresponding configuration values ​​are filled into the target sorting structure to generate and return the target configuration information.

2. The method according to claim 1, characterized in that, The template configuration structure is defined using a hierarchical relationship, which includes business stage hierarchy, node hierarchy, and configuration item hierarchy. The template configuration structure includes stage information corresponding to multiple business stages, node information corresponding to multiple nodes contained in each business stage, and configuration item information corresponding to multiple configuration items contained in each node. The node information includes the node code of the corresponding node, which is used to reference a preset node template to determine the configuration item information contained in the node; the configuration item information includes configuration item attributes inherited from the referenced node template, and the display order of configuration items defined in the target merchant template.

3. The method according to claim 2, characterized in that, The preset node template contains a set of configuration item definitions, which includes the configuration item code, configuration item data type, and configuration item display order. The target merchant template is generated based on a preset combination of node templates, including: selecting a target node template from a plurality of pre-built node templates; The target node template is referenced into the target merchant template through the node encoding, so that the target merchant template inherits the set of configuration item definitions defined in the target node template as the configuration item information.

4. The method according to claim 2, characterized in that, The step of merging the personalized configuration with the template configuration structure to obtain the merged complete configuration structure includes: Traverse the business stages and nodes in the template configuration structure; Node matching is performed based on the node encoding. If a target node is detected in the personalized configuration, the personalized node definition corresponding to the target node in the personalized configuration is used to override the template node definition corresponding to the target node in the template configuration structure. Based on the key name of the configuration item, item matching is performed. If a target configuration item is defined in the target node of the personalized configuration, the personalized configuration item definition corresponding to the target configuration item in the personalized configuration is used to override the template configuration item definition corresponding to the target configuration item in the template configuration structure. If a new personalized node or personalized configuration item not defined in the target merchant template is detected in the personalized configuration, then the personalized node or personalized configuration item is added to the complete configuration structure. If it is detected that no corresponding node or configuration item is defined in the personalized configuration, the corresponding template node definition or template configuration item definition in the template configuration structure is retained; All node definitions and configuration item definitions determined after the overwrite, add, and retain operations are integrated to obtain the merged complete configuration structure.

5. The method according to claim 4, characterized in that, The template order information includes the initial stage order, the initial node order, and the initial configuration item order; the personalized order information includes the personalized stage order, the personalized node order, or the personalized configuration item order; the process of sorting the multiple business stages, the nodes under each business stage, and the configuration items under each node in the complete configuration structure according to the target sorting rule to obtain the target sorting structure includes: From the target sorting rules, the target stage order determined by the personalized stage order or the initial stage order, the target node order determined by the personalized node order or the initial node order, and the target configuration item order determined by the personalized configuration item order or the initial configuration item order are parsed out. Based on the target stage sequence, the multiple business stages in the complete configuration structure are sorted in the first-level order; Based on the target node order, perform a second-level sorting on the nodes under each business stage after the first-level sorting; Based on the order of the target configuration items, the configuration items under each node after the second-level sorting are sorted in the third level to generate the target sorting structure.

6. The method according to claim 1, characterized in that, The step of loading the corresponding configuration values ​​of each configuration item in the target environment according to the configuration items contained in the target sorting structure includes: Extract the stage code, node code, and key name of each configuration item in the target sorting structure; According to the preset splicing rules, the extracted stage code, the node code, and the key name are combined into a unique configuration code, which serves as a globally unique index for mapping the specific configuration values ​​of the configuration items in different environments; Using the unique configuration code and the target environment as query conditions, the corresponding target configuration value is retrieved from the preset configuration value storage space as the corresponding configuration value.

7. The method according to claim 1, characterized in that, Both the preset node template and the target merchant template are configured with enabled and disabled states; the method further includes: Record the first reference relationship between the preset node template and the merchant template, and the second reference relationship between the merchant template and the merchant; Based on the first reference relationship, if it is determined that the preset node template to be processed is referenced by any merchant template, the deletion command of the node template to be processed is intercepted. Based on the second reference relationship, if it is determined that the merchant template to be processed is being used by any merchant, then the deletion instruction for the merchant template to be processed is intercepted.

8. The method according to any one of claims 1-7, characterized in that, Before receiving the configuration query request for the target merchant, the method also includes: Get the template code and configuration item key name of the configuration item to be created; Perform format validation and global uniqueness validation on the template encoding and the configuration item key name; If both the template code and the configuration item key name meet the preset format restrictions and are unique globally, then the corresponding configuration item can be saved, and a globally unique configuration code for configuration query can be generated based on the template code and the configuration item key name.

9. A configuration query system based on a hierarchical template architecture, characterized in that, include: The request receiving module is used to receive configuration query requests for the target merchant; The template loading module is used to determine the target merchant template associated with the target merchant based on the configuration query request, and load the template configuration structure corresponding to the target merchant template; The configuration acquisition module is used to acquire the personalized configuration customized by the target merchant for the template configuration structure; The merging processing module is used to extract template order information from the template configuration structure and use the template order information as the basic sorting rule for the complete configuration structure; if personalized order information is detected in the personalized configuration, the personalized order information is used to replace the corresponding template order information in the basic sorting rule to update the target sorting rule; according to the target sorting rule, the multiple business stages contained in the complete configuration structure, the nodes contained in each business stage, and the configuration items contained in each node are sorted to obtain the target sorting structure; The sorting module is used to sort the complete configuration structure according to a preset order to obtain the target sorted structure; The result generation module is used to load the corresponding configuration values ​​of each configuration item in the target environment according to the configuration items contained in the target sorting structure, and fill the loaded corresponding configuration values ​​into the target sorting structure to generate and return the target configuration information.

10. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the configuration query method based on a hierarchical template architecture as described in any one of claims 1 to 8.

Images