Embedded service system for dynamically loading corresponding service logic according to configuration file
By using a unified code engineering and dynamic code loading system, the problems of code redundancy and high maintenance costs between different city systems have been solved, enabling flexible business logic adaptation and rapid updates, and improving operation and maintenance efficiency.
Patent Information
- Application Number
- CN202511687169.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-18
- Publication Date
- 2026-02-24
AI Technical Summary
In smart city and chain service scenarios, when the same system runs in different cities, the differences in business rules, UI styles, interface addresses, etc., mean that the traditional approach requires maintaining an independent code branch for each city, resulting in code redundancy, high maintenance costs, and easy errors in updates.
It adopts a unified code engineering, city configuration files and resource repositories, dynamic code loading system and remote configuration center. The corresponding business logic is dynamically loaded through city configuration files, realizing unified code management and flexible adaptation, and supporting hot updates.
It enables different cities to share a single codebase, solving the problem of code redundancy, reducing maintenance costs, supporting rapid iteration and seamless updates, and improving operational efficiency.
Smart Images
Figure CN121560408A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of dynamic configuration file loading technology, specifically an embedded business system that dynamically loads corresponding business logic based on a configuration file. Background Technology
[0002] In scenarios such as smart cities, chain services, and regional applications, the same system needs to run in different cities, but there are differences in business rules, UI styles, interface addresses, and data formats between cities. The traditional approach is to maintain an independent code branch or project for each city, which leads to code redundancy, high maintenance costs, and errors in updates. Existing configuration center solutions are mostly focused on parameterization, which makes it difficult to handle differences in code logic. Summary of the Invention
[0003] To overcome the aforementioned problems in the prior art, this application provides a method and system, which adopts the following technical solution:
[0004] Firstly, this application provides an embedded business system that dynamically loads corresponding business logic based on a configuration file, including:
[0005] Unified code engineering, city configuration files and resource repositories, dynamic code loading system, and remote configuration center; among them...
[0006] The unified code project is a single code project used by different cities;
[0007] The city profile and resource library are used to abstract and externalize all the differentiating elements of each city, with the city profile as the core hub. The resource library is used to store the city profile.
[0008] The dynamic code loading system is used to obtain the storage path of the configuration file of the identified city code, retrieve the configuration file from the resource library based on the storage path, and inject different types of city configuration files into the main application through the runtime injector via the resource loader in the dynamic code loading system.
[0009] The hot update management module is used to obtain the latest city configuration files from the remote configuration center, enabling the application to dynamically update business rules without restarting.
[0010] Furthermore, the unified code engineering includes business logic, core framework, basic UI components, and main application entry points common to all cities.
[0011] Furthermore, all the differentiating elements of each city are abstracted and externalized. Abstraction is based on the design configuration files for different cities, while externalization is based on the extraction of the implementation code of the design configuration files. The design configuration file description is transformed into an external file independent of the main program, which is the final city configuration file.
[0012] Furthermore, the city configuration file defines the basic parameters of different cities, the storage path of business logic scripts / components, and data transformation rules.
[0013] Furthermore, the resource repository is an independent storage directory used to store executable code and resource files unique to each city.
[0014] Furthermore, the city configuration file is separated from the main body of the unified code project.
[0015] Furthermore, the dynamic code loading system includes a context recognition unit, a configuration parser, a resource loader, and a runtime injector.
[0016] Furthermore, the working principle of the embedded business system that dynamically loads the corresponding business logic based on the configuration file is as follows:
[0017] S1: City identification, determining the city code where the current operation is located;
[0018] S2: Configuration file loading and parsing. Based on the identified city code, locate and load the corresponding city configuration file from a specific directory path within the project, parse the city configuration file, and obtain all the differentiated information defined therein.
[0019] S3: Differentiated resources are loaded on demand. The dynamic code loading system loads the city-specific business logic scripts, UI component modules, and data conversion rules on demand based on the directory path information parsed in step S2.
[0020] S4: Runtime injection of business logic: The dynamic code loading system injects or hooks the dedicated business logic script loaded in step S3 into the general business process of the main application at runtime;
[0021] S5: Hot Update and Dynamic Response: When operators update the configuration file or script file of a city through the remote configuration center, the process from S2 to S4 is re-executed to dynamically load the new configuration and code, so that the city policy can take effect immediately without restarting the application or releasing a new version.
[0022] Furthermore, city identification determines the city code where the application is currently running, including: when the application starts, determining the city code by reading the device's geographical location, a user-selected identifier, or an identifier sent from the server.
[0023] This application has the following beneficial effects:
[0024] 1. This application, through the unified code engineering setup, allows different cities to share the same code program without needing to create dedicated code branches or projects for different cities. This solves the code redundancy problem caused by multiple branches or projects in different cities. It achieves a shift from decentralized functional coupling to centralized business capability management, realizing the adoption and unified management of business rules through configuration-driven approaches.
[0025] 2. This application extracts the differences between different cities through abstraction, and transforms these differences into directly applicable files through externalization. This solves the problem of transforming traditional hard-coded branch differences into configurable and hot-swappable modular components, achieving a balance between the flexibility and maintainability of the code program.
[0026] 3. This application uses a dynamic code loading system to dynamically load the required modules from the resource library according to the current city configuration, and uses a runtime injector to plug the required modules into the general process of the main application to achieve business customization.
[0027] 4. This application obtains the latest city configuration and script files from a remote configuration center and enables dynamic updates of business rules without restarting the application. Attached Figure Description
[0028] Figure 1 This application describes the system architecture and dynamic loading process of an embedded business system that dynamically loads corresponding business logic based on a configuration file, as exemplified in this application.
[0029] Figure 2 This is a flowchart illustrating the working principle of an embedded business system that dynamically loads corresponding business logic based on a configuration file, as described in an embodiment of this application. Detailed Implementation
[0030] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.
[0031] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.
[0032] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.
[0033] This invention addresses scenarios such as smart cities and chain services where a single business system needs to run in multiple cities, but each city has different requirements in terms of business rules, UI interfaces, and data formats. The traditional approach of maintaining a separate code branch for each city leads to severe code redundancy, high maintenance costs, and chaotic version management.
[0034] This invention proposes a dynamic code loading system based on city configuration files. By creating an independent configuration file for each city within a single code project, it uniformly manages all its differentiated settings (including parameters and business logic script paths). Upon application startup or runtime, the corresponding configuration and code modules are dynamically loaded based on the current city and injected into the main business process. This achieves the architectural goal of "one codebase, multiple city adaptations," fundamentally solving the branch explosion problem and supporting rapid iteration and hot updates of city strategies.
[0035] The core idea of this invention is to shift from decentralized functional coupling to centralized business capability management, and to achieve the reuse and unified management of business rules through configuration-driven approaches.
[0036] Suppose there are 100 independent business rules (numbered 1-100).
[0037] Multiple programs (such as programs A, B, and C) are like building blocks, each introducing its own required parts of the business rule library or code.
[0038] When business rule 30 changes, all programs that include rule 30 (assuming programs A and C both include rule 30) must be modified, tested, and redeployed. This is a point-to-point dependency, and maintenance costs increase exponentially with the number of businesses and programs.
[0039] Example 1: Please refer to Figure 1 This application provides an embedded business system that dynamically loads corresponding business logic based on a configuration file. The system includes: a unified code project, a city configuration file and resource library, a dynamic code loading system, and a remote configuration center.
[0040] The unified code project is a set of code projects that are used by different cities.
[0041] In one possible implementation, the unified code engineering includes business logic, core framework, basic UI components, and main application entry points common to all cities.
[0042] It's important to note that by setting up a unified code project, different cities can share the same codebase without needing to create separate code branches or projects for each city. This solves the code redundancy problem caused by multiple branches or projects in different cities. It also enables a shift from distributed, coupled functional management to centralized business capability management, achieving the adoption and unified management of business rules through configuration-driven approaches.
[0043] The city profile and resource library are used to abstract and externalize all the differentiating elements of each city, with the city profile as the core hub, and the resource library is used to store the city profile.
[0044] In one possible implementation, all the differentiating elements of each city are abstracted and externalized. Abstraction involves designing configuration files based on the differences between cities, while externalization involves extracting the implementation code from these configuration files. The design configuration file description is transformed into an external file independent of the main program body—the final city configuration file. This city configuration file is injected into the main application's configuration file via a runtime injector. Abstraction focuses on refining the differences between cities, while externalization focuses on transforming these differences into directly applicable files. This solves the problem of transforming traditional hard-coded branch differences into configurable, hot-swappable modular components, achieving a balance between code flexibility and maintainability.
[0045] In one possible implementation, the city configuration file defines the basic parameters of different cities, the storage path of business logic scripts / components, and data transformation rules.
[0046] The resource repository is an independent storage directory used to store city-specific configuration files for each city, including executable code or resource files such as business logic scripts, UI components, basic parameters, and data transformation rules.
[0047] The dynamic code loading system is used to obtain the storage path of the configuration file of the identified city code, retrieve the configuration file from the resource library based on the storage path, and inject different types of city configuration files into the main application through the runtime injector via the resource loader in the dynamic code loading system.
[0048] It should be noted that city configuration files are configured or code modules are loaded as needed.
[0049] It should be noted that, in the embodiments of this application, different types of configuration files include city-specific business scripts, basic parameters, city data conversion rules, etc.
[0050] It should be noted that when different types of city configuration files are injected into the main application through the runtime injector using the resource loader in the dynamic code loading system, the configuration files of the corresponding types are injected into the main application based on actual needs.
[0051] It should be noted that this application uses a dynamic code loading system to dynamically load the required modules from the resource library according to the current city configuration, and uses a runtime injector to plug the required modules into the general process of the main application to achieve business customization.
[0052] It should be noted that the dynamic code loading system includes a context recognition unit, a configuration parser, a resource loader, and a runtime injector.
[0053] The context recognition unit is used to determine the current urban environment.
[0054] It should be noted that the urban environment here refers to the program function. The business functions of different cities are different, and their corresponding program functions are also different.
[0055] The configuration parser is used to read and parse the configuration file of the current city based on the city environment. The configuration file of the current city includes city-specific business scripts, basic parameters, and city data transformation rules.
[0056] The resource loader dynamically loads city-specific code and resources based on the paths in the parsed configuration file. The configuration file paths are pre-defined by the program, and the resource loader loads the code and resources matching the specified paths.
[0057] Runtime injectors, using strategies, plugin mechanisms, or AOP technologies, seamlessly integrate city-specific code and resources into the main application's common business processes.
[0058] It should be noted that this application can dynamically determine which city's specific configuration file to execute through the context recognition unit.
[0059] It should be noted that the dynamic code loading system assembles the business system on demand based on the current context during application runtime, enabling dynamic adaptation of multiple logical business scenarios from the physical code project.
[0060] The hot update management module is used to obtain the latest city configuration file from the remote configuration center, enabling the application to dynamically update business rules without restarting.
[0061] It should be noted that the system supports retrieving the latest city configuration and script files from the remote configuration center, and enables dynamic updates of business rules without restarting the application.
[0062] The key technical points of this application are:
[0063] 1) City Profile: Create a configuration file named xx_config.h for each city (e.g., shanghai.h, beijing.h), defining:
[0064] Basic parameters (API address, theme color, language).
[0065] Business rule script path: points to the city-specific business logic code file.
[0066] Data conversion rules: Define the data format conversion function between cities.
[0067] 2) Unified code engineering architecture:
[0068] The main project includes general business logic, core framework, and basic UI.
[0069] Create a / cities directory to store configuration files and proprietary codes / resources for each city.
[0070] 3) Dynamic code loading system:
[0071] When the application starts, the current city is determined based on the device identifier or user selection.
[0072] Load the corresponding city configuration file.
[0073] On-demand loading: Dynamically loads the city's business rule scripts, UI components, and data transformation rules based on the configuration.
[0074] Runtime injection: Injecting city-specific logic into the main business process (e.g., through strategy pattern, plugin mechanism or AOP).
[0075] Hot update support: City configuration files and scripts can be dynamically updated via a remote configuration center without restarting the application or releasing a new version.
[0076] Figure 1 This invention clearly demonstrates how, by configuring driver code, a single codebase can run in multiple cities.
[0077] Core Engine: The dynamic code loading system is the brain of the system, responsible for identifying cities, parsing city configuration files, loading resources, and injecting them into the main program.
[0078] Configuration and code separation: All city-specific parts (configuration, scripts, UI, conversion rules) are stored in independent city configuration files and resource repositories, separated from the main body of the unified code project.
[0079] Dynamic assembly: The dynamic code loading system dynamically loads the required modules from the resource library according to the current city configuration, and plugs the required modules into the general process of the main application through the runtime injector to realize the customization of business.
[0080] Hot update mechanism: The remote configuration center can dynamically update city configurations and scripts, enabling rapid iteration and release of business strategies.
[0081] Please refer to Figure 2 The following describes the working principle of an embedded business system that dynamically loads corresponding business logic based on a configuration file, as provided in this application embodiment:
[0082] S1: City identification, determining the city code where the current operation is taking place.
[0083] In this application embodiment, determining the city code where the application is currently running includes: when the application starts, determining the city code (such as "shanghai" or "beijing") by reading the device's geographical location, the identifier manually selected by the user, or the identifier issued by the server.
[0084] S2: Configuration file loading and parsing: Based on the identified city code, locate and load the corresponding city configuration file (e.g., shanghai_config.h) from a specific directory within the project (e.g., / cities), parse the city configuration file, and obtain all the differentiated information defined therein. All differentiated information includes basic parameters (e.g., API address, theme color, UI components), business rule script paths, data conversion rules, etc.
[0085] S3: Differentiated Resource On-Demand Loading: Based on the directory path information parsed in step S2, the dynamic code loading system loads the city-specific business logic scripts, UI component modules, and data transformation rules on demand. These resources already exist as independent modules during the development phase and implement a unified interface or follow specific programming standards.
[0086] S4: Runtime Injection of Business Logic: The dynamic code loading system uses design patterns (such as strategy pattern, factory pattern) or advanced programming techniques (such as aspect-oriented programming, AOP) to "inject" or "hook" the city-specific business logic loaded in step S3 into the general business process of the main application at runtime. For example, when executing the general process of "payment", the script for calculating Shanghai-specific risk control rules will be automatically called.
[0087] S5: Hot Updates and Dynamic Responses: When operations personnel update a city's configuration file or script file via the remote configuration center, the system can monitor this change. Upon receiving the update notification, the system can re-execute the processes from S2 to S4, dynamically loading the new configuration and code, enabling the city's policies to take effect instantly without restarting the application or releasing a new version.
[0088] Example of application scenarios:
[0089] Application Scenario 1: Smart City Public Service Terminal;
[0090] Scope of application: A single "Government Self-Service Kiosk" software needs to be deployed in multiple cities across the country. However, the services available (e.g., provident fund withdrawal is available in city A but not in city B), procedures, form styles, and backend interface addresses vary from city to city.
[0091] Application of the invention: Only one configuration file needs to be created for each city. When the all-in-one machine starts up, the system loads the configuration corresponding to the city based on its deployment location, dynamically displays the city's unique business menu and UI theme, and loads the city-specific business processing scripts and interface call modules. When a city's policy is updated, only the city's configuration and script files need to be updated in the background, and all terminals in the city will take effect seamlessly, greatly improving the speed of policy implementation and operational efficiency.
[0092] Application Scenario 2: Chain retail and catering enterprises;
[0093] Scope of application: A large chain brand's POS system may have different promotional strategies (such as discounts, membership points rules), tax calculation rules, and payment integration methods in different cities (such as main integration with WeChat Pay in city A, and additional integration with a local payment platform in city B).
[0094] Application of the invention: The headquarters maintains a single, universal POS core system. Each city branch creates its own dedicated configuration file. When a store's POS machine logs in, the configuration is loaded based on its region, activating city-specific promotional calculation scripts and payment integration components. This allows the headquarters to unify the technology stack while flexibly supporting the differentiated marketing and settlement needs of various regions.
[0095] Application Scenario 3: Regional Internet Platforms or Apps
[0096] Scope of application: An app that provides local life services needs to display different homepage banners, recommend different content streams, and use different third-party services in different cities (such as map SDKs may differ between domestic and international markets).
[0097] Application of the invention: After the app launches, it locates a city via GPS or user selection, and then loads the configuration file for that city. Based on the configuration, it dynamically loads and renders the corresponding UI components, content filters, and third-party service adapters. This allows product operations personnel to quickly plan different online activities for different cities by modifying the configuration file, achieving refined operations.
[0098] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.
Claims
1. An embedded business system that dynamically loads corresponding business logic based on a configuration file, characterized in that, include: Unified code engineering, city configuration files and resource repositories, dynamic code loading system, and remote configuration center; among them... The unified code project is a single code project used by different cities; The city profile and resource library are used to abstract and externalize all the differentiating elements of each city, with the city profile as the core hub. The resource library is used to store the city profile. The dynamic code loading system is used to obtain the storage path of the configuration file of the identified city code, retrieve the configuration file from the resource library based on the storage path, and inject different types of city configuration files into the main application through the runtime injector via the resource loader in the dynamic code loading system. The hot update management module is used to obtain the latest city configuration files from the remote configuration center, enabling the application to dynamically update business rules without restarting.
2. The embedded business system that dynamically loads corresponding business logic based on a configuration file according to claim 1, characterized in that, The unified code engineering includes common business logic, core framework, basic UI components, and main application entry points for all cities.
3. The embedded business system that dynamically loads corresponding business logic based on a configuration file according to claim 1, characterized in that, The process involves abstracting and externalizing all the differentiating elements of each city. Abstraction is based on designing configuration files for the differences between cities, while externalization is based on extracting the code from the design configuration files. The design configuration file description is then transformed into an external file independent of the main program, which is the final city configuration file.
4. The embedded business system that dynamically loads corresponding business logic based on a configuration file according to claim 3, characterized in that, The city configuration file defines the basic parameters of different cities, the storage path of business logic scripts / components, and data transformation rules.
5. The embedded business system that dynamically loads corresponding business logic based on a configuration file according to claim 1, characterized in that, The resource repository is a separate storage directory used to store executable code and resource files unique to each city.
6. The embedded business system that dynamically loads corresponding business logic based on a configuration file according to claim 1, characterized in that, The city configuration file is separated from the main body of the unified code project.
7. The embedded business system that dynamically loads corresponding business logic based on a configuration file according to claim 1, characterized in that, The dynamic code loading system includes a context recognition unit, a configuration parser, a resource loader, and a runtime injector.
8. The embedded business system that dynamically loads corresponding business logic based on a configuration file according to claim 1, characterized in that, The working principle is as follows: S1: City identification, determining the city code where the current operation is located; S2: Configuration file loading and parsing. Based on the identified city code, locate and load the corresponding city configuration file from a specific directory path within the project, parse the city configuration file, and obtain all the differentiated information defined therein. S3: Differentiated resources are loaded on demand. The dynamic code loading system loads the city-specific business logic scripts, UI component modules, and data conversion rules on demand based on the directory path information parsed in step S2. S4: Runtime injection of business logic. The dynamic code loading system injects or hooks the exclusive business logic script loaded in step S3 into the general business process of the main application at runtime. S5: Hot update and dynamic response. When operators update the configuration file or script file of a city through the remote configuration center, the process from S2 to S4 is re-executed to dynamically load the new configuration and code. The city policy can take effect immediately without restarting the application or releasing a new version.
9. The embedded business system that dynamically loads corresponding business logic based on a configuration file according to claim 8, characterized in that, City identification determines the city code where the application is currently running, including: when the application starts, it determines the city code by reading the device's geographical location, manually selecting an identifier by the user, or obtaining an identifier from the server.