Dynamic rule processing method and device based on declarative configuration, medium and product

Abstract

The invention provides a dynamic rule processing method and device based on declarative configuration, a medium and a product, and relates to the technical field of rule engines, and the method comprises the following steps: constructing a rule object set in a memory by analyzing a declarative rule configuration file containing conditions, actions and cache strategies, a self-adaptive cache used for caching the handle is initialized; when a business object is processed, traversing rules according to a priority sequence, and acquiring and multiplexing a handle by utilizing a strategy-driven mechanism so as to efficiently execute condition judgment and action operation; the execution action judges whether the state of the current business object meets a cache failure triggering condition or not according to cache strategy information defined by a rule; and if yes, determining that the corresponding handle in the adaptive cache is invalid. By implementing the technical scheme provided by the invention, the data consistency and the result reliability in the dynamic rule processing process are ensured.

Description

Technical Field

[0001] This invention relates to the field of rule engine technology, and in particular to a dynamic rule processing method, device, medium, and product based on declarative configuration. Background Technology

[0002] In the field of modern information systems and enterprise software development, separating business logic from program code to improve system flexibility and maintainability has become a core technology in order to quickly respond to frequently changing market and business needs.

[0003] In existing technologies, solutions to achieve this goal mainly fall into two categories. One category involves hard-coding using if-else statements or strategy patterns directly in the code; the other involves introducing dedicated rule engine frameworks, such as heavy-duty engines based on domain-specific languages ​​(DSLs) (represented by Drools) or lightweight engines based on annotations / APIs (Application Programming Interfaces) (represented by Easy Rules). However, in practical applications, existing technologies generally have significant shortcomings in terms of declarative configuration capabilities and dynamic rule management: hard-coding solutions, which pursue high performance, lack flexibility due to their imperative nature; while rule engine frameworks that introduce declarative ideas often struggle to achieve an ideal balance between ease of configuration, dynamic management capabilities, and performance overhead due to limitations in their implementation. Existing technologies fail to achieve a balance between flexibility and high performance.

[0004] Therefore, a rule processing method that can balance flexibility and high performance is needed. Summary of the Invention

[0005] In view of this, this application provides a dynamic rule processing method, device, medium, and product based on declarative configuration to solve the above problems.

[0006] Firstly, a dynamic rule processing method based on declarative configuration is provided for application on a server. This method includes: Obtain and parse the preset declarative rule configuration file. The declarative rule configuration file contains multiple rules. Each rule contains a condition expression, action instructions, and caching strategy information to guide caching behavior. Based on declarative rule configuration files, a collection of rule objects corresponding to each rule is built in memory, and an adaptive cache is initialized. Obtain the business objects to be processed, traverse the collection of rule objects according to a preset priority order, and apply each rule object in the collection to all business objects in turn through the following steps: Using a pre-defined strategy-driven handle acquisition mechanism, the first handle corresponding to the target field or target method defined in the conditional expression of the rule object is obtained. The first handle is then used to extract data values ​​from the business object. The extracted data values ​​are compared with the pre-defined judgment logic in the conditional expression to generate a conditional matching result. When the condition matching result is met, the handle acquisition mechanism is used to obtain the second handle corresponding to the target field or target method defined in the action instruction of the rule object, and the obtained second handle is used to perform preset operations on the business object, including field assignment or method call. After performing a preset operation on the business object, determine whether the current state of the business object meets the cache invalidation triggering conditions defined in the cache strategy information. If it does, invalidate the corresponding handle in the adaptive cache according to the cache strategy information.

[0007] The above technical solution directly integrates caching strategy information guiding caching behavior into the definition of each declarative rule. By using and caching handles, it avoids the overhead of repeated reflection lookups, thereby improving processing performance. More importantly, to address potential data inconsistency issues caused by caching, this strategy immediately determines whether the new state of the business object meets the cache invalidation conditions after the rule's preset operations are executed, and accurately invalidates the corresponding cache handle. This mechanism directly binds cache cleanup logic to rule actions, forming a self-managed closed loop, thus ensuring the coexistence of caching acceleration and data consistency, achieving high performance and high reliability in dynamic rule processing.

[0008] Optionally, based on a declarative rule configuration file, a collection of rule objects corresponding to each rule is built in memory, and an adaptive cache is initialized, specifically including: The declarative rule configuration file is parsed to identify and extract the conditional expression, action instructions, caching strategy information and preset priority value contained in each rule; For each rule, the extracted conditional expressions and action instructions are pre-compiled; Create a rule object instance for each rule in memory, and store the pre-compiled condition expression, action instruction, caching strategy information and priority value into the corresponding attributes of the rule object instance. Aggregate all created rule object instances to obtain a rule object collection; Create a key-value store structure in memory as an adaptive cache and initialize it.

[0009] The above technical solution refines the initialization process of rule objects. By pre-compiling string-based conditional expressions and action instructions into directly executable intermediate forms, repetitive text parsing overhead is avoided in each subsequent rule matching and execution process. This significantly reduces the CPU's computational burden and directly improves the overall execution efficiency and throughput of the rule engine when handling a large number of rules or high-concurrency requests.

[0010] Optionally, the collection of rule objects can be traversed according to a preset priority order, specifically including: Before iterating through the collection of rule objects, sort the rule objects in the collection in descending order according to the priority value contained in each rule; Starting with the highest priority rule object in descending order, process them sequentially. Determine the first condition matching result as the target rule object. After executing the action instruction corresponding to the target rule object, terminate the traversal and processing of subsequent low-priority rule objects.

[0011] The above technical solution defines a priority-based short-circuit execution strategy. By pre-sorting the rules and immediately terminating the subsequent process after finding and executing the first rule that meets the conditions, it ensures that high-priority business logic is always applied first. This not only makes the execution result of the rules deterministic, but more importantly, it avoids unnecessary calculations for other low-priority rules, thus significantly reducing the response time of a single decision when rules can be hit frequently.

[0012] Optionally, a preset strategy-driven handle acquisition mechanism is used to obtain the first handle corresponding to the target field or target method defined in the conditional expression of the rule object, specifically including: Based on the caching strategy information corresponding to the rule object, determine whether there is a first handle in the adaptive cache that satisfies the preset cache validity criterion. The preset cache validity criterion corresponds to the target field or target method defined in the condition expression of the rule object. If it does not exist, the first handle is generated through reflection and stored in the adaptive cache according to the caching strategy information. If it exists, the first handle is obtained directly from the adaptive cache.

[0013] The above technical solution clearly defines a cache-first retrieval mechanism for handles. High-cost reflection operations (finding and generating handles by string names) are limited to cache misses, while subsequent duplicate requests are handled through low-cost memory reads (directly retrieving from the cache). This significantly reduces the number of calls to the reflection API during rule execution, thereby substantially reducing performance overhead and improving rule processing speed.

[0014] Optionally, a first handle is generated via reflection, and the generated first handle is stored in an adaptive cache according to the caching strategy information, specifically including: By using reflection, the target field or method can be located in the class corresponding to the business object based on the string name of the target field or method, and a preset security check can be performed. When the security check passes, obtain the first handle to the target field or target method; Determine if the caching strategy information specifies the use of a weak reference encapsulation strategy: If so, create a weak reference object that encapsulates the first handle, and store the string name and the weak reference object as key-value pairs in the adaptive cache; If not, store the string name and the first handle as a key-value pair in the adaptive cache.

[0015] The above technical solutions further refine the handle generation and caching strategies. A weak reference encapsulation mechanism based on the caching strategy is introduced. This allows the Java Virtual Machine's garbage collector to automatically reclaim handles and their associated objects held only by cache (weak references) when memory resources are scarce, without affecting the normal caching and reuse of handles. This effectively prevents memory leaks that may occur in scenarios such as dynamic class loading or application hot deployment, enhancing the long-term operational stability of the system.

[0016] Optionally, the method further includes: The system receives simulated business objects, simulation rules to be verified, and hypothetical data used to overwrite specific field values ​​in the simulated business objects through a pre-defined decision simulation interface. Based on the simulation rules and the execution conditions of the simulated business objects overwritten with the assumed data, a simulation decision log is generated, which indicates the points where the assumed data affects the decision path.

[0017] The above technical solution adds a decision simulation and impact analysis function. It provides a non-intrusive sandbox testing environment, allowing users to simulate the execution path of a new or modified rule by inputting hypothetical data without affecting real online business data. The generated logs visually demonstrate the specific impact of the hypothetical data on the decision outcome, providing a reliable basis for rule verification before deployment and thus reducing the risk of online incidents.

[0018] Optionally, the method further includes: The simulated decision log is compared with the preset baseline decision log, and based on the differences identified in the comparison and the preset metadata associated with the rules that caused the differences, test conclusions are generated. The test conclusions include a differentiated report classified by impact level. Upon receiving a change confirmation instruction from an authorized user via a pre-defined confirmation interface, the simulated decision log is set as the new benchmark decision log for subsequent comparisons.

[0019] The above technical solutions construct a complete closed-loop process for rule regression testing and benchmark management. By automatically comparing the results of simulation runs with known and correct benchmark logs and generating difference reports, rapid and automated assessment of the impact of rule changes is achieved. The provided benchmark setting function ensures that testing standards are updated synchronously with rule iterations, greatly improving the quality and efficiency of rule maintenance.

[0020] Secondly, embodiments of this application provide an electronic device, including a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, and both the user interface and the network interface are used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method described in any of the above-mentioned methods.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed, perform the method described in any of the above-mentioned embodiments.

[0022] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a server, cause the server to perform the method described in the first aspect and any possible implementation thereof.

[0023] It is understood that the electronic device provided in the second aspect, the computer-readable storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] In summary, implementing one or more technical solutions provided in this application has at least the following technical effects or advantages: By employing and caching handles, the overhead of repeated reflection lookups is avoided, thereby improving processing performance. To address potential data inconsistencies caused by caching, the rules include caching strategy information. This strategy, after the pre-defined operation of the rule is executed, immediately determines whether the new state of the business object meets the cache invalidation condition and invalidates the corresponding cache handle. This mechanism directly binds cache cleanup logic to rule actions, forming a self-managed closed loop. This ensures that caching acceleration and data consistency coexist, achieving high performance and high reliability in dynamic rule processing. Attached Figure Description

[0025] Figure 1 This is an exemplary system architecture diagram of a dynamic rule processing method based on declarative configuration proposed in this application; Figure 2 This is a flowchart illustrating a dynamic rule processing method based on declarative configuration in an embodiment of this application. Figure 3 This is a schematic diagram of the structure of an electronic device disclosed in the application embodiment.

[0026] Explanation of reference numerals in the attached figures: 100, System architecture; 101, First terminal device; 102, Second terminal device; 103, Third terminal device; 104, Network; 105, Server; 301, Processor; 302, Communication bus; 303, User interface; 304, Network interface; 305, Memory. Detailed Implementation

[0027] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0028] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0029] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0030] For clarity, the term "handle" as used in this application refers to a direct reference or accessor to a field or method within a business object. In implementations of object-oriented languages ​​such as Java, it can specifically correspond to a java.lang.reflect.Field or java.lang.reflect.Method object.

[0031] Figure 1 An exemplary system architecture diagram is shown, illustrating an embodiment of a dynamic rule processing method based on declarative configuration that can be applied according to this application.

[0032] like Figure 1 As shown, the system architecture 100 may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 is used as a medium to provide communication links between the terminal devices 101, 102, 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0033] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as model training applications, video recognition applications, web browser applications, social platform software, etc.

[0034] Terminal devices 101, 102, and 103 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptops, and desktop computers, etc. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services) or as a single software program or software module. No specific limitations are imposed here.

[0035] When terminals 101, 102, and 103 are hardware devices, video capture devices can also be installed on them. These video capture devices can be various devices capable of capturing video, such as cameras, sensors, etc. Users can use the video capture devices on terminals 101, 102, and 103 to capture video.

[0036] Server 105 can be a server that provides various services, such as a backend server for processing data displayed on terminal devices 101, 102, and 103. The backend server can analyze and process the received data and can feed back the processing results (such as recognition results) to the terminal devices.

[0037] It should be noted that a server can be either hardware or software. When the server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services), or as a single software program or software module. No specific limitations are made here.

[0038] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included. In particular, if the target data does not need to be obtained remotely, the above system architecture may exclude the network and include only terminal devices or servers.

[0039] Figure 2 This is a flowchart illustrating a dynamic rule processing method based on declarative configuration, as described in this application. This method can be implemented using a computer program or a microcontroller. The computer program can be integrated into an application or run as a standalone utility application. The specific steps of a dynamic rule processing method based on declarative configuration are described in detail below.

[0040] S201: Obtain and parse the preset declarative rule configuration file. The declarative rule configuration file contains multiple rules. Each rule contains a condition expression, action instructions, and caching strategy information to guide caching behavior.

[0041] In this embodiment, a declarative rule configuration file refers to an external file that is independent of hard-coded code and used to centrally define business logic. Its "declarative" nature means that the file only needs to describe the business objective (e.g., "a 10% discount is given when the user's level is VIP"), without describing the specific programming implementation, thus decoupling the rules from the execution engine. For example, the file can be a YAML or JSON text file that defines a series of rules. Each rule contains explicit conditions, actions to be performed, and related metadata, allowing administrators to edit, add, or delete business rules by editing the file without modifying or redeploying the service.

[0042] Specifically, the system actively retrieves the content of the declarative rule configuration file from a preset local file path, network address (URL), or configuration center. After retrieval, the system uses the corresponding parser to perform syntax validation and structured parsing of the file content, ensuring its correct format. During this process, it reads multiple rules defined in the file one by one, extracting and verifying key information within each rule. The conditional expression refers to the logical judgment statement used to trigger the rule. It defines the prerequisite for the rule to take effect. For example, "order.amount>500" means to judge whether the value of the "amount" field in the "order" business object is greater than 500. If the result of this condition judgment is true (satisfied), then the rule associated with this condition will be triggered and the corresponding action instruction will be executed. The action instruction refers to the specific operation that needs to be performed on the business object when the condition is met. For example, "order.setDiscount(0.9)" means to call the "set discount" method of the "order" object and set the discount value to 0.9. This operation will directly modify the state of the order object and is the final manifestation of the rule logic in the business data. The caching strategy information is the metadata attached to the rule, which is used to indicate how to cache and invalidate the handles related to the rule in subsequent steps. For example, it defines the triggering condition "when the state of the order object changes, the cache of the handles related to the object will be invalidated". After the entire parsing process is completed, the original configuration file text is transformed into a structured set of rule data that the program can directly use, preparing for the next step of building an executable rule object in memory.

[0043] To further clarify the technical solution of this application, the following uses YAML format as an example and the business scenario of e-commerce platform order price calculation as an example to illustrate its structure and content by showing key fragments in the declarative rule configuration file.

[0044] A complete configuration file contains multiple rules, and each rule is defined by several attributes.

[0045] # rules-config.yaml.

[0046] rules: id: RULE_001 Name: "High-Value Orders - Exclusive Discounts for Diamond Members" priority: 100 # Highest priority.

[0047] triggerField: "user.level" # The trigger field used for indexing.

[0048] condition: "order.getFinalPrice()>1000&&user.level == 'DIAMOND'" action: "order.applyDiscount('DIAMOND_EXCLUSIVE', 0.85)" # 15% off.

[0049] cachePolicy: # Use a weak reference cache for the getFinalPrice method handle of the order object.

[0050] - target: "order.getFinalPrice" strategy: "weakReference" # When the applyDiscount method of the order object is executed, all cached handles associated with the order object are invalidated.

[0051] - target: "order.applyDiscount" invalidateOn: "actionExecuted" The above YAML file example specifically demonstrates the structure and content of the declarative rule configuration file. After being obtained and parsed in step S201, this file will serve as the data basis for all subsequent processing steps.

[0052] id and name: These are the unique identifier and readable name of the rule, respectively, used for management and identification.

[0053] priority: Defines the priority value of the rule. As shown in the example, RULE_001 has the highest priority (100) and will be evaluated first in subsequent processing.

[0054] triggerField: Specifies the trigger field used for index optimization. For example, when the level field of the business object user changes, the system can quickly locate RULE_001 and RULE_002 through the index without traversing all rules.

[0055] condition: This is a conditional expression string. For example, in RULE_001, "order.getFinalPrice()>1000&&user.level=='DIAMOND'" defines that the rule must meet two prerequisites simultaneously for it to take effect: the order amount must be greater than 1000 and the user level must be a diamond member.

[0056] action: This is the action instruction string. For example, in RULE_001, "order.applyDiscount('DIAMOND_EXCLUSIVE',0.85)" indicates that the applyDiscount method of the order object should be called when the conditions are met, and the corresponding discount parameters should be passed in.

[0057] cachePolicy: This is cache policy information, a complex object used to fine-tune cache behavior in subsequent steps.

[0058] In RULE_001, the policy specifies that the handle of the `order.getFinalPrice` method is cached using a weak reference (`weakReference`). This weak reference is a special memory management mechanism that allows the cache to hold the handle to improve performance, but does not prevent the garbage collector from automatically reclaiming its memory when only the cache references it. This cleverly prevents memory leaks caused by the cache holding objects for a long time, and triggers cache invalidation after the `order.applyDiscount` action is executed (`actionExecuted`). Through this example, those skilled in the art can clearly understand how declarative rule configuration files completely encapsulate all the business logic and non-functional strategies (such as caching, priority, etc.) of a single rule in a structured, human-readable manner, thereby achieving decoupling between rules and program code.

[0059] S202: Based on a declarative rule configuration file, it constructs a collection of rule objects corresponding to each rule in memory and initializes an adaptive cache.

[0060] In this embodiment, the rule object set refers to a group of executable rule entities formed by instantiating and encapsulating the structured rule data parsed in the previous step in memory. This process represents the transformation of static configuration information into dynamic, object-oriented program units, where each rule object completely encapsulates all elements of a single rule, including its triggering conditions, execution actions, and caching strategies. For example, a parsed YAML rule entry {condition: 'user.level=="VIP", action: 'order.setDiscount(0.9)'} will become a RuleObject instance in memory after construction. This instance not only stores this string information but may also contain a pre-compiled representation of the condition judgment logic, which can be directly executed by subsequent processing steps.

[0061] Specifically, the system iterates through this dataset, instantiating a corresponding rule object in memory for each rule definition. During instantiation, not only are conditional expressions, action instructions, and caching strategy information stored as attributes in the object, but this information may also be preprocessed. For example, the conditional expression string may be compiled into an intermediate expression tree or bytecode that can be evaluated quickly, thereby optimizing subsequent matching performance. All instantiated rule objects are uniformly stored and managed in a collection (such as a list or map), forming a rule object collection. At the same time, the system initializes an adaptive cache, which is usually a key-value pair storage structure (such as a hash map), specifically used to store and manage handles dynamically generated during rule execution. The initialization action involves creating an empty instance of this cache and possibly setting its initial capacity, concurrency level, or cache eviction policy (such as LRU) according to system configuration, making it ready to provide high-performance data access support in subsequent rule execution. Its adaptability is not only reflected in the ability to choose between strong or weak reference storage methods based on the strategy of a single rule, but also in some more complex embodiments, it can refer to the ability of the cache to adaptively adjust the priority or lifespan of cache items based on runtime statistics such as the historical hit rate and execution frequency of the rule.

[0062] In one possible implementation, based on a declarative rule configuration file, a set of rule objects corresponding to each rule is constructed in memory, and an adaptive cache is initialized. Specifically, this includes: parsing the declarative rule configuration file to identify and extract the conditional expressions, action instructions, caching strategy information, and preset priority values ​​contained in each rule; pre-compiling the extracted conditional expressions and action instructions for each rule; creating a rule object instance for each rule in memory, and storing the pre-compiled conditional expressions, action instructions, caching strategy information, and priority values ​​into the corresponding attributes of the rule object instance; aggregating all created rule object instances to obtain a set of rule objects; and creating and initializing a key-value storage structure in memory as an adaptive cache.

[0063] In this embodiment, the declarative rule configuration file refers to a structured text file used to describe business rule logic. Its key feature is that it only requires declaring the triggering conditions and execution actions of the rules, without defining the specific execution process code, thus achieving separation of business logic and program code. This file is typically written in a human-readable format such as YAML, JSON, or XML. The conditional expressions it contains define the logical judgments that must be satisfied to trigger the rule, the action instructions specify the operations to be performed after the conditions are met, the caching policy information guides the caching behavior related to rule execution, and the priority value is used to determine the execution order between rules. For example, a JSON-formatted rule fragment could be: {"priority": 100, "condition": "user.age>18", "action": "user.setGroup('adult')", "cachePolicy": "invalidate_on_write"}.

[0064] Specifically, when the rule engine starts or receives an update instruction, it loads a declarative rule configuration file located in a preset path. A built-in parser (such as a YAML or XML parser) performs syntactic parsing on the text content of this file. During this process, the parser strictly adheres to predefined structural specifications, accurately identifying and extracting the four core elements constituting each rule: a string-based conditional expression, an action instruction, caching strategy information guiding caching behavior (such as a specific strategy identifier), and a preset priority value for sorting. To improve subsequent execution efficiency, the system does not directly use these raw strings. Instead, for each rule, it pre-compiles the extracted conditional expression and action instruction. This process converts the string expression into an intermediate form that is easier for the machine to execute, such as an Abstract Syntax Tree (AST) object or bytecode. The system instantiates a rule object instance in memory for each parsed and compiled rule. This is a structured data object. The system then fills the corresponding attributes of the rule object instance with the pre-compiled conditional expression and action instruction obtained in the previous step, as well as the originally extracted caching strategy information and priority value. All created rule object instances are added to a collection-type data structure (such as a List), thus forming a complete collection of rule objects in memory. The system creates a key-value store structure, such as a HashMap, and initializes it as an adaptive cache. At this point, the cache is usually empty and is prepared to be used to store and manage handles in subsequent rule executions to improve access performance.

[0065] S203: Obtain the business objects to be processed, traverse the rule object collection according to the preset priority order, and apply each rule object in the rule object collection to all business objects in turn through the following steps: S204: Using a preset strategy-driven handle acquisition mechanism, obtain the first handle corresponding to the target field or target method defined in the conditional expression of the rule object, and use the obtained first handle to extract data values ​​from the business object. Compare the extracted data values ​​with the preset judgment logic in the conditional expression to generate a conditional matching result. S205: When the condition matching result is satisfied, use the handle acquisition mechanism to obtain the second handle corresponding to the target field or target method defined in the action instruction of the rule object, and use the obtained second handle to perform preset operations on the business object, including field assignment or method call. S206: After performing a preset operation on a business object, determine whether the current state of the business object meets the cache invalidation triggering conditions defined in the cache strategy information. If it does, invalidate the corresponding handle in the adaptive cache according to the cache strategy information.

[0066] To more clearly illustrate the technical solution of the present invention, a specific embodiment is described below. In this embodiment, after the server executes the aforementioned steps S201 to S203, namely, obtaining and parsing the configuration file, constructing a set of rule objects in memory, and obtaining the business objects to be processed, it will enter the traversal and processing stage of the rule objects.

[0067] Specifically, the server employs a loop or iterative structure, retrieving rule objects one by one from the rule object set for processing according to a preset priority order. The loop process is as follows: Loop traversal begins: The server retrieves the first rule object from the set of rule objects that have been sorted by priority.

[0068] Loop Body - Step S204: The server performs condition matching on the currently retrieved rule object. This involves using the handle acquisition mechanism to extract data from the business object and compare it with the conditional expression of the rule object, generating a result indicating whether the condition is met or not.

[0069] Loop Body - Step S205: The server checks the condition matching result of the previous step. If the result is satisfied, the server continues to execute the action instructions associated with the rule object, such as assigning a value to a field of the business object. The server then checks whether the cache invalidation trigger condition is met. If the result is not satisfied, it means that the current rule object is not applicable to the business object. The server will skip the subsequent action execution and cache judgment steps, directly end the current loop, and enter the next loop to process the next rule object in the set.

[0070] Loop Body - Step S206: Only after the action instruction was executed in step S205 will the server further determine whether the current state of the business object meets the cache invalidation trigger condition. If it does, the corresponding handle will be invalidated according to the caching policy. If it does not meet the condition, no operation will be performed.

[0071] Loop condition judgment and iteration: After executing step S206 (or after skipping subsequent steps in step S205 due to the condition not being met), the server considers a rule object to have been processed. At this time, the server checks whether there are any unprocessed rule objects in the rule object set. If so, the server returns to the beginning of the loop, retrieves the next rule object with priority from the set, and repeats steps S204 to S206. If not (all rule objects have been processed), the loop ends, and the entire dynamic rule processing flow is complete.

[0072] In one possible implementation, the rule object set is traversed according to a preset priority order, specifically including: before traversing the rule object set, sorting the rule objects in the rule object set in descending order according to the priority value contained in each rule; starting from the highest priority rule object in the descending order, processing is performed sequentially to determine the first condition matching result as the target rule object that is satisfied; after executing the action instruction corresponding to the target rule object, the traversal and processing of subsequent low priority rule objects is terminated.

[0073] In this embodiment, terminating the traversal and processing of subsequent low-priority rule objects refers to an execution control strategy where the first matching rule wins. This strategy means that in a priority-ordered rule sequence, once the first rule that meets the conditions is found and its corresponding action is successfully executed, the entire rule traversal and evaluation process is immediately interrupted. For example, consider a set of mutually exclusive membership level determination rules (Diamond, Platinum, Gold), arranged in descending order of priority. When a user's spending meets the conditions for the highest priority Diamond membership, the system will mark them as a Diamond member and immediately terminate the subsequent judgment of Platinum and Gold level rules. The effect of this control strategy is that in a priority-ordered rule sequence, only the action corresponding to the first rule that meets the conditions is executed. After the corresponding action is executed, the rule traversal and evaluation process is interrupted, and subsequent low-priority rules will not be processed.

[0074] Specifically, this implementation performs preprocessing on the complete set of rule objects before starting the traversal. This involves sorting the entire set in descending order based on the priority value stored within each rule object, ensuring the orderliness of subsequent processing. The system starts from the top of the sorted list (the highest priority rule) and retrieves rule objects one by one for condition matching. If the condition of the current rule is not met, it is skipped, and the system continues processing the next lower priority rule. Once the first rule object with a matching condition is detected, the system immediately executes its corresponding action instruction. Crucially, after this action instruction is executed, the system terminates the traversal and processing of subsequent lower priority rule objects, immediately exiting the current traversal loop. This ensures that for the same business object, only the highest priority rule with a matching condition takes effect, thus guaranteeing the uniqueness of the decision and the efficiency of execution.

[0075] Regarding step S204, in this embodiment, the strategy-driven handle acquisition mechanism refers to a high-performance object access method that incorporates a caching strategy. This mechanism means that when obtaining a direct reference (i.e., a handle) to a target field or method of a business object, it does not always generate it in real-time using high-overhead methods such as reflection, but rather follows a preset strategy. The core of this strategy is cache priority, that is, it prioritizes checking whether a valid target handle already exists in the adaptive cache. For example, when the amount field of the Order object is accessed for the first time, the mechanism generates a handle through reflection and stores it in the cache according to the strategy; when the field is accessed again subsequently, the mechanism will directly obtain the handle from the cache, thus eliminating the need to perform reflection operations again.

[0076] Specifically, for the currently traversed rule object, the system parses its conditional expression (e.g., order.amount>1000) and determines that the target field to be accessed is order.amount. It then initiates a strategy-driven handle acquisition mechanism to obtain the first handle corresponding to this target field. After acquisition, the system uses this efficient handle to directly extract the current data value from the business object (e.g., the actual value of order.amount is 1200). This extracted data value (1200) is compared with the preset judgment logic in the conditional expression (i.e., >1000). Based on the comparison result, a Boolean conditional matching result is generated. In this example, because 1200 is greater than 1000, the generated conditional matching result is true. This result will serve as the direct input for subsequent steps to determine whether the action instruction for this rule needs to be executed.

[0077] In one possible implementation, a pre-defined strategy-driven handle acquisition mechanism is used to obtain a first handle corresponding to the target field or target method defined in the conditional expression of the rule object. Specifically, this includes: determining whether a first handle that satisfies a pre-defined cache validity criterion exists in the adaptive cache based on the cache strategy information corresponding to the rule object, wherein the pre-defined cache validity criterion corresponds to the target field or target method defined in the conditional expression of the rule object; if it does not exist, a first handle is generated through reflection and stored in the adaptive cache according to the cache strategy information; if it exists, the first handle is directly obtained from the adaptive cache.

[0078] In this embodiment, the cache validity criterion refers to a set of verification rules used to determine whether a handle stored in the adaptive cache is still usable. It represents an additional verification procedure performed besides checking if a handle exists in the cache, to ensure that the acquired handle is not an outdated handle that has become invalid due to data state changes or system updates. For example, one criterion could be time-to-live (TTL), stipulating that a handle stored in the cache automatically expires after 5 minutes; another criterion could be version-based, requiring that the handle's version number must match the structure version number of the current business object. These criteria effectively prevent potential data errors caused by using obsolete handles.

[0079] Specifically, when it's necessary to retrieve the first handle corresponding to the target field "order.amount" defined in the rule condition expression (e.g., "order.amount>1000"), this handle refers to a memory reference that can be directly and efficiently accessed for that field. This mechanism first accesses the adaptive cache, which is typically a key-value store (such as a hash map) used to store generated handles for reuse. Then, based on the caching strategy information attached to the current rule object, the system determines whether a first handle exists in the cache that satisfies the preset cache validity criteria. These criteria not only check if the key name (e.g., "order.amount") exists but may also include verifying whether the handle has become invalid due to weak reference reclamation, ensuring that the retrieved handle is usable. If the result is "exists," the existing first handle is directly read from the adaptive cache and returned, completing the retrieval operation; this is the cache hit path. Conversely, if the result is "not found," it indicates a cache miss or that the cached handle has expired. In this case, the system will activate a backup reflection mechanism. This mechanism can dynamically search for and generate a corresponding handle instance in the class definition of the business object based on the string name of the target field ("order.amount") at runtime. Before returning this newly generated first handle to the caller for subsequent conditional judgments, it will be stored in the adaptive cache again according to the current rule's caching strategy information (e.g., the strategy specifies the use of strong or weak references) for reuse in subsequent identical requests. This process ensures that a valid handle is obtained each time and achieves dynamic cache updates and performance optimization.

[0080] In one possible implementation, a first handle is generated via reflection, and the generated first handle is stored in an adaptive cache according to the caching strategy information. Specifically, this includes: using reflection, locating the target field or target method in the class corresponding to the business object based on the string name of the target field or target method, and performing a preset security check; when the security check passes, obtaining the first handle of the target field or target method; determining whether the caching strategy information specifies the use of a weak reference encapsulation strategy: if yes, creating a weak reference object encapsulating the first handle, and storing the string name and the weak reference object as a key-value pair in the adaptive cache; if no, storing the string name and the first handle as a key-value pair in the adaptive cache.

[0081] In this embodiment, the weak reference encapsulation strategy refers to a caching storage method for optimizing memory management. This strategy means that when storing a handle in the cache, instead of directly storing its strong reference, a weak reference object that does not prevent the garbage collection (GC) from reclaiming the handle is created and stored. The core of this mechanism is that when a handle is no longer used elsewhere in the system, even if a weak reference to it still exists in the cache, the garbage collector can still reclaim the memory it occupies. For example, after a handle is stored in the cache using a weak reference, if the handle is no longer held by any strong reference after the business process ends, the garbage collector will reclaim it. The next time the system attempts to retrieve the handle from the cache, it will find that the weak reference has been cleared, thus indicating that the handle has expired. This method effectively prevents memory leaks caused by long-term cache holding of objects, enhancing system stability.

[0082] Specifically, this process begins with a cache miss, requiring the generation of a new handle. The system uses reflection to search and locate the target field or method in the class definition of the business object based on the string name (e.g., 'amount') obtained from the rules. Upon successful location, a handle is not immediately generated; instead, a security check is performed. This check verifies whether the string name of the target field or method exists in a pre-defined whitelist of accessible targets or a blacklist of prohibited targets, preventing unauthorized operations by the rule configuration and ensuring system security. Only after the security check passes will the system officially create and obtain the first handle to the target field or method. Subsequently, the system checks the current rule's caching strategy information to determine if a weak reference encapsulation strategy is specified. If so, the system creates a weak reference object encapsulating this first handle. This is a special wrapper object that holds a reference to the handle but does not prevent the garbage collector from reclaiming it. The target's string name and this newly created weak reference object are then stored as a key-value pair in the adaptive cache, with the string name as the key and the weak reference object as the value. If not, it indicates that the default strong reference strategy is adopted, and the system will directly store the string name and the first handle itself as a key-value pair in the adaptive cache. This series of steps ensures that handle generation combines security and memory management flexibility.

[0083] To more clearly reveal the internal workflow of the policy-driven handle acquisition mechanism in this application's embodiments, a specific computer implementation of this mechanism will be illustrated below through a pseudocode example. This pseudocode demonstrates how the system, when needing to access a field or method of a business object, integrates multiple technologies such as cache priority, reflection creation, security verification, and dynamic caching strategy selection to achieve handle acquisition that balances high performance, high security, and high reliability. An example is as follows: / / Global adaptive cache used to store generated handles.

[0084] / / In practice, thread-safe hash tables, such as ConcurrentHashMap, are often used.

[0085] GLOBAL adaptiveCache = new ConcurrentHashMap() / / Function: Gets a handle to the target field or method.

[0086] / / Parameter targetName: The fully qualified name of the target, such as "order.getFinalPrice".

[0087] / / Parameter bizObject: The current business object instance.

[0088] / / Parameter aRule: The rule object that triggers this operation.

[0089] FUNCTION getHandle(targetName, bizObject, aRule): / / Step 1: Prioritize looking for handles in the adaptive cache.

[0090] IF adaptiveCache.containsKey(targetName) THEN handleOrRef = adaptiveCache.get(targetName) / / Step 1.1: Handling the case of weak reference encapsulation strategy.

[0091] IF handleOrRef IS a WeakReference THEN handle = handleOrRef.get() / / Attempts to get the actual handle from the weak reference.

[0092] IF handle IS NOT NULL THEN / / Weak references are still valid, and the cache is hit.

[0093] RETURN handle END IF / / If handle is null, it means the object has been garbage collected, the cache is invalid, and continue to execute the subsequent steps.

[0094] ELSE / / In the case of a strong reference, the handle is returned directly.

[0095] RETURN handleOrRef END IF END IF / / Step 2: Cache miss or invalidation, dynamically generated through reflection mechanism.

[0096] / / Search for the corresponding field or method in the class definition of the business object based on the string name.

[0097] handle = reflectivelyFindFieldOrMethod(bizObject.getClass(),targetName) / / Step 2.1: Verify that the target exists.

[0098] IF handle IS NULL THEN THROW new Exception("Target field or method not found: " + targetName) END IF / / Step 3: Perform the preset security check.

[0099] IF performSecurityCheck(handle) == FALSE THEN THROW new SecurityException("Access to the target is forbidden by the security policy:"+targetName) END IF / / Step 4: Store the new handle in the adaptive cache according to the caching strategy information of the rule.

[0100] cachePolicy=aRule.getCachePolicyFor(targetName) / / Get the specific caching policy for this target.

[0101] IF cachePolicy IS NOT NULL AND cachePolicy.strategy == "weakReference" THEN / / The strategy specifies the use of weak references for encapsulation.

[0102] adaptiveCache.put(targetName, new WeakReference(handle)) ELSE / / By default or by strategy, strong references are used to store the data directly.

[0103] adaptiveCache.put(targetName, handle) END IF / / Step 5: Return the newly created and cached handle.

[0104] RETURN handle END FUNCTION Step 1 embodies the principle of prioritizing caching. Instead of performing costly reflection operations every time, the system first checks if the target handle already exists in the `adaptiveCache`. This significantly improves performance when repeatedly accessing the same field or method. Step 1.1 specifically handles cache items encapsulated with weak references. Weak references allow the garbage collector to automatically reclaim handle objects when memory is low, effectively preventing memory leaks caused by long-term object references held by the cache. The code checks if the handle within the weak reference object is NULL to determine if the cache is still valid.

[0105] Step 2 demonstrates a fallback mechanism for cache misses. The system utilizes reflection to dynamically search within the business object's class based on the target's string name, thereby creating a handle instance at runtime. Step 2.1 ensures that the system can promptly throw an exception when rule configuration errors occur (e.g., a referenced field or method does not exist), enhancing the system's robustness.

[0106] Step 3 introduces a critical security control point. Before using the handle created by reflection, the system calls the `performSecurityCheck` function to determine whether the operation is permitted based on a preset whitelist or blacklist policy. This step is the core defense line for ensuring the secure operation of the rule engine and preventing malicious rule execution of unauthorized operations.

[0107] Step 4 demonstrates the adaptability of the caching strategy. The newly generated handle is cached before returning for later reuse. At this point, the system reads the caching strategy information defined in the current rule object `aRule` to determine whether to use strong or weak references for storage. This design allows caching behavior to be flexibly defined by the rule itself, achieving fine-grained memory management.

[0108] Through the organic combination of the above series of steps, the handle acquisition mechanism proposed in this application achieves a balance between high performance, high security, and flexible memory management in a single complete call process.

[0109] Regarding step S205, in this embodiment, the second handle refers to a directly executable reference corresponding to the action instruction of the rule. It represents a direct access channel pointing to a specific method or writable field in a business object, and its main purpose is to change the state of the business object, which contrasts with the first handle, which is mainly used for reading data. For example, if the action instruction of a rule is "order.setDiscount(0.9)", then the corresponding second handle is a direct reference to the setDiscount method in the Order class. Subsequent operations can efficiently complete the discount operation on the order object by calling this handle and passing the parameter 0.9, thereby executing the business logic defined by the rule.

[0110] Specifically, the condition matching result of step S204 is used as a prerequisite. This step is only executed if the result is true. After activation, the system parses the action instruction of the current rule object (such as order.setDiscount(0.9)) and uses the strategy-driven handle acquisition mechanism again to obtain the second handle corresponding to the instruction (i.e., the setDiscount method). This acquisition process also follows the cache priority principle. Once the second handle is obtained, the system uses it to perform operations on the business object: if the handle points to a method, the system calls the method and passes in the parameters defined in the instruction (such as 0.9); if the handle points to a field, the system updates the value of the field. This operation directly changes the internal state of the business object. For example, the discount field of the order object is successfully set, thus completing the final manifestation of the rule logic in the business data.

[0111] Regarding step S206, in this embodiment, the cache invalidation trigger condition refers to a set of logical judgments predefined in the caching strategy information of the rule. It represents a rule used to declare when cached data becomes invalid. Its core purpose is to proactively identify and clear cached items that may become inconsistent after a change in the state of a business object. For example, if the action of a rule is "to upgrade the user level from 'Silver' to 'Gold'", then its caching strategy can define a trigger condition: "when the value of the user.level field is modified". This condition ensures that after the user level is successfully modified, the system can proactively invalidate the cache handle associated with the user.level field, thereby preventing other subsequent rules from reading the outdated "Silver" state.

[0112] Specifically, the system reads the caching strategy information carried by the rule object that just completed the action and finds the predefined cache invalidation trigger condition. The system evaluates this trigger condition based on the latest state of the business object after the operation. If the evaluation result is not met, no operation is performed, and the current step ends. If the evaluation result is met, it means that a cache invalidation event has been triggered. At this time, the system will again locate one or more handles that need to be invalidated in the adaptive cache according to the indication of the caching strategy information (for example, the strategy may explicitly specify the name or associated fields of the handle to be invalidated) and perform the invalidation operation. This operation usually manifests as invalidating the corresponding handle in the adaptive cache, such as removing the corresponding key-value pair from the cache hash table. This post-execution check and cleanup mechanism ensures that the state changes caused by rule execution can be reflected in the cache in a timely manner, thereby ensuring data consistency during subsequent rule processing.

[0113] Optionally, the method also includes: receiving a simulated business object, a simulation rule to be verified, and hypothetical data for overwriting specific field values ​​in the simulated business object through a preset decision simulation interface; performing condition evaluation based on the simulation rule and the simulated business object overwritten by the hypothetical data, and generating a simulation decision log, in which the impact points of the hypothetical data on the decision path are marked.

[0114] In this embodiment, the hypothetical data used to overwrite specific field values ​​in the simulated business object is a set of key-value pairs provided by the user during simulation execution. During evaluation, these key-value pairs are used to overwrite the corresponding field values ​​in the in-memory copy of the simulated business object, while the original simulated business object itself remains unmodified. For example, when testing a rule that "free shipping is offered for orders over 500 yuan," the tester can use a standard simulated order of 300 yuan and provide a set of hypothetical data {'amount': 501}. The simulation engine will treat the order amount as 501 yuan during evaluation, thereby verifying whether the rule is correctly triggered at the threshold, greatly improving the flexibility and efficiency of testing.

[0115] Specifically, this process is initiated through a decision simulation interface. The system receives three types of input via this interface: a simulated business object (such as a standard order) as baseline data, one or more simulation rules to be verified, and a set of optional hypothetical data (such as {'amount': 501}). During processing, the system creates a memory snapshot based on the simulated business object and overwrites the corresponding field values ​​with the hypothetical data. The system performs conditional evaluation based on this modified simulated business object and simulation rules, just like normal execution. However, the key difference is that even if the conditional evaluation result is met, the system will not execute the action instructions corresponding to the simulation rules. At each step of the evaluation, the system records the decision-making process in detail, ultimately generating a simulation decision log. This log not only contains the complete decision chain and the evaluation results at each step, but also specifically indicates the points where the hypothetical data affects the decision path. For example, it explicitly states that "the condition order.amount>500 is true because the hypothetical data amount=501". The log records include the decision path, the evaluation results at each step, and clearly indicates which decision nodes' evaluation results are due to the overwriting of the hypothetical data.

[0116] Optionally, the method further includes: comparing the simulated decision log with a preset benchmark decision log, and generating test conclusions based on the differences identified in the comparison and the preset metadata associated with the rules that caused the differences. The test conclusions include a differentiated report classified by impact level. After receiving a change confirmation instruction from an authorized user through a preset confirmation interface, the simulated decision log is set as a new benchmark decision log for subsequent comparisons.

[0117] In this embodiment, the preset baseline decision log refers to a previously verified and saved simulated decision log template. It represents the expected decision path under a specific combination of simulated business objects and rules, serving as a benchmark for subsequent automated regression testing. For example, after initial testing of a set of risk control rules, the system generates a decision log for a high-risk user simulation scenario and manually confirms it as the baseline. When the risk control rules are modified in the future, the system will simulate the high-risk user scenario again and compare the newly generated log with this existing baseline, thereby automatically and quickly determining whether the rule modification has introduced unexpected behavioral changes.

[0118] Specifically, after generating a new simulated decision log in the previous step, the system automatically retrieves the corresponding baseline decision log from storage and compares the two line by line and field by field to identify all differences in the decision path. Based on these differences and combined with the metadata associated with the rules that caused the differences (such as rule importance, responsible person, etc.), the system generates a structured test conclusion, i.e., a difference report. This report categorizes the differences to users according to preset impact levels (e.g., severe, moderate, warning). After reviewing this report, authorized users who believe the changes are as expected can send a confirmation command through a confirmation interface (e.g., an "Approve Change" button on a webpage). Once the system receives this command, it performs a baseline update operation, overwriting the old baseline log with the current simulated decision log to make it the new baseline decision log for future comparisons. This process achieves a closed-loop management system from automatic change discovery, impact analysis, manual review to adoption of new standards.

[0119] This embodiment also discloses an electronic device, as shown in the reference. Figure 3 The electronic device may include: at least one processor 301, at least one communication bus 302, user interface 303, network interface 304, and at least one memory 305.

[0120] The communication bus 302 is used to enable communication between these components.

[0121] The user interface 303 may include a display screen and a camera. Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0122] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0123] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 305, and by calling data stored in memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 301 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0124] The memory 305 may include random access memory (RAM) or read-only memory. Optionally, the memory 305 may include a non-transitory computer-readable storage medium. The memory 305 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. Figure 3 As shown, the memory 305, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program based on a dynamic rule processing method using declarative configuration.

[0125] exist Figure 3In the electronic device shown, the user interface 303 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 301 can be used to call an application program stored in the memory 305 that is a dynamic rule processing method based on declarative configuration. When executed by one or more processors 301, the electronic device executes one or more methods as described in the above embodiments.

[0126] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0127] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0128] In some embodiments of this application, a computer-readable storage medium is provided, including instructions that, when executed on an electronic device, cause the electronic device to perform a dynamic rule processing method based on declarative configuration according to an embodiment of this application.

[0129] In some embodiments of this application, a computer program product is also provided, which, when run on an electronic device, causes the electronic device to execute a dynamic rule processing method based on declarative configuration as described in this application.

[0130] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.

[0131] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0132] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0133] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 305 and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory 305 includes various media capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.

[0134] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the disclosure in this specification. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are considered exemplary only, and the scope of this application is defined by the claims.

Claims

1. A dynamic rule processing method based on declarative configuration, characterized in that, Applied to a server, the method includes: Obtain and parse a preset declarative rule configuration file, which contains multiple rules. Each rule contains a condition expression, an action instruction, and caching strategy information to guide caching behavior. Based on the declarative rule configuration file, a set of rule objects corresponding to each rule is constructed in memory, and an adaptive cache is initialized. Obtain the business objects to be processed, traverse the set of rule objects according to a preset priority order, and apply each rule object in the set of rule objects to all the business objects in sequence through the following steps: Using a preset strategy-driven handle acquisition mechanism, a first handle corresponding to the target field or target method defined in the conditional expression of the rule object is obtained, and the obtained first handle is used to extract data values ​​from the business object. The extracted data values ​​are compared with the preset judgment logic in the conditional expression to generate a conditional matching result. When the condition matching result is satisfied, the handle acquisition mechanism is used to obtain the second handle corresponding to the target field or target method defined in the action instruction of the rule object, and the obtained second handle is used to perform preset operations on the business object, including field assignment or method call. After performing the preset operation on the business object, it is determined whether the current state of the business object meets the cache invalidation triggering condition defined in the cache policy information. If it does, the corresponding handle in the adaptive cache is invalidated according to the cache policy information.

2. The method according to claim 1, characterized in that, The process of constructing a set of rule objects corresponding to each rule in memory based on the declarative rule configuration file and initializing the adaptive cache specifically includes: The declarative rule configuration file is parsed to identify and extract the conditional expression, action instruction, caching strategy information, and preset priority value contained in each rule; For each rule, the extracted conditional expression and action instruction are pre-compiled; Create a rule object instance for each rule in memory, and store the pre-compiled condition expression, action instruction, caching strategy information and priority value into the corresponding attributes of the rule object instance. Aggregate all the created rule object instances to obtain the rule object set; A key-value storage structure is created in the memory as the adaptive cache and initialized.

3. The method according to claim 1, characterized in that, The step of traversing the set of rule objects according to a preset priority order specifically includes: Before traversing the set of rule objects, the rule objects in the set of rule objects are sorted in descending order according to the priority value contained in each rule; Starting with the highest priority rule object in the descending sort, the rules are processed sequentially. The first condition matching result is determined to be the target rule object. After the action instruction corresponding to the target rule object is executed, the traversal and processing of subsequent low-priority rule objects are terminated.

4. The method according to claim 1, characterized in that, The method of using a preset strategy-driven handle acquisition mechanism to acquire the first handle corresponding to the target field or target method defined in the conditional expression of the rule object specifically includes: Based on the caching strategy information corresponding to the rule object, it is determined whether there is a first handle in the adaptive cache that satisfies a preset cache validity criterion, wherein the preset cache validity criterion corresponds to the target field or target method defined in the condition expression of the rule object; If it does not exist, the first handle is generated through reflection mechanism, and the generated first handle is stored in the adaptive cache according to the caching strategy information; If it exists, the first handle is obtained directly from the adaptive cache.

5. The method according to claim 4, characterized in that, The step of generating the first handle through reflection and storing the generated first handle into the adaptive cache according to the caching strategy information specifically includes: Using reflection, the target field or target method is located in the class corresponding to the business object based on its string name, and a preset security check is performed. When the security check passes, obtain the first handle of the target field or the target method; Determine whether the caching strategy information specifies the use of a weak reference encapsulation strategy: If so, a weak reference object encapsulating the first handle is created, and the string name and the weak reference object are stored as a key-value pair in the adaptive cache; If not, the string name and the first handle are stored as a key-value pair in the adaptive cache.

6. The method according to claim 1, characterized in that, The method further includes: The system receives a simulated business object, a simulation rule to be verified, and hypothetical data for overwriting specific field values ​​in the simulated business object through a preset decision simulation interface. Based on the simulation rules and the execution conditions of the simulated business objects overwritten by the hypothetical data, a simulation decision log is generated, which indicates the impact points of the hypothetical data on the decision path.

7. The method according to claim 6, characterized in that, The method further includes: The simulated decision log is compared with a preset baseline decision log, and based on the differences identified in the comparison and the preset metadata associated with the rules that caused the differences, a test conclusion is generated, which includes a differentiated report classified by impact level. Upon receiving a change confirmation instruction from an authorized user via a preset confirmation interface, the simulated decision log is set as a new benchmark decision log for subsequent comparisons.

8. An electronic device, characterized in that, Including processor and memory; The memory is used to store computer program code, the computer program code including computer instructions, and the processor invokes the computer instructions to cause the electronic device to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed on the electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-7.

Images