Business processing method and device, nonvolatile storage medium and computer equipment

Abstract

The invention discloses a business processing method and device, a nonvolatile storage medium and computer equipment. The method comprises the following steps: acquiring a service request; identifying a target service feature corresponding to the service request; judging whether a rule corresponding to the target service feature exists or not based on a preset corresponding relationship between the service feature and the rule; and under the condition that the target rule corresponding to the target service feature exists, calling the target rule to process the service request. According to the method and the device, the technical problems that the request, analysis and processing of the current service mostly depend on hard coding or static rules, the limitation of the static rules exists, and the adaptability of complex scenes is poor are solved.

Description

Technical Field

[0001] This invention relates to the field of information technology, and more specifically, to a business processing method, apparatus, non-volatile storage medium, and computer equipment. Background Technology

[0002] With the continuous innovation and development of global financial market operations, back-end transactions involve numerous modules, such as transaction authorization, transaction verification, accounting, fund clearing, bonds, and physical settlement. Each module contains a series of checks, matching, or generation rules, which are executed to achieve functional requirements such as process scheduling, rule verification jumps, and handling different branch returns. To simplify the complexity of business processing code, it is necessary to abstract the rule processing process scattered across various business modules. Based on the characteristics of financial market back-end operations, a relatively independent and reusable dynamic rule engine is developed to provide unified rule parsing and execution services for each module. This engine is mainly divided into: a data acquisition module (for acquiring financial business requests, parsing multi-dimensional business data, and extracting business features); a rule management module (for loading rule sets based on business rules, self-learning and optimizing relevant rules, and executing them); an execution module (for triggering automated business operations based on rule judgment results); a log module (for recording processing processes and results to support compliance audits); and a monitoring module (for monitoring system performance and optimizing rule execution strategies).

[0003] Existing technologies are mostly static rules, which are difficult to adapt quickly to changes in new business formats and markets. They do not support automatic learning mechanisms and have the limitations of static rules, resulting in high maintenance costs. They also lack real-time performance: traditional rule engines cannot meet the needs of serial processing in scenarios such as high-frequency trading, and do not support automatic rule sorting and optimization.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides a business processing method, apparatus, non-volatile storage medium, and computer device to at least address the technical problems that current business requests rely heavily on hard-coded or static rules for parsing and processing, resulting in limitations of static rules and poor adaptability to complex scenarios.

[0006] According to one aspect of the present invention, a business processing method is provided, comprising: acquiring a business request; identifying a target business feature corresponding to the business request; determining whether a rule corresponding to the target business feature exists based on a preset correspondence between business features and rules; and, if a target rule corresponding to the target business feature exists, retrieving the target rule to process the business request.

[0007] Optionally, it also includes: sending a business request to the front end when there is no rule corresponding to the target business feature; receiving the processing result from the front end; and determining a new rule corresponding to the target business feature based on the processing result and the target business feature.

[0008] Optionally, it also includes: when there are multiple business requests whose corresponding business characteristics all match the target business characteristics, processing the multiple business requests using a new rule to obtain the processing results corresponding to each of the multiple business requests; determining the processing success rate based on the processing results corresponding to each of the multiple business requests; and adding the target business characteristics and the new rule to the correspondence when the processing success rate exceeds a preset success rate threshold and the number of multiple business requests exceeds a preset frequency threshold.

[0009] Optionally, the target business features and the new rules are added to the correspondence, including: detecting the number of intersections and unions of the new rules and the multiple rules in the correspondence; determining whether there are any rules among the multiple rules that satisfy the merging condition with the new rule based on the number of intersections and unions of the multiple rules; merging the rules with the new rule to obtain the merged rule if there are any rules among the multiple rules that satisfy the merging condition with the new rule; and updating the correspondence based on the merged rule and the target business features.

[0010] Optionally, based on the processing results and the target business characteristics, new rules corresponding to the target business characteristics are determined, including: based on the processing results, identifying the business characteristic pattern corresponding to the target business characteristics; and generating conditional expressions for the new rules based on the business characteristic pattern.

[0011] Optionally, it also includes: obtaining the execution frequency and success rate of each of the multiple rules in the corresponding relationship; determining the priority of each of the multiple rules based on the execution frequency and success rate of each of the multiple rules; when there are multiple target rules corresponding to the target business feature, selecting the target rule whose priority meets the preset conditions as the execution rule based on the priority of each of the multiple target rules; and calling the execution rule to process the business request.

[0012] According to another aspect of the present invention, a business processing apparatus is also provided, comprising: an acquisition module for acquiring a business request; an identification module for identifying a target business feature corresponding to the business request; a judgment module for determining whether a rule corresponding to the target business feature exists based on a preset correspondence between business features and rules; and a retrieval module for retrieving a target rule to process the business request if a target rule corresponding to the target business feature exists.

[0013] According to another aspect of the present invention, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored program, wherein, when the program is running, it controls the device where the non-volatile storage medium is located to execute any of the above-described business processing methods.

[0014] According to another aspect of the present invention, a computer device is also provided, the computer device including a processor, the processor being configured to run a program, wherein the program executes any of the above-described business processing methods during runtime.

[0015] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements any of the above-described business processing methods.

[0016] In this embodiment of the invention, a business processing method is adopted. This method involves obtaining a business request; identifying the target business characteristics corresponding to the business request; determining whether a rule corresponding to the target business characteristics exists based on a preset correspondence between business characteristics and rules; and, if a target rule corresponding to the target business characteristics exists, retrieving the target rule to process the business request. This achieves the purpose of introducing dynamic rule configuration, rule priority evaluation, and multi-threaded parallel processing mechanisms. As a result, the business processing method can be dynamically configured, adapting to complex financial scenarios, supporting real-time processing, automatic learning, and easy expansion. This solves the technical problem that current business request parsing and processing often rely on hard-coded or static rules, which have limitations of static rules and poor adaptability to complex scenarios. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0018] Figure 1 A hardware structure block diagram of a computer terminal for implementing a business processing method is shown.

[0019] Figure 2 This is a flowchart illustrating a business processing method provided according to an embodiment of the present invention;

[0020] Figure 3 This is a schematic diagram of a business processing method provided by an optional embodiment of the present invention;

[0021] Figure 4 This is a structural block diagram of a service processing apparatus provided according to an embodiment of the present invention. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0025] Rule engine: This refers to a framework where users can define a set of custom rules and explicitly specify the return values ​​for successful and unsuccessful execution of each rule. After the input data is processed by the rule engine, an execution result set is automatically generated, and users can extract the result values ​​from multiple dimensions according to business needs.

[0026] Rules: Rules are the basic building blocks of the rule engine framework. Each rule corresponds to a specific business rule. A rule includes a rule ID, sequence number, validation content (calculation type, rule description), and return value (success / failure response code and information).

[0027] According to an embodiment of the present invention, a method embodiment of a business processing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0028] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware structure block diagram of a computer terminal for implementing a business processing method is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0029] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0030] The memory 104 can be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the business processing methods in the embodiments of the present invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned application's business processing methods. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0031] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0032] Figure 2 This is a flowchart illustrating a business processing method provided according to an embodiment of the present invention, such as... Figure 2 As shown, the method includes the following steps:

[0033] Step S202: Obtain the business request.

[0034] This step can be divided into the following specific processes: The business system receives business request data packets from the front-end or external systems through its network interface. These data packets may carry various financial transaction information, such as transfer requests, account query requests, etc. After receiving the data packets, the system performs format and integrity checks to ensure that the data packets conform to the predefined business request format and contain all necessary business parameters. If the data packet format is incorrect or lacks key information, an error message may be returned, requiring the front-end to resubmit the correct request. Once the data packet is determined to be valid, the system parses the business request parameters in the data packet, such as extracting key fields such as transaction amount, transaction type, and account information of both parties, to prepare for subsequent business feature identification. After parsing the parameters, the system preprocesses the data, such as converting data types, unifying units, and cleaning up redundant information, to adapt to the data format requirements of subsequent business processing modules. All parsed and preprocessed data is encapsulated into a business request object, which contains all necessary business information and features.

[0035] Specifically, during data preprocessing, data standardization and data anonymization techniques can be employed to ensure data consistency and protect user privacy. For example, transaction amounts may need to be converted to different units based on currency type to ensure all transaction data is compared and processed within the same unit; account information may be replaced with unique identifiers during internal processing to avoid directly exposing sensitive data while maintaining data relevance and traceability.

[0036] Step S204: Identify the target business characteristics corresponding to the business request.

[0037] In this step, after receiving a business request, it is preprocessed, including formatting, standardization, and cleaning invalid data to ensure data consistency and integrity. Attributes closely related to business processing are extracted from the preprocessed data. For example, in a financial transaction scenario, these may include transaction amount, transaction type, transaction time, and information of the parties involved in the transaction. Based on the extracted business attributes, key features that can represent the characteristics of the business request are identified.

[0038] Specifically, machine learning models or pre-defined feature recognition algorithms can be used to transform business attributes into business features. The identified business features are then compared with a pre-defined feature library to find the best-matching business feature description. This helps in subsequent steps to match business requests with corresponding rules. In some cases, it is necessary to further refine the identified business features; for example, refining "large transaction" to the feature "amount greater than 50,000 yuan" to improve the accuracy of rule matching. Furthermore, the identified and refined features are encoded into feature vectors or feature sets for easy computer understanding and processing. This feature information is stored for use in subsequent steps such as rule matching, and also facilitates the tracking and auditing of the entire business processing process.

[0039] Step S206: Based on the preset correspondence between business features and rules, determine whether there is a rule corresponding to the target business feature.

[0040] In this step, the pre-defined relationship between rules and business features can be managed through a database. Each rule is defined as an entry, containing fields such as rule ID, business feature description, conditional expression, execution logic, and expected result. The database can be a relational database to support flexible queries and high-concurrency access. The correspondence between rules and business features can be encoded in configuration files, such as XML or JSON files. These files can be loaded by the rule engine at startup for subsequent querying and matching. Furthermore, for complex business scenarios, rule trees or rule graphs can be used to represent the correspondence between rules and business features, where nodes represent business features or rules, and edges represent the mapping relationship from features to rules.

[0041] The rule management module within the business system will consult a pre-defined business feature-rule mapping table, which contains the mapping relationship between all known business features and their corresponding rules. For each received business feature, the system will search for a matching rule. If a matching rule is found, the target business feature has been identified by the system and there is a ready-made processing logic that can be applied to the current business request. If no matching rule is found, it means that the current business feature belongs to a new scenario or is a situation that existing rules cannot cover. In this case, the system will adopt an alternative processing procedure, sending the business request to the front end for manual processing and collecting the processing results for subsequent learning and rule generation.

[0042] Furthermore, during the search process, the business system may encounter situations where multiple rules match the target business characteristics. In this case, further filtering and optimization will be performed based on rule priority and condition overlap. Rules with higher priority will be executed first, while rules with high condition overlap may be merged to reduce redundancy in the rule base and improve processing efficiency. Rule priority and overlap are dynamically adjusted through statistical analysis of historical business data and rule execution results. For example, if the business characteristic is "large online transactions," the business system will search the rule base for a rule that matches this characteristic. If it exists, the rule will be marked as a matching rule; if it does not exist, this deficiency will be recorded, and a new rule will be created based on the business characteristics and processing results after manual processing.

[0043] Step S208: If there is a target rule corresponding to the target business characteristics, retrieve the target rule to process the business request.

[0044] In this step, the business system searches a pre-defined rule set for specific rules that match the target business characteristics. This process may involve searching the rule base to ensure that the most relevant rules for the business request are found. Rule matching is based not only on an exact match of business characteristics but also on factors such as rule priority, scope of application, and historical success rate.

[0045] Once a matching target rule is found, the business system will invoke the corresponding rule processing service. This means that the identified rule and business request data are submitted to the rule engine through a calling mechanism (such as a function call, API call, or service messaging). The rule processing service will further decompose the business request data and compare it with the conditions in the rule to determine whether the rule requirements are met.

[0046] Specifically, after receiving the target rule and service call, the rule engine parses the conditional expressions in the rule. Once parsed, the rule engine executes the rule and evaluates the business request. During execution, the rule engine may need to access additional data sources or call other services to obtain the necessary information to complete the rule evaluation. The result of the rule execution will be generated according to the preset rule logic, including but not limited to approving, rejecting, or redirecting the business request.

[0047] Finally, the rules engine completes its execution and sends the result back to the caller. The result may be a simple pass / fail flag, or it may include detailed execution logs and a description of the reason.

[0048] The entire business process is as follows Figure 3As shown, the system first dynamically loads the corresponding rule set based on the business scenario. The rule set includes predefined rules and dynamically generated rules. It supports a visual interface and API operations, and supports automatic rule learning: if a transaction fails the rule engine verification, it needs to be manually processed. When the same rule is manually processed a certain number of times and the success rate reaches a certain threshold, it triggers automatic learning to generate new rules, which are then added to the rule library for subsequent automatic transaction processing.

[0049] Through the above steps, the business processing method can be dynamically configured to adapt to complex financial scenarios, support real-time processing, automatic learning, and be easily scalable. This solves the current technical problem that business requests, parsing, and processing rely heavily on hard-coded or static rules, which have limitations of static rules and poor adaptability to complex scenarios.

[0050] As an optional embodiment, this can be achieved through the following steps: further including: sending a business request to the front end when there is no rule corresponding to the target business feature; receiving the processing result from the front end; and determining a new rule corresponding to the target business feature based on the processing result and the target business feature.

[0051] Optionally, when the rule engine in the business processing method cannot find a matching rule to process a specific business request based on the preset correspondence between business characteristics and rules, this embodiment provides an efficient learning mechanism to dynamically generate new rules, thereby adapting to changes in business scenarios and new types of business requests.

[0052] Specifically, the following steps are included:

[0053] Step 1: When a business request enters the system, the rules engine attempts to identify and match the corresponding rules. If no rule is found that matches the target business characteristics, this may be due to changes in the business scenario or the first appearance of a new type of business request. In this case, the system will not immediately reject or postpone the request, but will forward it to the front-end interface or a manual intervention system.

[0054] Step 2: The business request is sent to the front end, where it is displayed to the business operator or customer service representative. The business operator or customer service representative will then review and process the request in detail based on their expertise and experience. This includes, but is not limited to, inquiring about more customer information, verifying transaction details, or performing additional credit checks.

[0055] Step 3: After manual processing is completed, the front-end will send the processing result to the rules engine. This feedback includes, but is not limited to, the final status of the business request (approved or rejected), the business logic used in the processing, and any additional comments or reasons. The rules engine collects and analyzes this feedback to identify potential business characteristic patterns and processing logic.

[0056] Step 4: Based on the collected processing results and target business characteristics, the rule engine generates new rules. Through statistical analysis, the rule engine identifies which business characteristics are associated with specific processing results and then constructs corresponding rule expressions. For example, if multiple "large online transaction" requests are manually approved, the rule engine might learn a new rule: "Automatically approve when the transaction amount exceeds X yuan and is an online transaction." Here, X yuan is a threshold that can be derived based on historical data analysis. After the new rule is generated, the rule engine will further verify its effectiveness and reliability, such as through simulation testing or small-scale trial runs, to observe its performance in a real business environment. Once verified, the new rule will be officially added to the rule base, becoming the standard process for handling similar business characteristic requests in the future.

[0057] As an optional embodiment, this can be achieved through the following steps: It further includes: when multiple business requests each have business characteristics that match the target business characteristics, processing the multiple business requests using a new rule to obtain processing results for each of the multiple business requests; determining the processing success rate based on the processing results for each of the multiple business requests; and adding the target business characteristics and the new rule to the correspondence when the processing success rate exceeds a preset success rate threshold and the number of multiple business requests exceeds a preset frequency threshold.

[0058] In this step, feature identification is performed first, grouping requests with the same or similar business characteristics together. These characteristics include, but are not limited to, transaction amount, transaction type, transaction time, and participant information. Once multiple business requests are identified as matching the target business characteristics, the business system will attempt to process these requests in batches using new rules. These new rules can be automatically generated during previous processing based on business operations and processing results fed back from the front end. Using new rules to process multiple requests can significantly improve processing efficiency, especially when handling high-frequency transactions.

[0059] Furthermore, after processing, the processing result of each business request is recorded, including whether it was successful, the reason for failure, and the processing time. Based on these processing results, the success rate of the new rule is calculated, which is the ratio of the number of business requests successfully processed by the new rule to the total number of business requests processed. If the success rate of the new rule exceeds a preset success rate threshold (e.g., 70%), and the number of business requests processed exceeds a preset frequency threshold (e.g., 100 times), then the new rule is considered to perform well in the current business scenario and is worth adding to the rule base for use in subsequent requests.

[0060] Specifically, before adding new rules to the rule base, a comparative analysis is performed between the new rules and existing rules. If there is overlap between the new and existing rules, and the overlap exceeds a preset merging threshold (e.g., 80%), these rules are merged into a more general rule to reduce the number of rules and improve the simplicity of the rule base. After merging the rules, the correspondence between business features and rules is updated based on the merged rules and target business characteristics to ensure the logical consistency and optimization of the rule base.

[0061] As an optional implementation, this can be achieved through the following steps: adding the target business features and new rules to the correspondence, including: detecting the number of intersections and unions of the new rules and the multiple rules in the correspondence; determining, based on the number of intersections and unions of the multiple rules, whether there is a rule among the multiple rules that satisfies the merging condition with the new rule; merging the rule with the new rule to obtain the merged rule if there is a rule among the multiple rules that satisfies the merging condition with the new rule; and updating the correspondence based on the merged rule and the target business features.

[0062] Optionally, the new rule is first compared with each existing rule in the corresponding relationship. For each existing rule, the intersection and union of the new rule with it are calculated. This involves comparing the condition fields of the new rule and the existing rule. The number of intersections and unions is calculated. This involves comparing the range of numerical conditions or evaluating the matching degree of string conditions.

[0063] Furthermore, a condition overlap threshold is defined to determine the likelihood of rule merging. This threshold can be flexibly set according to business needs and rule complexity. The number of intersections and unions of each existing rule is analyzed, and their overlap ratio is calculated. If the overlap ratio between an existing rule and a new rule exceeds a preset threshold, then the two rules are considered to have some degree of duplication or similarity, and merging can be considered.

[0064] Specifically, if existing rules meet the merging criteria, they will be merged. Generating merged rules involves the following steps: identifying the core differences between the two rules. This may involve comparing condition fields one by one to find similarities and differences; merging the differences into a broader conditional expression. For example, if the new rule requires "transaction amount greater than 5000," while an existing rule requires "transaction amount greater than 5500," then the merged rule could be "transaction amount greater than 5000"; and updating the rule's return value or action to ensure that the merged rule, when executed, covers the functionality of the original two rules.

[0065] Finally, after the rules are merged, the mapping between business features and rules is updated to ensure that newly added rules can be correctly applied to the corresponding business requests. The update process involves recalculating the priority, success rate, or execution frequency of the rules to reflect the latest state after the rule merge. The adjusted mapping is persistently stored to ensure that subsequent business requests can be processed based on the latest rule set.

[0066] As an optional embodiment, this can be achieved through the following steps: determining new rules corresponding to the target business characteristics based on the processing results and target business characteristics, including: identifying business characteristic patterns corresponding to the target business characteristics based on the processing results; and generating conditional expressions for new rules based on the business characteristic patterns.

[0067] This step first requires collecting all business request processing results related to the target business characteristics. This includes, but is not limited to, the request's review status, processing time, and detailed information about the processing results. Data analysis techniques, such as statistical analysis and machine learning algorithms, are used to identify patterns and regularities in these processing results, especially those patterns that occur frequently and conform to business logic. Based on the collected processing results, further identification of patterns related to the target business characteristics is needed—that is, which specific combinations of business characteristics lead to specific processing results. This involves multi-dimensional data analysis, including but not limited to the type of business request, the time of the request, the requester's information, the transaction amount, and the nature of the transaction.

[0068] Furthermore, these patterns are transformed into executable rule-based conditional expressions. This involves converting business characteristic patterns into logical expressions, such as combinations of logical AND, OR, and NOT operators, to cover all identified business characteristic patterns.

[0069] Specifically, the generated new rule condition expressions need to be validated to ensure their effectiveness and applicability. This includes two aspects: First, ensuring that the new rules can achieve correct processing results on existing business request data. That is, the execution result of the new rules should be consistent with the result previously processed manually or by the system. This can be achieved through backtracking testing, where previously collected business request data is processed again by the rule engine, and the newly generated rule condition expressions are used to compare whether the processing result is consistent with the result previously processed manually or by the system. This will assess the effectiveness of the new rules. Second, assessing the universality of the new rules. That is, whether the new rules can be applied to more business scenarios without causing abnormal or incorrect processing results. The new rules can be tested in different business scenarios to ensure that they do not negatively affect the processing results in other scenarios, while also assessing their processing capabilities in multiple scenarios.

[0070] Finally, based on the verification results, the new rules are optimized and adjusted as necessary, such as adjusting thresholds, adding or deleting conditions, to improve their accuracy and performance. After optimization, the new rule condition expressions are formally added to the rule base and merged or sorted with preset rules to ensure the efficiency and consistency of the rule base. If the new rule intersects or merges with existing rules and meets the merging conditions, the new rule should be merged to generate a more concise rule expression; if the priority of the new rule is higher than or equal to that of existing rules, the execution order of the new rule should be advanced so that it is called first when processing business requests.

[0071] As an optional embodiment, this can be achieved through the following steps: further including: obtaining the execution frequency and success rate of each of the multiple rules in the corresponding relationship; determining the priority of each of the multiple rules based on the execution frequency and success rate of each of the multiple rules; when there are multiple target rules corresponding to the target business feature, selecting the target rule whose priority meets the preset conditions as the execution rule based on the priority of each of the multiple rules; and retrieving the execution rule to process the business request.

[0072] In this step, the execution frequency and success rate data of each preset rule in historical business processing are first obtained. The execution frequency can be recorded using a counter. Each time a rule is invoked, the corresponding counter is incremented. The success rate is calculated based on the statistics of the rule execution results. For example, each time a rule is completed, the system records its success or failure status, and then calculates the success rate based on these statuses.

[0073] Furthermore, rule priority is determined based on execution frequency and success rate. This process can use specific algorithms, such as the weighted average method, where execution frequency and success rate are assigned different weight values. Specifically, the weight of success rate can be set higher than that of execution frequency, as rules with higher success rates are generally more accurate and more suitable for the current business scenario. For example, if the weight of success rate is 0.7 and the weight of execution frequency is 0.3, then the rule priority RS can be calculated using the following formula: RS = w1 SR+w2 EF, where SR is the success rate, EF is the execution frequency, and w1 and w2 are the weights of the success rate and execution frequency, respectively.

[0074] Finally, when the target business characteristics corresponding to the identified business request match multiple rules, the business system will filter them according to the calculated rule priorities. The result of the rule priority calculation will serve as the basis for selecting the execution rule, choosing the target rule whose priority meets the preset conditions (such as being higher than a certain threshold) for processing. The preset conditions can be a rule priority threshold; only when the priority of a rule exceeds this threshold will it be selected as the execution rule. Once the rules to be executed are determined, the business system will invoke these rules to process the business request.

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

[0076] Through the above description of the embodiments, those skilled in the art can clearly understand that the business processing methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0077] According to embodiments of the present invention, a business processing apparatus for implementing the above-described business processing method is also provided. Figure 4 This is a structural block diagram of a service processing apparatus provided according to an embodiment of the present invention, such as... Figure 4 As shown, the service processing device includes: an acquisition module 402, an identification module 404, a judgment module 406, and a retrieval module 408. The service processing device will be described below.

[0078] Module 402 is used to obtain business requests;

[0079] The identification module 404, connected to the acquisition module 402, is used to identify the target business characteristics corresponding to the business request.

[0080] The judgment module 406, connected to the recognition module 404, is used to determine whether there is a rule corresponding to the target business feature based on the preset correspondence between business features and rules.

[0081] The retrieval module 408, connected to the judgment module 406, is used to retrieve the target rule to process the business request when a target rule corresponding to the target business feature exists.

[0082] It should be noted that the acquisition module 402, identification module 404, judgment module 406, and retrieval module 408 mentioned above correspond to steps S202 to S208 in the embodiments. Multiple modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should also be noted that the above modules, as part of the device, can run on the computer terminal 10 provided in the embodiments.

[0083] Embodiments of the present invention may provide a computer device. Optionally, in this embodiment, the computer device may be located in at least one of a plurality of network devices in a computer network. The computer device includes a memory and a processor.

[0084] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the business processing methods and apparatus in the embodiments of the present invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned business processing methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0085] The processor can access information and applications stored in the memory via the transmission device to perform the following steps: obtain a service request; identify the target service feature corresponding to the service request; determine whether there is a rule corresponding to the target service feature based on the preset correspondence between service features and rules; and if there is a target rule corresponding to the target service feature, retrieve the target rule to process the service request.

[0086] Optionally, the processor may also execute program code that includes the following steps: sending a business request to the front end when there is no rule corresponding to the target business feature; receiving the processing result from the front end; and determining a new rule corresponding to the target business feature based on the processing result and the target business feature.

[0087] Optionally, the processor may also execute program code that includes the following steps: when multiple business requests each have business characteristics that match the target business characteristics, the processor uses a new rule to process the multiple business requests and obtains the processing results for each of the multiple business requests; based on the processing results for each of the multiple business requests, the processor determines the processing success rate; and when the processing success rate exceeds a preset success rate threshold and the number of multiple business requests exceeds a preset frequency threshold, the processor adds the target business characteristics and the new rule to the correspondence.

[0088] Optionally, the processor may also execute program code that performs the following steps: adding the target business features and new rules to the correspondence, including: detecting the number of intersections and unions of the new rules and the multiple rules in the correspondence; determining, based on the number of intersections and unions of the multiple rules, whether there is a rule among the multiple rules that satisfies the merging condition with the new rule; merging the rule with the new rule to obtain the merged rule if there is a rule among the multiple rules that satisfies the merging condition with the new rule; and updating the correspondence based on the merged rule and the target business features.

[0089] Optionally, the processor may also execute program code that performs the following steps: determining new rules corresponding to the target business characteristics based on the processing results and the target business characteristics, including: identifying business characteristic patterns corresponding to the target business characteristics based on the processing results; and generating conditional expressions for the new rules based on the business characteristic patterns.

[0090] Optionally, the processor may also execute program code that includes the following steps: obtaining the execution frequency and success rate of each of the multiple rules in the corresponding relationship; determining the priority of each of the multiple rules based on the execution frequency and success rate of each of the multiple rules; when there are multiple target rules corresponding to the target business feature, selecting the target rule whose priority meets the preset conditions as the execution rule based on the priority of each of the multiple rules; and calling the execution rule to process the business request.

[0091] This invention provides a solution for a business processing method. By acquiring a business request; identifying the target business characteristics corresponding to the business request; determining whether a rule corresponding to the target business characteristics exists based on a preset correspondence between business characteristics and rules; and if a target rule exists, retrieving the target rule to process the business request, this method achieves the goal of introducing dynamic rule configuration, rule priority evaluation, and a multi-threaded parallel processing mechanism. This solves the technical problems in related technologies where current business request parsing and processing often rely on hard-coded or static rules, resulting in limitations of static rules and poor adaptability to complex scenarios.

[0092] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a non-volatile storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0093] Embodiments of the present invention also provide a non-volatile storage medium. Optionally, in this embodiment, the aforementioned non-volatile storage medium can be used to store the program code executed by the business processing method provided in the above embodiments.

[0094] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0095] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: obtaining a service request; identifying the target service feature corresponding to the service request; determining whether there is a rule corresponding to the target service feature based on a preset correspondence between service features and rules; and, if there is a target rule corresponding to the target service feature, retrieving the target rule to process the service request.

[0096] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: further including: sending a service request to the front end when there is no rule corresponding to the target service feature; receiving the processing result fed back by the front end; and determining a new rule corresponding to the target service feature based on the processing result and the target service feature.

[0097] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: further including: when multiple business requests each have business characteristics that match the target business characteristics, processing the multiple business requests using a new rule to obtain processing results for each of the multiple business requests; determining the processing success rate based on the processing results for each of the multiple business requests; and adding the target business characteristics and the new rule to the correspondence when the processing success rate exceeds a preset success rate threshold and the number of multiple business requests exceeds a preset frequency threshold.

[0098] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: adding the target business feature and the new rule to the correspondence, including: detecting the number of intersections and unions of the new rule and each of the multiple rules in the correspondence; determining, based on the number of intersections and unions of the multiple rules, whether there is a rule among the multiple rules that satisfies the merging condition with the new rule; merging the rule with the new rule to obtain the merged rule if there is a rule among the multiple rules that satisfies the merging condition with the new rule; and updating the correspondence based on the merged rule and the target business feature.

[0099] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: determining new rules corresponding to the target business characteristics based on the processing results and target business characteristics, including: identifying business characteristic patterns corresponding to the target business characteristics based on the processing results; and generating conditional expressions for the new rules according to the business characteristic patterns.

[0100] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: further including: obtaining the execution frequency and success rate of each of the multiple rules in the correspondence; determining the priority of each of the multiple rules based on the execution frequency and success rate of each of the multiple rules; when there are multiple target rules corresponding to the target business feature, selecting the target rule whose priority meets the preset conditions as the execution rule based on the priority of each of the multiple rules; and retrieving the execution rule to process the business request.

[0101] Embodiments of the present invention also provide a computer program product, including a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it can: acquire a business request; identify the target business feature corresponding to the business request; determine whether there is a rule corresponding to the target business feature based on a preset correspondence between business features and rules; and if there is a target rule corresponding to the target business feature, retrieve the target rule to process the business request.

[0102] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

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

[0104] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

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

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

[0107] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0108] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A business processing method, characterized in that, include: Obtain the business request; Identify the target business characteristics corresponding to the business request; Based on the preset correspondence between business features and rules, determine whether there is a rule corresponding to the target business feature; If a target rule exists that corresponds to the target business characteristic, the target rule is retrieved to process the business request.

2. The method according to claim 1, characterized in that, Also includes: If no rule exists that corresponds to the target business characteristic, the business request will be sent to the front end. Receive the processing result fed back from the front end; Based on the processing results and the target business characteristics, a new rule corresponding to the target business characteristics is determined.

3. The method according to claim 2, characterized in that, Also includes: When multiple business requests have business characteristics that match the target business characteristics, the new rule is used to process the multiple business requests to obtain the processing results corresponding to each of the multiple business requests. Based on the processing results corresponding to each of the multiple business requests, the processing success rate is determined. If the processing success rate exceeds a preset success rate threshold and the number of the multiple business requests exceeds a preset frequency threshold, the target business feature and the new rule are added to the correspondence.

4. The method according to claim 3, characterized in that, Adding the target business feature and the new rule to the correspondence includes: Detect the number of intersections and unions between the new rule and each of the multiple rules in the correspondence relationship; Based on the number of intersections and unions corresponding to each of the multiple rules, determine whether there is a rule among the multiple rules that satisfies the merging condition with the new rule; If there is a rule among the multiple rules that satisfies the merging condition with the new rule, then the rule and the new rule are merged to obtain a merged rule; The corresponding relationship is updated based on the merging rules and the target business characteristics.

5. The method according to claim 2, characterized in that, The step of determining a new rule corresponding to the target business characteristic based on the processing result and the target business characteristic includes: Based on the processing results, identify the business feature patterns corresponding to the target business features; Based on the business characteristic pattern, generate the conditional expression for the new rule.

6. The method according to any one of claims 1 to 5, characterized in that, Also includes: Obtain the execution frequency and success rate of each rule in the correspondence relationship; Based on the execution frequency and success rate of each of the multiple rules, the priority of each of the multiple rules is determined; When there are multiple target rules corresponding to the target business feature, the target rule whose priority meets the preset conditions is selected as the execution rule based on the priority of each of the multiple rules. The execution rules are invoked to process the business request.

7. A business processing apparatus, characterized in that, include: The acquisition module is used to acquire business requests; The identification module is used to identify the target business characteristics corresponding to the business request; The judgment module is used to determine whether there is a rule corresponding to the target business feature based on the preset correspondence between business features and rules; The retrieval module is used to retrieve the target rule to process the business request when a target rule corresponding to the target business feature exists.

8. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is executed, the device containing the non-volatile storage medium is controlled to perform the service processing method according to any one of claims 1 to 6.

9. A computer device, characterized in that, include: Memory and processor The memory stores computer programs; The processor is configured to execute a computer program stored in the memory, wherein when the computer program is executed, the processor performs the business processing method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the business processing method according to any one of claims 1 to 6.

Images