A benefit issuance verification method and device, electronic equipment and storage medium

Abstract

The application relates to the technical field of computer data processing, and provides a right benefit issuing verification method and device, electronic equipment and a storage medium, which comprise the following steps: acquiring rule configuration data, and converting the rule configuration data into an executable rule object set containing a hierarchical identifier and a time sequence constraint based on the role level of the rule configuration data; a mapping relationship between a target object and the executable rule object set is established; in response to receiving a verification request, the executable rule object set is loaded based on the mapping relationship, and multi-level combined verification is sequentially performed according to the time sequence constraint, and a decision result is output. The application realizes decoupling of rule configuration and execution logic, improves verification efficiency and consistency of multi-entry execution standards through structured levels and time sequence constraints.

Description

Technical Field

[0001] This invention relates to the field of computer data processing technology, and specifically to a rights issuance verification method, apparatus, electronic device, and storage medium. Background Technology

[0002] In complex internet business systems, multi-dimensional rule validation of user requests is often required, such as participation eligibility, resource quotas, time windows, and channel restrictions. In existing technologies, this validation logic is often embedded in various business interfaces in the form of hard-coded or flattened configurations, resulting in high coupling between rule configuration data and underlying execution logic. When business rule types are added or changed, frequent modifications to core code and redeployment are necessary, leading to poor system scalability. More critically, existing solutions lack structured constraints on the hierarchical level and execution sequence of rules, making it impossible to effectively utilize hierarchical dependencies for short-circuit optimization when facing complex combined validations, resulting in significant unnecessary consumption of computational resources. Furthermore, due to the lack of a unified rule object abstraction and caching mechanism, different business entry points struggle to maintain consistent parsing standards for the same rule, and repeated parsing in scenarios with large volumes of requests incurs substantial overhead, severely impacting the overall processing efficiency and response performance of the system. Summary of the Invention

[0003] To address the issues of low execution efficiency, high computational resource consumption, and inconsistent execution standards across multiple entry points in existing technologies for verifying complex business rules, this application achieves decoupling of rule configuration and execution logic through a rights issuance verification method, device, electronic device, and storage medium. Furthermore, it improves system verification efficiency and consistency through structured hierarchical and temporal constraints.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: Obtain rule configuration data and, based on the hierarchical level of the rule configuration data, convert the rule configuration data into a set of executable rule objects. The executable rule objects in the set of executable rule objects contain hierarchical identifiers and temporal constraints. Establish a mapping relationship between the target object and the set of executable rule objects. In response to receiving a verification request, load the set of executable rule objects based on the mapping relationship, and sequentially perform multi-level combined verification according to the temporal constraints, and output the decision result.

[0005] As one implementation method, the rule configuration data is converted into a set of executable rule objects based on the hierarchical level of the rule configuration data, including: dividing the rule configuration data into multiple hierarchical levels based on attribute information in the rule configuration data; generating the timing constraints based on the dependencies or preset priorities between the multiple hierarchical levels; and generating the set of executable rule objects based on the multiple hierarchical levels and the timing constraints.

[0006] As one implementation method, multi-level combined verification is performed sequentially according to the timing constraints, and a decision result is output, including: if the verification result of the current action level fails during the execution of the multi-level combined verification, the verification of subsequent action levels with dependencies is blocked according to the timing constraints; and a decision result of refusing to execute is generated based on the blocking result.

[0007] As one implementation, the executable rule object includes rule encoding, rule parameters, comparison method, and execution order; the step of sequentially performing multi-level combined verification according to the timing constraints includes: comparing the rule parameters with the corresponding parameters in the verification request according to the comparison method.

[0008] As one implementation method, establishing a mapping relationship between a target object and the set of executable rule objects includes: writing the set of executable rule objects into a cache and establishing a mapping relationship between the identifier of the target object and the set of executable rule objects; the step of loading the set of executable rule objects based on the mapping relationship in response to receiving a verification request includes: loading the corresponding set of executable rule objects from the cache based on the identifier of the target object in response to receiving the verification request.

[0009] As one implementation, the method further includes: in response to receiving a rule update instruction, invalidating the corresponding set of executable rule objects in the cache; regenerating a new set of executable rule objects based on the updated rule configuration data, and updating the mapping relationship.

[0010] As one implementation method, based on the hierarchical nature of the rule configuration data, the rule configuration data is converted into a set of executable rule objects, including: reading the rule code in the rule configuration data; querying the parser registry for a rule parser that matches the rule code; and converting the rule configuration data into the set of executable rule objects through the rule parser.

[0011] Furthermore, this invention also provides a dynamic parsing and verification device for multi-level business rules, comprising: a data acquisition module, used to acquire rule configuration data and, based on the hierarchical level of the rule configuration data, convert the rule configuration data into a set of executable rule objects, wherein the executable rule objects in the set of executable rule objects include hierarchical identifiers and temporal constraints; a mapping establishment module, used to establish a mapping relationship between target objects and the set of executable rule objects; and a combination verification module, used to, in response to receiving a verification request, load the set of executable rule objects based on the mapping relationship, and sequentially perform multi-level combination verification according to the temporal constraints, and output a decision result.

[0012] Furthermore, the present invention also provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described above.

[0013] In addition, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to perform the method described above.

[0014] Beneficial effects: This application transforms the traditional flat and disordered data processing model in rule validation by converting raw rule configuration data into a set of executable rule objects containing hierarchical identifiers and temporal constraints. This structured object construction method enables the system to strictly adhere to preset temporal constraints for multi-level ordered scheduling during validation. In particular, combined with the hierarchical dependency blocking mechanism, it can immediately terminate subsequent redundant calculations when pre-validation fails, thereby reducing the average computational complexity and resource consumption per request while ensuring the integrity of the validation logic. Simultaneously, by establishing a cache mapping between target objects and structured rule objects, the time-consuming parsing and conversion process is completely separated from the high-frequency validation execution process. This not only eliminates performance bottlenecks caused by repeated parsing in multi-entry scenarios but also ensures that all callers execute validation based on the same memory object, guaranteeing the global consistency of complex business rule judgment standards and the system's high concurrency processing capabilities from a fundamental technical perspective. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the overall architecture of the multi-level business rule dynamic parsing and verification system according to an embodiment of the present invention; Figure 2 This is a flowchart of the multi-level business rule dynamic parsing and verification method according to an embodiment of the present invention; Figure 3 This is a flowchart of the rule configuration data parsing and time series constraint generation process according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the executable rule object and its mapping relationship structure according to an embodiment of the present invention; Figure 5 This is a flowchart of multi-level combined verification and hierarchical blocking according to an embodiment of the present invention; Figure 6 This is a flowchart of the rule object cache mapping and dynamic refresh process according to an embodiment of the present invention; Figure 7 This is a flowchart of the dynamic matching process of the registry parser in an embodiment of the present invention; Figure 8This is a block diagram of the multi-level business rule dynamic parsing and verification device module according to an embodiment of the present invention; Figure 9 This is a schematic diagram of the electronic device structure according to an embodiment of the present invention; Figure 10 This is a schematic diagram of the multi-level combined verification process for rights issuance requests according to an embodiment of the present invention. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions in the embodiments of this invention will be described more clearly and completely below with reference to the accompanying drawings. It should be noted that the embodiments described below are only some exemplary embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort can fall within the protection scope of this invention.

[0017] Unless otherwise defined or expressly limited, the technical and scientific terms used herein shall have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The use of related terms in this specification is intended to describe specific embodiments and their technical relationships, and should not be construed as an undue limitation on the scope of protection of this invention.

[0018] Example 1 like Figure 1 and Figure 2 As shown, this embodiment provides a dynamic parsing and verification method for multi-level business rules. This method constructs structured rule objects and a temporal constraint mechanism to achieve standardized processing, orderly scheduling, and efficient execution of complex business rules. The method of this embodiment mainly includes the following steps.

[0019] Step S100: Obtain rule configuration data and, based on the hierarchical level of the rule configuration data, convert the rule configuration data into a set of executable rule objects. The executable rule objects in the set of executable rule objects contain hierarchical identifiers and timing constraints.

[0020] Specifically, rule configuration data is typically stored as raw business rule descriptions in text format (such as JSON, XML, or database records). It usually describes the content of business rules and does not directly correspond to an execution object that the validation engine can call, and may lack explicit execution order information. In this embodiment, the system first reads this raw data and identifies the scope level of each rule according to predefined metadata specifications. Here, scope level refers to the abstract position of the rule in the business logic tree, such as the user qualification level, resource quota level, or channel restriction level, rather than a specific business name. After identifying the scope level, the system uses a parsing engine to convert and instantiate rule configuration data from different sources and storage formats into executable rule objects in memory. It is important to note that the executable rule object is not merely a simple key-value pair mapping, but a specific memory data structure that encapsulates validation logic metadata. This object contains at least two key attributes: a scope identifier and a timing constraint. Among them, the hierarchical identifier is used to quickly classify the logical group to which the rule belongs at runtime, facilitating subsequent batch management or group skipping; the timing constraint is a numerical or enumerated scheduling parameter used to explicitly define the preset absolute execution position of the object in the overall verification chain or its execution position relative to other rule objects. Through this transformation, the originally flat and disordered configuration data is reconstructed into a structured collection of objects with inherent topological relationships, laying the data foundation for subsequent ordered scheduling. It should be understood that although... Figure 2 A linear parsing process is shown, but in other implementations, parallel parsing or batch asynchronous conversion can also be used, as long as the final generated object set can contain the level identifiers and corresponding timing information required to perform multi-level combination verification.

[0021] Step S200: Establish a mapping relationship between the target object and the set of executable rule objects.

[0022] Specifically, the target object refers to the core entity identifier pointed to by the business request, such as an activity ID, product SKU, or user account identifier. After the rule object is transformed, the system does not directly discard the object or simply keep it in a temporary variable. Instead, it writes it into a cache or memory policy pool for storage and reuse, and constructs a one-to-one or one-to-many index mapping using the unique identifier of the target object as the key and the corresponding set of executable rule objects as the value. This mapping essentially decouples the time-consuming rule parsing process from the high-frequency request verification process. When a large number of concurrent requests for the same target object are received in a short period of time, the system does not need to repeat the parsing and transformation operation in step S100. Instead, it directly retrieves and reuses the existing memory object instance through the identifier. This not only significantly reduces the CPU's computational overhead but also ensures that all verification requests for the same target can be executed based on the same effective rule version and rule state. This helps reduce the problem of inconsistent judgment standards caused by asynchronous parsing timing in multi-entry or multi-threaded environments and improves the execution consistency under the same rule version.

[0023] In step S300, in response to receiving the verification request, the set of executable rule objects is loaded based on the mapping relationship, and multi-level combined verification is performed sequentially according to the time sequence constraints, and the decision result is output.

[0024] Specifically, when the system receives an externally initiated verification request, it first extracts the target object identifier carried in the request and quickly loads the corresponding set of executable rule objects from the cache using the mapping relationship established in step S200. When the cache is hit and the system load, network status, and other operating conditions are suitable, the reading of rule objects can achieve a millisecond-level response. After loading, the verification engine does not execute according to the physical storage order or random order of the objects in the set, but strictly reads the timing constraint field inside each object and sorts or traverses the set in order. The timing constraint serves as the scheduling basis for the verification engine to determine the execution order, which is used to ensure that the verification logic is executed in a predetermined order or dependency relationship, thereby improving the determinism and predictability of the execution path. For example, the system can first execute the basic qualification verification with a smaller timing value, and then execute the complex resource deduction verification with a larger timing value. During execution, the verification engine calls the comparison logic encapsulated in each object, matches the request parameters with the rule parameters, and generates the corresponding decision result (such as pass, reject, or pending manual review) based on the verification results of all rules. This data-driven execution model eliminates the need for hard-coded if-else nested structures in the verification process. When adjusting verification priorities or inserting new rules, only the timing parameters in the configuration data need to be modified to trigger re-parsing, without changing the core code of the verification engine. Through this mechanism, this embodiment achieves relative decoupling between rule configuration and execution logic, ensuring verification accuracy while improving the system's scalability, rule maintenance efficiency, and operational efficiency.

[0025] Example 2 like Figure 3 , Figure 4 , Figure 5As shown in Example 1, this example further details the generation mechanism of timing constraints, the hierarchical blocking strategy, and the internal data structure of executable rule objects. As one implementation method, based on the hierarchical level of the rule configuration data, the rule configuration data is converted into a set of executable rule objects. Specifically, this includes: dividing the rule configuration data into multiple hierarchical levels based on attribute information; generating timing constraints based on the dependencies or preset priorities between multiple hierarchical levels; and generating a set of executable rule objects based on the multiple hierarchical levels and timing constraints. Specifically, attribute information refers to metadata tags in the rule configuration data used to characterize the scope of rule application, such as identifiers like "user," "activity," "budget," or "channel." The system parses these tags to categorize flat rule entries into different logical levels. Regarding the generation of timing constraints, this invention provides two parallel implementation paths to adapt to business scenarios of varying complexity. The first path is a static generation method based on preset priorities, where the rule configuration data explicitly contains a sequence field (such as sort_order). The system directly reads the value of this field as the timing constraint during parsing. This method is intuitive and suitable for simple scenarios with fixed hierarchical relationships. The second approach is a dynamic derivation method based on dependencies. The system predefines a directed acyclic graph (DAG) dependency model between different action levels; for example, the "budget layer" depends on the "activity layer," and the "channel layer" depends on the "user layer." During the parsing phase, the system performs topological sorting based on the levels involved in the currently loaded rule set, combined with the pre-defined dependency model. It calculates the executable sequence that satisfies the hierarchical dependency prerequisites and assigns the position index in this sequence to the timing constraint field of the corresponding object. The advantage of this dynamic derivation mechanism is that when adding new rule types or adjusting the hierarchical architecture, there is no need to manually rearrange the order of all rules. The system can ensure that the generated execution order satisfies the established dependencies and priority constraints, thus helping to reduce the operational complexity and configuration error probability caused by manually rearranging the rule order. When using the dynamic derivation method based on dependencies, the basic requirement of topological sorting is that any rule object corresponding to a dependent level enters the execution sequence before any rule object that depends on that level. When there are multiple levels that have no dependencies on each other, their order can be further determined by combining preset priorities.

[0026] Furthermore, to improve resource utilization efficiency in the verification process, this embodiment introduces a hierarchical blocking mechanism. Multi-level combined verification is executed sequentially according to timing constraints, and a decision result is output, including: if the verification result of the current level fails during the execution of multi-level combined verification, subsequent verifications of dependent levels are blocked according to timing constraints; a decision result of refusal to execute is generated based on the blocking result. Combined with... Figure 3The verification process shown can be understood as using the hierarchical dependency information corresponding to the timing constraints to short-circuit verification branches that do not need to continue execution. Specifically, when the verification engine executes a rule object at a certain level and determines that the result is a failure, it does not directly continue to traverse all remaining objects in the collection. Instead, it queries the dependency relationship between the current failed level and other levels that follow it in timing. If the subsequent levels logically depend on the current failed level (for example, the subsequent "budget deduction verification" must be based on the "user qualification verification" passing), or if the subsequent levels have high computational or I / O overhead and do not have independent execution significance under the current failure result, the system will immediately terminate the scheduling of these subsequent levels, directly encapsulate the rejection decision result containing the reason for the failure, and return it. For example, in a typical processing sequence, the system first performs a lightweight "user blacklist check" (time sequence T1). If this check fails, the system recognizes that the subsequent "real-time inventory locking" (time sequence T2) and "cross-domain budget deduction" (time sequence T3) are operations with dependencies or high I / O overhead, and therefore directly blocks the execution of T2 and T3. In this way, the present invention can avoid continuing to execute potentially invalid database queries, distributed lock contention, or remote service calls, achieving fine-grained control of computing resources from the underlying data processing logic, thereby helping to reduce the average response time and unnecessary CPU, database, and remote call resource consumption in high-concurrency rejection scenarios.

[0027] Furthermore, to support the aforementioned general verification scheduling logic, this embodiment also standardizes the data structure of executable rule objects. An executable rule object includes a rule code, rule parameters, comparison method, and execution order; it executes multi-level combined verification sequentially according to temporal constraints, including comparing the rule parameters with the corresponding parameters in the verification request based on the comparison method. Specifically, the rule code is the object's unique identifier in the system, used to associate it with specific verification operators or external service interfaces; the rule parameters store rvalue data such as thresholds, whitelists, or regular expressions required for verification. These data have undergone type conversion and validity verification from the original configuration during object construction, reducing the overhead of repeatedly performing type parsing and parameter validity verification at runtime; the comparison method is an enumerated field that explicitly specifies the logical operator to be used in this verification, such as "EQUALS", "GREATER_THAN", "CONTAINS", or "REGEX_MATCH"; the execution order carries the aforementioned temporal constraint information, guiding the traversal order of the verification engine. During actual verification execution, the verification engine, acting as a general interpreter, reads the comparison method field of the current object, calls the corresponding atomic comparison function through reflection or strategy mapping, and passes the dynamic parameters (left-hand values) extracted from the verification request and the rule parameters (right-hand values) within the object to the function for calculation. This structured design, which decouples "data" from "behavior," eliminates the need for the verification engine to fix the judgment branches corresponding to various specific business rules, and only handles sequential scheduling and general comparison. When new rule types need to be supported, the corresponding rule types can be implemented by extending the new comparison method enumeration values ​​and their corresponding comparison functions without modifying the engine's main loop code. This approach helps maintain the stability of the core verification chain, provides a standardized access specification for the continuous evolution of the rule system, and helps improve the consistency and predictability of rule execution behavior under multiple entry points and scenarios. For cases where multiple rule objects are contained in the same action level, they can be sorted within the level according to the execution order field, and then the verification result of that level can be formed according to the preset all-satisfied, any-satisfied, or other configured aggregation methods for use in subsequent level blocking judgments.

[0028] Example 3 like Figure 6As shown, based on Embodiments 1 and 2, this embodiment further details the caching mapping mechanism and dynamic refresh process of rule objects to support the system's performance and data consistency in high-concurrency scenarios. As one implementation method, establishing a mapping relationship between the target object and the set of executable rule objects includes: writing the set of executable rule objects into the cache and establishing a mapping relationship between the identifier of the target object and the set of executable rule objects; in response to receiving a verification request, loading the set of executable rule objects based on the mapping relationship includes: in response to receiving a verification request, loading the corresponding set of executable rule objects from the cache based on the identifier of the target object. Specifically, in an optional implementation, the cache can adopt a hierarchical caching architecture and a composite key design strategy to balance fast reading of rule objects, version differentiation, and cache lifecycle management. When writing to the cache, the system first converts the set of executable rule objects in memory into a byte stream using a binary serialization protocol (e.g., Protobuf or Hessian); compared to text serialization, this method can reduce the storage overhead caused by redundant text fields and help reduce CPU processing overhead during serialization and deserialization, provided the rule object structure and serialization protocol are compatible. In the design of the cache key, this embodiment adopts a combined structure of "business type + target object identifier + rule version number", such as "rule:act_10086:v20231001". One of the functions of this composite key design is to differentiate different rule versions in the key space. When a rule changes, the old and new versions of the cache can coexist for a short period of time, thereby supporting canary releases or rapid rollbacks and reducing potential concurrent read conflicts caused by directly overwriting the same cache key. In the reading process, the verification engine first constructs the cache key based on the target object identifier in the request, and prioritizes querying the local heap memory cache (L1 Cache). If it misses, it then accesses the distributed remote cache (L2 Cache). This multi-level caching mechanism keeps frequently accessed rule objects residing within the application process, which can reduce the network I / O overhead caused by repeated access to the remote cache by high-frequency requests. Under suitable conditions of local cache hit, system load, and network status, the rule loading time of a single verification request can be kept at a low level, reaching millisecond-level access, thereby supporting the improvement of rule reading throughput in scenarios with large batch requests. It should be noted that L1 Cache and L2 Cache are only used to illustrate an optional cache hierarchy organization method and do not require the use of specific cache products. Those skilled in the art can choose in-process caching, distributed caching, or a combination of the two based on the deployment scale, number of nodes, and access frequency.

[0029] Furthermore, to address the consistency issue between cached data and configuration source data, this embodiment also provides a corresponding dynamic refresh mechanism. As one implementation method, the method further includes: in response to receiving a rule update instruction, invalidating the corresponding set of executable rule objects in the cache; regenerating a new set of executable rule objects based on the updated rule configuration data, and updating the mapping relationship. Specifically, the rule update instruction is typically triggered by a configuration change event in the operations backend. When the system receives this instruction, it does not simply delete the old cache, but can adopt a versioned update strategy combining "version number increment + asynchronous broadcast". First, the system increments the rule version number of the corresponding target object by 1 in the configuration center, and re-executes the parsing and conversion process described in Embodiment 1 based on the new configuration to generate a new set of executable rule objects; subsequently, the system writes the new version of the object set into the cache. Since the key contains the new version number, and since there is no need to directly overwrite the old version cache key, the impact of writing the new version on concurrent requests reading the old version rule objects can be reduced; finally, the system broadcasts a cache invalidation notification to all service nodes through a message queue, and each node clears the old version reference in its local L1Cache after receiving the notification. Compared to the direct "delete-then-write" update method, this mechanism helps reduce the risk of cache breakdown during the period between old cache deletion and new cache generation. This addresses the issue of a large number of requests directly penetrating the database within the time window between old cache deletion and new cache generation. Simultaneously, the asynchronous broadcast mechanism allows service nodes in a cluster environment to gradually perceive rule changes while messages are being delivered and processed normally, thereby reducing discrepancies in verification results caused by long-term inconsistencies in rule versions between nodes. It should be understood that although this embodiment describes a message queue-based proactive push refresh method, other implementations can also use a TTL-based passive expiration strategy or a timed polling strategy to achieve cache updates, as long as the system can update the mapping relationship within a preset time window after a rule change. Through the coordinated work of the above cache mapping and dynamic refresh mechanisms, this invention ensures flexible and variable rule configuration while also considering access performance and version consistency control at the verification execution level. It can also achieve eventual consistency between nodes through version updates and cache invalidation mechanisms, thus improving the insufficient scalability of traditional hard-coded schemes and the difficulty in controlling rule version consistency in simple cache update methods. For requests that have already entered the execution phase and hold references to the old version of the rule object, they can be allowed to complete the current verification according to the version they hold; subsequent new requests will load the new version of the rule object according to the updated version identifier, thereby reducing the situation where the rule version switches during a single request execution, resulting in inconsistent verification standards before and after.

[0030] Example 4 like Figure 7As shown, based on Embodiments 1 to 3, this embodiment further details the dynamic parsing mechanism in the process of converting rule configuration data into executable rule objects, to support the system's scalability and main process stability in scenarios with frequent changes in rule types. As one implementation method, based on the hierarchical structure of the rule configuration data, the rule configuration data is converted into a set of executable rule objects, including: reading the rule code in the rule configuration data; querying the parser registry for a rule parser that matches the rule code; and converting the rule configuration data into a set of executable rule objects through the rule parser.

[0031] Specifically, the parser registry is the core routing component for decoupling rule conversion logic in this invention. It is initialized during system startup and remains resident in memory during runtime. From a data structure perspective, the parser registry is essentially an index container that maintains a mapping relationship between "rule codes" and "parser instances." For example, a hash map structure can be used to achieve fast lookup with an average time complexity of O(1), or standard service discovery mechanisms such as Java SPI (Service Provider Interface) can be used to achieve automatic loading and assembly of parser components. When the system receives the original rule configuration data, step S101 is executed first to extract the rule code (rule_code) that uniquely identifies the rule type from the metadata field of the configuration data. Then, step S102 is executed to perform an exact match query in the parser registry using the rule code as the key to obtain the corresponding rule parser instance. If no matching parser is found, the system can enter a preset exception handling branch, such as recording the unregistered rule code, returning a parsing failure message, and preventing the rule from entering the subsequent execution queue. In scenarios where a default processing strategy is allowed, the system can also call controlled default parsing logic to prevent unidentified rule configurations from directly entering the normal verification process. Finally, step S103 is executed, calling the standardized conversion interface implemented by the obtained rule parser instance to instantiate the unstructured raw configuration data into an executable rule object conforming to a unified specification. It is important to emphasize that the "rule parser" here does not refer to a specific software design pattern, but rather to a data processing unit that follows a preset input-output contract. This contract stipulates that all parsers must receive raw configuration input in the same format and output a standard object containing hierarchical identifiers, timing constraints, and verification parameters. This unified interface constraint at the interface level allows the verification engine to avoid perceiving the differences in the underlying configuration structure of different rule types in the main scheduling process; it only needs to schedule based on a unified object interface. The mapping relationship in the parser registry can be established once at system startup, or it can be incrementally updated according to configuration changes in implementations that allow dynamic expansion. However, regardless of the method used, a deterministic correspondence must be maintained between the rule encoding and the actual parser called.

[0032] To more clearly illustrate the versatility and technical advantages of the dynamic matching mechanism, the following comparison uses two different types of rule parsing as examples. The first type is numerical comparison rules, such as "limit on the number of times you can participate in a day". After receiving the configuration, the corresponding numerical parser mainly performs data type conversion and boundary value verification logic, converting the string threshold in the configuration into an integer or long integer value, and setting the comparison method field to "LESS_THAN" or "GREATER_THAN". At the same time, it automatically calculates the temporal position of the rule in the "user qualification layer" according to the preset hierarchical dependency model. The second type is set inclusion rules, such as "list of available channels". When processing, the corresponding set parser focuses on the encapsulation of set operation logic. It parses the comma-separated string or JSON array in the configuration into a HashSet or BloomFilter structure in memory so as to perform member judgment during the verification stage. Among them, when using HashSet, member query can be achieved in O(1) time complexity on average. When using BloomFilter, it can be used as a pre-filter structure in scenarios that allow probabilistic prediction, and the comparison method field is set to "CONTAINS" or "IN". Although these two rules differ significantly in business semantics, parameter forms, and underlying validation algorithms, in the architecture of this invention, they are both retrieved through the same registry and invoked through the same conversion interface. For the main flow of the validation engine, adding a new rule type (such as regular expression matching or remote service call type) only means adding a new key-value pair mapping in the registry and deploying a new parser class that implements the standard interface. Typically, it does not require synchronous modification of the validation engine's core traversal code, sorting logic, or result aggregation logic. This dynamic extension mechanism based on data-driven and interface abstraction reduces the scope of modification impact caused by the coupling between rule types and the main execution flow in traditional hard-coded solutions from the data processing architecture level. This allows the system to adapt to continuously changing rule extension needs on the business side while maintaining relative stability of the core chain, while also helping to reduce the increased workload of regression testing and the risk of operational failures due to frequent modifications to the main flow code. It should be understood that although this embodiment uses hash mapping and SPI mechanism as examples to illustrate the implementation of the registry, in other embodiments, dynamic loading based on database configuration, automatic scanning based on annotations, or plug-in distribution based on message bus can also be used. As long as the function of dynamically locating and calling the corresponding conversion logic according to the rule encoding can be realized, it should be covered within the protection scope of this invention.

[0033] Example 5 like Figure 8As shown, this embodiment provides a dynamic parsing and verification device 800 for multi-level business rules. The device 800 is logically divided into multiple collaborative functional modules to implement the dynamic parsing and verification method described in the aforementioned embodiment. Specifically, the device 800 includes a data acquisition module 810, a mapping establishment module 820, and a combination verification module 830. The data acquisition module 810, the mapping establishment module 820, and the combination verification module 830 can interact and control each other through shared memory space, an internal message bus, or a standardized function call interface, jointly forming a rule processing system with relatively independent responsibilities and collaborative capabilities, thereby reducing direct coupling between different processing stages.

[0034] The data acquisition module 810 is configured to acquire rule configuration data and, based on the hierarchical level of the rule configuration data, convert the rule configuration data into a set of executable rule objects. The executable rule objects in the set of executable rule objects contain hierarchical identifiers and timing constraints.

[0035] In one exemplary embodiment, the data acquisition module 810 may include a configuration acquisition unit 811, a hierarchy identification unit 812, a parser matching unit 813, and a rule object generation unit 814. The configuration acquisition unit 811 is used to actively pull rule configuration data from an external configuration source, or to receive rule configuration data sent by an external configuration source; the hierarchy identification unit 812 is used to identify the hierarchical level of the corresponding rule based on attribute information, scope information, or metadata tags in the rule configuration data; the parser matching unit 813 is used to read the rule code in the rule configuration data and determine the rule parser that matches the rule code from the parser registry; the rule object generation unit 814 is used to transform the rule configuration data using the matched rule parser to generate an executable rule object containing hierarchy identifiers and temporal constraints, and further form an executable rule object set.

[0036] Specifically, the data acquisition module 810 serves as the input terminal and preprocessing core of the entire device 800, internally encapsulating a rule parsing engine and a metadata recognition component. When the external configuration source changes or the device 800 initializes, the configuration acquisition unit 811 actively retrieves or receives the original rule configuration data and sends the acquired rule configuration data to the hierarchical recognition unit 812. The hierarchical recognition unit 812 processes the rule configuration data using preset metadata parsing rules and hierarchical recognition logic, dividing the rule configuration data into multiple logical units with clearly defined scopes of action, and determining the corresponding hierarchical level for different logical units.

[0037] The parser matching unit 813 queries the parser registry for the rule parser corresponding to the rule code carried in the rule configuration data, and provides the matched rule parser to the rule object generation unit 814. The rule object generation unit 814 calls the corresponding conversion strategy or standardized conversion interface to instantiate the aforementioned logic unit into a standardized executable rule object in memory.

[0038] During the aforementioned conversion process, the rule object generation unit 814, while completing the data format conversion, also writes structured attributes such as hierarchical identifiers and temporal constraints to the corresponding executable rule objects. The hierarchical identifier characterizes the position of the corresponding rule object within a multi-level business rule system, while the temporal constraint characterizes the execution order of the corresponding rule object during the combined verification process or its sequential dependency on other levels. Therefore, subsequent modules do not need to repeatedly handle the data format differences between different original configurations during the execution phase, but can instead process the data using a unified executable rule object model.

[0039] It should be understood that, although Figure 8 The data acquisition module 810, configuration acquisition unit 811, hierarchy recognition unit 812, parser matching unit 813, and rule object generation unit 814 are depicted as independent functional blocks. However, in actual engineering implementation, each of these units can be implemented by an independent software component, or at least two of them can be integrated into the same software component. For example, the data acquisition module 810 can also be composed of components such as a configuration listener, a parser factory, a metadata recognition component, and an object assembler, as long as the whole can realize the function of converting rule configuration data into a set of executable rule objects containing hierarchy identifiers and temporal constraints.

[0040] The mapping establishment module 820 is coupled to the output of the data acquisition module 810 and configured to establish a mapping relationship between the target object and the set of executable rule objects.

[0041] In one exemplary embodiment, the mapping establishment module 820 may include an object writing unit 821, an identifier mapping unit 822, a cache management unit 823, and a version update unit 824. The object writing unit 821 is used to write the set of executable rule objects generated by the data acquisition module 810 into a cache or in-memory database; the identifier mapping unit 822 is used to establish a key-value mapping relationship between the identifier of the target object and the set of executable rule objects; the cache management unit 823 is used to load, invalidate, delete, and manage the lifecycle of the set of executable rule objects in the cache; and the version update unit 824 is used to update the rule version number and the corresponding mapping relationship when the rule configuration data changes.

[0042] Specifically, the mapping establishment module 820 acts as an index bridge between the rule production side and the rule consumption side. The object writing unit 821 receives the set of executable rule objects generated by the rule object generation unit 814 in the data acquisition module 810, and writes the set of executable rule objects into a cache, distributed cache, or in-memory database according to the business type, business object, or business scope.

[0043] The identifier mapping unit 822 extracts a unique identifier for the target object based on the business dimension, such as an activity identifier, user group identifier, product identifier, or coupon identifier. It then uses the unique identifier of the target object as the key and the corresponding set of executable rule objects as the value to establish a mapping relationship between the target object and the set of executable rule objects. In some implementations, the key used for mapping may also include the business type, the target object identifier, and the rule version number to form a composite key that can distinguish between different business types and different rule versions.

[0044] The process of establishing this mapping relationship essentially involves organizing discrete executable rule objects into an aggregated view centered on the business entity. Through this structural design, when the combined verification module 830 initiates a rule object query, the identification mapping unit 822 can determine the corresponding cache key based on the target object identifier carried in the verification request. When using key-value mapping structures such as hash indexes, the mapping establishment module 820 can locate the corresponding set of executable rule objects in an average time complexity of O(1), avoiding a full scan of all rule objects and reducing the computational overhead caused by repeatedly parsing the original rule configuration data after the verification request arrives.

[0045] The cache management unit 823 is also used to maintain mapping relationships and the lifecycle of executable rule object sets. For example, the cache management unit 823 can automatically invalidate the corresponding rule object set according to a preset cache expiration time, or it can actively delete or mark the old version of the rule object set in response to a rule update notification. The version update unit 824 can atomically update the corresponding rule version number when the rule configuration data is updated, generate a mapping relationship corresponding to the new version of the rule object set, and control the old version of the rule object set to become invalid according to preset conditions. This helps maintain the consistency, version identifiability, and timeliness of rule data access in a high-concurrency environment.

[0046] The combined verification module 830 is coupled to the mapping establishment module 820, or to the cache storage managed by the mapping establishment module 820, and is configured to load a set of executable rule objects based on the mapping relationship in response to a received verification request, perform multi-level combined verification in sequence according to the timing constraints, and output the decision result.

[0047] In one exemplary embodiment, the combined verification module 830 may include a request receiving unit 831, a rule loading unit 832, a timing scheduling unit 833, a parameter comparison unit 834, a hierarchical blocking unit 835, and a result generation unit 836. The request receiving unit 831 is used to receive verification requests initiated by external business systems, business interfaces, or business terminals; the rule loading unit 832 is used to load a set of corresponding executable rule objects according to the target object identifier in the verification request; the timing scheduling unit 833 is used to sort multiple rule objects or construct an execution queue according to the timing constraints in the executable rule objects; the parameter comparison unit 834 is used to compare rule parameters with corresponding parameters in the verification request according to the comparison method in the rule objects; the hierarchical blocking unit 835 is used to block the verification of subsequent dependent levels according to the dependency relationship between the levels when the current level of verification fails; the result generation unit 836 is used to generate a pass, reject, or other preset type decision result based on the verification results of each level of verification.

[0048] Specifically, the combined verification module 830 constitutes the runtime execution engine of the device 800. It does not need to hardcode the judgment branches for each specific business rule. Instead, it can form a general time-series scheduling and rule comparison processing mechanism through the time-series scheduling unit 833 and the parameter comparison unit 834.

[0049] When a verification request arrives, the request receiving unit 831 first receives the verification request and extracts the target object identifier and the request parameters required to perform the verification from the verification request. Subsequently, the request receiving unit 831 sends the target object identifier to the rule loading unit 832. The rule loading unit 832 loads the set of executable rule objects corresponding to the target object identifier through the indexing mechanism provided by the identifier mapping unit 822 in the mapping establishment module 820, or through the cache structure managed by the cache management unit 823.

[0050] After loading the set of executable rule objects, the timing scheduling unit 833 reads the timing constraint fields from each executable rule object and sorts the rule object set according to the timing constraints, or constructs a rule execution queue according to the dependencies between action levels. The parameter comparison unit 834 obtains the executable rule objects sequentially according to the execution order determined by the timing scheduling unit 833, extracts the request parameters corresponding to the current executable rule object from the verification request, and compares the request parameters with the rule parameters according to the comparison method recorded in the executable rule object, thereby obtaining the verification result of the current rule object or the current action level.

[0051] During execution, when the parameter comparison unit 834 determines that the verification result of the current action level has failed, the level blocking unit 835 determines whether to block the verification of subsequent action levels based on the dependency relationship between the current action level and subsequent action levels. If the subsequent action level depends on the current action level, the level blocking unit 835 terminates the scheduling of the corresponding subsequent action level to avoid continuing to execute database queries, cache accesses, distributed lock operations, or remote service calls that lack business meaning. If there is no dependency relationship between the subsequent action level and the current failed level, the relatively independent action level can continue to be executed according to the preset verification strategy.

[0052] The result generation unit 836 generates a corresponding decision result based on the verification result obtained by the parameter comparison unit 834 and the blocking result generated by the hierarchical blocking unit 835, and returns the decision result to the caller. For example, when all necessary action levels pass the verification, the result generation unit 836 can generate a pass decision result; when any necessary action level fails the verification, the result generation unit 836 can generate a rejection decision result containing the failure rule code, the failure action level, or the failure reason.

[0053] This data-driven execution architecture gives the combined verification module 830 good versatility and operational stability. When upper-layer business rules are added or removed within the existing parsing and comparison capabilities, or when the rule execution priority is adjusted, the core scheduling code of the combined verification module 830 usually does not need to be modified synchronously. Instead, it can adaptively complete the corresponding multi-level combined verification tasks by relying on the structured features of the input executable rule objects, such as hierarchical identifiers, timing constraints, rule parameters, and comparison methods.

[0054] Through the modular device architecture described above, this invention effectively separates the three key stages of rule parsing, index construction, and execution verification both physically and logically. The data acquisition module 810 focuses on acquiring rule configuration data, hierarchical identification, parser matching, and rule object generation, providing a unified semantic foundation for rule objects in device 800. The mapping establishment module 820 focuses on writing rule objects, identifier mapping, cache management, and version updates, providing device 800 with efficient organization and access capabilities for rule objects. The combined verification module 830 focuses on receiving verification requests, loading rules, timing scheduling, parameter comparison, hierarchical blocking, and generating decision results, providing device 800 with a relatively stable rule execution kernel.

[0055] The data acquisition module 810, the mapping establishment module 820, and the combined verification module 830 work together to not only achieve relative decoupling between the rule configuration processing logic and the verification execution logic, but also improve the processing efficiency, expansion flexibility, and execution consistency of multi-level combined verification through a structured data flow mechanism, and reduce the impact of rule changes on the main process code under integrated or hard-coded implementation methods.

[0056] Example 6 like Figure 9 As shown, this embodiment provides an electronic device 900. The electronic device 900 includes at least one processor 910 and a memory 920 communicatively connected to the at least one processor 910; wherein, the memory 920 stores a computer program or instructions 921 executable by the at least one processor 910. When the computer program or instructions 921 are executed by the at least one processor 910, the electronic device 900 is able to execute the dynamic parsing and verification method for multi-level business rules described in the foregoing method embodiment.

[0057] Specifically, the processor 910 can be a Central Processing Unit (CPU), a Network Processor (NP), a Graphics Processing Unit (GPU), a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), or other processing devices capable of executing instructions and performing data processing. The processor 910 may include one processing core or multiple processing cores; when the processor 910 includes multiple processing cores, different processing cores can execute processing tasks in parallel, such as rule configuration data parsing, executable rule object generation, mapping relationship maintenance, and combination verification.

[0058] The memory 920 may include volatile memory such as random access memory (RAM), or non-volatile memory such as flash memory, solid-state drive, or disk storage. The memory 920 may be used to store data such as the operating system, computer programs or instructions 921, rule configuration data, a set of executable rule objects, the mapping relationship between target objects and the set of executable rule objects, rule version information, intermediate verification results, and final decision results.

[0059] The processor 910 and the memory 920 can transmit computer programs or instructions 921, rule configuration data, executable rule objects, mapping indexes, and verification results via a bus 950 or other communication connection methods. The bus 950 may include an address bus, a data bus, a control bus, or a combination of the above buses, and is used to transmit data and control signals between the processor 910, the memory 920, the communication interface 930, and the input / output interface 940.

[0060] The electronic device 900 can also be equipped with a communication interface 930, an input / output interface 940, and other peripheral devices according to actual deployment needs. The communication interface 930 can communicate with the processor 910 and the memory 920 via a bus 950, and is used to realize data communication between the electronic device 900 and external configuration sources, service request terminals, distributed caches, message queues, or other service nodes. The communication interface 930 may include a network interface, which can be a wired network interface, a wireless network interface, or other interfaces capable of data communication.

[0061] Specifically, the communication interface 930 can be used to acquire rule configuration data sent by an external configuration source, receive verification requests sent by an external business system, access the set of executable rule objects in the distributed cache, or send rule update notifications, cache expiration notifications, and rule version change messages to other service nodes. The input / output interface 940 can communicate with the processor 910 via the bus 950 and is used to connect to a keyboard, display, touch device, storage device, or other input / output device to realize the input of rule configuration data, the display of processing status, and the output of decision results.

[0062] In this embodiment, the computer program or instruction 921 stored in the memory 920 can be divided into instruction related to rule configuration data acquisition, instruction related to rule object parsing and transformation, instruction related to mapping relationship establishment and maintenance, instruction related to timing scheduling, and instruction related to combination verification according to their respective functions.

[0063] When the processor 910 executes instructions related to obtaining rule configuration data, it can acquire rule configuration data from the configuration center, business management platform, or other external configuration sources via the communication interface 930. When the processor 910 executes instructions related to parsing and converting rule objects, it can identify the hierarchical level of the rule configuration data, generate corresponding timing constraints, and call the rule parser that matches the rule encoding to convert the rule configuration data into a standardized set of executable rule objects.

[0064] When the processor 910 executes the instructions related to establishing and maintaining the mapping relationship, it can establish a mapping relationship between the target object identifier and the set of executable rule objects, and store the mapping relationship and the set of executable rule objects in the memory 920, the local cache, or a distributed cache accessed through the communication interface 930. Upon receiving a rule update instruction, the processor 910 can also update the rule version number according to the computer program or instruction 921, invalidating the old version of the set of executable rule objects, and establishing a mapping relationship between the target object identifier and the new version of the set of executable rule objects.

[0065] When the timing-related instructions are executed by the processor 910, the processor 910 can read the timing constraints in the executable rule objects, and sort or construct corresponding execution queues based on the timing constraints. When the combination verification-related instructions are executed by the processor 910, the processor 910 can sequentially call the corresponding verification logic according to the execution queue, compare the request parameters in the verification request with the rule parameters in the executable rule objects, and generate corresponding decision results based on the verification results of each action level.

[0066] When processor 910 executes the aforementioned computer program or instruction 921, it can load the parsed executable rule object, intermediate verification results, target object identifier, mapping index, and rule version information into the corresponding storage space in memory 920, and call the corresponding verification logic according to timing constraints. When the verification result of the current action level fails, processor 910 can also block the verification of subsequent action levels with dependent relationships with the current action level based on the dependency relationship between the current action level and the subsequent action level, and generate a decision result of refusal to execute.

[0067] In a multi-core processor environment, parsing tasks for different rule configuration data, verification requests corresponding to different target objects, or independent verification tasks at different action levels can be processed in parallel by different processing cores in processor 910. In a distributed deployment environment, multiple electronic device nodes 900 can also undertake rule parsing, cache access, time-series scheduling, or verification execution tasks respectively. The electronic device nodes 900 can exchange executable rule objects, rule version information, cache expiration messages, and verification results through communication interface 930.

[0068] It should be understood that Figure 9The hardware configuration of the electronic device 900 shown is merely an example. In other embodiments, the electronic device 900 may also include a power management component, a display component, an external storage interface, a security encryption component, or other hardware units. The specific number and connection method of the processor 910, memory 920, communication interface 930, and input / output interface 940 can also be adjusted according to the actual application scenario. As long as the electronic device 900 can execute the computer program or instructions 921 in the memory 920 through the processor 910 to complete the aforementioned multi-level business rule dynamic parsing and verification method, it can be considered an implementation of the electronic device 900 described in this embodiment.

[0069] This embodiment also provides a computer-readable storage medium. The computer-readable storage medium stores computer instructions, which, when read and executed by a computer or other electronic device 900 with data processing capabilities, are used to cause the computer or electronic device 900 to execute the dynamic parsing and verification method for multi-level business rules described in the foregoing method embodiment.

[0070] Specifically, a computer-readable storage medium can be a storage medium capable of recording or storing computer programs, computer instructions, program modules and related data in a tangible manner. It may include, but is not limited to, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory, flash memory, solid-state drive, hard disk, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory card, USB flash drive or other media suitable for storing computer programs.

[0071] The computer instructions stored in the computer-readable storage medium may include instructions for reading rule configuration data, instructions for identifying the rule application level and generating time constraints, instructions for calling the rule parser to generate executable rule objects, instructions for establishing or updating the mapping relationship between the target object and the set of executable rule objects, and instructions for responding to verification requests and performing multi-level combined verification according to time constraints.

[0072] The aforementioned computer instructions can be stored as a complete computer program in the computer-readable storage medium, or they can be divided into multiple program modules and stored separately according to different functions. When executing the computer instructions, the electronic device 900 can load the computer instructions into the memory 920 through the communication interface 930 or the input / output interface 940, and have them executed as a whole by the processor 910 or executed on demand according to actual verification requirements.

[0073] After the processor 910 reads and executes the corresponding computer instructions, it can complete the following processing according to the data processing relationship described in the foregoing embodiments: rule configuration data acquisition, action level identification, time sequence constraint generation, rule parser matching, executable rule object generation, rule object cache loading, target object mapping, hierarchical dependency judgment, failure blocking, and decision result output.

[0074] It should be understood that the specific physical form, storage capacity, and interface type of the computer-readable storage medium can be selected according to the deployment environment of the electronic device 900, and this embodiment is not limited to a specific storage device. As long as the computer-readable storage medium can store computer instructions for implementing the aforementioned dynamic parsing and verification method for multi-level business rules, it can be used as an implementation of the computer-readable storage medium in this embodiment.

[0075] Example 7 like Figure 10 As shown, based on the aforementioned embodiments, this embodiment will take the typical application scenario of rights issuance verification as an example to further illustrate the specific implementation of the multi-level business rule dynamic parsing and verification method provided by the present invention in an actual business system. It should be noted that this embodiment is only an illustrative example, intended to help those skilled in the art better understand the substantive content of the invention, and does not constitute a limitation on the scope of protection of the present invention. In this embodiment, the aforementioned target object is specifically set as a composite business entity composed of user identifier, activity identifier, and coupon identifier, while the rule configuration data specifically manifests as various business constraints such as daily limit on the number of claims, user tag matching conditions, activity budget balance, and channel inventory quantity.

[0076] Specifically, during the configuration phase of the rights distribution business, operators configure a series of verification rules for specific marketing activities through the management backend. For example, rules such as "new users only," "limited to one claim per person per day," "total activity budget not exceeding 100,000 yuan," and "available on designated APP channels" are configured. After receiving this raw configuration data, the system, according to the parser registration mechanism described in Example 4, calls the user tag parser, frequency control parser, budget deduction parser, and channel verification parser respectively to convert these heterogeneous configuration texts into a unified set of executable rule objects. During this process, the system assigns corresponding hierarchical identifiers and timing constraints to each object based on a preset hierarchical dependency model. For example, "User Tag Matching" is categorized as the "User Qualification Layer," and its priority is set to the highest among the four rule layers in this example (e.g., T1); "Daily Limit on Redemption Times" is categorized as the "Frequency Control Layer," with a lower priority (e.g., T2); "Activity Budget Deduction," due to its involvement with distributed locks and database write operations, is categorized as the "Resource Consumption Layer," with a lower priority (e.g., T3); "Channel Inventory Verification" also belongs to the Resource Consumption Layer, but depends on channel parameters, and its priority is set to T4. After the conversion is complete, the system serializes the executable rule set containing these four objects and writes it to the distributed cache with "activity_10086:coupon_5566:v20231001" as the key, establishing a mapping relationship between activity and coupon combination identifiers and rule objects, thereby completing the conversion and mapping process from business rule configuration data to executable rule objects that can be loaded and scheduled by the verification engine. The T1 to T4 above only represent the relative execution order in this example, and do not limit the timing constraints to be represented by a combination of the character T and numbers; in other implementations, integer ordinal numbers, enumeration values, priority fields, or sorting indices calculated from dependencies can also be used.

[0077] When a user initiates a claim request on a mobile device, the system enters the verification execution phase. First, the gateway layer extracts the user ID, activity ID, coupon ID, and channel source information from the request message, assembles them into a target object identifier, and quickly loads the corresponding set of executable rule objects from the cache based on this identifier; when the cache is hit and the running conditions are suitable, this loading process can achieve millisecond-level response. Subsequently, the combined verification module strictly sorts and traverses according to the temporal constraint fields within the object. When executing the "user tag matching" verification of temporal T1, the verification engine reads the comparison method as "CONTAINS" in the object and compares the list of user tags in the request with the rule parameter "NEW_USER". If the current user is not a new user and the tag list does not contain "NEW_USER", then this level of verification fails. At this point, the system immediately triggers the hierarchical blocking mechanism described in Example 2: Recognizing that subsequent operations such as T2 frequency verification, T3 budget deduction, and T4 inventory verification are resource-intensive or have high I / O overhead, and that user eligibility is a prerequisite in the business logic, the system directly terminates the scheduling of these subsequent levels, no longer initiating any Redis counting queries or database deduction requests. Instead, it immediately encapsulates a rejection decision containing the message "Non-new users are not entitled to claim" and returns it to the front end. Through this intelligent short-circuiting based on time constraints, the system can avoid continuing to occupy budget deduction interface calls, database connections, and other subsequent processing resources on requests that have already been determined not to meet the prerequisite eligibility conditions, thereby helping to improve system throughput and response stability in high-concurrency rejection scenarios.

[0078] In contrast, traditional hard-coded validation methods often require developers to write nested if-else statements in the coupon issuance interface, leading to high code maintenance costs and difficulty in ensuring that all delivery entry points (such as the app homepage, H5 activity pages, and backend compensation interfaces) follow the exact same validation order and blocking strategy. If business adjustments necessitate moving "channel validation" to the forefront to reduce cross-domain calls, it typically requires modifying the relevant core code and re-executing testing, release, and other deployment processes. However, with the technical solution described in this embodiment, operations personnel only need to adjust the priority parameters or modify the rule content in the configuration interface. The system can then automatically update the cached executable rule objects and their timing constraints through a dynamic refresh mechanism. Provided the rule type and corresponding parser are already supported by the system, the rule object can be refreshed without modifying the core scheduling code of the validation engine, and the adjusted validation strategy will take effect after the refresh process is completed. Furthermore, since all entry points reuse the same set of parsed memory objects and verification engines, it helps reduce the risk of inconsistent execution order or judgment standards caused by different business entry points implementing verification logic separately. This ensures that the rights issuance business maintains fast response capabilities, adherence to established risk control rule execution requirements, and consistency with rule versions in complex and ever-changing market and business environments. It should be understood that although this embodiment uses rights issuance as an example for detailed explanation, the technical solution of this invention is also applicable to other business scenarios with multi-dimensional rule verification needs, such as credit approval, risk control interception, and membership level assessment. As long as their data processing flow conforms to the core concepts of dynamic parsing, structured mapping, and temporal combination verification disclosed in the foregoing embodiments, they should all be covered within the protection scope of this invention.

[0079] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for verifying the issuance of rights, characterized in that, include: Obtain rule configuration data, and based on the hierarchical level of the rule configuration data, convert the rule configuration data into a set of executable rule objects. The executable rule objects in the set of executable rule objects contain hierarchical identifiers and timing constraints. Establish a mapping relationship between the target object and the set of executable rule objects; In response to receiving a verification request, the executable rule object set is loaded based on the mapping relationship, and multi-level combined verification is performed sequentially according to the time sequence constraints, and the decision result is output.

2. The method according to claim 1, characterized in that, The step of converting the rule configuration data into a set of executable rule objects based on the hierarchical effect of the rule configuration data includes: Multiple action levels are divided based on the attribute information in the rule configuration data; The timing constraints are generated based on the dependencies or preset priorities among the multiple action levels. Based on the multiple action levels and the timing constraints, the set of executable rule objects is generated.

3. The method according to claim 2, characterized in that, The step of performing multi-level combined verification sequentially according to the time constraints and outputting decision results includes: During the execution of the multi-level combined verification, if the verification result of the current action level fails, the verification of subsequent action levels with dependencies is blocked according to the timing constraints. The decision to refuse execution is generated based on the blocking result.

4. The method according to claim 3, characterized in that, The executable rule object includes rule code, rule parameters, comparison method, and execution order; The step of performing multi-level combined verification sequentially according to the timing constraints includes: According to the comparison method, the rule parameters are compared with the corresponding parameters in the verification request.

5. The method according to claim 1, characterized in that, The process of establishing the mapping relationship between the target object and the set of executable rule objects includes: Write the set of executable rule objects into the cache, and establish a mapping relationship between the identifier of the target object and the set of executable rule objects; The step of loading the set of executable rule objects based on the mapping relationship in response to receiving a verification request includes: In response to receiving the verification request, the corresponding set of executable rule objects is loaded from the cache based on the identifier of the target object.

6. The method according to claim 5, characterized in that, Also includes: In response to receiving a rule update instruction, the set of executable rule objects corresponding to the cache is invalidated; A new set of executable rule objects is regenerated based on the updated rule configuration data, and the mapping relationship is updated.

7. The method according to claim 1, characterized in that, The step of converting the rule configuration data into a set of executable rule objects based on the hierarchical effect of the rule configuration data includes: Read the rule code from the rule configuration data; Search the resolver registry for rule resolvers that match the rule code; The rule parser converts the rule configuration data into the set of executable rule objects.

8. A method and apparatus for verifying the issuance of rights, characterized in that, include: The data acquisition module is used to acquire rule configuration data and, based on the hierarchical level of the rule configuration data, convert the rule configuration data into a set of executable rule objects. The executable rule objects in the set of executable rule objects contain hierarchical identifiers and timing constraints. The mapping establishment module is used to establish a mapping relationship between the target object and the set of executable rule objects; The combined verification module is used to respond to a received verification request, load the set of executable rule objects based on the mapping relationship, and perform multi-level combined verification in sequence according to the time constraints, and output the decision result.

9. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the method of any one of claims 1 to 7.

Images