Business bottom-up method, device, equipment, medium and program product
By synchronously triggering a fallback thread for suspicious transactions when obtaining transaction instruction information in a microservice distributed system, and reading the configuration parameters corresponding to the business type to execute the fallback logic program, the intermediate problem of transaction status is solved, and the timely update of transaction status and the reliability and flexibility of the system are realized.
Patent Information
- Application Number
- CN202210983799.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-08-16
- Publication Date
- 2025-12-19
- Estimated Expiration
- 2042-08-16
AI Technical Summary
In microservice distributed systems, service RPC call timeouts and exceptions caused by network unreliability result in an intermediate transaction status, making it impossible for customers to accurately obtain transaction results. Furthermore, the uniformly configured fallback program cannot meet the needs of multiple business systems.
A business fallback method is provided, which synchronously triggers a suspicious fallback thread by obtaining transaction instruction information, reads configuration parameters corresponding to the business type, including suspicious period threshold and suspicious fallback logic program, executes the fallback logic program to update the transaction status, and triggers an alarm process when it fails.
It improves the reliability and flexibility of business processing in microservice distributed systems, ensures timely and closed-loop updates of transaction status, and enhances customer experience.
Smart Images

Figure CN115471332B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present disclosure relates to the technical field of computer or finance, in particular to a business bottoming-out method, device, equipment, medium and program product. BACKGROUND
[0002] In a micro-service distributed system, a transaction link involves multiple different platform applications, and different platform applications interact through service RPC calls. Due to the unreliability of the network, there are cases of service RPC call timeout and exceptions, resulting in suspicious data between platforms, and customers seeing an intermediate state of the transaction status, unable to accurately obtain the transaction result. Therefore, the business system needs to increase the bottoming-out processing method for the suspicious state (i.e. intermediate state) transaction instruction to ensure the consistency of multi-platform data and the timely update of the transaction state closed loop. In addition, due to the differences in the instructions and processing logic of different business types, the uniformly configured bottoming-out program cannot meet the bottoming-out needs of multiple business systems. SUMMARY
[0003] In view of the above problems, the embodiments of the present disclosure provide a business bottoming-out method, device, equipment, medium and program product for improving business processing flexibility and reliability.
[0004] According to a first aspect of the present disclosure, a business bottoming-out method is provided, comprising: obtaining transaction instruction information, and synchronously triggering a suspicious bottoming-out thread based on the transaction instruction information; reading configuration parameters corresponding to the business type of the transaction instruction information, the configuration parameters at least including a suspicious period threshold and a suspicious bottoming-out logic program, wherein the suspicious bottoming-out logic program has a mapping relationship with the execution state of the transaction instruction information; obtaining the execution state and execution time of the transaction instruction information based on the suspicious bottoming-out thread, and when the execution time of the transaction instruction information exceeds the suspicious period threshold, obtaining the suspicious bottoming-out logic program corresponding to the execution state of the transaction instruction information; executing the suspicious bottoming-out logic program, and updating the execution state of the transaction execution information based on the execution result.
[0005] According to an embodiment of the present disclosure, the configuration parameters are obtained from a suspicious bottoming-out configuration center, the suspicious bottoming-out configuration center containing configuration parameters corresponding to transaction instruction information of different business types, and the configuration parameters being variable parameters.
[0006] According to an embodiment of the present disclosure, the business type of the transaction instruction information is associated with a business module corresponding to the transaction instruction information.
[0007] According to an embodiment of the present disclosure, the configuration parameters further include a maximum retry number threshold, and the maximum retry number threshold has a mapping relationship with the suspicious bottoming-out logic program.
[0008] According to an embodiment of the present disclosure, the suspicious bottom logic program includes a non-gray program and a gray program, wherein the non-gray program assigns a bottom program for full traffic data, and the gray program assigns a bottom program for data traffic segmentation.
[0009] According to an embodiment of the present disclosure, the executing the suspicious bottom logic program and updating the execution state of the transaction execution information based on an execution result includes: determining whether the suspicious bottom logic program is successfully executed; when the suspicious bottom logic program is successfully executed, obtaining an execution result, and updating the execution state of the transaction execution information based on the execution result.
[0010] According to an embodiment of the present disclosure, when the suspicious bottom logic program fails to execute, the method further includes: determining whether the number of executions of the suspicious bottom logic program exceeds the maximum retry number threshold; when the number of executions of the suspicious bottom logic program is less than or equal to the maximum retry number threshold, repeatedly executing the suspicious bottom logic program.
[0011] According to an embodiment of the present disclosure, when the number of executions of the suspicious bottom logic program is greater than the maximum retry number threshold, the method further includes: triggering an alarm process, the alarm process including sending alarm information to a business staff, the alarm information being used to prompt the business staff to perform manual processing.
[0012] A second aspect of the present disclosure provides a business bottom device, including: an acquisition module configured to acquire transaction instruction information, and synchronously trigger a suspicious bottom thread based on the transaction instruction information; a parameter reading module configured to read configuration parameters corresponding to a business type of the transaction instruction information, the configuration parameters at least including a suspicious period threshold and a suspicious bottom logic program, wherein the suspicious bottom logic program has a mapping relationship with an execution state of the transaction instruction information; a monitoring module configured to acquire the execution state and execution time of the transaction instruction information based on the suspicious bottom thread, and acquire the suspicious bottom logic program corresponding to the execution state of the transaction instruction information when the execution time of the transaction instruction information exceeds the suspicious period threshold; and an execution module configured to execute the suspicious bottom logic program, and update the execution state of the transaction execution information based on an execution result.
[0013] According to an embodiment of the present disclosure, the execution module can include a first judgment submodule and an update submodule. The first judgment submodule is configured to determine whether the suspicious bottom logic program is successfully executed. The update submodule is configured to, when the suspicious bottom logic program is successfully executed, obtain an execution result, and update the execution state of the transaction execution information based on the execution result.
[0014] According to an embodiment of the present disclosure, the execution module can further include a second judgment sub-module and a retry sub-module. The second judgment sub-module is configured to judge whether the execution times of the suspicious bottom logic program exceed the maximum retry times threshold. The retry sub-module is configured to repeatedly execute the suspicious bottom logic program when the execution times of the suspicious bottom logic program are less than or equal to the maximum retry times threshold.
[0015] According to an embodiment of the present disclosure, the execution module can further include an alarm sub-module. The alarm sub-module is configured to trigger an alarm process, the alarm process including sending alarm information to a business staff, the alarm information being used to prompt the business staff to perform manual processing.
[0016] A third aspect of the present disclosure provides an electronic device, comprising: one or more processors; a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the business bottom-up method described above.
[0017] A fourth aspect of the present disclosure further provides a computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the business bottom-up method described above.
[0018] A fifth aspect of the present disclosure further provides a computer program product comprising a computer program that, when executed by a processor, implements the business bottom-up method described above.
[0019] The embodiments of the present disclosure provide a method, which, by configuring configuration parameters including suspicious bottom logic programs matched with business types, takes into account the flexibility of bottom logic processing on the basis of establishing a general business bottom-up processing flow, improves the reliability and flexibility of business processing, and improves customer experience. BRIEF DESCRIPTION OF DRAWINGS
[0020] The above and other objects, features and advantages of the present disclosure will become more apparent from the following description when taken in conjunction with the accompanying drawings, in which:
[0021] Figure 1 An application scenario diagram of a business bottom-up method, device, equipment, medium and program product according to an embodiment of the present disclosure is schematically shown.
[0022] Figure 2 A flowchart of a business bottom-up method according to an embodiment of the present disclosure is schematically shown.
[0023] Figure 3 A flowchart of a method of executing a suspicious bottom logic program and updating an execution state of transaction execution information based on an execution result according to an embodiment of the present disclosure is schematically shown.
[0024] Figure 4 A flowchart of a service fallback method according to a specific example of the present disclosure is schematically shown.
[0025] Figure 5 A structural block diagram of a service fallback apparatus according to an embodiment of the present disclosure is schematically shown.
[0026] Figure 6 A structural block diagram of an execution module according to an embodiment of the present disclosure is schematically shown.
[0027] Figure 7 A structural block diagram of an execution module according to another embodiment of the present disclosure is schematically shown.
[0028] Figure 8 A structural block diagram of an execution module according to still another embodiment of the present disclosure is schematically shown.
[0029] Figure 9 A block diagram of an electronic device suitable for implementing a service fallback method according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION
[0030] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood, however, that the description which follows is merely illustrative and is not intended to limit the scope of the present disclosure. In the following detailed description of embodiments of the present disclosure, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present disclosure. However, it would be apparent to one skilled in the art that the embodiments of the present disclosure can be practiced without these specific details. In other instances, well-known structures and functions have not been described in detail in order to avoid obscuring aspects of the present disclosure.
[0031] The terms used herein are merely used to describe specific embodiments and are not intended to limit the present disclosure. The terms "include", "comprise", and the like used herein indicate the presence of the described features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.
[0032] All terms used herein, including technical and scientific terms, have the same meanings as those generally understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having meanings consistent with the context of the present description, and should not be interpreted in an idealized or excessively formal manner.
[0033] In the case of using expressions similar to "at least one of A, B, and C, etc.", it is generally intended to mean any of A, B, C, etc. individually, or in any combination, e.g., A alone, B alone, C alone, A and B in combination, A and C in combination, B and C in combination, and / or A, B, and C in combination, etc.
[0034] With the expansion of business needs and the iterative innovation and development of information technology, from the aspects of data storage, response time and concurrency, etc., in enterprises including bank systems, the traditional mainframe centralized architecture has been unable to meet the requirements, and needs to be transformed into a micro-service distributed architecture. In the micro-service distributed system, the transaction link involves multiple different platform applications, and different platform applications interact through service RPC calls. Due to the unreliability of the network, there are cases of service RPC call timeout and exceptions, resulting in suspicious data between platforms, and customers seeing an intermediate state of the transaction status, unable to accurately obtain the transaction result. Therefore, the business system needs to increase the bottom-up processing method for the transaction instruction of the suspicious state (i.e., the intermediate state) to ensure the consistency of the multi-platform data and the timely update of the transaction state closed loop.
[0035] On the other hand, since the enterprise system often contains multiple different business types, the corresponding business system contains multiple columns, and each column instruction has differences and processing logic, a unified bottom-up program cannot meet the bottom-up needs of multiple business systems. It is urgent to design a business bottom-up system that takes into account generality and flexibility to ensure the consistency of the data between the multiple platforms of the business system and guarantee the correct closed loop of the transaction instruction state, avoiding affecting the production and life of customers.
[0036] In view of the above problems existing in the prior art, the embodiment of the present disclosure provides a business bottom-up method, comprising: acquiring transaction instruction information, and synchronously triggering a suspicious bottom-up thread based on the transaction instruction information; reading configuration parameters corresponding to the business type of the transaction instruction information, the configuration parameters at least including a suspicious period threshold and a suspicious bottom-up logic program, wherein the suspicious bottom-up logic program has a mapping relationship with the execution state of the transaction instruction information; acquiring the execution state and execution time of the transaction instruction information based on the suspicious bottom-up thread, and when the execution time of the transaction instruction information exceeds the suspicious period threshold, acquiring the suspicious bottom-up logic program corresponding to the execution state of the transaction instruction information; executing the suspicious bottom-up logic program, and updating the execution state of the transaction execution information based on the execution result.
[0037] The business fallback method provided in the embodiments of this disclosure establishes a business fallback processing flow that is both universal and flexible by setting configuration parameters, including a suspicious fallback logic procedure, that matches the business type. This improves the reliability and flexibility of business processing in microservice distributed systems and enhances the customer experience.
[0038] It should be noted that the business fallback method, apparatus, device, medium, and program products provided in this disclosure can be used in computer technology related to business fallback processing, and can also be used in various fields other than computer technology, such as the financial field. The application fields of the business fallback method, apparatus, device, medium, and program products provided in this disclosure are not limited.
[0039] The above-described operations for achieving at least one objective of this disclosure will be described below in conjunction with the accompanying drawings and their descriptions.
[0040] Figure 1 The illustration schematically depicts application scenarios of the business fallback method, apparatus, device, medium, and program product according to embodiments of this disclosure.
[0041] like Figure 1 As shown, application scenario 100 according to this embodiment may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as a medium for providing a communication link between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.
[0042] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).
[0043] Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.
[0044] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using terminal devices 101, 102, and 103 (for example only). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.
[0045] It should be noted that the service bottoming-up method provided by the embodiments of the present disclosure can be generally executed by the server 105. Accordingly, the service bottoming-up apparatus provided by the embodiments of the present disclosure can be generally arranged in the server 105. The service bottoming-up method provided by the embodiments of the present disclosure can also be executed by a server or a server cluster different from the server 105 and capable of communicating with the terminal device 101, 102, 103 and / or the server 105. Accordingly, the service bottoming-up apparatus provided by the embodiments of the present disclosure can also be arranged in a server or a server cluster different from the server 105 and capable of communicating with the terminal device 101, 102, 103 and / or the server 105.
[0046] It should be understood that Figure 1 The number of terminal devices, networks and servers in the above-mentioned scenario is only illustrative. Any number of terminal devices, networks and servers can be provided according to the implementation needs.
[0047] The service bottoming-up method of the embodiments of the present disclosure will be described in detail below based on the scenario described above. Figure 1 Figures 2-4 The service bottoming-up method of the embodiments of the present disclosure will be described in detail below based on the scenario described above.
[0048] Figure 2 A flowchart of the service bottoming-up method according to the embodiments of the present disclosure is schematically shown.
[0049] As shown in Figure 2 The service bottoming-up method of this embodiment includes operations S210-S240, which can be executed by a processor or any electronic device including a processor.
[0050] In operation S210, transaction instruction information is acquired, and a suspicious bottoming-up thread is triggered based on the transaction instruction information.
[0051] In operation S220, configuration parameters corresponding to the service type of the transaction instruction information are read, and the configuration parameters at least include a suspicious period threshold and a suspicious bottoming-up logic program, wherein the suspicious bottoming-up logic program has a mapping relationship with the execution state of the transaction instruction information.
[0052] In operation S230, the execution state and execution time of the transaction instruction information are acquired based on the suspicious bottoming-up thread, and when the execution time of the transaction instruction information exceeds the suspicious period threshold, the suspicious bottoming-up logic program corresponding to the execution state of the transaction instruction information is acquired.
[0053] In operation S240, the suspicious bottoming-up logic program is executed, and the execution state of the transaction execution information is updated based on the execution result.
[0054] According to an embodiment of the present disclosure, the transaction instruction information can be instruction data corresponding to a transaction inserted in a business system database after the transaction is initiated based on the business system. During business execution, a system process completes a state transition closed loop through a service RPC call. In the event of an abnormal instruction state transition due to network or cloud container abnormalities, an embodiment of the present disclosure processes the abnormal state of the intermediate state through a business bottom-up manner. To ensure timely triggering of the business bottom-up process, a suspicious bottom-up thread can be triggered synchronously while the transaction instruction information is obtained. The suspicious bottom-up thread is configured in a system bottom-up framework. To improve data processing efficiency, the related parameters of the suspicious bottom-up thread, such as the number of thread parallel running, the frequency of thread running, and the time interval, can be configured based on the business type corresponding to the transaction instruction information.
[0055] In an embodiment of the present disclosure, the configuration parameters can be stored in a separate module. The transaction instruction information corresponding to each business type can be configured with corresponding configuration parameters. When the suspicious bottom-up thread is triggered, the bottom-up system reads the current configuration parameters. The suspicious period threshold can be a time limit parameter for determining whether to trigger the suspicious bottom-up logic program. The bottom-up logic program can be a specific bottom-up logic running program. It can be understood that the transaction instruction information can have multiple execution states, and for each execution state, a corresponding suspicious bottom-up logic program can be configured. Thus, the suspicious period threshold corresponding to each business type of transaction instruction information and the suspicious bottom-up logic program corresponding to each execution state of each business type of transaction instruction information can be formed, achieving dynamic and flexible bottom-up logic processing.
[0056] After reading the configuration parameters, the suspicious bottom-up thread can be used to scan the instruction table of the database to query the transaction instruction information whose execution time exceeds the suspicious period threshold, and synchronously obtain the specific execution state of the transaction instruction information. Thus, the suspicious bottom-up logic program corresponding to the execution state of the current transaction instruction information can be obtained from the configuration parameters based on the execution state and the execution time of the transaction instruction information, and the suspicious bottom-up logic program is executed.
[0057] In other embodiments, operation S220 can also be performed synchronously with operation S230. For example, the configuration parameters can be read at the same time as the execution state and the execution time of the transaction instruction information are obtained based on the suspicious bottom-up thread.
[0058] In an embodiment of the present disclosure, by setting configuration parameters including suspicious bottom-up logic programs that match the business type, a set of business bottom-up processing procedures with universality and flexibility is established, and the reliability and flexibility of business processing are improved.
[0059] In some embodiments, the configuration parameters are obtained from a suspicious bottom-up configuration center, which includes configuration parameters corresponding to transaction instruction information of different business types, and the configuration parameters are variable parameters. In embodiments of the present disclosure, the configuration parameters can be set by support personnel in the configuration center. The configuration center is separated from the suspicious bottom-up thread to separate the bottom-up logic code and the underlying running code. In the configuration center, configuration parameters corresponding to transaction instruction information of different business types can be configured centrally, and the configuration parameters are variable, i.e., the configuration parameters can be dynamically adjusted, and the latest configuration parameters are updated when the bottom-up system reads the configuration parameters. Thus, the business bottom-up method of embodiments of the present disclosure can be efficiently and flexibly implemented.
[0060] In some embodiments, the business type of the transaction instruction information is associated with a business module corresponding to the transaction instruction information. The business type of the transaction instruction information can be determined based on the business module corresponding to the transaction instruction information. In a specific example, in an enterprise online banking system, the business module can include transfer and account management. Correspondingly, there can be transaction instruction information corresponding to transfer and transaction instruction information corresponding to account management. The transaction instruction information corresponding to different business types can be coded for the suspicious bottom-up thread to scan and obtain the corresponding state information. For example, the coding of the transaction instruction information of the transfer type can be set as "A", and for each transaction instruction information under this type, its unique code can be set as "A + number".
[0061] In some embodiments, the configuration parameters further include a maximum retry number threshold, and the maximum retry number threshold has a mapping relationship with the suspicious bottom-up logic program. According to embodiments of the present disclosure, a retry mechanism can be set when the business bottom-up logic is executed. By continuously retrying to compensate for reducing manual compensation, the compensation success rate is improved and the manual processing cost is reduced, and the system fault tolerance is improved. Based on the requirements of program closed loop and waiting time control, the maximum retry number threshold can be set as a limit to the number of times of repeatedly executing the suspicious bottom-up logic program.
[0062] In some embodiments, the suspicious fallback logic program includes a non-gray program and a gray program, wherein the non-gray program assigns a fallback program to full traffic data, and the gray program assigns a fallback program to traffic splitting. In embodiments of the present disclosure, the non-gray program and the gray program can be configured when configuring the suspicious fallback logic program based on the upgrade requirement of the suspicious fallback logic program. In the fallback system and / or suspicious fallback logic program upgrade test, the gray program can be enabled. When the gray program is enabled, the full traffic data can be split based on the traffic distribution rules configured in the system bottom running logic, and part of the traffic is assigned to the old version program for fallback logic processing, and the remaining traffic is assigned to the new version program for fallback logic processing. When the program upgrade is completed, the non-gray program can be enabled. When the non-gray program is enabled, the full traffic data can be assigned to the new version program. Thus, the shunt upgrade of the fallback logic code is realized, and the system upgrade production risk is reduced.
[0063] Figure 3 A flowchart of a method of executing a suspicious fallback logic program and updating an execution state of transaction execution information based on an execution result according to an embodiment of the present disclosure is schematically shown.
[0064] As shown in Figure 3 The method of executing a suspicious fallback logic program and updating an execution state of transaction execution information based on an execution result according to an embodiment can include operation S310 to operation S320.
[0065] In operation S310, it is determined whether the suspicious fallback logic program is successfully executed.
[0066] When the suspicious fallback logic program is successfully executed, operation S320 is performed.
[0067] In operation S320, the execution result is obtained, and the execution state of the transaction execution information is updated based on the execution result.
[0068] According to an embodiment of the present disclosure, when the program is successfully executed, the execution state of the transaction execution information can be updated, for example, the instruction state corresponding to the current transaction in the database can be updated to a terminal state. For example, it can include transaction success or transaction failure.
[0069] When the suspicious fallback logic program fails, operation S330 can be performed.
[0070] In operation S330, it is determined whether the number of executions of the suspicious fallback logic program is greater than the maximum retry number threshold.
[0071] When the number of executions of the suspicious fallback logic program is less than or equal to the maximum retry number threshold, operation S340 is performed.
[0072] At operation S340, the suspicious bottom logic program is repeatedly executed.
[0073] In embodiments of the present disclosure, the total number of executions of the suspicious bottom logic program can be set as a maximum retry number threshold. The remaining number of executions of the suspicious bottom logic program is the total number of executions minus one each time the suspicious bottom logic program is repeatedly executed. The suspicious bottom logic program can be repeatedly executed until the remaining number of executions is zero.
[0074] When the number of executions of the suspicious bottom logic program is greater than the maximum retry number threshold, operation S350 is performed.
[0075] At operation S350, an alarm process is triggered.
[0076] The alarm process includes sending alarm information to a business staff, and the alarm information is used to prompt the business staff to perform manual processing. In embodiments of the present disclosure, a manual bottom mechanism can be set, that is, manual compensation is triggered when the number of retries is exhausted, to ensure the completion of the program closed loop, avoid the inability to discover and even handle suspicious problems, and improve the robustness of the business bottom-up method of embodiments of the present disclosure. The alarm information can be common notification information, for example, email, SMS, WeChat message, etc. Correspondingly, the alarm contact person, for example, the business staff contact information, can be preset in the configuration parameter. After receiving the alarm information, the business staff can manually intervene to confirm the actual processing of the suspicious instruction, and adjust the database instruction state to a terminal state, for example, success or failure information.
[0077] The following reference Figure 4 The business bottom-up method according to the specific examples of the present disclosure is described in detail. It should be noted that the following description is only exemplary and does not constitute a specific limitation on the specific examples of the present disclosure.
[0078] Figure 4 The flowchart of the business bottom-up method according to the specific examples of the present disclosure is schematically shown. The specific examples of the present disclosure are described in the business bottom-up process of the bank's enterprise online banking system.
[0079] Step 1, the customer initiates a transaction through the enterprise online banking system, and inserts a corresponding instruction data in the enterprise online banking database. The system process completes the state transition closed loop through the service RPC call. Due to network and cloud container abnormalities, the instruction state transition is abnormal, and the abnormal situation of the intermediate state is handled.
[0080] Step 2, the bank application support personnel configure the suspicious bottom logic program corresponding to the instructions in different columns, the maximum retry number, the suspicious period threshold, the notification person's mailbox and mobile phone information, and other parameters in the configuration center.
[0081] Step 3, when the suspicious bottom thread is started, read the configuration parameters from the configuration center, and receive the configuration center parameter adjustment and synchronize the update.
[0082] Step 4, the suspicious bottom thread scans the instruction table of the database in parallel, and queries the instruction data whose suspicious period exceeds the threshold time configured;
[0083] Step 5, for the data of step 4, execute the bottom logic program set by the configuration center. If the program is executed normally, update the instruction state in the enterprise online banking database to the final state (success or failure); if the program is executed abnormally, determine whether the number of retries has exceeded the maximum number of retries set by the configuration center. If it exceeds, send a notification message according to the email and mobile phone number of the notifier set in the configuration center, and send an alarm to the monitoring alarm center; if it does not exceed, continue to attempt to execute the bottom logic program set by the configuration center.
[0084] Step 6, after receiving the alarm or notification email, the application support personnel manually access to confirm the actual processing of the suspicious instruction, and adjust the instruction state in the enterprise online banking database to the final state (success or failure).
[0085] Step 7, the customer initiates a transaction query through the enterprise online banking system, and can correctly view the instruction execution. If it fails, it can be re-initiated according to the demand.
[0086] Based on the above business bottom-up method, the present disclosure also provides a business bottom-up device. The following will be combined Figure 5 with the description of the device.
[0087] Figure 5 The structure block diagram of the business bottom-up device according to the embodiment of the present disclosure is schematically shown.
[0088] As Figure 5 shown, the business bottom-up device 500 of the embodiment includes an acquisition module 510, a parameter reading module 520, a monitoring module 530, and an execution module 540.
[0089] The acquisition module 510 is configured to acquire transaction instruction information, and trigger a suspicious bottom thread based on the transaction instruction information.
[0090] The parameter reading module 520 is configured to read configuration parameters corresponding to the business type of the transaction instruction information, the configuration parameters at least including a suspicious period threshold and a suspicious bottom logic program, wherein the suspicious bottom logic program and the execution state of the transaction instruction information have a mapping relationship.
[0091] The monitoring module 530 is configured to acquire an execution state and an execution time of the transaction instruction information based on the suspicious bottom thread, and acquire suspicious bottom logic programs corresponding to the execution state of the transaction instruction information when the execution time of the transaction instruction information exceeds the suspicious period threshold.
[0092] The execution module 540 is configured to execute the suspicious bottom logic programs and update the execution state of the transaction execution information based on an execution result.
[0093] In some embodiments, the execution module can further include a first judgment submodule and an updating submodule.
[0094] Figure 6 A structural block diagram of the execution module according to some embodiments of the present disclosure is schematically shown.
[0095] As Figure 6 shown, the execution module 540 of this embodiment includes a first judgment submodule 5401 and an updating submodule 5402.
[0096] The first judgment submodule 5401 is configured to judge whether the execution of the suspicious bottom logic programs is successful.
[0097] The updating submodule 5402 is configured to acquire an execution result when the execution of the suspicious bottom logic programs is successful, and update the execution state of the transaction execution information based on the execution result.
[0098] In other embodiments, in addition to the first judgment submodule and the updating submodule, the execution module can further include a second judgment submodule and a retry submodule.
[0099] Figure 7 A structural block diagram of the execution module according to other embodiments of the present disclosure is schematically shown.
[0100] As Figure 7 shown, the execution module 540 of this embodiment includes a first judgment submodule 5401, an updating submodule 5402, a second judgment submodule 5403 and a retry submodule 5404.
[0101] The steps performed by the first judgment submodule 5401 and the updating submodule 5402 are as described above, and will not be repeated here.
[0102] The second judgment submodule 5403 is configured to judge whether the execution times of the suspicious bottom logic programs exceed the maximum retry times threshold.
[0103] The retry submodule 5404 is configured to repeatedly execute the suspicious bottom logic programs when the execution times of the suspicious bottom logic programs are less than or equal to the maximum retry times threshold.
[0104] It should be understood that when the second judging submodule 5403 and the retry submodule 5404 are triggered to execute their steps, the updating submodule 5402 is not triggered at the same time.
[0105] Figure 8 A structural block diagram of the execution module according to still some embodiments of the present disclosure is schematically shown.
[0106] As shown in Figure 8 The execution module 540 of this embodiment includes a first judging submodule 5401, an updating submodule 5402, a second judging submodule 5403, a retry submodule 5404, and an alarm submodule 5405.
[0107] The steps executed by the first judging submodule 5401, the updating submodule 5402, the second judging submodule 5403, and the retry submodule 5404 are as described above, and will not be repeated here.
[0108] The alarm submodule 5405 is configured to trigger an alarm process, which includes sending alarm information to a service personnel, the alarm information being used to prompt the service personnel to perform manual processing.
[0109] It should be understood that when the alarm submodule 5405 is triggered to execute its steps, the updating submodule 5402 and the retry submodule 5404 are not triggered at the same time.
[0110] According to an embodiment of the present disclosure, any multiple of the acquisition module 510, the parameter reading module 520, the monitoring module 530, the execution module 540, the first judgment sub-module 5401, the updating sub-module 5402, the second judgment sub-module 5403, the retry sub-module 5404 and the alarm sub-module 5405 can be combined in one module for implementation, or any one of the modules can be split into multiple modules. Alternatively, at least part of the functions of one or more of the modules can be combined with at least part of the functions of other modules, and implemented in one module. According to an embodiment of the present disclosure, at least one of the acquisition module 510, the parameter reading module 520, the monitoring module 530, the execution module 540, the first judgment sub-module 5401, the updating sub-module 5402, the second judgment sub-module 5403, the retry sub-module 5404 and the alarm sub-module 5405 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on chip, a system on board, a system on package, an application specific integrated circuit (ASIC), or any other reasonable manner of hardware or firmware that can be integrated or packaged, or implemented in any one of software, hardware and firmware or in a proper combination of any of them. Alternatively, at least one of the acquisition module 510, the parameter reading module 520, the monitoring module 530, the execution module 540, the first judgment sub-module 5401, the updating sub-module 5402, the second judgment sub-module 5403, the retry sub-module 5404 and the alarm sub-module 5405 can be at least partially implemented as a computer program module that can perform corresponding functions when the computer program module is run.
[0111] Figure 9 A block diagram of an electronic device suitable for implementing the business bottom-up method according to an embodiment of the present disclosure is schematically shown.
[0112] As Figure 9 shown, the electronic device 900 according to an embodiment of the present disclosure includes a processor 901 that can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 902 or loaded from a storage portion 908 into a random access memory (RAM) 903. The processor 901 can include, for example, a general-purpose microprocessor (such as a CPU), an instruction set processor and / or a related chipset, and / or a special-purpose microprocessor (such as an application specific integrated circuit (ASIC)), and the like. The processor 901 can also include an on-board memory for cache use. The processor 901 can include a single processing unit or multiple processing units for performing different actions of the method processes according to embodiments of the present disclosure.
[0113] In the RAM 903, various programs and data required for the operation of the electronic device 900 are stored. The processor 901, the ROM 902, and the RAM 903 are connected to each other via the bus 904. The processor 901 performs various operations of the method flow according to the embodiments of the present disclosure by executing the programs in the ROM 902 and / or the RAM 903. It should be noted that the programs can also be stored in one or more memories other than the ROM 902 and the RAM 903. The processor 901 can also perform various operations of the method flow according to the embodiments of the present disclosure by executing the programs stored in the one or more memories.
[0114] According to an embodiment of the present disclosure, the electronic device 900 can further include an input / output (I / O) interface 905, which is also connected to the bus 904. The electronic device 900 can further include one or more of the following components connected to the I / O interface 905: an input part 906 including a keyboard, a mouse, etc.; an output part 907 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage part 908 including a hard disk, etc.; and a communication part 909 including a network interface card such as a LAN card, a modem, etc. The communication part 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the I / O interface 905 as necessary. A removable medium 911 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is mounted on the drive 910 as necessary, so that a computer program read out therefrom is installed in the storage part 908 as necessary.
[0115] The present disclosure also provides a computer readable storage medium, which can be included in the device / apparatus / system described in the above embodiments; or can exist separately without being assembled into the device / apparatus / system. The above computer readable storage medium carries one or more programs, when the one or more programs are executed, the method according to the embodiments of the present disclosure is implemented.
[0116] According to an embodiment of the present disclosure, the computer readable storage medium can be a nonvolatile computer readable storage medium, for example, can include, but is not limited to, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read Only Memory (ROM), an Erasable Programmable Read Only Memory (EPROM or Flash memory), a portable compact disc read only memory (CD-ROM), an optical storage device, a magnetic storage device, or any appropriate combination thereof. In the present disclosure, the computer readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device. For example, according to an embodiment of the present disclosure, the computer readable storage medium can include one or more memories such as the ROM 902 and / or the RAM 903 described above and / or one or more memory other than the ROM 902 and the RAM 903.
[0117] Embodiments of the present disclosure also include a computer program product that includes a computer program containing program codes for executing the methods shown in the flowcharts. When the computer program product is run in a computer system, the program codes are used to make the computer system implement the methods provided by the embodiments of the present disclosure.
[0118] The above-described functions defined in the system / device of the embodiments of the present disclosure are performed when the computer program is executed by the processor 901. According to an embodiment of the present disclosure, the system, device, module, unit, etc. described above can be implemented by computer program modules.
[0119] In one embodiment, the computer program can rely on a tangible storage medium such as an optical storage device, a magnetic storage device, etc. In another embodiment, the computer program can also be transmitted, distributed, and downloaded in the form of a signal on a network medium and installed and executed through the communication part 909 and / or installed from the detachable medium 911. The program codes contained in the computer program can be transmitted by any appropriate network medium, including but not limited to wireless, wired, etc., or any appropriate combination thereof.
[0120] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 909 and / or installed from the detachable medium 911. When the computer program is executed by the processor 901, the above-described functions defined in the system of the embodiments of the present disclosure are performed. According to an embodiment of the present disclosure, the system, device, apparatus, module, unit, etc. described above can be implemented by computer program modules.
[0121] According to embodiments of the present disclosure, program code of the computer program for performing the methods provided by the embodiments of the present disclosure can be written in any combination of one or more programming languages, and can be implemented in a computer program product. Specifically, the computer program can be implemented in a high-level procedural and / or object-oriented programming language, and / or in assembly / machine language. The programming language includes, but is not limited to, Java, C++, python, “C” language, or similar programming languages. The program code can execute entirely on the user's computing device, partly on the user's device, and partly on a remote computing device, or entirely on the remote computing device or server. In the latter scenario, the remote computing device can be connected to the user's computing device through any kind of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computing device, such as through the Internet using an Internet Service Provider (ISP).
[0122] The computer program product of the present disclosure can be a computer program product, which is a machine-readable medium (or computer readable medium) having stored therein a sequence of instructions readable by a machine (e.g., a computer). The instructions in the machine-readable medium focus on the function of the computer program (e.g., in the form of a computer program product). The instructions can be executed by one or more processors to produce a computer-implemented process, such as the one(s) described above. The instructions can be stored in a computer memory, which can be a single memory or spread out over multiple memories. The machine-readable medium can be a magnetic or optical disk, a magnetic tape, a semiconductor memory, a computer disk, or any other suitable medium. The machine-readable medium can be loaded into the computer memory, and the instructions can be executed by the computer to produce a computer-implemented process, such as the one(s) described above.
[0123] It is to be understood that the features mentioned herein can be combined with one another in any way possible, unless such a combination is clearly indicated to be not possible or is technically impossible. In particular, the features of the various embodiments and / or claims of the present disclosure can be combined with one another in any way possible, without departing from the spirit and the scope of the present disclosure. All combinations of the features mentioned herein are within the scope of the present disclosure.
[0124] The above describes embodiments of the present disclosure. However, these embodiments are merely for illustrative purposes, and are not intended to limit the scope of the present disclosure. Although each embodiment is described above separately, this does not mean that the measures in each embodiment cannot be used advantageously in combination. The scope of the present disclosure is defined by the appended claims and their equivalents. Those skilled in the art can make various substitutions and modifications without departing from the scope of the present disclosure, and these substitutions and modifications should all fall within the scope of the present disclosure.
Claims
1. A business fallback method, characterized in that, include: Retrieve transaction instruction information from the database, and simultaneously trigger a fallback thread for suspicious transactions based on the transaction instruction information; Read configuration parameters, which correspond to the business type of the transaction instruction information. The configuration parameters include at least a suspicious period threshold and a suspicious fallback logic program, wherein the suspicious fallback logic program has a mapping relationship with the execution status of the transaction instruction information. The suspicious fallback logic program includes a non-grayscale program and a grayscale program. The non-grayscale program is a fallback program for all traffic data allocation, and the grayscale program is a fallback program for data traffic segmentation and allocation. The grayscale program segments the all traffic data according to a preset traffic allocation rule to allocate it to the new and old versions of the program for fallback logic processing. Based on the instruction table of the suspicious fallback thread scanning database, the execution status and execution time of the transaction instruction information are obtained. When the execution time of the transaction instruction information exceeds the suspicious period threshold, the suspicious fallback logic program corresponding to the execution status of the transaction instruction information is obtained; and Execute the aforementioned fallback logic procedure and update the execution status of the transaction execution information based on the execution result.
2. The business fallback method according to claim 1, wherein, The configuration parameters are obtained from the suspicious fallback configuration center, which contains configuration parameters corresponding to transaction instruction information for different business types. The configuration parameters are variable parameters.
3. The business fallback method according to claim 1, wherein, The business type of the transaction instruction information is associated with the business module corresponding to the transaction instruction information.
4. The business fallback method according to claim 1, wherein, The configuration parameters also include a maximum retry threshold, which is mapped to the suspicious fallback logic program.
5. The method according to claim 4, wherein, The execution of the suspicious fallback logic procedure, and the updating of the transaction execution information status based on the execution result, includes: Determine whether the suspected fallback logic procedure was executed successfully; and When the suspicious fallback logic program is executed successfully, the execution result is obtained, and the execution status of the transaction execution information is updated based on the execution result.
6. The method according to claim 5, wherein, When the suspected fallback logic procedure fails to execute, the method further includes: Determine whether the number of times the suspected fallback logic procedure has been executed exceeds the maximum retry threshold; and When the number of times the suspicious fallback logic program is executed is less than or equal to the maximum retry threshold, the suspicious fallback logic program is executed repeatedly.
7. The method according to claim 6, wherein, When the number of executions of the suspected fallback logic procedure exceeds the maximum retry threshold, the method further includes: The alarm process is triggered, which includes sending alarm information to business personnel to prompt them to handle the situation manually.
8. A business backup device, characterized in that, include: The acquisition module is configured to retrieve transaction instruction information from the database and synchronously trigger a fallback thread based on the transaction instruction information; The parameter reading module is configured to read configuration parameters, which correspond to the business type of the transaction instruction information. The configuration parameters include at least a suspicious period threshold and a suspicious fallback logic program, wherein the suspicious fallback logic program has a mapping relationship with the execution status of the transaction instruction information. The suspicious fallback logic program includes a non-grayscale program and a grayscale program. The non-grayscale program is a fallback program for all traffic data allocation, and the grayscale program is a fallback program for data traffic segmentation and allocation. The grayscale program segments the all traffic data according to a preset traffic allocation rule to allocate it to the new and old versions of the program for fallback logic processing. The monitoring module is configured to obtain the execution status and execution time of the transaction instruction information based on the instruction table of the database scanned by the suspicious fallback thread; when the execution time of the transaction instruction information exceeds the suspicious period threshold, it obtains the suspicious fallback logic program corresponding to the execution status of the transaction instruction information; and The execution module is configured to execute the suspicious fallback logic program and update the execution status of the transaction execution information based on the execution result.
9. An electronic device, comprising: One or more processors; Storage device for storing one or more programs. Wherein, when the one or more programs are executed by the one or more processors, the one or more processors perform the method according to any one of claims 1 to 7.
10. A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.
11. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 7.
Citation Information
Patent Citations
Abnormal state repairing method and device and readable storage medium
CN111064590A