Freight rate system interface parameter dynamic verification method and system based on rule engine
By using a rule engine-based approach, parameter validation logic is decoupled from business code, enabling dynamic management. This solves the problems of high maintenance costs and low scalability in traditional interface parameter validation methods, and improves the system's flexibility and responsiveness.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- TRAVELSKY TECHNOLOGY LIMITED
- Filing Date
- 2025-12-31
- Publication Date
- 2026-04-17
AI Technical Summary
Traditional interface parameter validation methods suffer from high maintenance costs, low scalability, and bloated code in domestic private fare systems, making it difficult to flexibly adapt to business changes and multi-tenant differentiated configuration requirements.
By adopting a rule engine-based approach, parameter validation logic is decoupled from business code and managed through a centralized rule engine, enabling dynamic and configurable operation. It supports multi-tenant differentiated rule configuration and introduces fast failure and delayed failure modes.
It significantly improves the system's flexibility, maintainability, and scalability, enabling rapid response to changes in business needs. Rules can be applied or rolled back instantly without modifying the code, avoiding the shortcomings of traditional hard-coding methods.
Smart Images
Figure CN121879820A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer software technology, and in particular to a method and system for dynamic verification of interface parameters of a fare system based on a rule engine. Background Technology
[0002] In the development of domestic private fare publishing front-ends, ensuring the correctness and validation of parameters passed via DFF interfaces is crucial for guaranteeing system stability and data validity. With increasing business complexity and frequent changes in validation rules, traditional parameter validation methods face significant challenges. Specifically, the system needs a dynamic parameter validation mechanism that can flexibly adapt to business changes, support multi-tenant differentiated configurations, and eliminate the need for frequent code modifications and releases. This would address issues such as high maintenance costs, low scalability, and slow response to changes in business requirements caused by validation logic being "hardcoded" into the code.
[0003] Currently, common interface parameter validation technologies in the industry are mainly divided into two categories. The first category is hard-coded validation, which involves embedding validation logic directly into the business code. For example, using Java's if-else statements or Spring framework's Validation annotations (such as @NotBlank and @Size) to constrain request parameters. The second category is rule engine-based validation, which is a software system approach that separates business rules from application code. By using a rule engine (such as Drools, Easy Rules, or a self-developed lightweight engine), validation logic can be managed in a configurable and externalized form (such as DSL, JSON, XML, or database records), and dynamically loaded and executed by the engine at runtime, thereby achieving flexible configuration and dynamic adjustment of validation rules.
[0004] Traditional hard-coded validation methods have significant limitations. First, they are costly to maintain: validation rules are deeply coupled with business code. If business requirements change (e.g., the length limit of a field needs adjustment), the source code must be modified, recompiled, tested, and the entire service re-released – a time-consuming process prone to introducing new errors. Second, they have poor scalability: in microservice architectures or multi-tenant scenarios, different customers (e.g., different airlines) may require different validation rules, and hard-coded methods struggle to support such flexible and differentiated configuration needs. Finally, they suffer from poor readability and manageability: numerous if-else statements and annotations scattered throughout the code make core business logic bloated and unclear, hindering centralized rule management and auditing. While existing rule engine-based solutions can theoretically address these issues, designing a rule engine system that is deeply integrated with domestic fare business, supports efficient hot updates, and provides complete management functions remains a challenging technical problem that requires further investigation.
[0005] In summary, domestic private fare pricing systems urgently need an innovative solution to overcome the shortcomings of traditional hard-coding methods in interface parameter validation. This solution should aim to decouple validation logic from the code, enabling dynamic and configurable rule management, thereby significantly improving the system's flexibility, maintainability, and responsiveness to rapidly changing business needs. A rule engine-based approach provides a feasible direction for this, but it requires customized design and implementation tailored to the specific business scenarios of the fare pricing system. Summary of the Invention
[0006] To overcome the shortcomings of existing technologies, this invention provides a method and system for dynamic verification of interface parameters in a fare system based on a rule engine. Its core objective is to completely separate parameter verification logic from the application's business code, managing, understanding, and executing it through a centralized rule engine, thereby significantly improving the system's flexibility, maintainability, scalability, and responsiveness to business changes.
[0007] The technology of this invention is achieved through the following technical solution: In a first aspect, the present invention provides a method for dynamic verification of interface parameters of a fare system based on a rule engine, comprising the following steps: S1: Rule Configuration and Management: Through an independent rule management module, parameter validation rules are configured for specific interfaces. The parameter validation rules include one or more rules, and all parameter validation rules constitute a rule set and are configured with rule names and version numbers. S2: Rule compilation and deployment: The rule set is compiled and processed into compiled rules that can be executed by the rule engine. The rule set that passes the rule test is stored in the rule repository, and the rule management module is used to perform 'deployment' or 'deactivation' operations to achieve timely effectiveness or invalidation. S3: Interface Request Interception and Rule Loading: The fare system receives interface call requests and loads all online and corresponding rule sets from the rule repository using the identifier of the corresponding interface; S4: Data and Function Loading: Based on the computational expression requirements of the rules in the loaded rule set, dynamically load the data and custom functions required for rule execution; S5: Rule Engine Execution: The rule engine parses and executes the rule set loaded in S3 in priority order. Using the data and functions loaded in S4, it evaluates the "rule calculation expression" of each rule and obtains a Boolean result of "pass" or "fail". S6: Result Processing and Return: Aggregate and return results based on the "verification mode" configured for each rule.
[0008] Specifically, in S1: The version number is used for version control, which facilitates rule tracing and rollback to the original version when the version does not meet expectations after going live. The rule management module is used to manage the validation rules for each interface parameter, including adding rules, deleting rules, updating rules, running rules, and compiling rules.
[0009] Furthermore, each rule in the rule set includes a rule ID, interface identifier, rule calculation expression, validation mode, rule priority, and rule status, among which: The rule calculation expression is an executable string used to describe the verification logic, defined using either a domain-specific language or a scripting language. The verification modes include 'fast failure mode' and 'delayed failure mode'. Fast failure mode means that once a rule fails verification, the process is immediately stopped and a failure result is returned. Delayed failure mode means that after all rules have been executed, all failure results are aggregated and returned together. The rule status is used to identify the current status of the rule, including active, offline, initial, and verification.
[0010] Specifically, in S4: The data and custom functions required for the loading rule execution include request input parameter data, external dependency data, and custom function libraries, wherein: The request input parameter data is the interface parameter object to be verified loaded into the rule engine context; The external dependency data is implemented through a custom DataLoader interface, which determines the required data from the database, cache, or remote service loading rules. The custom function library is a collection of predefined or user-defined functions registered in the rule engine for use by rule expressions.
[0011] Specifically, in S6: The process of aggregating and returning results based on the "verification mode" configured for each rule includes: If it is in fail-fast mode: During the execution process, if any rule fails to be calculated, the engine will immediately terminate the execution of subsequent rules and return the failure result and the failed rule information directly to the caller; In delayed failure mode: the engine will execute all rules in the rule set, collect detailed information on all failed rules, and finally return a complete list of failure results to the caller.
[0012] A second aspect of the present invention, based on the same inventive concept as the first aspect, provides a dynamic interface parameter validation system based on a rule engine, the system comprising: Rule Management Module: Provides a visual or configurable interface for adding, deleting, modifying, querying, compiling, testing (i.e. simulating test execution), and launching / deploying validation rules. Rule repository: Used to store all compiled validation rules, supports version control, and facilitates rule tracing and rollback; The core of the rules engine is a built-in rule expression executor, which is responsible for dynamically loading rules, loading data and functions, executing rule calculation logic and producing validation results at runtime. It also supports two processing modes: "fast failure" and "delayed failure". Data Loading Layer: Provides a standardized DataLoader interface, allowing for extended implementations to load the data required for rule execution from various data sources; Function Library: Provides a set of built-in basic functions (such as string processing and numerical comparison) and an extensible custom function interface for encapsulating complex validation logic.
[0013] A third aspect of the present invention provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs all the steps of a rule engine-based dynamic verification method for interface parameters as described above.
[0014] In a fourth aspect, the present invention provides a computer storage medium storing a computer program that, when executed by the processor, is used to implement all the steps of a rule engine-based dynamic validation method for interface parameters as described above.
[0015] Compared with the prior art, the present invention has the following advantages: This invention completely decouples parameter validation logic from business code and implements dynamic management through a rule engine, significantly improving the system's flexibility, maintainability, and scalability. Specifically, this solution utilizes a visual rule management module to enable online configuration, compilation, testing, and hot updating of validation rules (such as string length, numerical range, and business conditions). It supports multi-tenant differentiated rule configuration and introduces two validation modes, "fast failure" and "delayed failure," to adapt to different business scenarios. Rules are defined as executable script expressions, associated with specific interfaces, and stored in a version-controlled rule repository. This allows changes to business rules to take effect or be rolled back immediately without modifying or redeploying the code, thus efficiently responding to changes in business requirements. It also effectively avoids the high maintenance costs, low scalability, and bloated code problems inherent in traditional hard-coding methods, providing a highly configurable, centrally managed, and business-friendly dynamic validation mechanism.
[0016] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a flowchart illustrating a dynamic verification method for interface parameters of a fare system based on a rule engine, as shown in Example 1. Detailed Implementation
[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0020] Example 1: This embodiment provides a method for dynamic verification of fare system interface parameters based on a rule engine. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a flowchart illustrating a dynamic verification method for interface parameters of a fare system based on a rule engine, as described in this embodiment. The method includes the following steps: Step S1: Rule Configuration and Management: Configure parameter verification rules for specific interfaces through an independent rule management module. The parameter verification rules include one or more rules. All parameter verification rules constitute a rule set and the rule name and version number are configured. Furthermore, the version number serves as a tool for version control, facilitating rule tracing and rollback to the original version when the system does not meet expectations after deployment. Furthermore, each rule in the rule set includes a rule ID, interface identifier, rule calculation expression, validation mode, rule priority, and rule status, among which: The rule calculation expression is an executable string used to describe the verification logic, defined using either a domain-specific language or a scripting language. The verification modes include 'fast failure mode' and 'delayed failure mode'. Fast failure mode means that once a rule fails verification, the process is immediately stopped and a failure result is returned. Delayed failure mode means that after all rules have been executed, all failure results are aggregated and returned together. The rule status is used to identify the current status of the rule, including active, offline, initial, and verification.
[0021] Furthermore, the rule management module is used to manage the validation rules for each interface parameter, including adding rules, deleting rules, updating rules, running rules, and compiling rules.
[0022] Step S2: Rule compilation and deployment: The rule set is compiled into executable rules for the rule engine and tested. The rule set that passes the test is stored in the rule repository, and the rule management module is used to perform 'deployment' or 'deactivation' operations to achieve timely effectiveness or invalidation. Furthermore, in this embodiment, after the rule is tested and compiled, it can be taken offline or relaunched immediately, without requiring a system deployment process, thus achieving seamless integration with the entire system. When it is found that a rule no longer meets the needs of the business scenario and needs to be taken offline, the rule can be taken offline directly without requiring a system deployment.
[0023] Step S3: Interface Request Interception and Rule Loading: The fare system receives the interface call request and loads all online and corresponding rule sets from the rule repository using the identifier of the corresponding interface; Step S4: Data and Function Loading: Based on the calculation expression requirements of the rules in the loaded rule set, dynamically load the data and custom functions required for rule execution; Furthermore, the data and custom functions required for the execution of the loading rule include request input parameter data, external dependency data, and custom function libraries, wherein: The request input parameter data is the interface parameter object to be verified loaded into the rule engine context; The external dependency data is implemented through a custom DataLoader interface, which determines the required data from the database, cache, or remote service loading rules. The custom function library is a collection of predefined or user-defined functions registered in the rule engine for use by rule expressions.
[0024] Furthermore, in this embodiment, the purpose of data loading is to serve as the data source in the expression used for rule validation in Lass. For example, the interface parameter is Param, which defines two attributes: destPort and departPort. If destPort needs to be validated, then Param needs to be loaded into the rule engine before the corresponding calculation can be performed. However, if the expression to be validated depends on other data, then the corresponding data needs to be loaded into the rule engine.
[0025] Step S5: Rule engine performs calculation: The rule engine parses and executes the rule set loaded in step S3 in priority order. Using the data and functions loaded in step S4, it evaluates the "rule calculation expression" of each rule and obtains a Boolean result of "pass" or "fail". Step S6: Result Processing and Return: Aggregate and return the results according to the "verification mode" configured for each rule.
[0026] Furthermore, the process of aggregating and returning results based on the "verification mode" configured for each rule includes: If it is in fail-fast mode: During the execution process, if any rule fails to be calculated, the engine will immediately terminate the execution of subsequent rules and return the failure result and the failed rule information directly to the caller; In delayed failure mode: the engine will execute all rules in the rule set, collect detailed information on all failed rules, and finally return a complete list of failure results to the caller.
[0027] Example 2: In this embodiment, a dynamic validation system for interface parameters based on a rule engine is provided, the system comprising: Rule Management Module: Provides a visual or configurable interface for adding, deleting, modifying, querying, compiling, testing (i.e. simulating test execution), and launching / deploying validation rules. Rule repository: Used to store all compiled validation rules, supports version control, and facilitates rule tracing and rollback; The core of the rules engine is a built-in rule expression executor, which is responsible for dynamically loading rules, loading data and functions, executing rule calculation logic and producing validation results at runtime. It also supports two processing modes: "fast failure" and "delayed failure". Data Loading Layer: Provides a standardized DataLoader interface, allowing for extended implementations to load the data required for rule execution from various data sources; Function Library: Provides a set of built-in basic functions (such as string processing and numerical comparison) and an extensible custom function interface for encapsulating complex validation logic.
[0028] Example 3: In this embodiment, an electronic device is provided, including a memory and a processor. The memory stores a computer program. When the computer program is executed by the processor, the processor executes a rule engine-based dynamic interface parameter verification method as described above.
[0029] Example 4: In this embodiment, a computer storage medium is provided, on which a computer program is stored. When the computer program is executed by the processor, it is used to implement a rule engine-based dynamic verification method for interface parameters as described above.
[0030] 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; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.
Claims
1. A method for dynamic verification of interface parameters of a fare system based on a rule engine, characterized in that: S1, Rule Configuration and Management: Configure parameter validation rules for the interface through an independent rule management module. The parameter validation rules include one or more rules. All parameter validation rules constitute a rule set and are configured with rule names and version numbers. S2, Rule Compilation and Deployment: The rule set is compiled and processed into compiled rules that the rule engine can execute. The rule set that passes the rule test is then stored in the rule repository. The rule management module is used to perform deployment or decommissioning operations to achieve timely activation or deactivation. S3, Interface Request Interception and Rule Loading: The fare system receives interface call requests and loads all online and corresponding rule sets from the rule repository using the identifier of the corresponding interface; S4, Data and Function Loading: Based on the computational expression requirements of the rules in the loaded rule set, dynamically load the data and custom functions required for rule execution; S5, Rule Engine Execution: The rule engine parses and executes the rule set loaded in S3 in priority order. Using the data and functions loaded in S4, it evaluates the rule calculation expression of each rule and obtains a Boolean result of pass or failure. S6, Result Processing and Return: Aggregate and return results according to the verification mode configured for each rule.
2. The method for dynamic verification of interface parameters of a fare system based on a rule engine as described in claim 1, characterized in that: The version number is used for version control, which facilitates rule tracing and rollback to the original version when the version does not meet expectations after going live. The rule management module is used to manage the validation rules for each interface parameter, including adding rules, deleting rules, updating rules, running rules, and compiling rules.
3. The method of claim 1, wherein the rule engine-based tariff system interface parameter dynamic verification method is characterized by, Each rule in the rule set includes a rule ID, interface identifier, rule calculation expression, validation mode, rule priority, and rule status, among which: The rule calculation expression is an executable string used to describe the verification logic, defined using either a domain language or a scripting language. The verification modes include fast failure mode and delayed failure mode. Fast failure mode means that once a rule fails verification, the process is immediately stopped and a failure result is returned. Delayed failure mode means that after all rules have been executed, all failure results are aggregated and returned together. The rule status is used to identify the current status of the rule, including active, offline, initial, and verification.
4. The method of claim 1, wherein the rule engine-based tariff system interface parameter dynamic verification method is characterized by, The data and custom functions required for the loading rule execution include request input parameter data, external dependency data, and custom function libraries, wherein: The request input parameter data is the interface parameter object to be verified loaded into the rule engine context; The external dependency data is implemented through a custom DataLoader interface, which determines the required data from the database, cache, and remote service loading rules. The custom function library is a collection of predefined and user-defined functions registered in the rule engine for use by rule expressions.
5. The method of claim 3, wherein the rule engine-based tariff system interface parameter dynamic verification method is characterized by, The process of aggregating and returning results based on the "verification mode" configured for each rule includes: If it is in fail-fast mode: During the execution process, if any rule fails to be calculated, the engine will immediately terminate the execution of subsequent rules and return the failure result and the failed rule information directly to the caller; In delayed failure mode: the engine will execute all rules in the rule set, collect detailed information on all failed rules, and finally return a complete list of failure results to the caller.
6. A rule engine based interface parameter dynamic checking system for performing a rule engine based interface parameter dynamic checking method according to any one of claims 1-5, characterized in that, The system includes: Rule Management Module: Provides a visual and configurable interface for adding, deleting, modifying, querying, compiling, testing, and launching / deploying validation rules; Rule repository: Used to store all compiled validation rules, supports version control, and facilitates rule tracing and rollback; The core of the rules engine is a built-in rule expression executor, which is responsible for dynamically loading rules, loading data and functions, executing rule calculation logic and producing verification results at runtime. It also supports two processing modes: fast failure and delayed failure. Data Loading Layer: Provides a standardized DataLoader interface, allowing for extended implementations to load the data required for rule execution from various data sources; Function library: Provides a set of built-in basic functions and extensible custom function interfaces for encapsulating complex validation logic.
7. An electronic device, comprising a memory and a processor, characterized in that: The memory stores a computer program, which, when executed by the processor, causes the processor to perform a dynamic interface parameter verification method based on a rule engine as described in any one of claims 1 to 5.
8. A computer storage medium, characterized in that: The storage medium stores a computer program, which, when executed by the processor, is used to implement a rule engine-based dynamic verification method for interface parameters as described in any one of claims 1 to 5.