Service request processing method and device, equipment and medium

Abstract

The invention relates to the technical field of big data and the field of financial science and technology, and discloses a business request processing method, which comprises the following steps of: receiving a business request, transmitting the business request to a business logic module for processing, monitoring an abnormal condition in business logic processing, capturing abnormal information and storing the abnormal information in a retry business data table; initializing a retry state and retry times, setting a timed task, scanning a to-be-retry record according to a preset time interval, recalling and executing service logic by using a reflection mechanism according to a service processing class path, a method name and a calling parameter in the record, judging whether execution succeeds or not, and if the execution succeeds, updating the retry state and time of the record; and if the execution fails, increasing the number of retry times and keeping the to-be-retry state. According to the invention, the timing task is combined with the reflection mechanism to realize the decoupling of the business logic and the retry logic, the retry task is managed in a centralized manner, and a flexible multi-retry mechanism is provided, so that the system maintenance complexity is reduced, and the robustness and fault tolerance of the system are improved.

Description

Technical Field

[0001] The present invention relates to the fields of big data technology and financial technology, and in particular to a business request processing method, device, equipment and storage medium. Background Art

[0002] With the rapid development of Internet technology, the business functions of the financial industry are becoming increasingly complex, and business processing often requires interaction with external third-party services or internal systems. This cross-system service call makes the business process dependent on the external network environment and the availability of remote services. However, the stability of network connections and the robustness of remote services are often not fully controlled. For financial systems, business process interruptions may lead to serious consequences, especially in key businesses such as real-time transactions, payment systems, and customer service. Abnormal interruptions in business processing will directly affect customer experience and business continuity.

[0003] In order to improve the fault tolerance and robustness of the system, many financial systems usually introduce automatic retry mechanisms when encountering business process interruptions or failures, hoping to compensate for temporary network failures or temporary unavailability of external services through retries.

[0004] In some systems, when a business process is interrupted, a scheduled task is set up through the task scheduling system for compensation and retry. Although this method can automatically retry after the external service is restored, as the business volume grows, the number of scheduled tasks in the system will increase significantly, resulting in an increased load on the task scheduling system and increased scheduling and management difficulties. This not only increases the consumption of system resources, but also leads to an increase in maintenance costs, which is not conducive to the sustainable development of the system.

[0005] Some systems implement automatic retry mechanisms by directly embedding retry logic. This approach often leads to a high degree of coupling between business logic and exception handling logic, increasing code complexity and system maintenance costs. For complex business processes in financial systems, logical coupling may also cause more potential problems, especially when the system is expanded and upgraded, making decoupling more difficult.

[0006] The existing retry mechanism usually attempts to re-call the business interface when the external service is temporarily unavailable, but when the external service is unavailable for a long time, the retry mechanism often lacks flexible recovery methods. In this case, key businesses in the financial system, such as payment and transactions, may not be able to be restored in time, resulting in long-term business interruption, which seriously affects the stability of the system and user experience. Summary of the invention

[0007] The main purpose of the present invention is to provide a business request processing method, device, equipment and storage medium, aiming to solve the technical problems in the prior art that the business logic and retry logic are highly coupled, resulting in complex system maintenance, difficult code expansion and upgrading, increased maintenance costs and system error risks.

[0008] To achieve the above object, the present invention provides a service request processing method, comprising:

[0009] Receive business requests and pass the business requests to the business logic module for business logic processing;

[0010] During the business logic processing, monitor whether any abnormal situations occur;

[0011] When an abnormal situation is detected, the abnormal information is captured, and the abnormal information includes the business processing class path, method name, calling parameters and abnormal cause of the abnormal situation;

[0012] The exception information is stored in a retry business data table, wherein each record in the retry business data table includes the business processing class path, method name, call parameters, exception reason, retry status, number of retries, creation time and / or update time where the exception occurred;

[0013] In the record first stored in the retry service data table, the retry state is set to pending retry, and the number of retries is initialized to zero;

[0014] Setting a timer task, wherein the timer task scans the records in the retry service data table whose retry status is pending retry according to a preset time interval;

[0015] For the scanned records to be retried, a reflection mechanism is used to re-call and execute the business logic according to the business processing class path, method name and calling parameters in the records to be retried;

[0016] After re-executing the business logic, determine whether the business logic is successfully executed;

[0017] If the business logic is executed successfully, update the retry status of the corresponding record in the retry business data table to retry success, record the success time, and update the update time of the corresponding record;

[0018] If the business logic execution fails, increase the number of retries of the corresponding record in the retry business data table, update the update time of the corresponding record, and keep the retry status of the corresponding record as pending retry.

[0019] Furthermore, to achieve the above object, the present invention provides a service request processing device, comprising:

[0020] A business request processing module is used to receive business requests and pass the business requests to the business logic module for business logic processing;

[0021] The exception monitoring module is used to monitor whether an abnormal situation occurs during the business logic processing;

[0022] The exception capture module is used to capture the exception information when an exception is detected. The exception information includes the business processing class path, method name, call parameters and exception cause where the exception occurs;

[0023] An exception recording and storage module is used to store the exception information in a retry business data table, each record in the retry business data table includes the business processing class path where the exception occurred, the method name, the calling parameters, the exception reason, the retry status, the number of retries, the creation time and / or the update time;

[0024] A retry status management module, used to set the retry status to be retried in the record first stored in the retry service data table, and initialize the number of retries to zero;

[0025] A scheduled task management module, used to set a scheduled task, wherein the scheduled task scans the records in the retry service data table whose retry status is "to be retried" according to a preset time interval;

[0026] The reflection mechanism and business retry module is used to use the reflection mechanism to re-call and execute the business logic according to the business processing class path, method name and calling parameters in the scanned record to be retried;

[0027] The business execution result judgment module is used to judge whether the business logic is successfully executed after re-executing the business logic;

[0028] The success status update module is used to update the retry status of the corresponding record in the retry business data table to retry success if the business logic is executed successfully, record the success time, and update the update time of the corresponding record;

[0029] The failure processing and retry times updating module is used to increase the retry times of the corresponding record in the retry business data table, update the update time of the corresponding record, and keep the retry status of the corresponding record as pending retry if the business logic execution fails.

[0030] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a business request processing program stored in the memory and executable on the processor, and the business request processing program, when executed by the processor, implements the steps of the business request processing method described above.

[0031] Furthermore, to achieve the above object, the present invention also provides a computer-readable storage medium, on which a service request processing program is stored, and when the service request processing program is executed by a processor, the steps of the service request processing method described above are implemented.

[0032] Beneficial effects: The present invention relates to the fields of big data technology and financial technology, and discloses a business request processing method, which receives a business request and passes it to a business logic module for processing, monitors abnormal situations in business logic processing, captures abnormal information and stores the abnormal information in a retry business data table, initializes the retry status and number of retries, sets a scheduled task to scan the records to be retried according to a preset time interval, uses a reflection mechanism to re-call and execute the business logic according to the business processing class path, method name and call parameters in the record, and determines whether the execution is successful. If the execution is successful, the retry status and time of the record are updated; if the execution fails, the number of retries is increased and the state to be retried is maintained. The present invention achieves the decoupling of business logic and retry logic by using a scheduled task combined with a reflection mechanism, centrally manages retry tasks, and provides a flexible multiple retry mechanism, thereby reducing the complexity of system maintenance, improving system robustness and fault tolerance, and effectively enhancing the automatic recovery capability of business processes. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0034] Figure 1 A schematic diagram of an application environment of a service request processing method in an embodiment of the present invention;

[0035] Figure 2 A schematic diagram of a flow chart of an embodiment of a method for processing a business request of the present invention;

[0036] Figure 3 A schematic diagram of functional modules of a preferred embodiment of a service request processing device of the present invention;

[0037] Figure 4 A schematic diagram of the structure of a computer device in one embodiment of the present invention;

[0038] Figure 5 FIG. 4 is another schematic diagram of the structure of a computer device in one embodiment of the present invention. DETAILED DESCRIPTION

[0039] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0040] The service request processing method provided by the embodiment of the present invention can be applied in Figure 1In an application environment, the user end communicates with the server end through a network. The server end can receive a business request through the user end and pass it to the business logic module for processing, monitor the abnormal situation in the business logic processing, capture the abnormal information and store the abnormal information in the retry business data table. Initialize the retry state and the number of retries, set a scheduled task to scan the records to be retried according to a preset time interval, use the reflection mechanism to re-call and execute the business logic according to the business processing class path, method name and call parameters in the record, and judge whether the execution is successful. If the execution is successful, update the retry state and time of the record; if the execution fails, increase the number of retries and keep the state to be retried. The present invention realizes the decoupling of business logic and retry logic by using a scheduled task combined with a reflection mechanism, centrally manages retry tasks, and provides a flexible multiple retry mechanism, thereby reducing the complexity of system maintenance, improving system robustness and fault tolerance, and effectively enhancing the automatic recovery capability of business processes. Among them, the user end can be but not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server end can be implemented with an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0041] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of a method for processing a business request provided by the present invention. It should be noted that although a logical sequence is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0042] like Figure 2 As shown, the service request processing method proposed by the present invention includes the following steps:

[0043] S10, receiving a business request, and passing the business request to a business logic module for business logic processing;

[0044] In this embodiment, the input module of the system receives service requests from the outside, which are usually sent by the client or other service systems through API, HTTP request or message queue.

[0045] You can configure a REST API interface to receive HTTP requests. The interface can be implemented based on the Spring framework. When receiving the request, it can extract the necessary parameters and pass them to the subsequent business processing module. You can also use a message queue system (such as RabbitMQ, Kafka) as the receiving end of the request to ensure reliable message transmission in high-concurrency scenarios.

[0046] After receiving the request, the system needs to route it to the corresponding business logic module for processing based on the content of the request. This routing process depends on the information contained in the request, such as operation type, request type, user identifier, etc.

[0047] In the Spring framework, after receiving a request through the controller layer (Controller), it can be passed to the specified business service module using the routing mechanism through the request parameters (such as the HTTP header and the data field in the request body). These modules are defined using annotations such as @Service, and cooperate with the controller to pass the request to the specific business processing logic. In the microservice architecture, service discovery and routing gateways can be used, such as Zuul or Spring Cloud Gateway to route business requests and forward requests to the corresponding microservices.

[0048] After the system passes the request to the business logic module, the business logic module will perform predefined business processing. Business logic processing usually includes database operations, external API calls, calculation logic execution, etc.

[0049] If the business logic involves data access operations, you can use the ORM framework (such as Hibernate, JPA) to access the database. Database operations can include basic operations such as adding, deleting, checking, and modifying, combined with transaction management to ensure data consistency.

[0050] If the business logic needs to call external services, you can initiate HTTP requests through RestTemplate or FeignClient and process the response data. To ensure the reliability of the call, you can introduce the circuit breaker mode in the external API call, such as using Hystrix to monitor the health status of the external service.

[0051] When complex business calculations need to be performed, the calculation logic can be encapsulated in the business service layer to ensure that it is decoupled and maintainable. Business processing in different computing scenarios can be implemented through design patterns such as strategy patterns.

[0052] Example description: In the financial field, the system usually needs to receive a large number of transaction requests or query requests. For example, in a payment processing system, when a customer initiates a payment request, the system first receives the payment request through the API and extracts parameters such as the payment amount, payment method, and customer account information. This information is then passed to the business logic module, which performs corresponding processing based on the specific content of the request, such as querying the customer account balance, calling an external payment gateway, and updating the payment status. If the business logic involves calling an external bank payment interface, it is necessary to interact with the bank system through an API call and update the payment status based on the results returned by the bank.

[0053] By receiving business requests and passing them to the business logic module for processing, it is possible to achieve efficient separation of business requests and business processing logic, ensure the clarity and modularity of the system structure, and facilitate subsequent expansion and maintenance. The use of REST API or message queue-based methods not only improves the system's concurrent processing capabilities, but also reduces the system's coupling.

[0054] S20, during the business logic processing, monitoring whether an abnormal situation occurs;

[0055] In this embodiment, monitoring is performed throughout the entire business logic processing flow, rather than performing anomaly detection after the business is completed or the processing is finished, which means that in each key link, the system should have the ability to capture and handle anomalies.

[0056] In actual implementation, the business logic module can monitor the execution of business logic through monitoring points or interceptors. Usually, during the execution of the method, the exception handling mechanism provided by the framework (such as Java's try-catch block, Spring's AOP mechanism, etc.) is used to capture and handle exceptions in each link. Use a logging system (such as Log4j, Slf4j) to record the status of business execution, including detailed information on the start and end of method execution and when an exception occurs, to facilitate subsequent debugging and analysis.

[0057] During the execution of business logic, the system monitors in real time whether there are any anomalies, including network anomalies, service call failures, database errors, insufficient permissions, etc. This monitoring process involves capturing all unexpected situations that occur during the execution of the system.

[0058] By setting up an exception capture mechanism in each link of the business logic, you can use the try-catch block in Java to capture runtime exceptions. At the same time, combined with Spring AOP, the exception monitoring function is woven into the business logic, enabling the system to monitor the running status of each business logic in real time.

[0059] To enhance monitoring, the system can also monitor the health of external service calls through a fuse mechanism (such as Hystrix). When an external service fails or responds too slowly, it automatically triggers exception capture and switches to predefined processing logic.

[0060] Example: In financial systems, the accuracy and continuity of business processing are crucial. For example, in a bank payment system, when a user initiates a payment request, the system will sequentially execute multiple business logic steps such as user identity authentication, account balance check, and payment instruction sending. Each step may cause an exception due to external service problems (such as unavailable payment gateway service) or internal system problems (such as database timeout). In this scenario, the system needs to monitor abnormal situations in real time before and after the payment instruction is sent, and detect problems such as external service response timeout or data verification failure through the exception capture mechanism. If an exception occurs, the system can immediately trigger a retry mechanism or rollback operation to ensure the security of the payment transaction and the continuity of the business.

[0061] By monitoring exceptions during the execution of business logic, we can ensure that the system can capture various runtime exceptions in a timely manner during the execution of business processes, and prevent exceptions from spreading to other modules of the system. Using exception capture mechanisms such as Spring AOP or try-catch not only decouples business logic from exception monitoring logic, but also monitors business execution status in real time, enhancing the fault tolerance and robustness of the system, especially in scenarios with high concurrency and complex business logic, effectively improving the stability of the system and its exception handling capabilities.

[0062] S30, when an abnormal situation is detected, capturing the abnormal information, wherein the abnormal information includes the business processing class path, method name, calling parameters and abnormal cause of the abnormal situation;

[0063] In this embodiment, the system can capture abnormal situations that occur during the business logic processing in real time. Once the system detects any predefined abnormal type (such as network timeout, database operation failure, external API call failure, etc.), it immediately enters the abnormal capture process. The abnormal situation can be any expected or unexpected error in the system, including runtime exceptions and logical exceptions.

[0064] In the Spring framework, you can use AOP (aspect-oriented programming) or the try-catch mechanism in Java to monitor exceptions. When an exception is caught, you can set monitoring points (such as before and after methods of business logic) to obtain the exception type and related information in a timely manner.

[0065] When an exception is detected, the system will automatically capture the exception information. The captured information includes the source and specific details of the exception for subsequent analysis and processing. The captured exception information usually needs to be recorded in the system log or stored in a special exception handling table to support subsequent retries or manual intervention.

[0066] Use exception handling mechanisms (such as Java's Exception class) to capture specific exception information, including exception stack information, error location, and call chain. The captured exception information can be stored in a file or database through a logging system (such as Log4j, Slf4j) to track the source of the exception.

[0067] The business processing class path in the exception information refers to the class and its complete path where the business logic where the exception occurred is located. This information is used to indicate which specific business module or class has an error, helping developers quickly locate the problem.

[0068] In the Spring framework, you can dynamically obtain the path of the class where the exception occurred through getClass().getName() and record it. When the system captures the exception, it stores this information as part of the exception data.

[0069] The method name is used to identify the specific method where the exception occurred in the business processing logic. By recording the method name where the exception occurred, you can more accurately locate the point where the problem occurred, which is convenient for subsequent troubleshooting. Through the reflection mechanism or the StackTrace object that captures the exception, extract the name of the currently called method and record it in the exception information. You can use Throwable.getStackTrace() to extract the call stack of the exception and then get the method name.

[0070] Call parameters refer to the input parameters passed when the business logic where the exception occurred is executed. These parameters may be directly related to the exception in some cases, such as illegal parameters or missing parameters. Recording these parameters helps restore the context in which the exception occurred and helps developers analyze the root cause of the problem. In the business logic, by capturing the input parameters at the time of the exception, these parameters are recorded and saved in the exception log. Usually, the parameters passed to the business logic (such as parameters in the HTTP request, input variables in the method, etc.) can be actively recorded by customizing the exception capture logic.

[0071] The exception cause is the specific type or description of the exception captured by the system. This can be an exception message thrown by the system (such as network timeout, database connection failure, null pointer exception, etc.), which helps developers understand and analyze the underlying cause of the exception. Use Throwable.getMessage() to get the error information in the exception object. For some complex exceptions, you can recursively get the underlying cause of the exception (getCause()) to analyze the root cause of the entire exception chain.

[0072] Example description: In the financial system, the business process is complex and any exception may lead to serious financial consequences. For example, in the loan approval system, when a user submits a loan application, the system needs to be verified by multiple services, such as identity authentication, credit scoring, loan amount verification, etc. If an exception occurs when calling an external service (such as a credit scoring service), the system needs to capture the class path, method name, and calling parameters (such as the user's identity information, the amount of the loan applied for, etc.) where the exception occurred. At the same time, the system will record the cause of the exception (such as a credit scoring service timeout) and store this information in a log or exception table for subsequent system retries or manual intervention by operation and maintenance personnel. This exception capture mechanism ensures that any exceptions can be accurately tracked and handled in a timely manner when the system is processing financial business, avoiding system interruptions and data loss.

[0073] By capturing detailed exception information when an exception occurs, including the business processing class path, method name, call parameters, and exception cause, the system can accurately locate the specific location and cause of the exception when a problem occurs. This mechanism not only ensures the integrity of the exception data, but also provides rich contextual information for subsequent retry mechanisms or manual processing, thereby effectively improving the robustness and maintainability of the system. Especially in complex business scenarios, by capturing and recording this information, the time for troubleshooting can be greatly shortened and the reliability and fault tolerance of the system can be improved.

[0074] S40, storing the exception information in a retry business data table, wherein each record in the retry business data table includes the business processing class path where the exception occurred, the method name, the calling parameters, the exception reason, the retry status, the number of retries, the creation time and / or the update time;

[0075] In this embodiment, the captured exception information is persistently stored for subsequent retry or manual processing. The storage process of the exception information involves the read and write operations of the database, ensuring that the exception data will not be lost after it occurs, and can support the execution of subsequent retry tasks of the system. The captured exception information can be stored in a special database table (i.e., the retry business data table) through an ORM framework (such as Hibernate, JPA) or directly using SQL commands. The storage operation can be performed while capturing the exception, or asynchronous tasks can be used to increase the system response speed. The table should be designed to be able to store multiple types of exception information and support subsequent queries.

[0076] Each record in the retry business data table represents a captured exception information, including context information and system status related to the exception. Each time an exception occurs, the system inserts a new record into the table. The design of the data table should ensure that the structure of the record is reasonable, and the table in the relational database can be used for design. The fields of the table should include key information of various exceptions to facilitate the smooth operation of subsequent query, update, and delete operations. A unique identifier (such as a primary key ID) can be set for each record to ensure that each inserted record is independent.

[0077] Each record will contain the business processing class path where the exception occurred, to clarify which business class or module had a problem during execution. This helps with subsequent troubleshooting and the accuracy of retry calls. The system can extract the class path where the exception occurred through the reflection mechanism or the StackTrace when the exception is captured, and insert it into the database table as part of the record.

[0078] Each record also needs to include the name of the method where the exception occurred, which is used to further accurately locate the location where the exception occurred. The method name provides the specific point where the exception occurred, which is convenient for developers to debug and reproduce the problem later. By extracting the method name through reflection or from the exception stack information, ensure that the information can be stored in the retry business data table together with the class path, so as to accurately locate the source of the exception.

[0079] The call parameters when the exception occurs also need to be saved in the record. These parameters are the input information that triggers the business logic to run and may be closely related to the occurrence of the exception. Recording these parameters helps to restore the business scenario during subsequent retries. You can capture the input parameters in the business logic and store them in a table. A common method is to serialize the input parameters when calling the method and store them in the database. You can also store the call parameters as string types in JSON format to facilitate parsing during retries.

[0080] The cause of the exception is a detailed description of the exception when it occurs. It is usually the exception information automatically captured by the system, such as network timeout, database connection failure, etc. This is key information for locating the root cause of the problem. Use the getMessage() method of the exception object to extract the detailed description in the exception information and store it in the data table for subsequent analysis and processing.

[0081] The retry status is used to mark whether the current exception has been processed or needs to be retried. Common retry statuses include: waiting for retry, retry successful, retry abandoned, etc. The system uses this field to determine whether a record needs to be retried. The initial status is usually set to "waiting for retry" (0), and is updated to "retry successful" (1) when the business logic is successfully processed. If the maximum number of retries is reached, it is marked as "retry abandoned" (2). This field can be represented by an enumeration or an integer.

[0082] The number of retries is used to record the number of retries after each exception occurs, so as to control the retry frequency of the system and avoid wasting resources due to infinite retries. Usually a threshold for the maximum number of retries is set, and retries are stopped after exceeding this value. After each retry task is executed, the system automatically updates the number of retries field of the record. If the retry is successful, the increment stops. This field is synchronized with the actual retry task execution process through the update operation of the database.

[0083] The creation time of the record is used to mark the time when the exception first occurred, and the update time is used to record the time of each retry or status update. These two fields help track the timeline of exception handling. The creation time is automatically set when the record is inserted, and the update time is updated after each retry task is executed. This function is usually implemented using the timestamp field of the database.

[0084] Example description: In a financial data processing system, such as a credit assessment system, the system may obtain the user's credit score by calling an external service. If the external credit score service fails to be called due to network failure or service unavailability, the system will capture the exception and store the exception information in the retry business data table. The recorded exception information includes the path of the credit assessment class, the method name for calling the credit service, the parameters such as the passed user ID and loan amount, and the specific cause of the exception (such as service timeout). The system will mark the retry status of the record as "pending retry" and set the number of retries to 0. When the service is restored, the system scheduled task will re-call the credit score service according to the record until the retry is successful or the maximum number of retries is reached.

[0085] By storing exception information in the retry business data table, the system can effectively record and track each exception that occurs, ensuring the transparency of the exception handling process. Combined with detailed exception context information such as class path, method name, and call parameters, the system can accurately locate and retry exceptions and restore the scene when the exception occurred. By managing the retry status and the number of retries, the system can flexibly control the retry mechanism, avoid resource waste and invalid retries, and significantly improve the robustness and maintainability of the system.

[0086] S50, in the record first stored in the retry service data table, setting the retry state to be retried, and initializing the number of retries to zero;

[0087] In this embodiment, after each exception occurs, the system writes the exception information to the retry business data table for the first time. When storing for the first time, some states need to be initialized to support subsequent retry operations. Whenever the system captures an exception and decides to store the exception information in the retry business data table, the system will create a new record and insert the captured exception information into the table. The first storage can be completed using the database insert operation (such as SQL's INSERT INTO).

[0088] The retry status field is used to indicate the current processing status of the exception record. When first stored, the retry status should be set to "pending retry", indicating that the exception has not been retried yet and needs to wait for further processing by a scheduled task or other mechanism. When inserting a record, the retry status field can be set to a default value, such as pending retry, represented by an enumeration or a numerical value. For example, 0 represents "pending retry", 1 represents "retry successful", and 2 represents "retry abandoned". The initial value of this field can be specified directly through a SQL statement, or configured using a default value in the ORM framework.

[0089] The retry count is used to track the number of times the exception record has been retried. When it is first stored, the exception has not been retried, so the retry count should be initialized to 0. When the system inserts a new exception record, the initial value of the retry count field is set to 0. After the retry task is executed, the system automatically updates the retry count to record the actual number of retries. The default value of this field can be configured through the INSERT INTO statement or the ORM framework.

[0090] Example description: In the financial field, such as a payment processing system, if an exception occurs when the system calls an external bank interface when a user initiates a payment (such as a network timeout or no response from the bank system), the system will capture the exception and store it in the retry business data table. The system will set the retry status of the record to "pending retry" (i.e., need to retry) when it is first stored, and initialize the number of retries to 0. In this way, after the bank system is restored, the system can automatically scan the retry business data table through a scheduled task, find the record to be retried, and call the bank interface again until the payment is successful or the maximum number of retries is reached. Through this mechanism, the financial system can effectively handle payment exceptions and ensure that the user's payment request will not fail permanently due to a short-term network or service failure.

[0091] By setting the retry status to pending retry and initializing the number of retries to zero when the exception information is first stored in the retry business data table, the system can correctly manage and track each exception record. The initial status setting provides a data basis for the subsequent retry mechanism, ensuring that the system can determine whether a retry task needs to be executed based on the retry status and the number of retries.

[0092] S60, setting a scheduled task, wherein the scheduled task scans the records in the retry service data table whose retry status is "to be retried" according to a preset time interval;

[0093] In this embodiment, a scheduled task is configured so that the system can periodically scan the records in the retry business data table to check whether there are tasks that need to be retried. The scheduled task uses a timer mechanism to ensure that the retry operation can be automatically executed within a preset time interval. Scheduled tasks can be configured by using Spring Scheduler or other scheduled task frameworks (such as Quartz). In Spring, the execution frequency of the task can be configured through the @Scheduled annotation. The scheduled task will automatically perform the corresponding scanning operation according to the predefined time interval.

[0094] The execution frequency of scheduled tasks is based on a preset time interval. This time interval can be flexibly adjusted according to business needs, such as scanning every 5 minutes or 10 minutes. This time interval ensures that the system can frequently check whether there are tasks to be retried, but not too frequently to avoid wasting resources. In the configuration of scheduled tasks, you can define the execution time interval through a specific time expression. For example, in Spring, you can use Cron expressions or fixedRate parameters to control the execution frequency of scanning tasks. Depending on business needs, you can set it to run every few minutes or every hour.

[0095] The system scheduled task will scan all records in the retry business data table to find those records with a retry status of "pending retry". Each record in the table corresponds to a failed business logic processing, and the retry status field is used to mark whether the business logic needs to be executed again. The system can query all records to be retried through SQL statements such as SELECT*FROM retry_business_tableWHEREretry_status='pending retry'. Each time the scheduled task is executed, the system will run the query and obtain the business logic records to be retried.

[0096] The retry status of each record marks the processing progress of the current task. The status of pending retry is usually represented by 0 or a similar mark, indicating that the business logic of the record has not succeeded and needs to be retried again. Other statuses may include successful retry, abandoned retry, etc. The system will set the retry status to "pending retry" (such as set to 0) when the exception information is first stored in the retry business data table. The scheduled task will scan all records with the status of "pending retry" and trigger the corresponding retry operation after finding the records that meet the conditions.

[0097] Example description: In the financial system, the application scenarios of scheduled tasks are very extensive. For example, in the payment system, if the payment request initiated by the user fails due to a bank interface timeout, the system will capture the exception and store it in the retry business data table. The system can automatically scan the table through a scheduled task (for example, every 10 minutes), find all records with a status of "pending retry", and automatically initiate a retry operation. In this way, when the bank system returns to normal, the user's payment request can be reprocessed to ensure the integrity and continuity of the payment process without manual intervention. Through the scheduled task mechanism, the stability of the system in high concurrency and complex business scenarios is greatly improved.

[0098] By setting up scheduled tasks, the system can regularly scan the records to be retried in the retry business data table within a preset time interval to implement an automated exception handling and retry mechanism. This mechanism reduces reliance on manual operations and ensures that the system can quickly re-call business logic after external services are restored to avoid business interruptions. The use of scheduled tasks allows the system to balance system performance and real-time task execution based on actual business needs through flexible time interval configuration, thereby improving the system's automation capabilities and maintainability.

[0099] S70, for the scanned record to be retried, use the reflection mechanism to re-call and execute the business logic according to the business processing class path, method name and calling parameters in the record to be retried;

[0100] In this embodiment, the system scans the records to be retried in the retry business data table through a scheduled task. Each record to be retried contains information such as the business processing class path, method name, and call parameters where the exception occurred. The record corresponds to a task that requires re-executing the business logic. All records marked as "to be retried" are queried through SQL query statements (such as SELECT * FROM retry_business_tableWHEREretry_status = 'to be retried') or the ORM framework, and these records are loaded into memory for processing. The class path, method name, and call parameters stored in the record will be used for subsequent business logic calls.

[0101] The system uses reflection mechanism to dynamically load and execute business logic. The reflection mechanism allows the system to dynamically obtain relevant information about classes and methods at runtime and call the method. The reflection mechanism makes it unnecessary to rely on hard coding for retry operations and can flexibly respond to various business logic calls. In Java, the reflection mechanism operates through objects such as Class class, Method class, Field class, etc. First, the system loads the corresponding class (that is, the business processing class) through the class path, then obtains the target method of the class according to the method name, and finally calls the method and passes the captured call parameters to it.

[0102] Each record to be retried contains the full path of the business processing class. Through this class path, the system can dynamically load the class and obtain its structure and methods. In the reflection call process, the class path is the key element for the reflection mechanism to find and instantiate the target class. The system can load the target class according to the class path in the record to be retried through the Class.forName(String className) method. The loaded class instance can be used for further reflection operations (such as obtaining methods, executing methods, etc.).

[0103] The method name in the business processing class is used to indicate the specific method to be called by the reflection mechanism. In the record to be retried, the method name is an important parameter for dynamic calling. The system locates the target method in the business processing class by the method name and executes the method by reflection. The system obtains the corresponding method object through Class.getMethod(String methodName,Class<?>...parameterTypes). Then, the reflection mechanism is used to call the method on the loaded class instance. The method name is usually saved as a string in the record to be retried, and is passed to the reflection method after being obtained by parsing the record.

[0104] Call parameters are the input required to execute business logic, usually including the content of user requests, business-related data, etc. The system passes these parameters to the target method through the reflection mechanism when re-calling the business logic, ensuring that the business logic can be re-executed in the same context. When reflectively calling the target method, the system needs to pass a parameter list (possibly multiple parameters) to the method. Dynamic method calls can be implemented and parameters can be passed through Method.invoke(Object obj,Object...args). The call parameters stored in the record to be retried are usually in serialized form (such as JSON format), and need to be deserialized to the actual parameter type when used.

[0105] The system uses the reflection mechanism to re-call and execute the business logic that failed when the exception occurred. The purpose of the re-call is to restore the business process that was interrupted by the exception. During the calling process, the business logic uses the classes and methods dynamically loaded by the reflection mechanism and the parameters in the retry record to simulate the environment of the first execution. The reflection mechanism is used to call the target method and pass the parameters to re-execute the business logic. After the business logic is successfully executed, the system updates the record status to "Retry Successful"; if the business logic fails again, the system will increase the number of retries by 1 and keep the record status as "Waiting for Retry".

[0106] By using the reflection mechanism to re-call and execute business logic, the system can flexibly handle tasks to be retried dynamically and without hard coding. The reflection mechanism allows the corresponding business logic to be dynamically executed according to the class path, method name, and call parameters in the record to be retried, and the business process that was interrupted abnormally can be restored. This method enhances the adaptability and scalability of the system, especially in the face of complex and ever-changing business scenarios, which can effectively improve the system's fault tolerance and robustness.

[0107] S80, after re-executing the business logic, determining whether the business logic is successfully executed;

[0108] In this embodiment, the system calls and executes the business logic again through the reflection mechanism. After the business logic is executed, the system needs to immediately determine whether the logic is successfully executed to determine whether further operations are required (such as updating the retry status or continuing to retry). The system can determine whether the business logic is successfully executed through the return value of the business logic or the exception capture mechanism. For example, when the business method is executed, a Boolean value indicating success or failure is returned; if the business logic throws an exception, it can be considered that the execution has failed.

[0109] The focus of this step is how to determine the execution result of the business logic. Usually, the business logic will inform the system whether the logic is successfully executed through a clear return value (such as true / false) or a status code (such as 200OK for success). Alternatively, the system can also determine whether the business has failed by checking whether an exception is thrown. After the business logic is executed, the system can determine whether it is successful by capturing the return value of the business method. The return value can be a flag indicating success or failure, or a specific business processing result (such as the number of rows affected by a database operation). If the return value indicates success, the status of the business processing is updated; if the return value indicates failure or an exception is thrown, the system will record the failure information and may proceed to the next step of processing (such as retry or manual intervention).

[0110] Example description: In the financial field, such as in the payment system, if the system fails to pay due to network problems when executing the payment logic, the system will record the exception information and store it in the retry business data table. When the network is restored, the system re-executes the business logic through a scheduled task (i.e., re-initiates the payment request). After the payment request is executed, the system will determine whether the business logic is successfully executed by the returned payment result status (such as "success" or "failure"). If the payment is successful, the system will update the record to "retry successful"; if the payment still fails, the system will increase the number of retries or transfer the payment request to the manual processing queue. This mechanism ensures that the payment business can be automatically restored under abnormal circumstances, while ensuring the accuracy of the payment process and customer experience.

[0111] By judging the execution status of the business logic after re-executing it, the system can quickly determine whether the business process has returned to normal. Whether based on the return value or exception capture, the system can take different follow-up actions based on the success or failure of the business execution, such as updating the retry status or performing further retry operations. This judgment mechanism ensures the continuity of the business process and the fault tolerance of the system, effectively improves the system's ability to handle exceptions, and avoids long-term interruptions to the business process.

[0112] S90, if the business logic is executed successfully, update the retry status of the corresponding record in the retry business data table to retry success, record the success time, and update the update time of the corresponding record;

[0113] In this embodiment, the system confirms that the business logic has been successfully executed through a return value or an exception capture mechanism. This means that the business process has returned to normal and no retry is required. The successful execution of the business logic means that the system can perform subsequent status updates to reflect that the record has been processed. The system can confirm the success of the business logic through a return value (such as true) or a capture mechanism. If no exception occurs or the business logic returns a successful status, the system can perform the status update operation.

[0114] When the business logic is successfully executed, the system needs to update the retry status of the record from "pending retry" to "retry successful". This operation indicates that the business logic of the record has been successfully executed and no longer needs to be retried. The system can update the retry status of the record in the database through SQL statements (such as UPDATEretry_business_table SET retry_status = 'retry successful' WHERE id =?) or ORM framework. The status can be set to 1 (indicating successful retry), or a more semantic value (such as "successful").

[0115] After the system updates the retry status to "Retry Successful", it also needs to record the current time as the timestamp of successful execution of the business logic. This timestamp helps track the processing time of the business process and provides support for system auditing and troubleshooting. You can use the database's timestamp function (such as CURRENT_TIMESTAMP) or the system time obtained by the application to write the current time into the database's success time field. SQL example: UPDATEretry_business_table SETsuccess_time=CURRENT_TIMESTAMPWHERE id=? 。

[0116] When the retry status of each retry record changes, the system needs to update its "update time" field to reflect the most recent modification to the record. Recording the update time helps the system track the progress and frequency of retry operations. While updating the retry status and success time, the system can use UPDATE statements or ORM operations to update the "update time" field. Similar to recording the success time, the update time can also use CURRENT_TIMESTAMP to automatically fill in the latest time value.

[0117] By updating the retry status and recording the success time and update time in a timely manner after the business logic is successfully executed, the system can accurately track the processing progress of each retry record and ensure the traceability of the business process. The update of the retry status indicates that the business process has returned to normal, and the record of the success time and update time provides strong support for the audit and debugging of the system. This design improves the robustness and exception handling capabilities of the system, while reducing the waste of resources on repeated retries.

[0118] S100, if the business logic execution fails, increase the retry times of the corresponding record in the retry business data table, update the update time of the corresponding record, and keep the retry status of the corresponding record as pending retry.

[0119] In this embodiment, during the process of re-executing the business logic, if the system detects that the business logic is not successfully executed (such as returning an error status code or throwing an exception), the business logic execution is considered to have failed. In this case, the system needs to handle the failure and prepare for subsequent retries. The judgment basis for the failure of business logic execution can be the return value of the method (such as false or an error status code) or the exception capture mechanism (such as try-catch catching an exception). If the method does not return success after execution, or the system captures the exception, the failure handling logic is entered.

[0120] Each retry record stores the number of times the business logic has been retried. After the business logic fails to execute, the system needs to increase the number of retries for the record to record the number of failures and provide a basis for the system to determine whether the maximum retry threshold has been reached. The system increases the number of retries field through database update operations. For example, after each failure, the system will execute a SQL statement similar to UPDATEretry_business_table SETretry_count=retry_count+1WHERE id=? to update the number of retries field of the record. The ORM framework can also automatically complete this process through entity attribute operations.

[0121] After each business logic execution fails, in addition to increasing the number of retries, the system also needs to update the "update time" field of the record to reflect the time when the record was last retried. This helps track the execution time and frequency of each retry task, which facilitates system scheduling and management. Similar to the update of the number of retries, after a retry fails, the system can update the update time of the record by UPDATEretry_business_table SET update_time=CURRENT_TIMESTAMP WHERE id=?. In this way, the update time in the database will always reflect the latest retry time.

[0122] After the business logic execution fails, the system needs to retain the "pending retry" status of the record so that the scheduled task can try again in the next scan. The maintenance of the retry status indicates that the task has not been completed and still needs further processing. The retry status field is already set to "pending retry" when it is first inserted. After each retry fails, the system does not need to change the status, and keeps its value unchanged and continues to mark it as "pending retry". For example, the status value can be 0, indicating that the task is still in the retry queue.

[0123] Example description: In a financial system, suppose a network error occurs when the loan approval system calls an external credit scoring service, resulting in approval failure. The system will record the exception and start a retry mechanism. Each time the credit scoring service is retried, the system will check whether the execution is successful. If the business logic fails again, the system will increase the number of retries for the retry record and update the last retry time of the record to the current time. Since the status is still "pending retry", the system will try to call the external service again in the next scheduled task until the business is successfully executed or the maximum number of retries is reached. In this way, the loan approval system can resume normal operation when the service is temporarily unavailable, ensuring business continuity.

[0124] By increasing the number of retries, updating the update time, and keeping the retry status as pending retry when the business logic fails to execute, the system can effectively manage the life cycle of the retry task. After each failure, the increase in the number of retries provides the system with an important basis for judging when to stop retrying; the update time ensures that the system accurately records the time of each retry operation, which is convenient for subsequent scheduling. At the same time, maintaining the "pending retry" status allows the task to continue to be processed until it succeeds or reaches the maximum number of retries. This mechanism greatly enhances the system's fault tolerance and the level of automation of exception handling.

[0125] The present invention relates to the fields of big data technology and financial technology, and discloses a business request processing method, which receives a business request and passes it to a business logic module for processing, monitors abnormal situations in business logic processing, captures abnormal information and stores the abnormal information in a retry business data table, initializes the retry state and the number of retries, sets a scheduled task to scan the records to be retried according to a preset time interval, uses a reflection mechanism to re-call and execute the business logic according to the business processing class path, method name and call parameters in the record, and determines whether the execution is successful. If the execution is successful, the retry state and time of the record are updated; if the execution fails, the number of retries is increased and the state to be retried is maintained. The present invention realizes the decoupling of business logic and retry logic by using a scheduled task in combination with a reflection mechanism, centrally manages retry tasks, and provides a flexible multiple retry mechanism, thereby reducing the complexity of system maintenance, improving system robustness and fault tolerance, and effectively enhancing the automatic recovery capability of business processes.

[0126] In one embodiment, the above S10 includes:

[0127] S101, configuring an interface module, and receiving a service request through the interface module;

[0128] S102, the interface module parses the service request and extracts request parameters from the service request;

[0129] S103, performing format verification and legality check on the request parameters;

[0130] S104, routing the service request to a corresponding service logic module according to the verified request parameters;

[0131] S105: Execute predefined business logic processing in the business logic module.

[0132] In this embodiment, the interface module is responsible for receiving external business requests and acts as an interface between the system and the external system or client. It can be a module based on HTTP, WebSocket or message queue, which is used to receive and process external incoming business requests. The interface module receives requests in different formats, such as HTTP POST requests or messages in message queues. The interface module receives requests by listening to ports or subscribing to message queues, and passes the requests to the internal processing flow of the system.

[0133] Request parameters are the input data required for the execution of business logic. The step of parsing the request is to convert the request into a processable internal data structure and extract the required parameter information, such as operation type, user ID, data content, etc. The interface module parses the necessary parameters from the request, usually by decoding the message body of the request or parsing the parameters in the URL to extract the information. This information will be used as input for subsequent business logic to ensure that the system can obtain all necessary parameters. The detailed explanation of the request parameters includes several important information, such as:

[0134] Operation Type: Indicates the specific business operation that needs to be performed, such as Create, Update, or Delete.

[0135] User Identifier: Used to identify the user making the request.

[0136] Data field: core data involved in business logic processing.

[0137] Timestamp: Records the time when the request was generated to ensure time sensitivity.

[0138] Permission information: Verify whether the user has the permission to perform the operation.

[0139] The above parameters are extracted by parsing the request body or request header information. Each parameter has specific format requirements, and the system needs to ensure the correctness and completeness of these parameters.

[0140] After receiving the request, the system first needs to verify its format and legitimacy. This step ensures that the request parameters conform to the format specifications expected by the system and checks the legitimacy of the operation permissions. Verification usually includes checking user identity, permissions, and the format and range of data. Use a verification mechanism (such as predefined rules) to verify each parameter to ensure that the user identity is valid, the permissions are sufficient, the data field format is correct, the timestamp is not expired, etc. If the verification fails, the system should return a corresponding error prompt.

[0141] After verification, the system needs to distribute the request to the appropriate business logic module based on the operation type or other parameters. Different business logic modules are responsible for different business functions, such as processing different types of user requests, operating databases, etc. Based on the parameters of the request (especially the operation type), the system dynamically decides which module to route the request to. For example, for a "create" operation, it may be routed to the create module, while an "update" request is routed to the update module.

[0142] Finally, the business logic module performs specific business processing operations, such as updating the database, calling external APIs, triggering internal events, etc. The business logic module receives the parsed request parameters and completes the operation accordingly. Different operations are performed according to the request type, such as creating records, updating data, deleting records, etc. These operations usually involve the implementation of the core business of the system and data persistence processing. The output of the business logic module is usually the result of the success or failure of the operation, and the result is returned to the caller.

[0143] By configuring the interface module and receiving the service request, the system can flexibly parse the request parameters and perform legality verification to ensure that the format and content of the request are correct. The verified request is routed to the corresponding business logic module, so that the business processing logic of the system can be flexibly expanded and adapted to different business needs.

[0144] In one embodiment, the above S20 includes:

[0145] S201, setting monitoring points before and after key operations executed by the business logic;

[0146] S202, predefine a plurality of exception types, and based on the exception types, use an exception handling mechanism based on a programming language exception capture framework to capture exceptions occurring at the monitoring point.

[0147] In this embodiment, monitoring points are used to monitor the execution status of operations at key locations in the business process. These key operations may include high-risk links such as interactions with external systems and database access operations. Setting monitoring points can capture possible anomalies in a timely manner before or after these operations to ensure the stability of the system. The system automatically or manually sets monitoring points before and after these key operations to record the execution status of the operations. Monitoring can be performed by capturing execution status logs or tracking operation execution results to ensure that each key business operation can be effectively monitored and recorded.

[0148] In order to handle different exception situations more accurately, the system needs to predefine some common exception types. Different exception types represent different exception scenarios, and the system can make corresponding processing strategies according to the exception type, such as network timeout, service call failure, data processing error, etc. Some typical exception types can be set in the system, such as network-related exceptions, exceptions caused by external system call failures, errors in data processing, etc. Depending on the exception type, the system takes different response measures, such as retry, logging, or alarm.

[0149] When the monitoring point captures anomalies in business operations, the system will rely on the exception capture mechanism provided by the programming language to capture these exceptions to ensure that the business process will not be interrupted or crashed when an exception occurs. The system can identify and capture exceptions and then perform corresponding processing, such as recording exception information, retrying operations, or notifying relevant personnel. The exception capture mechanism monitors the execution of operations at key points in the business logic. Once an exception is detected, the corresponding exception handling process is immediately triggered to ensure that the business process can continue or stop at an appropriate location and perform subsequent processing.

[0150] By setting monitoring points before and after key operations of business logic, this embodiment enables the system to effectively monitor the execution status of important business operations and ensure that exceptions can be captured and processed in a timely manner when they occur. The predefined exception types can ensure that the system can classify and process different exception types, thereby improving the accuracy of exception processing. By using the exception capture mechanism, the system can take corresponding remedial measures when an exception occurs, avoiding interruption or failure of business processes due to exceptions, thereby improving the fault tolerance and stability of the system.

[0151] In one embodiment, the above S60 includes:

[0152] S601, configuring a timer task module, wherein the timer task module is used to perform a scan operation on a retry service data table according to a predetermined scan time interval;

[0153] S602, dynamically adjusting the scanning time interval based on the number of records in the retry service data table;

[0154] S603, when executing the scheduled task each time, query the retry business data table for records with a retry status of pending retry;

[0155] S604, submitting the record to be retried to the retry module, wherein the retry module is used to re-call and execute the business logic according to the business processing class path, method name and calling parameters in the record.

[0156] In this embodiment, the scheduled task module is responsible for regularly scanning the retry business data table at preset time intervals to detect whether there are records to be retried. The scheduled task module ensures that the system can regularly detect the business logic that needs to be retried to ensure business continuity. Configure a scheduled task and execute it within a predetermined time interval through the task scheduling mechanism. The scheduled task will call a database query operation to scan the records in the retry business data table with a status of "pending retry" to ensure that the retry logic runs regularly.

[0157] In order to improve the utilization efficiency of system resources, the scanning frequency of the scheduled task can be dynamically adjusted according to the number of records in the retry business data table. When the number of records to be retried is large, the system can shorten the scanning interval to improve processing efficiency; when the number of records is small, the interval can be appropriately extended to save resources. During each scan, the scheduled task module will dynamically adjust the scanning frequency according to the number of records to be retried in the table. You can set multiple time periods and decide whether to shorten or extend the scanning time interval based on the number of retry records to ensure the rational use of system resources.

[0158] Each time a scheduled task is executed, the system queries all records in the retry business data table that are in the "pending retry" state. The core of this step is to locate the records that need to be retried and prepare data for the subsequent retry logic. The scheduled task module performs a database query operation to find records in the retry business data table that are in the "pending retry" state. These records mark the tasks that failed last time and need to be re-executed.

[0159] After the scheduled task finds the records that need to be retried, it submits these records to the retry module. The retry module is responsible for calling the business logic and retrying the failed operation. The retry module calls the business logic according to the class path, method name and parameters in the record. The scheduled task passes the records to be retried to the retry module. The retry module dynamically executes the corresponding business logic according to the information in each record (such as class path, method name, call parameters, etc.) and tries to recover the last failed operation.

[0160] In this embodiment, by setting a scheduled task, the system can regularly scan and retry the business data table to ensure automatic retry in the event of a business logic failure. Dynamically adjusting the scanning interval helps improve the efficiency of system resource usage and avoid unnecessary frequent scanning. During each scan, the system can automatically discover and process the records to be retried, ensuring that the business logic can automatically resume execution after an exception, thereby improving the stability and robustness of the system.

[0161] In one embodiment, the above S70 includes:

[0162] S701, extracting the business processing class path, method name and calling parameters from the scanned record to be retried;

[0163] S702, using the reflection mechanism to load the business processing class according to the business processing class path, and if the target method is a non-static method, instantiate the business processing class object;

[0164] S703, using the reflection mechanism, through the business processing class object, obtaining a target method that matches the method name in the record to be retried;

[0165] S704, using the reflection mechanism, calling the target method through the instantiated business processing class object, and passing the calling parameters to the target method to re-execute the business logic.

[0166] In this embodiment, each record to be retried contains key information required for retrying, including business processing class path, method name, and call parameters. This information points to the business logic that needs to be re-executed. The system extracts this information from the records in the retry business data table for subsequent business logic re-calling. The class path defines the business class to be loaded, the method name indicates the specific operation to be called, and the call parameters provide the context data required for the business logic execution.

[0167] The reflection mechanism allows the system to dynamically load business classes according to the class path at runtime. Based on the extracted class path, the system can locate the specific business processing class. If the method is non-static, the class needs to be instantiated so that the non-static method can be called later. The system uses the reflection mechanism to load the class according to the business processing class path. If the class contains non-static methods, the system will instantiate the class object to ensure that these non-static methods can be called.

[0168] The reflection mechanism is used to obtain the target method from the business processing class. The system will match the corresponding method in the business processing class according to the method name provided in the record to be retried, so as to call the method in the subsequent steps. The system uses the reflection mechanism to find the target method that matches the method name in the instantiated business class object. The target method defines the execution entry point of the business logic, and the system will proceed to the next step according to the matched target method.

[0169] After completing the class loading and method matching, the system calls the target method through the reflection mechanism, re-executes the business logic that needs to be retried, and passes the call parameters in the record to the target method. The system uses the reflection mechanism to execute the target method and passes the call parameters in the record to be retried to the method. In this way, the system can dynamically re-execute the business logic.

[0170] For example, when the target method in the business logic is a static method, the system can directly use the reflection mechanism to call the target method through the class path without instantiating the class object. Extract the class path, method name, and call parameters from the record to be retried. Use the reflection mechanism to load the business processing class. Directly call the static target method through the reflection mechanism, and pass the call parameters to the target method to re-execute the business logic.

[0171] When the target method is a non-static method, the system needs to instantiate the business processing class object first, and then call the target method through the reflection mechanism. Extract the class path, method name, and call parameters from the record to be retried. Use the reflection mechanism to load the business processing class and instantiate the business processing class object. Use the reflection mechanism to call the target method through the instantiated object, pass the call parameters to the method, and re-execute the business logic.

[0172] This embodiment uses the reflection mechanism to flexibly handle the retry requirements of dynamic business logic. After each scan of the record to be retried, the system loads the corresponding business logic according to the class path and method name in the record, and instantiates the class object as needed, thereby realizing the re-execution of the business logic.

[0173] In one embodiment, after the above S100, the method further includes:

[0174] S1101, when the number of retries of a certain record in the retry service data table reaches a preset maximum number of retries, the operation of re-executing the service logic is terminated;

[0175] S1102, updating the retry status of the corresponding record in the retry service data table to give up retrying;

[0176] S1103, record the current time as the time when the corresponding service request is abandoned and retried.

[0177] In this embodiment, when the business logic fails to execute, the system needs to increase the number of retries in the failure record and update the update time of the record. The number of retries is used to record the current number of failures, and the update time records the time of the last retry, ensuring that the system can perform subsequent retries based on this information. When the system detects that the business logic fails, it automatically updates the relevant fields in the retry business data table, including increasing the number of retries and updating the last update time of the record. At the same time, the system keeps the retry status as "pending retry" so that the system will try the business logic again on the next scan.

[0178] Each business logic has a maximum allowed number of retries. When the number of retries reaches the preset upper limit, the system will stop retrying the business logic. This design is used to prevent the waste of resources that may be caused by infinite retries and control the number of exception handling in the business process. The system will pre-set a threshold for the maximum number of retries. When the system detects that the number of retries for a record has reached the threshold, it will terminate the business logic retry operation of the record to avoid invalid repeated attempts.

[0179] Once the number of retries for a record reaches the upper limit, the system needs to update its status from "pending retry" to "abandon retry". This means that the system has stopped retrying the business logic and marked it as no longer executed. When the number of retries reaches the upper limit, the system will change the retry status of the corresponding record to "abandon retry". This prevents the record from being retrieved and processed again in subsequent scheduled task scans.

[0180] When abandoning the business logic retry, the system also needs to record the current time as the timestamp of abandoning the retry. This time mark is helpful for subsequent system analysis and auditing, and it is convenient to track the time point when the retry failed. When the system updates the retry status to "abandon retry", it records the current system time and saves it to the "abandon time" field of the corresponding record for subsequent viewing and tracking.

[0181] In this embodiment, by increasing the number of retries, updating the retry status, and setting a limit on the maximum number of retries, the system can effectively avoid the waste of resources caused by unlimited retries. When the number of retries reaches the upper limit, the system can automatically stop retrying and update its status to "abandon retrying" to ensure that system resources will not continue to be occupied. By recording the time of abandoning retries, the system can provide a basis for subsequent abnormal analysis and tracking, and improve the auditability and transparency of the system.

[0182] In one embodiment, after the above S1102, the method further includes:

[0183] S1201, generating an exception log based on the record that the retry status is retry abandonment;

[0184] S1202, marking the business request corresponding to the record of giving up retry as a failed state;

[0185] S1203: Based on the exception log, send the service request marked as a failed state to an exception handling end.

[0186] In this embodiment, when the retry status of a record is updated to "abandon retry", the system needs to generate an exception log to record the detailed information of the retry failure. The exception log is used to record the failed business logic call information, including the failure reason and the number of attempts. Based on the records marked as "abandon retry", the system will extract the business processing class path, method name, call parameters, exception reason, number of retries and the last retry time, and write this information to the exception log file or database for subsequent audit and analysis.

[0187] After recording the abandoned retry, the system needs to mark the business request as failed. This mark is used to inform the subsequent processing flow that the request has not been successfully processed and requires further manual intervention or other special processing. The system will set the status of this business request to "failed status" by updating the retry business data table or the related business request table, so that the system interrupts its automatic processing and reminds the relevant parties to perform subsequent manual processing or special processing.

[0188] The generated exception log and the failure status of the business request are sent to the exception handling module or endpoint, which is usually used to record the exception information and trigger the notification or alarm mechanism. The exception handling end will decide how to further handle these failed requests based on the exception log information, such as notifying the operation and maintenance personnel or triggering an alarm. The system will send the business request marked as "failed status" and the generated exception log to a dedicated exception handling module through an interface or message queue. The exception handling module will further process these records, such as conducting manual review or sending an alarm notification.

[0189] Example: In the payment system in the financial field, if a payment operation fails after multiple retries due to a failure in calling an external service, the system will record the payment request as "abandoned retry". At this time, the system will generate an exception log, record the payment service call information, failure reasons and number of retries, and mark the payment request as "failed". Subsequently, the system sends the failed request and exception log to the exception handling module, and the operation and maintenance team will receive a notification and analyze the failure reasons, and perform manual processing in a timely manner. This mechanism ensures that failed requests in the payment process can be discovered and processed in a timely manner, reducing customer complaints and business losses caused by payment failures.

[0190] By generating an exception log and marking the failure status, this embodiment enables the system to record and track the exceptions in the business logic in detail, ensuring that relevant information can be accurately captured even after the automatic retry fails. The exception log provides detailed data for subsequent analysis, and marking the failure status enables the system to effectively distinguish between processed and failed requests to avoid duplicate processing. At the same time, by sending this information to the exception handling end, the system can promptly notify relevant personnel to intervene, ensuring that key business processes can be repaired and processed in a timely manner.

[0191] In one embodiment, a service request processing device is provided, and the service request processing device corresponds one-to-one to the service request processing method in the above embodiment. Figure 3 , Figure 3This is a functional module diagram of a preferred embodiment of the service request processing device of the present invention. Service request processing module 10, exception monitoring module 20, exception capture module 30, exception recording and storage module 40, retry status management module 50, scheduled task management module 60, reflection mechanism and service retry module 70, service execution result judgment module 80, success status update module 90 and failure processing and retry times update module 100. The functional modules are described in detail as follows:

[0192] The business request processing module 10 is used to receive business requests and pass the business requests to the business logic module for business logic processing;

[0193] The abnormality monitoring module 20 is used to monitor whether an abnormality occurs during the business logic processing;

[0194] The exception capture module 30 is used to capture the exception information when an exception is detected, wherein the exception information includes the business processing class path, method name, calling parameters and exception cause of the exception;

[0195] The exception recording and storage module 40 is used to store the exception information in a retry business data table, wherein each record in the retry business data table includes the business processing class path, method name, call parameters, exception reason, retry status, number of retries, creation time and / or update time where the exception occurred;

[0196] A retry status management module 50, for setting the retry status to be retried in the record first stored in the retry service data table, and initializing the number of retries to zero;

[0197] A scheduled task management module 60, used to set a scheduled task, wherein the scheduled task scans the records in the retry service data table whose retry status is "to be retried" according to a preset time interval;

[0198] A reflection mechanism and business retry module 70 is used to use a reflection mechanism to re-call and execute business logic according to the business processing class path, method name and calling parameters in the scanned record to be retried;

[0199] The business execution result judgment module 80 is used to judge whether the business logic is successfully executed after re-executing the business logic;

[0200] The success status update module 90 is used to update the retry status of the corresponding record in the retry business data table to retry success if the business logic is executed successfully, record the success time, and update the update time of the corresponding record;

[0201] The failure processing and retry times updating module 100 is used to increase the retry times of the corresponding record in the retry business data table, update the update time of the corresponding record, and keep the retry status of the corresponding record as pending retry if the business logic execution fails.

[0202] In one embodiment, the service request processing module 10 is specifically used for:

[0203] Configure an interface module, and receive a service request through the interface module;

[0204] The interface module parses the service request and extracts request parameters from the service request;

[0205] Performing format verification and legality check on the request parameters;

[0206] Routing the business request to the corresponding business logic module according to the verified request parameters;

[0207] Predefined business logic processing is executed in the business logic module.

[0208] In one embodiment, the abnormality monitoring module 20 is specifically used to:

[0209] Set up monitoring points before and after key operations performed by business logic;

[0210] A plurality of exception types are predefined, and based on the exception types, an exception handling mechanism based on a programming language exception capture framework is used to capture exceptions occurring at the monitoring point.

[0211] In one embodiment, the scheduled task management module 60 is specifically used to:

[0212] Configure a timed task module, the timed task module is used to perform a scan operation on the retry business data table according to a predetermined scan time interval;

[0213] Dynamically adjust the scanning time interval based on the number of records in the retry service data table;

[0214] Each time a scheduled task is executed, the retry business data table is queried for records with a retry status of pending retry;

[0215] The record to be retried is submitted to the retry module, which is used to re-call and execute the business logic according to the business processing class path, method name and calling parameters in the record.

[0216] In one embodiment, the reflection mechanism and service retry module 70 is specifically used for:

[0217] Extract the business processing class path, method name and calling parameters from the scanned records to be retried;

[0218] Using the reflection mechanism, the business processing class is loaded according to the business processing class path, and if the target method is a non-static method, the business processing class object is instantiated;

[0219] Using the reflection mechanism, through the business processing class object, obtain the target method that matches the method name in the record to be retried;

[0220] The reflection mechanism is used to call the target method through the instantiated business processing class object, and the call parameters are passed to the target method to re-execute the business logic.

[0221] In one embodiment, the failure processing and retry times updating module 100 is specifically used to:

[0222] When the number of retries of a certain record in the retry business data table reaches the preset maximum number of retries, the operation of re-executing the business logic is terminated;

[0223] Update the retry status of the corresponding record in the retry service data table to give up retrying;

[0224] The current time is recorded as the time when the corresponding business request was abandoned and retried.

[0225] In one embodiment, the failure processing and retry times updating module 100 is specifically used to:

[0226] Generate an exception log based on the record that the retry status is retry abandonment;

[0227] Mark the business request corresponding to the record that gave up retrying as failed;

[0228] Based on the exception log, the service request marked as a failure state is sent to an exception handling end.

[0229] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a service request processing method service end side.

[0230] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server through a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of a service request processing method

[0231] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0232] Receive business requests and pass the business requests to the business logic module for business logic processing;

[0233] During the business logic processing, monitor whether any abnormal situations occur;

[0234] When an abnormal situation is detected, the abnormal information is captured, and the abnormal information includes the business processing class path, method name, calling parameters and abnormal cause of the abnormal situation;

[0235] The exception information is stored in a retry business data table, wherein each record in the retry business data table includes the business processing class path, method name, call parameters, exception reason, retry status, number of retries, creation time and / or update time where the exception occurred;

[0236] In the record first stored in the retry service data table, the retry state is set to pending retry, and the number of retries is initialized to zero;

[0237] Setting a timer task, wherein the timer task scans the records in the retry service data table whose retry status is pending retry according to a preset time interval;

[0238] For the scanned records to be retried, a reflection mechanism is used to re-call and execute the business logic according to the business processing class path, method name and calling parameters in the records to be retried;

[0239] After re-executing the business logic, determine whether the business logic is successfully executed;

[0240] If the business logic is executed successfully, update the retry status of the corresponding record in the retry business data table to retry success, record the success time, and update the update time of the corresponding record;

[0241] If the business logic execution fails, increase the number of retries of the corresponding record in the retry business data table, update the update time of the corresponding record, and keep the retry status of the corresponding record as pending retry.

[0242] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0243] Receive business requests and pass the business requests to the business logic module for business logic processing;

[0244] During the business logic processing, monitor whether any abnormal situations occur;

[0245] When an abnormal situation is detected, the abnormal information is captured, and the abnormal information includes the business processing class path, method name, calling parameters and abnormal cause of the abnormal situation;

[0246] The exception information is stored in a retry business data table, wherein each record in the retry business data table includes the business processing class path, method name, call parameters, exception reason, retry status, number of retries, creation time and / or update time where the exception occurred;

[0247] In the record first stored in the retry service data table, the retry state is set to pending retry, and the number of retries is initialized to zero;

[0248] Setting a timer task, wherein the timer task scans the records in the retry service data table whose retry status is pending retry according to a preset time interval;

[0249] For the scanned records to be retried, a reflection mechanism is used to re-call and execute the business logic according to the business processing class path, method name and calling parameters in the records to be retried;

[0250] After re-executing the business logic, determine whether the business logic is successfully executed;

[0251] If the business logic is executed successfully, update the retry status of the corresponding record in the retry business data table to retry success, record the success time, and update the update time of the corresponding record;

[0252] If the business logic execution fails, increase the number of retries of the corresponding record in the retry business data table, update the update time of the corresponding record, and keep the retry status of the corresponding record as pending retry.

[0253] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0254] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0255] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0256] It should be noted that if software tools or components other than those of the Company appear in the embodiments of the present application, they are only used for illustration and do not represent actual use. The above-described embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the above-mentioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the above-mentioned embodiments can still be modified, or some of the technical features thereof can be replaced by equivalents; and these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A method for processing a business request, characterized in that: The following steps are involved: Receive business requests and pass the business requests to the business logic module for business logic processing; During the business logic processing, monitor whether any abnormal situations occur; When an abnormal situation is detected, the abnormal information is captured, and the abnormal information includes the business processing class path, method name, calling parameters and abnormal cause of the abnormal situation; The exception information is stored in a retry business data table, wherein each record in the retry business data table includes the business processing class path, method name, call parameters, exception reason, retry status, number of retries, creation time and / or update time where the exception occurred; In the record first stored in the retry service data table, the retry state is set to pending retry, and the number of retries is initialized to zero; Setting a timer task, wherein the timer task scans the records in the retry service data table whose retry status is "to be retried" according to a preset time interval; For the scanned records to be retried, use the reflection mechanism to re-call and execute the business logic according to the business processing class path, method name and calling parameters in the records to be retried; After re-executing the business logic, determine whether the business logic is successfully executed; If the business logic is executed successfully, update the retry status of the corresponding record in the retry business data table to retry success, record the success time, and update the update time of the corresponding record; If the business logic execution fails, increase the retry count of the corresponding record in the retry business data table, update the update time of the corresponding record, and keep the retry status of the corresponding record as pending retry.

2. The service request processing method according to claim 1, characterized in that: Receiving a business request and passing the business request to the business logic module for business logic processing, including: Configure an interface module, and receive a service request through the interface module; The interface module parses the service request and extracts request parameters from the service request; Performing format verification and legality check on the request parameters; Routing the business request to the corresponding business logic module according to the verified request parameters; Predefined business logic processing is executed in the business logic module.

3. The service request processing method as claimed in claim 1, characterized in that: During the business logic processing, monitor whether any abnormal situations occur, including: Set up monitoring points before and after key operations performed by business logic; A plurality of exception types are predefined, and based on the exception types, an exception handling mechanism based on a programming language exception capture framework is used to capture exceptions occurring at the monitoring point.

4. The service request processing method according to claim 1, characterized in that: Setting a timer task, wherein the timer task scans the records in the retry service data table whose retry status is pending retry according to a preset time interval, including: Configure a timed task module, the timed task module is used to perform a scan operation on the retry business data table according to a predetermined scan time interval; Dynamically adjust the scanning time interval based on the number of records in the retry service data table; Each time a scheduled task is executed, the retry business data table is queried for records with a retry status of pending retry; The record to be retried is submitted to the retry module, which is used to re-call and execute the business logic according to the business processing class path, method name and calling parameters in the record.

5. The service request processing method according to claim 1, characterized in that: For the scanned records to be retried, a reflection mechanism is used to re-call and execute the business logic according to the business processing class path, method name and calling parameters in the records to be retried, including: Extract the business processing class path, method name and calling parameters from the scanned records to be retried; Using the reflection mechanism, the business processing class is loaded according to the business processing class path, and if the target method is a non-static method, the business processing class object is instantiated; Using the reflection mechanism, through the business processing class object, obtain the target method that matches the method name in the record to be retried; The reflection mechanism is used to call the target method through the instantiated business processing class object, and the call parameters are passed to the target method to re-execute the business logic.

6. The service request processing method according to claim 1, characterized in that: If the business logic execution fails, increase the retry times of the corresponding record in the retry business data table, update the update time of the corresponding record, and keep the retry state of the corresponding record as pending retry, and also include: When the number of retries of a certain record in the retry business data table reaches the preset maximum number of retries, the operation of re-executing the business logic is terminated; Update the retry status of the corresponding record in the retry service data table to give up retrying; The current time is recorded as the time when the corresponding business request was abandoned and retried.

7. The service request processing method according to claim 6, characterized in that: After updating the retry status of the corresponding record in the retry service data table to give up retrying, it also includes: Generate an exception log based on the record that the retry status is retry abandonment; Mark the business request corresponding to the record that gave up retrying as failed; Based on the exception log, the service request marked as a failure state is sent to an exception handling end.

8. A service request processing device, characterized in that: The service request processing device comprises: A business request processing module is used to receive business requests and pass the business requests to the business logic module for business logic processing; The exception monitoring module is used to monitor whether an abnormal situation occurs during the business logic processing; The exception capture module is used to capture the exception information when an exception is detected. The exception information includes the business processing class path, method name, call parameters and exception cause where the exception occurs; An exception recording and storage module is used to store the exception information in a retry business data table, each record in the retry business data table includes the business processing class path where the exception occurred, the method name, the calling parameters, the exception reason, the retry status, the number of retries, the creation time and / or the update time; A retry status management module, used to set the retry status to be retried in the record first stored in the retry service data table, and initialize the number of retries to zero; A scheduled task management module, used to set a scheduled task, wherein the scheduled task scans the records in the retry service data table whose retry status is "to be retried" according to a preset time interval; The reflection mechanism and business retry module is used to use the reflection mechanism to re-call and execute the business logic according to the business processing class path, method name and calling parameters in the scanned record to be retried; The business execution result judgment module is used to judge whether the business logic is successfully executed after re-executing the business logic; The success status update module is used to update the retry status of the corresponding record in the retry business data table to retry success if the business logic is executed successfully, record the success time, and update the update time of the corresponding record; The failure processing and retry times updating module is used to increase the retry times of the corresponding record in the retry business data table, update the update time of the corresponding record, and keep the retry status of the corresponding record as pending retry if the business logic execution fails.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a service request processing program stored in the memory and executable on the processor. When the service request processing program is executed by the processor, the steps of the service request processing method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that: The storage medium stores a service request processing program, and when the service request processing program is executed by the processor, the steps of the service request processing method according to any one of claims 1 to 7 are implemented.

Images