Data processing method and device based on request interception, equipment and medium

Abstract

The invention provides a data processing method based on request interception, which comprises the following steps of: intercepting a calling request for marking a service method through a request interception mechanism, preposing a decision point of service logic, and selecting whether the service method is executed or not according to a request context. According to the method and the device, the business rules are stored in the configuration center, external rule configuration is performed, the business rule expressions are pre-stored in the configuration center, dynamic acquisition is performed based on the rule identifiers, decoupling of the business rules and the codes is realized, the business rules can be configured independent of the codes, and flexible business processing can be realized only by modifying the expressions of the corresponding rules in the configuration center. The problems of code expansion and difficult maintenance caused by business rule change in a multi-channel environment are effectively solved, so that the flexibility and maintainability of a business data processing system are improved. The method can be applied to a business processing system in the financial field or the medical field, so that the flexibility of the business processing system in the financial field or the medical field is improved.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a data processing method, apparatus, computer device, and computer-readable storage medium based on request interception. Background Technology

[0002] During business system development, as application scenarios diversify, it becomes necessary to deploy the same core business logic across multiple business channels. For example, in the financial sector, the same approval logic needs to be deployed across multiple channels, including online channels (mobile banking, online banking), offline channels (branch counters, customer manager home visits), and third-party channels (partner e-commerce platforms, payment institutions). Similarly, in the healthcare sector, the same appointment registration logic needs to be deployed across multiple channels, including hospital websites, WeChat official accounts, Alipay mini-programs, self-service registration machines, telephone appointments, and on-site windows. As business rules change in a multi-channel environment, numerous conditional statements need to be embedded in the code to differentiate channel characteristics, leading to code bloat. Furthermore, maintaining multiple independent code branches subsequently increases maintenance difficulties. Summary of the Invention

[0003] The main purpose of this application is to provide a data processing method, apparatus, computer device, and computer-readable storage medium based on request interception, which aims to solve the problems of code bloat and maintenance difficulties caused by changes in business rules in a multi-channel environment.

[0004] To achieve the above objectives, this application provides a data processing method based on request interception, the data processing method comprising the following steps: When the currently invoked business method belongs to the marked business method, the current invocation request corresponding to the current invocation business method is intercepted, and the business request parameters are extracted from the current invocation request; Based on the rule identifier of the currently invoked business method, the current business rule expression of the currently invoked business method is obtained from the configuration center and used as the target expression; Based on the business request parameters and the target expression, generate the invocation decision result for the current business method being invoked; When the call decision result is to execute, the current call request is allowed, and the current call business method is called to process the business request parameters; When the call decision result is interception, the current call request is rejected and the current call business method is skipped in order to process the next call request.

[0005] To achieve the above objectives, this application provides a data processing apparatus based on request interception, characterized in that the question-answering apparatus includes: The call request interception module is used to intercept the current call request corresponding to the current call business method when the current call business method belongs to the marked business method, and extract the business request parameters from the current call request; The rule expression acquisition module is used to acquire the current business rule expression of the currently invoked business method from the configuration center based on the rule identifier of the currently invoked business method, and use it as the target expression; The business method invocation module is used to generate the invocation decision result of the current business method invocation based on the business request parameters and the target expression; The business method allowing module is used to allow the current call request when the call decision result is to execute, and to call the current call business method to process the business request parameters; The business method interception module is used to reject the current call request and skip the current call business method when the call decision result is interception, so as to process the next call request.

[0006] This application provides a data processing method based on request interception. When the currently invoked business method belongs to a marked business method, the method intercepts the current invocation request corresponding to the current invocation business method and extracts business request parameters from the current invocation request. Based on the rule identifier of the current invocation business method, the method obtains the current business rule expression of the current invocation business method from the configuration center as the target expression. Based on the business request parameters and the target expression, the method generates a call decision result for the current invocation business method. If the call decision result is "execute," the method allows the current invocation request and invokes the current invocation business method to process the business request parameters. If the call decision result is "intercept," the method rejects the current invocation request and skips the current invocation business method to process the next invocation request. Through this method, this application intercepts invocation requests for marked business methods using a request interception mechanism, bringing the decision point of the business logic forward and deciding whether to execute the business method based on the request context. Furthermore, by externalizing rule configuration and pre-storing business rule expressions in the configuration center, and dynamically retrieving them based on rule identifiers, business rules are decoupled from code. This allows business rules to be configured independently of the code. By simply modifying the expression of the corresponding rule in the configuration center, flexible business processing can be achieved. This effectively solves the problems of code bloat and maintenance difficulties caused by changes in business rules in a multi-channel environment, thereby improving the flexibility and maintainability of the business data processing system. Attached Figure Description

[0007] Figure 1 A flowchart illustrating a data processing method based on request interception provided in this application; Figure 2 A flowchart illustrating another data processing method based on request interception provided in this application; Figure 3 A flowchart illustrating yet another data processing method based on request interception provided in this application; Figure 4 A functional module diagram of a data processing device based on request interception provided in this application; Figure 5 A schematic block diagram of the structure of a computer device provided in this application.

[0008] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0009] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0010] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0011] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0012] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0013] The data processing method based on request interception involved in the embodiments of this application is mainly applied to computer devices, which can be PCs, laptops, mobile terminals, or other devices with display and processing functions.

[0014] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0015] Reference Figure 1 , Figure 1 This is a flowchart illustrating a data processing method based on request interception provided in this application.

[0016] like Figure 1 As shown, this application provides a data processing method based on request interception, which includes steps S101 to S105.

[0017] Step S101: When the currently invoked business method belongs to the marked business method, the current invocation request corresponding to the current invocation business method is intercepted, and the business request parameters are extracted from the current invocation request; In traditional business systems, when business logic is horizontally expanded to multiple business channels, the specific logical differences between the channels necessitate the introduction of numerous conditional branch statements in the code. This leads to increased code complexity, reduced maintainability, and consequently affects the system's iteration efficiency and stability. Furthermore, the disorderly growth of business logic branches causes the core code to be wrapped in multiple layers of conditional statements, reducing code readability. Additionally, each update requires verification of compatibility across all channels, increasing the complexity of system maintenance.

[0018] For example, in an insurance business system, the development channel requires specific customer risk assessment logic, while the comprehensive expansion channel does not. When a new business channel is added, developers need to add a channel type judgment branch to the core business method, resulting in the code being filled with if-else statements. Furthermore, as the number of channels continues to increase, the core business logic is nested with multiple layers of conditional judgments, significantly reducing code readability. Each business logic update requires testing the compatibility of all channels, extending the testing and verification cycle. There is also the possibility of maintaining multiple sets of code branches, further increasing system maintenance costs.

[0019] In this embodiment, before a business method is actually invoked, a specific mechanism captures and controls incoming requests through request interception. This mechanism allows for the inspection, modification, or blocking of requests before they reach the target business logic, thereby achieving refined management of the business process. Marked business methods refer to those explicitly identified by the system that require special processing or decision-making. These methods typically carry business logic that needs dynamic judgment based on specific rules, such as permission verification, traffic control, or differentiated business processing. Each invoked business method is considered the currently invoked business method, which is any instance of a business method that the system attempts to invoke at a specific moment. This method is the direct object of the request interception mechanism, and its behavior is dynamically decided based on preset rules and request parameters. The current invocation request refers to the specific request initiated for the currently invoked business method. This request carries all the input information required to execute the business logic and is the basis for decision analysis by the data processing method. Business request parameters refer to the key data extracted from the current invocation request used to drive the execution of the business logic. These parameters will serve as input to the rule expression, affecting the final invocation decision result.

[0020] Specifically, when a business method is invoked, it needs to be determined whether the currently invoked business method is a marked business method. If the method is identified as a marked business method, its corresponding current invocation request is intercepted. During the interception process, business request parameters need to be extracted from the current invocation request. For example, a unified proxy layer or aspect can be set at the entry point of the business method, which is responsible for capturing all incoming invocation requests. For business methods identified as requiring special handling, the proxy layer or aspect will pause further execution of the request and parse the data required by the business from the request body, request headers, or URL parameters as business request parameters. One implementation is to explicitly specify which methods need to be intercepted in the code through hard coding and manually write code to parse the request parameters. Another implementation is to record the list of methods to be intercepted in a configuration file or database and query it at runtime, while obtaining the parameters through reflection or manual parsing of the request body.

[0021] Step S102: Based on the rule identifier of the currently invoked business method, obtain the current business rule expression of the currently invoked business method from the configuration center as the target expression; In this embodiment, a rule identifier is a code or name used to uniquely identify and locate a specific business rule expression. Through this identifier, the system can accurately retrieve the rule related to the current business method from the configuration center. The configuration center is a service that centrally stores and manages system configuration information. It allows business rules, parameters, and other configuration items to be dynamically loaded and updated at runtime, thereby improving the system's flexibility and maintainability. A business rule expression is a statement or code snippet that represents business logic in a structured or executable form. This expression defines the logic of how a business request should be processed under specific conditions, such as "if the user's level is VIP, then access is allowed." The target expression refers to the business rule expression, after processing and optimization, that is ultimately used to evaluate the business request parameters and generate the call decision result. This expression is the core of the decision-making process.

[0022] Specifically, once a request is intercepted and the business request parameters are extracted, the system retrieves the current business rule expression related to that method from the configuration center based on the rule identifier of the currently calling business method, and uses it as the target expression. For example, each marked business method can be assigned a unique string or number as a rule identifier. When the method is called, the system uses this identifier to initiate a query request to the configuration center. The configuration center can be a simple key-value pair store, where the key is the rule identifier and the value is the corresponding business rule expression. One implementation is to store the business rule expression directly as text in a local file and load it using the file path as the rule identifier. Another implementation is to store the business rule expression in a relational database and retrieve it using a query statement based on the rule identifier.

[0023] Step S103: Based on the business request parameters and the target expression, generate the invocation decision result for the current business method invocation; In this embodiment, the call decision result is a conclusion drawn from the evaluation of the business request parameters and the target expression. This result indicates whether the current call request should be "executed" (allowed and the business method is invoked) or "intercepted" (rejected and the business method is skipped).

[0024] Specifically, based on the acquired business request parameters and the target expression, the system generates a call decision result for the currently invoked business method. This process involves evaluating the target expression to determine whether the request conforms to preset business rules. For example, if the target expression is "user age is greater than 18", and the business request parameters include "user age = 20", the evaluation result will be "true". This evaluation result is then converted into a call decision result. One implementation is to interpret and execute the target expression as a piece of script code (such as JavaScript or Python script), and use the business request parameters as input variables for the script. Another implementation is to parse the target expression into an abstract syntax tree, and then manually traverse the syntax tree and perform calculations based on the business request parameters.

[0025] Step S104: When the call decision result is to execute, allow the current call request and call the current call business method to process the business request parameters; Step S105: When the call decision result is interception, the current call request is rejected and the current call business method is skipped in order to process the next call request.

[0026] In this embodiment, the system will adopt different processing methods based on the generated call decision result. When the call decision result is "execute," it means that the request conforms to the business rules and should be allowed. At this time, the current call request will continue to be passed, and the current call business method will be invoked to actually process the business request parameters. For example, if the decision result is "execute," the interceptor will unblock the request, allowing the request to flow to the original business method implementation. Conversely, when the call decision result is "intercept," it means that the request does not conform to the business rules and should be rejected. At this time, the current call request will be rejected, and the current call business method will be skipped, and the system will process the next call request. For example, if the decision result is "intercept," the interceptor will directly return an error response or an empty response without touching the original business method, thereby avoiding unnecessary execution of business logic.

[0027] The following example will provide a more detailed explanation of the above technical solution: Suppose an e-commerce platform has a business method called "Calculate Order Discount," which calculates the final discount based on the order amount and user level. However, different sales channels (e.g., channel A and channel B) have different rules for calculating discounts. A traditional approach might be to use numerous if-else statements within the "Calculate Order Discount" method to determine which channel the current request originated from and apply the corresponding discount logic. This results in complex and difficult-to-maintain code.

[0028] The data processing method provided in this embodiment can effectively solve this problem. First, the system marks the "calculate order discount" method as a business method that needs to be intercepted. When user A initiates an order through channel A and calls the "calculate order discount" method, this method is identified as the marked business method, and its corresponding current call request will be intercepted. During the interception process, the system extracts business request parameters from the current call request, such as order amount, user level, and channel identifier (channel A).

[0029] Subsequently, the system will retrieve the current business rule expression related to channel A from the configuration center based on the rule identifier preset in the "calculate order discount" method (e.g., "discount_rule_id_001"). For example, the configuration center may store a rule expression for channel A that reads, "If the order amount is greater than 500 and the user level is VIP, the discount rate is 0.8; otherwise, the discount rate is 0.9." This expression, once retrieved, becomes the target expression.

[0030] Next, the system generates a call decision result for the "Calculate Order Discount" method based on the extracted business request parameters (order amount, user level, channel identifier) ​​and the target expression. Specifically, the system substitutes parameters such as order amount and user level into the target expression for evaluation. For example, if user A's order amount is 600 and the user level is VIP, the evaluation result of the target expression is "discount rate is 0.8". This evaluation result is converted into a call decision result, such as "Execute, and apply a 0.8 discount rate".

[0031] Finally, based on the call decision result, the system will take corresponding action. If the call decision result is "execute," and indicates the application of a discount rate of 0.8, the system will allow the current call request and invoke the "calculate order discount" method, passing the 0.8 discount rate as a parameter to this method for processing. This method will calculate the final order price based on the input discount rate. If another user B initiates a request through channel B, and the evaluation result of channel B's rule expression is "block" (e.g., channel B does not allow this type of order to enjoy a discount), the system will reject the current call request, skip the "calculate order discount" method, and directly return a no-discount or error message, thus processing the next call request. In this way, the differentiated processing of business logic is externalized into the rule expression, avoiding complex branch judgments within the core business methods.

[0032] Based on the above examples, the data processing method provided in this embodiment demonstrates significant technical contributions. In traditional business system development, when faced with differentiated logic across different business channels, a common approach is to pile up numerous conditional statements (such as if-else statements) within the core business methods. As the number of business channels increases, this approach leads to highly coupled code logic, poor readability, high maintenance costs, and requires comprehensive testing of all branches during updates and iterations, easily introducing new defects. For example, in the discount calculation scenario of the e-commerce platform mentioned above, if the discount rules for each channel are hard-coded into the "calculate order discount" method, then every time a new channel is added or its discount rules are modified, the core method needs to be modified and redeployed, undoubtedly increasing the burden on development and maintenance.

[0033] This embodiment effectively solves the aforementioned problems by introducing request interception, externalized rule configuration, and a dynamic decision-making mechanism. First, by intercepting requests for marked business methods, the decision-making point of business logic is brought forward, allowing core business methods to maintain their purity and focus on implementing business functions without needing to concern themselves with complex rule judgments. Second, by storing business rule expressions in the configuration center and dynamically retrieving them based on rule identifiers, business rules are decoupled from the code. This allows business rules to be configured, modified, and managed independently of the code, enabling adjustments to business logic without recompiling and deploying the code. For example, when the discount rule for channel A needs to be adjusted from "0.8 discount rate" to "0.85 discount rate," only the corresponding rule expression needs to be modified in the configuration center, without touching the code of the "calculate order discount" method, greatly improving the system's flexibility and response speed.

[0034] Furthermore, the mechanism for generating call decision results based on business request parameters and target expressions enables the system to dynamically determine the behavior of business methods according to the real-time request context, thereby achieving fine-grained business control. Whether allowing a request and executing a business method, or rejecting a request and skipping a business method, is driven by externalized rules rather than hard-coded logic. This design not only reduces code complexity and improves system scalability, but also avoids the dilemma of maintaining multiple sets of code for different channels, significantly reducing maintenance costs. Overall, the technical solution in this embodiment provides an efficient, flexible, and easy-to-maintain framework for differentiated business logic processing, providing solid technical support for the construction and evolution of complex business systems.

[0035] Reference Figure 2 , Figure 2 A flowchart illustrating another data processing method based on request interception provided in this application.

[0036] like Figure 2As shown, this application provides a data processing method based on request interception. In one embodiment, before step S101, the method further includes: Step S010: Obtain the set of business methods of the business system, and extract features from each business method in the set of business methods to obtain a set of method features; Step S020: Match the method feature set with the preset interception rules to obtain the set of business methods to be intercepted and marked; Step S030: Add interception annotations to each business method in the set of business methods to be marked to obtain the set of marked business methods; Step S040: Register each marking service method in the marking service method set and establish an interception point mapping relationship to complete the marking of the service methods to be intercepted.

[0037] In this embodiment, obtaining the set of business methods in the business system refers to scanning or analyzing all executable business operations or functional units in the business system using specific technical means. This can be achieved by using reflection to traverse all classes and their methods under a specified package when the application starts; or by using static code analysis tools to parse the source code or bytecode during the compilation phase to identify all business methods that conform to specific naming conventions or interface definitions. Feature extraction is performed on each business method in the set of business methods to obtain a set of method features, which means obtaining the inherent attribute information of each business method for subsequent rule matching. These features may include, but are not limited to, the method name, parameter list (type, order), return type, access modifier, class name, and existing annotation information on the method. Feature extraction can be performed by obtaining the metadata of Java's `Method` object, or by directly parsing the method bytecode using bytecode manipulation libraries such as ASM. The set of method features is matched with preset interception rules to obtain a set of business methods to be intercepted and marked, aiming to filter out business methods that need to be intercepted based on predefined conditions. Preset interception rules can be a series of logical expressions. For example, matching method names that start with a specific prefix (such as "create" or "update"), matching method parameters containing a specific business object type, or matching methods with specific business annotations (such as `@SensitiveOperation`). The matching process can be implemented using regular expressions, pattern matching algorithms, or a custom rule engine. Adding interception annotations to each business method in the set of business methods to be marked, resulting in a marked business method set, means that after identifying the methods that need to be intercepted, a specific identifier is added to them programmatically. An interception annotation is a type of metadata used to indicate at runtime or compile time that the method should be processed by the interceptor. Adding annotations can be achieved through bytecode enhancement techniques (such as compile-time weaving in AspectJ, runtime dynamic modification of bytecode in ASM or ByteBuddy), or through dynamic proxy mechanisms (such as JDK dynamic proxies or CGLIB) to dynamically generate proxy objects at the time of method calls and add interception logic to the proxy objects. Registering each marked business method in the set of marked business methods and establishing an interception point mapping relationship completes the marking of business methods that need to be intercepted. This means incorporating business methods with added interception annotations into a unified management system and clarifying their association with specific interception logic. The registration process typically involves storing the method's unique identifier (such as its fully qualified name and method signature) in a globally accessible registry. The interception point mapping relationship refers to associating the registered method with one or more interceptor instances or interceptor chains. When the method is invoked, the system can find and execute the corresponding interception logic based on this mapping relationship.This can be achieved through the configuration of the AOP framework (such as the association of pointcut expressions with advice in Spring AOP) or a custom interceptor chain manager.

[0038] This application's solution employs a systematic business method marking mechanism to ensure accurate and efficient identification of marked business methods when the currently invoked business method belongs to that category, laying a solid foundation for subsequent request interception. This mechanism first obtains the set of business methods from the business system, comprehensively understanding all executable business operations within the system. Then, it performs detailed feature extraction on these business methods, analyzing aspects such as method name, parameter types, and annotations, thus forming a structured set of method features. This set of features forms the basis for subsequent identification. Next, the system intelligently matches these extracted method features with pre-defined interception rules. These interception rules can be flexibly configured according to business needs; for example, specifying that all methods involving sensitive data operations need to be intercepted, or all methods named with a specific prefix need to be intercepted. Through this matching, the system can automatically identify all business methods to be marked that need to be intercepted. Once identification is complete, the system automatically adds specific interception annotations to these business methods to be marked, thus clearly identifying their interception attributes at the code level, forming a set of marked business methods. Finally, these marked business methods with interception annotations are registered in the system's interception management module, establishing a mapping relationship between the methods and specific interception logic, thus completing the automated marking of business methods that need to be intercepted. This series of steps greatly improves the automation and accuracy of the interception strategy, avoiding errors and inefficiencies caused by manual intervention.

[0039] The following example illustrates this. Suppose a business system based on the Spring framework needs to intercept all methods involving user account operations for permission verification. First, the system can obtain all Spring-managed beans through Spring's `ApplicationContext` at application startup and use the Java reflection API to traverse all public methods in these beans, thus obtaining the set of business methods for the system. Next, for each method, its method name, parameter types, and the presence of the `@AccountOperation` custom annotation can be extracted to form a method feature set. The default interception rule can be defined as follows: if the method name contains "updateAccount" or "deleteAccount", or if the method has the `@AccountOperation` annotation, then the method needs to be intercepted. The system matches the method feature set with these rules to identify all eligible business methods to be marked. Then, AspectJ can be used at compile time or Spring AOP can be used at runtime to dynamically add a custom interception annotation named `@InterceptRequired` to these business methods to be marked, thus obtaining the set of marked business methods. Finally, the system registers these marked business methods annotated with `@InterceptRequired` to a custom interceptor registry and establishes a mapping between method signatures and specific permission verification interceptor instances. For example, the method `com.example.UserService.updateAccount(String, double)` is mapped to `PermissionCheckInterceptor`. When the `updateAccount` method is called, the interceptor management module automatically triggers `PermissionCheckInterceptor` to perform permission verification based on this mapping, thus completing the automated marking and registration of the business methods that need to be intercepted.

[0040] Through the above technical solution, this application provides an automated and systematic business method marking mechanism. This mechanism effectively solves the problems of low efficiency, error-proneness, and difficulty in maintenance caused by manual identification and marking of business methods in traditional methods. By extracting features from business methods and matching them with preset rules, the system can accurately identify the business methods that need to be intercepted and automatically add interception tags to them, thereby establishing a mapping relationship between methods and interception logic. This not only significantly reduces development and maintenance costs and improves the deployment efficiency and accuracy of interception strategies, but also enables the interception logic to adapt more flexibly to business changes, ensuring the stability and reliability of data processing methods.

[0041] In one embodiment, before step S102, the method further includes: Analyze the business rules for each business scenario and extract the set of rule components; Based on the syntax rules, the various rule components in the rule component set are organized into a tree structure to obtain the expression syntax tree; Based on parameterized templates, placeholders are replaced in the fixed parameters of the expression syntax tree to generate parameterized expressions, thereby improving the configurability of the expressions. Based on the syntax correctness verification results and logical integrity verification results of the parameterized expression, the parameterized expression is optimized to generate various business rule expressions; Each business rule expression is associated with its corresponding rule identifier and stored in the configuration center.

[0042] In this embodiment, business rules for various business scenarios are analyzed, and a set of rule components is extracted. The aim is to decompose complex, naturally language-described business rules into basic units that can be processed by a computer. For example, the business rule "If a user's level is VIP and the order amount is greater than 1000 yuan, they will enjoy a 10% discount" can be decomposed into components such as "user level," "VIP," "order amount," "greater than," and "1000 yuan." This process can utilize Natural Language Processing (NLP) technology to perform lexical and syntactic analysis on the business rule text, automatically identifying and extracting keywords, operators, values, variables, etc. Alternatively, a manually defined rule template or configuration interface can guide business personnel to input business rules in a structured manner, thereby directly obtaining the rule components.

[0043] Based on grammatical rules, the constituent elements of the rule set are organized into a tree structure to obtain an expression syntax tree. Its function is to represent the structure of business rules in an abstract way, where each node represents a component of the rule. Organizing the constituent elements into a syntax tree helps to clearly express the logical hierarchy and order of operations of the rules, facilitating subsequent parsing, verification, and execution. For example, the rule "User level == VIP && Order amount > 1000" can be represented as a binary tree with "&&" as the root node, and its left and right child nodes being "User level == VIP" and "Order amount > 1000" respectively. This can be achieved by using a lexical analyzer and parser from compiler principles to construct the expression syntax tree according to predefined grammatical rules (such as BNF paradigm). Alternatively, algorithms such as recursive descent parsers or operator precedence parsers can be used to directly construct a tree structure conforming to specific grammatical rules from the sequence of rule constituent elements.

[0044] Based on parameterized templates, placeholders are replaced in the fixed parameters of the expression syntax tree to generate parameterized expressions, thereby improving the configurability of the expressions. Fixed parameters refer to numerical values ​​or strings that may change in business rules but whose structure remains unchanged, such as "1000 yuan" in "order amount greater than 1000 yuan". By replacing them with placeholders (such as `$amount`), the expressions can be templated, allowing them to adapt to different business scenarios or strategy adjustments by modifying the values ​​of the placeholders without changing the expression structure, greatly improving the configurability and reusability of the rules. This can be achieved by pre-defining a set of parameterized templates, which includes placeholders and corresponding parameter types, and after building the expression syntax tree, traversing the syntax tree, identifying nodes that meet the characteristics of fixed parameters, and replacing them with the corresponding placeholders in the template. Alternatively, potential fixed parameters can be identified during the rule component extraction stage, and placeholders can be used directly when building the syntax tree, or after the syntax tree is built, placeholders can be inserted and replaced through a separate parameterization module.

[0045] Based on the results of syntax correctness and logical integrity verification of the parameterized expressions, the parameterized expressions are optimized to generate various business rule expressions. This step aims to ensure that the generated parameterized expressions are syntactically valid and logically complete and conflict-free. Syntax correctness verification ensures that the expressions conform to predefined syntax rules, such as matching brackets and using operators correctly. Logical integrity verification checks whether the expressions cover all necessary conditions and whether there are any contradictions or redundant logic. Through verification and optimization, the quality and reliability of business rule expressions can be improved. Syntax correctness verification can be performed by traversing the expression syntax tree and checking whether the type of each node and its child nodes conform to the syntax rules. Logical integrity verification can employ formal verification methods, such as model checking and theorem proving, or by using simulation execution and boundary condition testing to discover potential logical problems. Optimization can include removing redundant conditions and merging similar conditions. In addition, professional rule engines or expression parsing libraries can be integrated, as these libraries typically have built-in syntax checking and some logical verification functions.

[0046] Each business rule expression is associated with its corresponding rule identifier and stored in the configuration center. The configuration center is a platform that centrally manages system configurations and business rules. Optimized business rule expressions are associated with unique rule identifiers, allowing the system to quickly and accurately retrieve the corresponding business rule expression using the rule identifier. This centralized storage and management approach facilitates unified rule maintenance, version control, and dynamic updates, ensuring the consistency and availability of business rules throughout the system. This can be achieved using key-value stores (such as Redis, Etcd, Zookeeper, etc.), where the rule identifier is the key and the business rule expression is the value. Alternatively, a relational database (such as MySQL) or a document-oriented database (such as MongoDB) can be used to create a dedicated rule table containing fields such as rule identifier, rule expression content, version information, and creation time.

[0047] The proposed solution operates as follows: First, to ensure that the business rules used for decision-making are robust, flexible, and correctly formulated, the system initiates a structured rule generation and management process. This begins with a detailed analysis of business rules across various business scenarios, breaking them down into basic rule components. These components, as atomic parts of the rules, are then systematically organized into an expression syntax tree according to predefined syntax rules. This tree structure clearly captures the logical hierarchy and operational priorities of the rules, transforming potentially ambiguous textual descriptions into precise, machine-interpretable formats. To enhance the adaptability of these rules, a key step is parameterizing the expression syntax tree. Specifically, any fixed parameters in the expression tree are identified and replaced with generic placeholders using parameterized templates. This transformation produces a parameterized expression, which serves as a flexible blueprint, allowing for dynamic adjustments to the specific details of the rules (e.g., threshold values) without altering the underlying rule logic. This significantly improves the configurability and reusability of rules across different contexts or time periods. Before deployment, the generated parameterized expression undergoes rigorous validation, including syntactic correctness and logical integrity verification. Syntax validation ensures that expressions conform to the defined syntactic structure, preventing erroneous rules. Logical integrity validation checks internal consistency, contradictions, and comprehensive condition coverage, ensuring rule reliability and preventing unexpected behavior. Based on these validation results, parameterized expressions are optimized to generate final, robust business rule expressions. Finally, these optimized business rule expressions are securely stored in a centralized configuration center, with each expression associated with a unique rule identifier. This centralized storage mechanism ensures that when data processing methods need to retrieve business rule expressions for specific tagged business methods, they can reliably and efficiently obtain correct, validated, and optimized expressions through their rule identifiers. This structured rule generation and management approach directly addresses the challenges posed by the complexity, diversity, and frequent changes of business rules, ensuring that decision-making processes are always based on accurate, flexible, and well-maintained rules.

[0048] Through the above technical solution, this application provides a structured, automated, and configurable mechanism for generating and managing business rule expressions. By meticulously analyzing business rules, constructing expression syntax trees, and introducing parameterized templates for placeholder replacement, the configurability and reusability of business rule expressions are greatly improved, enabling business rules to flexibly adapt to changing business needs without frequent modifications to the underlying code. Furthermore, rigorous syntax correctness and logical integrity verification ensure the accuracy and reliability of the generated business rule expressions, effectively avoiding decision-making errors caused by rule mistakes. Finally, these optimized and verified business rule expressions are centrally stored in a configuration center, providing a solid foundation for retrieving and applying business rules in subsequent data processing methods, significantly improving the robustness, flexibility, and maintenance efficiency of the entire data processing system.

[0049] Reference Figure 3 , Figure 3 This is a flowchart illustrating another data processing method based on request interception provided in this application.

[0050] like Figure 3 As shown, this application provides a data processing method based on request interception. In one embodiment, step S102 includes: Step S1021: Based on graph theory algorithms, perform dependency analysis on the current business rule expression, and construct a rule dependency graph based on the analysis results; Step S1022: Based on the rule conflict detection algorithm and the rule dependency graph, perform logical conflict detection, parameter conflict detection, and execution order conflict detection on the current business rule expression; Step S1023: Based on preset optimization rules, optimize the conflicting business expressions to obtain the target expression.

[0051] In this embodiment, dependency analysis is performed on the current business rule expression based on graph theory algorithms. Graph theory is a branch of mathematics that studies graphs, which consist of nodes and edges connecting the nodes, and can effectively represent and analyze complex relationships between entities. By applying graph theory algorithms, the dependencies between the various components (e.g., sub-rules, conditions, variables) in the current business rule expression can be identified. For example, algorithms such as depth-first search (DFS) or breadth-first search (BFS) can be used to traverse the structure of the expression to discover its internal logical flow and data dependencies. Based on the analysis results, a rule dependency graph is constructed. A rule dependency graph is a graphical representation where nodes can represent the various components or sub-rules of a business rule, and edges represent the dependencies between these components. For example, if the execution of one sub-rule depends on the output of another sub-rule, a directed edge can be established between them. The construction of this graph helps to intuitively understand the structure of the rule and provides a foundation for subsequent conflict detection. Based on the rule conflict detection algorithm and the rule dependency graph, logical conflict detection, parameter conflict detection, and execution order conflict detection are performed on the current business rule expression. Rule conflict detection algorithms aim to identify contradictions, inconsistencies, or irrationalities in business rules. For example, predicate logic-based inference engines or expert system rule matching techniques can be used to identify conflicts. Logical conflict detection identifies contradictory logical conditions within rules; for example, when two rules have mutually exclusive conditions but the same conclusion, or when one rule's condition directly contradicts another's conclusion. Parameter conflict detection checks for undefined, type-mismatched, or value-domain-conflicting parameters referenced in rules, ensuring their correctness and validity. Execution order conflict detection analyzes the execution order of rules to ensure correct execution flow by identifying circular dependencies, unmet preconditions, or uncertain results. Based on preset optimization rules, conflicting business expressions are optimized. Preset optimization rules are a set of predefined strategies or transformation rules used to improve or correct business expressions. These rules may include, but are not limited to: merging duplicate conditions, simplifying Boolean expressions, eliminating redundant logic, constant folding, and eliminating common subexpressions. These rules aim to improve the execution efficiency and readability of expressions and eliminate potential errors. Optimization refers to correcting detected conflicts or structurally improving expressions according to predefined optimization rules to eliminate redundancy, improve efficiency, or enhance robustness. For example, if a logical conflict is detected, optimization rules may suggest modifying the conflict conditions or adjusting the priority of the rules; if a redundant expression is detected, it will be simplified.

[0052] This application's solution ensures the accuracy and reliability of current business rule expressions as target expressions by deeply analyzing, detecting, and optimizing them from the configuration center. Specifically, firstly, graph theory algorithms are used to analyze the dependency relationships within the internal structure of the current business rule expressions, identifying the interrelationships between various sub-rules, conditions, and variables, and constructing an intuitive rule dependency graph. This graph clearly shows the execution path and data flow of the rules, laying the foundation for subsequent conflict detection. Next, based on the constructed rule dependency graph and combined with a rule conflict detection algorithm, a comprehensive logical conflict detection, parameter conflict detection, and execution order conflict detection are performed on the current business rule expressions. Logical conflict detection aims to discover contradictions between rule conditions, parameter conflict detection verifies the correctness of parameter references, and execution order conflict detection ensures that the rule execution flow is reasonable and error-free. Once any form of conflict is detected, the system intelligently optimizes the conflicting business expressions according to preset optimization rules. This optimization process not only eliminates inconsistencies, redundancy, and potential errors in the rules but also improves the execution efficiency and stability of the expressions. Ultimately, the business rule expression, after rigorous testing and optimization, was established as the target expression. This ensures that the subsequent call decision results generated based on the target expression are accurate, reliable, and efficient, effectively avoiding erroneous decisions caused by rule defects, and thus improving the robustness and decision quality of the entire data processing method.

[0053] Through the above technical solution, this application can systematically perform dependency analysis, conflict detection, and optimization of complex business rule expressions. This effectively solves problems such as logical contradictions, parameter errors, and improper execution order that may exist in business rules, significantly improving the robustness, accuracy, and reliability of business rule expressions. The optimized target expression ensures that the decision logic is more rigorous when generating call decision results, avoiding erroneous judgments or inefficient execution caused by rule defects, thereby improving the decision quality and operational efficiency of the entire data processing method.

[0054] In one embodiment, generating the invocation decision result for the current invocation of the business method based on the business request parameters and the target expression includes: The business request parameters are bound to the variable environment of the target expression to obtain the parameter binding environment, so as to establish an association between the business request parameters and the variables of the target expression; The target expression is converted into a string form to generate an executable expression object, which is then executed in the parameter binding environment to obtain the invocation decision result.

[0055] In this embodiment, business request parameters are bound to the variable environment of the target expression to establish a mapping relationship between actual input data and abstract variables in the rule logic. Business request parameters are the actual input data, such as user ID, order amount, request time, etc., while the target expression is the logical representation of the business rule, containing variables, such as "user level" in "user level > 5". The variable environment or parameter binding environment is the data structure that stores this mapping relationship. This step enables the expression to understand and use actual business data for calculation. In a specific implementation, a hash table (Map / Dictionary) can be used to store key-value pairs, where the key is the variable name in the expression, and the value is the corresponding business request parameter. For example, a mapping table can be constructed to map "user_id" to the actual user ID value and "order_amount" to the actual order amount value. Alternatively, a context object can be defined, which encapsulates all business request parameters and provides methods to retrieve parameter values ​​by name. The expression parser can directly retrieve variable values ​​from this context object.

[0056] The process involves converting the target expression into a string, generating an executable expression object, and then executing this expression object within a parameter-bound environment. The aim is to transform a text-based expression into a computable form and perform actual calculations using the bound parameters. The target expression is typically a string, such as "user_id>100&&order_amount<1000". An executable expression object is an object that has been parsed, compiled, or interpreted and can be directly evaluated at runtime. This step transforms abstract rule logic into a concrete computational process and yields the final decision result. In practical implementations, an expression parser (such as Aviator, MVEL, SpEL, OGNL, etc.) can be used to parse the string expression into an Abstract Syntax Tree (AST), then traverse the AST and evaluate it within the parameter-bound environment. Alternatively, the string expression can be dynamically compiled into bytecode or an executable function, which can then be called and executed with the parameters passed to the parameter-bound environment.

[0057] When generating the call decision result for the current business method, this application first constructs a parameter binding environment by binding the business request parameters with the variable environment of the target expression. This step ensures that the abstract variables in the target expression can be accurately mapped to the actual business data. Subsequently, the target expression in string form is converted into an executable expression object. This conversion process makes the originally static rule logic dynamically computable. Finally, the executable expression object is executed in the established parameter binding environment, thereby dynamically calculating the call decision result based on the actual business request parameters. This mechanism effectively solves the problem of how to efficiently and accurately associate and effectively calculate dynamically changing business request parameters with abstract business rule expressions, ensuring the flexibility and accuracy of the decision-making process, thus providing a reliable basis for subsequent request approval or rejection.

[0058] The following example illustrates this. Suppose a business scenario requires deciding whether to allow a request based on user level and order amount. The target expression corresponding to the current business method call might be the string `"userLevel>5&&orderAmount>= 1000"`. When a current call request is received, the business request parameters extracted from it might include `userLevel = 7` and `orderAmount = 1200`. First, the system binds these business request parameters to the variable environment of the target expression. Specifically, a parameter binding environment can be created, such as a Map structure containing `{"userLevel": 7, "orderAmount": 1200}`. In this way, the variables `userLevel` and `orderAmount` in the expression are associated with the actual values. Next, the system converts the target expression `"userLevel>5&&orderAmount>= 1000"` into a string, generating an executable expression object. This process can be completed by an expression engine, which parses the string into an internal computable structure. Finally, the executable expression object is executed within the parameter binding environment described above. The expression engine retrieves the value of `userLevel` (7) and the value of `orderAmount` (1200) from the parameter binding environment, and then calculates `7>5` (true) and `1200>=1000` (true). Since both conditions are true, through a logical AND operation, the final call decision is "execute".

[0059] Through the above technical solution, this application can efficiently and accurately associate and calculate dynamically changing business request parameters with abstract business rule expressions. By binding business request parameters to the variable environment of the target expression, and further converting the target expression into an executable object and executing it in that environment, dynamic evaluation of business rules is achieved. This not only improves the flexibility and configurability of business rule processing and avoids the maintenance difficulties caused by hard-coded rules, but also ensures that in complex business scenarios, call decision results can be accurately generated based on real-time data, thereby effectively supporting intelligent interception and release of requests, and improving the automation level of data processing and the accuracy of decision-making.

[0060] In one embodiment, before intercepting the current call request corresponding to the current call request when the currently called business method belongs to the marked business method, and extracting the business request parameters from the current call request, the method further includes: Obtain the method object of the currently invoked business method, and perform annotation scanning on the method object to obtain all annotations corresponding to the currently invoked business method, which are then used as a method annotation set; Based on annotation type matching and the annotation type corresponding to the marked business method, the annotation set of the method is marked for annotation identification. If the method annotation set contains an annotation of the same type as the marker annotation, then the currently invoked business method belongs to the marked business method; If there is no annotation of the same type as the marker annotation in the method annotation set, then the currently invoked business method does not belong to the marker business method.

[0061] In this embodiment, obtaining the method object of the currently invoked business method refers to obtaining an abstract representation of the currently invoked business method itself at runtime. This method object contains the method's metadata information and is the basis for subsequent annotation scanning. For example, in object-oriented languages ​​such as Java, the `Method` object of a specific method can be dynamically obtained at runtime using reflection mechanisms, such as the `Class.getMethod()` or `Class.getDeclaredMethod()` methods. Furthermore, in some frameworks (such as Spring AOP), the instance of the currently invoked method can also be obtained before the method call through proxy mechanisms or aspect-oriented programming. Annotation scanning of the method object refers to checking whether specific annotations exist on the method object. Through scanning, all annotations declared on the method can be discovered; these annotations are typically used to add metadata to the method or indicate its specific behavior. Specifically, after obtaining the method object, its `getAnnotations()` or `getDeclaredAnnotations()` methods can be called to obtain all annotation instances declared on the method. Alternatively, by combining specific annotation processors or framework APIs, annotation information on methods can be traversed and parsed more efficiently. Obtaining all annotations corresponding to the currently invoked business method, as a method annotation set, involves organizing all scanned annotations into a collection for easier unified management and querying later. This collection is the direct basis for determining whether a method is a "marked business method." It can use data structures such as `java.util.Set` or `java.util.List` to store the obtained annotation objects, or store the annotation type as the key and the annotation instance as the value in a `Map` for quick lookup of specific annotation types. Based on annotation type matching and the marked annotation type corresponding to the marked business method, identifying the marked annotations in the method annotation set is the core step in determining whether a business method is marked. The marking of a method is determined by comparing the type of each annotation in the method annotation set with a predefined "marked annotation type." For example, the method annotation collection can be traversed. For each annotation in the collection, its type (Class) can be obtained, and then compared with a preset marker annotation type (e.g., `@InterceptedMethod`) using `equals()`. Alternatively, an annotation processor can be defined that can recognize multiple marker annotation types and match them according to configured priorities or rules. If an annotation with the same type as the marker annotation exists in the method annotation collection, then the currently invoked business method belongs to the marked business method. This clarifies the judgment logic; once a matching marker annotation is found, the method is confirmed as a marked business method, thereby triggering subsequent interception processing.If there is no annotation of the same type as the marked annotation in the method annotation set, then the currently called business method does not belong to the marked business method. This clarifies the reverse judgment logic, ensuring that only explicitly marked methods will be intercepted, and avoiding the false interception of unmarked methods.

[0062] This application's solution dynamically obtains the method object of the currently calling business method before the method call and scans its annotations to construct a set of all annotations for that method. Subsequently, the system matches and identifies this annotation set based on preset marker annotation types. If an annotation of the same type as the marker annotation exists in the method annotation set, the business method is identified as a "marked business method," triggering the request interception process in the aforementioned data processing method. Conversely, if no matching annotation exists, the method is not considered a "marked business method," and the request will not be intercepted. This mechanism provides a declarative, non-intrusive way to identify business methods that need to be intercepted, decoupling business logic from interception logic and greatly improving the system's flexibility and maintainability. In this way, the aforementioned data processing method can accurately determine when to intercept the current call request, ensuring that only business methods conforming to specific rules are included in subsequent rule decisions and processing flows, thereby avoiding unnecessary processing overhead and guaranteeing the accuracy of data processing.

[0063] The following example illustrates this. Suppose a Java-based business system contains a service class named `OrderService`, which includes a method `processOrder` for processing orders. To allow the `processOrder` method to be intercepted by the aforementioned data processing method, a custom annotation, such as `@Intercept`, can be added to this method. When the system is about to call the `OrderService.processOrder(Order order)` method, it first obtains the `Method` object of the `processOrder` method through Java reflection. For example, this can be done using `OrderService.class.getMethod("processOrder", Order.class)`. Next, the system performs an annotation scan on this `Method` object, calling the `method.getAnnotations()` method to retrieve all annotation instances declared on the method and collect them into a `List`. <annotation>In this context, the `processOrder` method is defined as a `setup of method annotations`. The system then iterates through each annotation in this set, checking if its type matches the predefined `marker annotation type corresponding to the marked business method` (i.e., `@Intercept.class`). If the `processOrder` method is declared as `@Intercept public void processOrder(Order order)`, then an instance of the `@Intercept` annotation will exist in the `setup of method annotations`. In this case, the system recognizes that the method contains the `@Intercept` annotation, thus determining that the `processOrder` method belongs to the `marked business method` category. Conversely, if the `processOrder` method does not have the `@Intercept` annotation, then no annotation of that type will exist in the `setup of method annotations`, and the system will determine that the `processOrder` method does not belong to the `marked business method` category. In this way, the system can dynamically determine at runtime whether any called business method needs to be intercepted without modifying the business logic code itself; marking can be achieved solely through annotations.

[0064] Through the above technical solution, this application provides a flexible and easy-to-maintain mechanism for accurately identifying business methods that require request interception. By utilizing method annotations, business developers can declaratively mark whether a method is a "marked business method" directly on its definition, without modifying core business logic or maintaining separate configuration files. This greatly simplifies the identification process of "marked business methods," avoids hard-coding or configuration errors that may occur in traditional methods, and improves the accuracy and efficiency of system identification. When combined with the aforementioned data processing methods, it ensures that only explicitly marked business methods are included in the interception process, thereby avoiding unnecessary interception of non-marked methods, reducing system overhead, and improving the overall performance and stability of data processing. Simultaneously, this annotation-based identification method also enhances the system's scalability, making it more convenient to add or modify business methods that need to be intercepted.

[0065] In one embodiment, intercepting the current call request corresponding to the currently invoked business method includes: Obtain the original call request, and based on protocol parsing technology, parse the original call request according to the protocol format to obtain the protocol parsing result; The business request parameters are extracted from the protocol parsing result, and a context is constructed from the business request parameters to obtain request context information containing call chain information; An interceptor execution chain is constructed based on the request context information, and the current call request is intercepted based on each interceptor in the interceptor execution chain and the interception order.

[0066] In this embodiment, obtaining the original call request refers to the unprocessed, raw form of request data received by the system. This can be an HTTP request from the client, a Remote Procedure Call (RPC) request, a message in a message queue, or any other form of external input. It can be obtained through various means such as network listening, API gateway reception, and message queue consumption. Based on protocol parsing techniques, the original call request is parsed to obtain the protocol parsing result. This refers to the process of structurally interpreting the binary stream or text data of the original call request according to predefined communication protocol specifications. For example, for an HTTP request, its request header, request body, URL parameters, etc., can be parsed; for an RPC request, its service name, method name, parameter serialization format, etc., can be parsed. This can be achieved using existing protocol parsing libraries or custom parsers, aiming to convert raw, unstructured request data into structured data that the program can understand and manipulate, i.e., the protocol parsing result. Extracting business request parameters from the protocol parsing result and constructing a context for these parameters to obtain request context information containing call chain information refers to the input data directly related to the business logic identified and extracted from the structured protocol parsing result. For example, in an e-commerce order creation request, business request parameters might include product ID, user ID, and purchase quantity. Context construction refers to further integrating information related to the current request execution environment, especially call chain information, based on the extracted business request parameters. Call chain information is typically used in distributed systems to trace the complete path of a request, for example, by using identifiers such as Trace ID and Span ID to record the flow of the request from the initiating end to the final processing end. This can be achieved by passing trace information in the request header and parsing and passing it at each service node. Building request context information aims to provide a comprehensive and rich view of the runtime environment for subsequent business processing and decision-making. Building an interceptor execution chain based on request context information, and intercepting the current call request based on the individual interceptors and their interception order, means that the interceptor execution chain consists of a series of interceptors arranged in a specific order, each responsible for executing specific preprocessing, post-processing, or conditional judgment logic. Building an interceptor execution chain based on request context information means that the system can dynamically select and organize the interceptors to be executed based on the characteristics of the request (such as request type, source, call chain information, etc.). For example, a security authentication interceptor can be added for high-risk requests; a logging interceptor can be added for requests that require logging. The interception order determines the execution order of each interceptor. Through this mechanism, the current request will pass through each interceptor in the execution chain before reaching the actual business method. Each interceptor can check, modify, or terminate the request, thereby achieving fine-grained request interception and control.

[0067] This application's solution first acquires the original call requests received by the system, ensuring coverage of all potential requests. Then, it uses protocol parsing techniques to perform structured parsing on these original requests, converting them from their raw format into operable protocol parsing results, thereby accurately identifying and extracting the business request parameters contained within. Based on this, it further constructs context for these business request parameters, and importantly, integrates call chain information, providing comprehensive request background and tracing capabilities for subsequent decision-making and processing. Finally, based on this rich request context information, the system can dynamically construct an interceptor execution chain and execute each interceptor in the chain sequentially according to a preset interception order, thereby achieving fine-grained and configurable interception of the current call request. This mechanism not only solves the limitations of simple interception methods when handling complex protocols and lacking context information, but also greatly improves the flexibility and scalability of request interception by dynamically constructing and executing the interceptor chain, ensuring that only requests that meet specific rules can enter the subsequent business processing flow, while providing crucial support for request tracing and problem localization in a distributed environment.

[0068] As a specific implementation, assuming a microservices-based system, when a user initiates an API call request via HTTP, the system first obtains the original HTTP call request. Next, the system can use an HTTP protocol parser, such as one implemented using the Netty framework, to parse the request headers, request body, and URL parameters of the original HTTP request, obtaining a structured protocol parsing result. From this parsing result, the business-related JSON request body content can be extracted as business request parameters. Simultaneously, the system identifies and extracts distributed tracing identifiers (such as `X-B3-TraceId` or `traceparent`) from the HTTP request headers and encapsulates them together with the business request parameters to construct request context information containing call chain information. For example, this context information might include the request's unique trace ID, the current service ID, and the upstream service ID. Subsequently, the system dynamically constructs an interceptor execution chain based on this request context information. For example, if the request context indicates that this is an API requiring user authentication, the execution chain will include a user authentication interceptor; if the request context indicates that the API requires traffic control, a rate limiting interceptor will be added. These interceptors will be executed in a preset order, performing operations such as security verification, logging, and parameter validity checks on the request, and finally deciding whether to allow the current call request.

[0069] Through the above technical solutions, this application enables fine-grained and configurable interception of current call requests. By parsing the protocol format of the original call request, the system can effectively handle various complex communication protocols, ensuring the accurate extraction of business request parameters. Furthermore, by constructing request context information containing call chain information, it provides crucial support for request tracing, fault location, and performance monitoring in distributed systems, significantly improving system observability. In addition, dynamically constructing the interceptor execution chain based on the request context information allows the interception logic to be flexibly adjusted and expanded according to the actual characteristics of the request, thereby achieving fine-grained control over the request processing flow. This effectively solves the limitations of traditional interception mechanisms in handling diverse requests and complex business scenarios, improving the robustness and efficiency of data processing.

[0070] Please see Figure 4 , Figure 4 A schematic diagram of the functional modules of a data processing device based on request interception provided in this application.

[0071] like Figure 4 As shown, the data processing device 400 based on request interception includes: The call request interception module 410 is used to intercept the current call request corresponding to the current call business method when the current call business method belongs to the marked business method, and extract the business request parameters from the current call request; The rule expression acquisition module 420 is used to acquire the current business rule expression of the currently invoked business method from the configuration center based on the rule identifier of the currently invoked business method, and use it as the target expression; The business method invocation module 430 is used to generate the invocation decision result of the current business method invocation based on the business request parameters and the target expression; The business method allowing module 440 is used to allow the current call request when the call decision result is to execute, and to call the current call business method to process the business request parameters; The business method interception module 450 is used to reject the current call request and skip the current call business method when the call decision result is interception, so as to process the next call request.

[0072] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the above-described apparatus and modules can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0073] The aforementioned device can be implemented as a computer program, which can be used in, for example... Figure 5 It runs on the computer device shown.

[0074] Please see Figure 5 , Figure 5 This application provides a schematic block diagram of the structure of a computer device. The computer device may be a server.

[0075] See Figure 5 The computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0076] Non-volatile storage media can store operating systems and computer programs. These computer programs include program instructions that, when executed, cause the processor to perform any request-based data processing method.

[0077] The processor provides computing and control capabilities, supporting the operation of the entire computer device.

[0078] Internal memory provides an environment for the execution of computer programs stored in non-volatile storage media. When executed by a processor, the computer program enables the processor to perform any request-based data processing method.

[0079] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0080] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0081] The embodiments of this application also provide a computer-readable storage medium storing a computer program, the computer program including program instructions, and the processor executing the program instructions to implement any of the request interception-based data processing methods provided in the embodiments of this application.

[0082] The computer-readable storage medium may be an internal storage unit of the computer device described in the foregoing embodiments, such as the hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, SmartMedia Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the computer device.

[0083] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / annotation>

Claims

1. A data processing method based on request interception, characterized in that, The data processing method includes the following steps: When the currently invoked business method belongs to the marked business method, the current invocation request corresponding to the current invocation business method is intercepted, and the business request parameters are extracted from the current invocation request; Based on the rule identifier of the currently invoked business method, the current business rule expression of the currently invoked business method is obtained from the configuration center and used as the target expression; Based on the business request parameters and the target expression, generate the invocation decision result for the current business method being invoked; When the call decision result is to execute, the current call request is allowed, and the current call business method is called to process the business request parameters; When the call decision result is interception, the current call request is rejected and the current call business method is skipped in order to process the next call request.

2. The data processing method as described in claim 1, characterized in that, Before intercepting the current call request corresponding to the currently called business method and extracting the business request parameters from the current call request when the currently called business method belongs to the marked business method, the method further includes: Obtain the set of business methods from the business system, and extract features from each business method in the set to obtain a set of method features; The method feature set is matched with preset interception rules to obtain a set of business methods to be intercepted and marked. Add interception annotations to each business method in the set of business methods to be marked to obtain the set of marked business methods; Each marking service method in the set of marking service methods is registered, and an interception point mapping relationship is established to complete the marking of the service methods that need to be intercepted.

3. The data processing method as described in claim 1, characterized in that, Before obtaining the current business rule expression of the currently invoked business method from the configuration center based on the rule identifier of the currently invoked business method, and using it as the target expression, the process further includes: Analyze the business rules for each business scenario and extract the set of rule components; Based on the syntax rules, the various rule components in the rule component set are organized into a tree structure to obtain the expression syntax tree; Based on parameterized templates, placeholders are replaced in the fixed parameters of the expression syntax tree to generate parameterized expressions, thereby improving the configurability of the expressions. Based on the syntax correctness verification results and logical integrity verification results of the parameterized expression, the parameterized expression is optimized to generate various business rule expressions; Each business rule expression is associated with its corresponding rule identifier and stored in the configuration center.

4. The data processing method as described in claim 1, characterized in that, The step of obtaining the current business rule expression of the currently invoked business method from the configuration center based on the rule identifier of the currently invoked business method, as the target expression, includes: Based on graph theory algorithms, dependency analysis is performed on the current business rule expression, and a rule dependency graph is constructed based on the analysis results. Based on the rule conflict detection algorithm and the rule dependency graph, logical conflict detection, parameter conflict detection, and execution order conflict detection are performed on the current business rule expression. Based on preset optimization rules, conflicting business expressions are optimized to obtain the target expression.

5. The data processing method as described in claim 1, characterized in that, The step of generating the invocation decision result for the current invocation of the business method based on the business request parameters and the target expression includes: The business request parameters are bound to the variable environment of the target expression to obtain the parameter binding environment, so as to establish an association between the business request parameters and the variables of the target expression; The target expression is converted into a string form to generate an executable expression object, which is then executed in the parameter binding environment to obtain the invocation decision result.

6. The data processing method as described in claim 1, characterized in that, Before intercepting the current call request corresponding to the currently called business method and extracting the business request parameters from the current call request when the currently called business method belongs to the marked business method, the method further includes: Obtain the method object of the currently invoked business method, and perform annotation scanning on the method object to obtain all annotations corresponding to the currently invoked business method, which are then used as a method annotation set; Based on annotation type matching and the annotation type corresponding to the marked business method, the annotation set of the method is marked for annotation identification. If the method annotation set contains an annotation of the same type as the marker annotation, then the currently invoked business method belongs to the marked business method; If there is no annotation of the same type as the marker annotation in the method annotation set, then the currently invoked business method does not belong to the marker business method.

7. The data processing method according to any one of claims 1-6, characterized in that, The interception of the current call request corresponding to the currently invoked business method includes: Obtain the original call request, and based on protocol parsing technology, parse the original call request according to the protocol format to obtain the protocol parsing result; The business request parameters are extracted from the protocol parsing result, and a context is constructed from the business request parameters to obtain request context information containing call chain information; An interceptor execution chain is constructed based on the request context information, and the current call request is intercepted based on each interceptor in the interceptor execution chain and the interception order.

8. A data processing apparatus based on request interception, characterized in that, The question-and-answer device includes: The call request interception module is used to intercept the current call request corresponding to the current call business method when the current call business method belongs to the marked business method, and extract the business request parameters from the current call request; The rule expression acquisition module is used to acquire the current business rule expression of the currently invoked business method from the configuration center based on the rule identifier of the currently invoked business method, and use it as the target expression; The business method invocation module is used to generate the invocation decision result of the current business method invocation based on the business request parameters and the target expression; The business method allowing module is used to allow the current call request when the call decision result is to execute, and to call the current call business method to process the business request parameters; The business method interception module is used to reject the current call request and skip the current call business method when the call decision result is interception, so as to process the next call request.

9. A computer device, characterized in that, The computer device includes a processor, a memory, and a request-based interception data processing program stored in the memory and executable by the processor, wherein when the request-based interception data processing program is executed by the processor, it implements the steps of the request-based interception data processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a request-based data processing program, wherein when the request-based data processing program is executed by a processor, it implements the steps of the request-based data processing method as described in any one of claims 1 to 7.

Images