Method, device, equipment, medium and program product for monitoring pre-transaction procedures

Abstract

The application provides a pre-transaction program monitoring method, device, equipment, medium and program product, and relates to the field of financial technology or other related fields. The method comprises the following steps: acquiring running state information of a pre-transaction program according to a preset time interval; in response to the acquisition of the running state information of the pre-transaction program, determining whether the pre-transaction program is normally running according to the running state information; in response to the normal running of the pre-transaction program, acquiring transaction-related information corresponding to the pre-transaction program within the preset time interval; adjusting the preset time interval according to the transaction-related information to obtain an adjusted time interval; in response to the adjusted time interval being greater than the preset time interval, determining that the fault cause is that a server of a financial institution to which the pre-transaction program belongs is out of order, and continuing to acquire the running state information of the pre-transaction program according to the adjusted time interval. The method of the application can save hardware resources and quickly determine the fault cause.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related fields, and in particular to a method, apparatus, equipment, medium and program product for monitoring a front-end transaction process. Background Technology

[0002] Businesses and merchants, as well as other financial institutions, can have accounts with multiple financial institutions. To improve user experience and avoid the need for users to log in to multiple financial institution accounts or frequently switch pages during transactions, a seamless connection between the user and each financial institution can be established through the cooperation of treasury management applications, multi-bank routing servers, and front-end transaction programs from different financial institutions. This allows users to conduct transactions through multiple financial institution accounts using only the treasury management application. The front-end transaction programs are application programming interfaces (APIs) provided by the financial institutions, and the multi-bank routing server enables account switching between different financial institutions. Users can log in to any financial institution's account on the treasury management software and then access the corresponding financial institution's server through the multi-bank routing server and the front-end transaction program to conduct transactions or view account status on the financial institution's server.

[0003] In the above scenario, the front-end transaction program is installed on the front-end server, and the enterprise treasury management application software is installed on the client device. Users conduct transactions under accounts in multiple financial institutions through the treasury management application software. This requires the cooperation of the front-end server, the front-end transaction program, and the servers of the financial institutions. Therefore, if a user encounters a problem while using the treasury management application software, determining the cause of the fault requires checking each front-end server and the front-end transaction program in turn, which is inefficient. Furthermore, for the front-end transaction program, the current method of troubleshooting is mostly based on timed checks. When there are many front-end transaction programs, it consumes a lot of hardware resources, which will affect the performance of the client device and reduce the user experience.

[0004] The preceding description is intended to provide general background information and does not necessarily constitute prior art. Summary of the Invention

[0005] This application provides a method, apparatus, device, medium, and program product for monitoring a pre-trading process, in order to solve the problems of low efficiency in determining the cause of failure and the need to consume a lot of hardware resources to monitor the pre-trading process in the prior art.

[0006] According to a first aspect of this application, a method for monitoring a pre-transaction process is provided, comprising: acquiring operational status information of the pre-transaction process at preset time intervals; in response to acquiring the operational status information of the pre-transaction process, determining whether the pre-transaction process is operating normally based on the operational status information; in response to the pre-transaction process operating normally, acquiring transaction-related information corresponding to the pre-transaction process within the preset time interval; the transaction-related information is transaction-related information generated by a user conducting transactions on a financial institution's server through the pre-transaction process; adjusting the preset time interval based on the transaction-related information to obtain an adjusted time interval; in response to the adjusted time interval being greater than the preset time interval, determining that the cause of the fault is a fault in the server of the financial institution to which the pre-transaction process belongs, and continuing to acquire the operational status information of the pre-transaction process at the adjusted time interval to continue monitoring the pre-transaction process.

[0007] In one possible design, the operating status information includes a running state or a stopped running state; when the operating status information is a running state, the operating status information also includes operating parameters; determining whether the pre-trading program is running normally based on the operating status information includes: in response to the operating status information being a stopped running state, determining that the pre-trading program is not running normally; in response to the operating status information being a running state, determining whether the pre-trading program is running normally based on the operating parameters.

[0008] In one possible design, determining whether the pre-trading program is running normally based on the operating parameters includes: obtaining preset operating parameter conditions corresponding to the pre-trading program; determining that the pre-trading program is not running normally in response to the operating parameters not meeting the preset operating parameter conditions; and determining that the pre-trading program is running normally in response to the operating parameters meeting the preset operating parameter conditions.

[0009] In one possible design, the operating parameters include CPU utilization and memory usage;

[0010] The step of determining that the pre-processing trading program is not running normally in response to the fact that the operating parameters do not meet the preset operating parameter conditions includes: determining that the pre-processing trading program is not running normally in response to at least one of CPU utilization being greater than a preset CPU utilization and memory usage being greater than a preset memory amount; the step of determining that the pre-processing trading program is running normally in response to the fact that the operating parameters meet the preset operating parameter conditions includes: determining that the pre-processing trading program is running normally in response to the fact that CPU utilization is less than or equal to a preset CPU utilization and memory usage is less than or equal to a preset memory amount.

[0011] In one possible design, the transaction-related information includes a transaction failure rate; adjusting the preset time interval based on the transaction-related information includes: obtaining a first preset threshold that has a mapping relationship with a pre-stored mapping relationship between a pre-stored transaction program and a first preset threshold; and increasing the preset time interval in response to the transaction failure rate being greater than or equal to the corresponding first preset threshold.

[0012] In one possible design, before obtaining the first preset threshold that has a mapping relationship with the preceding transaction program from the pre-stored mapping relationship between the preceding transaction program and the first preset threshold, the method further includes: constructing the mapping relationship based on the preset importance of the transactions performed by the preceding transaction program; the preset importance is positively correlated with the first preset threshold.

[0013] In one possible design, the method further includes: in response to the transaction failure rate being greater than or equal to a second preset threshold, controlling the running state of the pre-processing transaction program to switch to a stopped running state; the second preset threshold is greater than the first preset threshold.

[0014] In one possible design, after determining whether the front-end transaction program is running normally based on the running status information, the method further includes: in response to the front-end transaction program not running normally, determining that the cause of the fault is a fault in the front-end transaction program.

[0015] In one possible design, after obtaining the running status information of the front-end transaction program at preset time intervals, the method further includes: in response to not obtaining the running status information of the front-end transaction program, determining whether communication with the multi-bank routing server is possible; the multi-bank routing server communicating with the front-end server to which the front-end transaction program belongs; in response to being able to communicate with the multi-bank routing server, determining that the cause of the fault is a fault in the front-end server to which the front-end transaction program belongs; in response to not being able to communicate with the multi-bank routing server, determining that the cause of the fault is a network connection failure.

[0016] In one possible design, the method further includes: in response to determining the cause of the fault, outputting alarm information; the alarm information includes the cause of the fault; the cause of the fault includes a fault in the server of the financial institution to which the pre-transaction program belongs, a fault in the pre-transaction program itself, a fault in the pre-transaction server to which the pre-transaction program belongs, or a network connection failure.

[0017] According to a second aspect of this application, a monitoring device for a pre-transaction process is provided, comprising:

[0018] The first acquisition module is used to acquire the running status information of the preceding transaction program at preset time intervals;

[0019] The determination module is used to determine whether the front-end transaction program is running normally based on the obtained running status information in response to the acquisition of the running status information.

[0020] The second acquisition module is used to acquire transaction-related information corresponding to the front-end transaction program within a preset time interval in response to the normal operation of the front-end transaction program; the transaction-related information is transaction-related information generated by the user through the front-end transaction program on the server of a financial institution.

[0021] The adjustment module is used to adjust the preset time interval according to the transaction-related information to obtain the adjusted time interval;

[0022] The monitoring module is used to determine that the server of the financial institution to which the front-end transaction program belongs has failed when the adjusted time interval is greater than the preset time interval, and to continue to acquire the running status information of the front-end transaction program according to the adjusted time interval, so as to continue to monitor the front-end transaction program.

[0023] According to a third aspect of this application, an electronic device is provided, comprising: a processor and a memory communicatively connected to the processor;

[0024] The memory stores computer-executed instructions;

[0025] The processor executes computer execution instructions stored in the memory to implement the method as described in the first aspect.

[0026] According to a fourth aspect of this application, a computer-readable storage medium is provided, wherein computer-executable instructions are stored therein, which, when executed by a processor, are used to implement the method as described in the first aspect.

[0027] According to a fifth aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in the first aspect.

[0028] The monitoring method, apparatus, equipment, medium, and program product for the pre-transaction process provided in this application acquires the operating status information of the pre-transaction process at preset time intervals; in response to acquiring the operating status information of the pre-transaction process, it determines whether the pre-transaction process is operating normally based on the operating status information; in response to the pre-transaction process operating normally, it acquires transaction-related information corresponding to the pre-transaction process within the preset time interval; the transaction-related information is transaction-related information generated by the user conducting transactions on the financial institution's server through the pre-transaction process; it adjusts the preset time interval based on the transaction-related information to obtain an adjusted time interval; in response to the adjusted time interval being greater than the preset time interval, it determines that the cause of the fault is a fault in the server of the financial institution to which the pre-transaction process belongs, and continues to acquire the operating status information of the pre-transaction process at the adjusted time interval to continue monitoring the pre-transaction process. Since transaction-related information is generated by users conducting transactions on the servers of financial institutions through pre-processing transaction programs, it reflects the operational status of the financial institution's servers. Therefore, the preset time interval can be adjusted based on the transaction-related information to ensure that the monitoring of the pre-processing transaction program matches the operational status of the financial institution's server. This avoids ineffective monitoring of the pre-processing transaction program when the financial institution's server malfunctions, thereby reducing the hardware resources required for monitoring the pre-processing transaction program. Furthermore, if the adjusted time interval is greater than the preset time interval, it can be determined that the cause of the malfunction is a failure of the financial institution's server, enabling quick and efficient identification of the cause when users are unable to successfully complete transactions. Attached Figure Description

[0029] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0030] Figure 1 This is a network architecture diagram corresponding to the application scenario provided in the embodiments of this application;

[0031] Figure 2 This is a flowchart illustrating the monitoring method for the pre-transaction procedure provided in Embodiment 1 of this application;

[0032] Figure 3 This is a flowchart illustrating the monitoring method for the pre-transaction procedure provided in Embodiment 2 of this application;

[0033] Figure 4 This is a schematic diagram of the structure of the monitoring device for the pre-transaction process provided in Embodiment 3 of this application;

[0034] Figure 5This is a schematic diagram of the structure of an electronic device provided according to Embodiment 4 of this application.

[0035] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0036] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0037] The collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0038] The prior art involved in this application will be described in detail and analyzed below.

[0039] When users encounter problems while using treasury management applications, they need to log in to each front-end server separately to check the progress of the front-end transaction program and the status of the front-end server, which is inefficient. Although a scheduled monitoring program can be installed on the client device to periodically check the front-end transaction program, when the user has multiple financial institution accounts and multiple front-end transaction programs installed on the front-end server, scheduled monitoring still consumes a lot of hardware resources, affecting the performance of the client device, and thus affecting the operation of the treasury management application, reducing the user experience.

[0040] In summary, existing technologies suffer from problems such as low efficiency in determining the cause of failures and the need for a large amount of hardware resources to monitor the pre-transaction process.

[0041] The monitoring method, apparatus, equipment, medium, and program products for pre-transaction procedures provided in this application aim to solve the aforementioned technical problems of the prior art. In addressing the problems in the prior art, the inventors, through inventive research, have found that to reduce the hardware resources consumed by the pre-transaction procedure and improve user experience, the monitoring frequency of the pre-transaction procedure needs to be adjusted based on the actual transactions conducted within it. For a user to successfully complete a transaction, the cooperation of the treasury management software, client devices, multi-bank routing servers, pre-transaction servers, pre-transaction procedures, and the financial institution's servers is required. The financial institution's server is the final link for successful transactions; if the financial institution's server malfunctions, the user cannot successfully complete a transaction. Therefore, under the premise that the user cannot successfully complete a transaction, by increasing the time interval for monitoring the pre-transaction procedures of financial institutions that have experienced server malfunctions, the hardware resources of the client devices can be saved, ensuring the normal operation of the treasury management software and not affecting the user's transactions under accounts at other financial institutions that have not experienced server malfunctions. Simultaneously, the cause of the malfunction can be directly determined during the monitoring of the pre-transaction procedure, improving the efficiency of determining the cause of the malfunction.

[0042] Therefore, the inventor proposes the technical solution of this application, which involves acquiring the running status information of the pre-transaction program at preset time intervals; in response to acquiring the running status information of the pre-transaction program, determining whether the pre-transaction program is running normally based on the running status information; in response to the pre-transaction program running normally, acquiring transaction-related information corresponding to the pre-transaction program within the preset time interval; the transaction-related information is transaction-related information generated by the user through the pre-transaction program on the financial institution's server; adjusting the preset time interval based on the transaction-related information to obtain the adjusted time interval; in response to the adjusted time interval being greater than the preset time interval, determining that the cause of the fault is a fault in the server of the financial institution to which the pre-transaction program belongs, and continuing to acquire the running status information of the pre-transaction program at the adjusted time interval to continue monitoring the pre-transaction program. Since transaction-related information is generated by users conducting transactions on the servers of financial institutions through pre-processing transaction programs, it reflects the operational status of the financial institution's servers. Therefore, the preset time interval can be adjusted based on the transaction-related information to ensure that the monitoring of the pre-processing transaction program matches the operational status of the financial institution's server. This avoids ineffective monitoring of the pre-processing transaction program when the financial institution's server malfunctions, thereby reducing the hardware resources required for monitoring the pre-processing transaction program. Furthermore, if the adjusted time interval is greater than the preset time interval, it can be determined that the cause of the malfunction is a failure of the financial institution's server, enabling quick and efficient identification of the cause when users are unable to successfully complete transactions.

[0043] The network architecture and application scenarios of the monitoring method for the pre-transaction process provided in the embodiments of this application will be introduced below.

[0044] Figure 1 This is a network architecture diagram corresponding to the application scenario provided in the embodiments of this application. For example... Figure 1 As shown in the figure, the network architecture corresponding to an application scenario provided in this application embodiment includes: a client device 10, a multi-bank routing server 11, at least one front-end server 12, and a financial institution's server 13.

[0045] The client device 10 is equipped with financial management software and is connected to the multi-line routing server 11. The multi-line routing server 11 is used to connect the client device to the front-end servers 12 of different financial institutions.

[0046] The front-end server 12 has front-end trading programs installed on it from various financial institutions. The front-end server 12 communicates with the server 13 of the financial institution to which the front-end trading program belongs through its installed front-end trading programs. The front-end server 12 can access the financial institution's server 13 to conduct transactions through the front-end trading programs.

[0047] Client device 10 acquires the running status information of the front-end transaction program at preset time intervals. Upon acquiring the running status information, it determines whether the front-end transaction program is running normally. If the front-end transaction program is running normally, it acquires the transaction-related information corresponding to the front-end transaction program within the preset time interval. The transaction-related information is transaction-related information generated when a user conducts transactions on the financial institution's server through the front-end transaction program.

[0048] Client device 10 adjusts the preset time interval according to transaction-related information to obtain the adjusted time interval; in response to the adjusted time interval being greater than the preset time interval, it determines that the cause of the fault is a fault in the server of the financial institution to which the front-end transaction program belongs, and continues to obtain the running status information of the front-end transaction program according to the adjusted time interval in order to continue monitoring the front-end transaction program.

[0049] The embodiments of this application will now be described with reference to the accompanying drawings. The embodiments described below do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0050] Example 1

[0051] Figure 2 This is a flowchart illustrating the monitoring method for the pre-transaction process provided in Embodiment 1 of this application. Figure 2 As shown, the executing entity of this application is a monitoring device for the pre-transaction process, which is located in an electronic device. The monitoring method for the pre-transaction process provided in this embodiment includes steps 201 to 205.

[0052] Step 201: Obtain the running status information of the preceding transaction program according to the preset time interval.

[0053] In this embodiment, the electronic device can be a client device in the network architecture, or it can be other devices that communicate and connect with the client device and the multi-bank routing server.

[0054] In this embodiment, the front-end server can be assigned to different financial institutions, and one or more front-end transaction programs belonging to the same financial institution can be installed on the front-end server.

[0055] In this embodiment, each front-end server may be equipped with a monitoring program to monitor each front-end transaction program. Electronic devices can access the monitoring program on each front-end server through the multi-bank routing server to obtain the running status information of each front-end transaction program.

[0056] Step 202: In response to obtaining the running status information of the front-end transaction program, determine whether the front-end transaction program is running normally based on the running status information.

[0057] In this embodiment, the running status information may include information that the front-end transaction program is in a normal running state or information that the front-end transaction program is in an abnormal running state. After receiving the running status information, the electronic device can read from the running status information whether the front-end transaction program is running normally.

[0058] For example, the running status information can be uninterruptible sleep, runnable, sleeping, traced or stopped, zombie, etc. The electronic device can determine that the front-end transaction program is running normally when the running status information is "running," and determine that the front-end transaction program is not running normally when the running status information is not "running."

[0059] Step 203: In response to the normal operation of the pre-transaction process, obtain the transaction-related information corresponding to the pre-transaction process within a preset time interval; the transaction-related information is the transaction-related information generated by the user through the pre-transaction process on the financial institution's server.

[0060] In this embodiment, users conduct transactions under their accounts at various financial institutions through financial management software. These transactions can include checking account balances, account status, account transaction history, and initiating transfers. Users can initiate transaction requests on the financial management software. These requests can include the financial institution to which the transaction pertains. After receiving the transaction request, the multi-bank routing server forwards it to the front-end server containing the corresponding front-end transaction program of that financial institution. Upon receiving the request, the front-end server accesses the financial institution's server by invoking the front-end transaction program and forwards the request to the financial institution's server. Once the financial institution's server receives the transaction request, it can execute the transaction under the user's account and generate a transaction response. This response is then returned to the client device sequentially through the front-end transaction program and the multi-bank routing platform, and finally displayed in the financial management software. For example, if the user's transaction request is to check their account balance, the transaction response will display the user's account balance.

[0061] In this embodiment, transaction-related information may include the number of times the user initiates a transaction request, the number of times the financial institution's server responds to a transaction request, the number of successful transactions, and the number of failed transactions in the above transaction process.

[0062] Step 204: Adjust the preset time interval based on transaction-related information to obtain the adjusted time interval.

[0063] In this embodiment, when the number of failed transactions exceeds the number of successful transactions, a preset time interval can be added. For example, the preset time interval is 600 seconds. If, within 600 seconds, the transaction-related information of the preceding transaction procedure shows 50 transactions, 20 successful transactions, and 30 failed transactions, then the preset time interval can be increased to make the adjusted time interval greater than 600 seconds, for example, it can be 900 seconds. Optionally, the adjustment ratio of the preset time interval can be positively correlated with the ratio of failed transactions to successful transactions. For example, in the above example, if the ratio of failed transactions to successful transactions is 3 / 2, then the preset time interval can be increased to 3 / 2 of the original, resulting in an adjusted time interval of 900 seconds.

[0064] Here, since the running status information of the front-end transaction program can be obtained, and it has been determined that the running status of the front-end transaction program is normal, the reason for the transaction failure is unrelated to the multi-bank routing server, the front-end server, and the front-end transaction program. Therefore, it can be determined that the failure to successfully complete the transaction is due to a server failure of the financial institution. Thus, increasing the preset time interval can save hardware resources while continuously monitoring the running status of the front-end transaction program.

[0065] In this embodiment, when the number of failed transactions is less than the number of successful transactions, but the number of failed transactions is greater than a first preset number, the preset time interval can be reduced. For example, if the preset time interval is 600 seconds, and within 600 seconds, the transaction-related information of the preceding transaction procedure shows 50 transactions, 30 successful transactions, and 20 failed transactions, then the preset time interval can be reduced so that the adjusted time interval is less than 600 seconds, for example, it can be 400 seconds. The first preset number can be 0.

[0066] Optionally, the adjustment ratio of the preset time interval can be positively correlated with the ratio of the number of failed transactions to the number of successful transactions. For example, in the example above, the ratio of the number of failed transactions to the number of successful transactions is 2 / 3, so the preset time interval can be increased to 2 / 3 of the original, resulting in an adjusted time interval of 400s.

[0067] Here, when the number of successful transactions is greater than the number of failed transactions, it can be determined that the financial institution's server is basically normal. However, if the number of failed transactions is greater than the first preset number, it means that some transactions still cannot be completed successfully. Therefore, in order to avoid an increase in the number of unsuccessful transactions in the future, the preset time interval can be reduced to obtain transaction-related information more frequently and determine the cause of the failure in a timely manner.

[0068] Step 205: In response to the adjusted time interval being greater than the preset time interval, the cause of the fault is determined to be a fault in the server of the financial institution to which the front-end transaction program belongs. The system continues to acquire the running status information of the front-end transaction program according to the adjusted time interval in order to continue monitoring the front-end transaction program.

[0069] In this embodiment, if the adjusted time interval is greater than the preset time interval, it indicates a reduction in the monitoring frequency of the front-end transaction process. Since the operational status information of the front-end transaction process can be obtained, and its operational status has been determined to be normal, the reason for the transaction failure is unrelated to the multi-bank routing server, the front-end server, and the front-end transaction process. Therefore, it can be determined that the failure to successfully complete the transaction is due to a server failure at the financial institution. Simultaneously, the operational status information of the front-end transaction process continues to be obtained according to the adjusted time interval, and the front-end transaction process continues to be monitored.

[0070] The monitoring method for the pre-transaction process provided in this embodiment acquires the running status information of the pre-transaction process at preset time intervals; in response to acquiring the running status information of the pre-transaction process, it determines whether the pre-transaction process is running normally based on the running status information; in response to the pre-transaction process running normally, it acquires the transaction-related information corresponding to the pre-transaction process within the preset time interval; the transaction-related information is transaction-related information generated by the user through the pre-transaction process on the financial institution's server; it adjusts the preset time interval based on the transaction-related information to obtain the adjusted time interval; in response to the adjusted time interval being greater than the preset time interval, it determines that the cause of the fault is a fault in the server of the financial institution to which the pre-transaction process belongs, and continues to acquire the running status information of the pre-transaction process at the adjusted time interval to continue monitoring the pre-transaction process. Since transaction-related information is generated by users conducting transactions on the servers of financial institutions through pre-processing transaction programs, it reflects the operational status of the financial institution's servers. Therefore, the preset time interval can be adjusted based on the transaction-related information to ensure that the monitoring of the pre-processing transaction program matches the operational status of the financial institution's server. This avoids ineffective monitoring of the pre-processing transaction program when the financial institution's server malfunctions, thereby reducing the hardware resources required for monitoring the pre-processing transaction program. Furthermore, if the adjusted time interval is greater than the preset time interval, it can be determined that the cause of the malfunction is a failure of the financial institution's server, enabling quick and efficient identification of the cause when users are unable to successfully complete transactions.

[0071] Optionally, the running status information includes a running status or a stopped running status; when the running status information is a running status, the running status information also includes running parameters. Furthermore, step 202, "determine whether the pre-transaction program is running normally based on the running status information," is further refined into steps 301 to 302.

[0072] Step 301: In response to the running status information being in a stopped running state, it is determined that the pre-transaction program is not running normally.

[0073] In this embodiment, when the running status information is "stop running", it means that the front-end transaction program is not running on the front-end server. Therefore, it is determined that the front-end transaction program is not running normally.

[0074] Step 302: In response to the running status information indicating that the system is running, determine whether the pre-transaction program is running normally based on the running parameters.

[0075] In this embodiment, even if the running status information of the pre-trading program is "running", the pre-trading program may not be running normally. Therefore, it is necessary to determine whether the pre-trading program is running normally based on its running parameters.

[0076] Specifically, the operating parameters of the front-end trading program may include memory usage. Furthermore, the electronic device can determine that the front-end trading program is not running normally when its memory usage is greater than a preset memory amount, and determine that the front-end trading program is running normally when its memory usage is less than or equal to the preset memory amount.

[0077] The monitoring method for the pre-trading program provided in this embodiment includes a running status or a stopped running status. When the running status is running, the running status information also includes running parameters. By responding to a stopped running status, it is determined that the pre-trading program is not running normally; by responding to a running status, it is determined whether the pre-trading program is running normally based on the running parameters. Since the pre-trading program is determined to be not running normally when its running status is stopped, and its running status is determined to be running normally based on the running parameters when its running status is running, it can quickly determine if the pre-trading program is not running normally, and at the same time, it can more accurately determine whether the pre-trading program is running normally based on the running parameters.

[0078] Optionally, based on any of the above embodiments, step 302, "determining whether the pre-transaction procedure is running normally according to the operating parameters", may be further refined to include steps 401 to 403.

[0079] Step 401: Obtain the preset operating parameters and conditions corresponding to the pre-transaction program.

[0080] In this embodiment, the preset operating parameters corresponding to the pre-processing transaction program may include at least one of the following: CPU utilization rate and memory usage.

[0081] Step 402: In response to the fact that the operating parameters do not meet the preset operating parameter conditions, it is determined that the pre-transaction program is not running normally.

[0082] Step 403: In response to the fact that the operating parameters meet the preset operating parameter conditions, it is determined that the pre-transaction program is running normally.

[0083] In this embodiment, when there is only one preset operating parameter, if the operating parameters of the preceding trading program do not meet the preset operating parameters, it is determined that the preceding trading program is not running normally. If the operating parameters of the preceding trading program meet the preset operating parameters, it is determined that the preceding trading program is running normally. When there are multiple preset operating parameters, the running status of the preceding trading program can be determined based on the number of preset operating parameters that the preceding trading program meets.

[0084] Optionally, the operating parameters include CPU utilization and memory usage. Step 402 is further refined into step 4021, and step 403 is further refined into step 4031.

[0085] Step 4021: In response to determining that at least one of the CPU utilization rate is greater than the preset CPU utilization rate and the memory utilization rate is greater than the preset memory utilization rate, it is determined that the front-end transaction program is not running normally.

[0086] In this embodiment, the preset CPU utilization rate is the CPU utilization rate pre-allocated to the front-end trading program, and the preset memory amount is the memory usage pre-allocated to the front-end trading program. If the CPU utilization rate of the front-end trading program is greater than the preset CPU utilization rate, and / or the memory usage of the front-end trading program is greater than the preset memory amount, then the front-end trading program may be experiencing memory overflow or overload operation. Therefore, it is determined that the front-end trading program is not running normally.

[0087] Step 4031: In response to determining that the CPU utilization rate is less than or equal to the preset CPU utilization rate and the memory usage is less than or equal to the preset memory usage, the pre-transaction program is determined to be running normally.

[0088] In this embodiment, if the CPU utilization rate of the pre-processing transaction program is less than or equal to the preset CPU utilization rate and the memory usage is less than or equal to the preset memory usage, then the running status parameters of the pre-processing transaction program meet expectations. Therefore, it is determined that the pre-processing transaction program is running normally.

[0089] In this embodiment, the operating parameters include CPU utilization and memory usage. In response to determining that at least one of the following is true, the pre-processing transaction is not running normally: CPU utilization is greater than a preset CPU utilization, and memory usage is greater than a preset memory amount. In response to determining that CPU utilization is less than or equal to a preset CPU utilization and memory usage is less than or equal to a preset memory amount, the pre-processing transaction is running normally. Because the running status of the pre-processing transaction is determined based on the magnitude of CPU utilization and the preset CPU utilization, as well as the magnitude of memory usage and the preset memory amount, the running status of the pre-processing transaction can be accurately determined.

[0090] Optionally, based on any of the above embodiments, the transaction-related information includes the transaction failure rate, and step 204, "adjusting the preset time interval according to the transaction-related information", is further refined to include steps 2041 to 2042.

[0091] Step 2041: Obtain the first preset threshold that has a mapping relationship with the pre-stored mapping relationship between the pre-existing transaction program and the first preset threshold.

[0092] In this embodiment, different pre-transaction procedures can execute different transactions. Therefore, different pre-transaction procedures can be mapped to different first preset thresholds. For example, querying account transaction history can have a different first preset threshold than querying account balance, and initiating a transfer can have a different first preset threshold than querying account transaction history.

[0093] In this embodiment, it is understood that if the server of the financial institution to which the pre-transaction procedure belongs malfunctions, transactions conducted in the pre-transaction procedure will fail. Therefore, the first preset threshold is used to determine whether the server of the financial institution to which the pre-transaction procedure belongs is operating normally.

[0094] Step 2042: In response to the transaction failure rate being greater than or equal to the corresponding first preset threshold, increase the preset time interval.

[0095] In this embodiment, if the transaction failure rate is greater than or equal to the first preset threshold corresponding to the pre-transaction procedure, it indicates that the server of the financial institution to which the pre-transaction procedure belongs has malfunctioned. Since the transaction failure is caused by the server of the financial institution to which the pre-transaction procedure belongs, it is only meaningful to monitor the pre-transaction procedure after the server of the financial institution to which the pre-transaction procedure belongs has returned to normal. Only then can the malfunction of the pre-transaction procedure be identified in time, and staff be notified in time to handle it. Therefore, in order to save hardware resources, the preset time interval can be increased.

[0096] Optionally, in this embodiment, when the transaction failure rate is less than or equal to the first preset threshold corresponding to the pre-transaction procedure, a preset time interval can be maintained, and the running status information of the pre-transaction procedure can continue to be obtained according to the preset time interval, so as to continue to monitor the pre-transaction procedure.

[0097] The monitoring method for the pre-transaction process provided in this embodiment obtains the first preset threshold that is mapped to the pre-transaction process from a pre-stored mapping relationship between pre-transaction processes and the first preset threshold; and increases the preset time interval in response to a transaction failure rate greater than or equal to the corresponding first preset threshold. Since the preset time interval is increased when the transaction failure rate of a transaction on the transaction process is greater than or equal to the first preset threshold corresponding to the pre-transaction process, it can increase the monitoring time interval of the pre-transaction process when the server of the financial institution to which the pre-transaction process belongs fails, reducing the number of times the pre-transaction process needs to be monitored and saving hardware resources.

[0098] Optionally, based on any of the above embodiments, step 501 is included before step 2041.

[0099] Step 501: Construct a mapping relationship based on the preset importance of transactions performed by the preceding transaction procedure; the preset importance is positively correlated with the first preset threshold.

[0100] In this embodiment, the preset importance is a user-defined level representing the importance of each transaction performed by the preceding transaction procedures. For example, the importance of initiating a transfer can be higher than the importance of querying an account balance. Here, the preset importance is used to establish a mapping relationship between the preceding transaction procedures and a first preset threshold. The higher the preset importance of a transaction performed by a preceding transaction procedure, the lower the corresponding first preset threshold can be. This is because, for more important transactions, even if the server of the financial institution to which the preceding transaction procedure belongs fails, the failure needs to be detected promptly to ensure the preceding transaction procedure remains operational. Once the server of the financial institution to which the preceding transaction procedure belongs is restored, the user can immediately conduct transactions normally.

[0101] The monitoring method for pre-transaction procedures provided in this embodiment constructs a mapping relationship based on the preset importance of the transactions performed by the pre-transaction procedures; the preset importance is positively correlated with a first preset threshold. Since the preset importance is positively correlated with the first preset threshold, the preset time interval for monitoring pre-transaction procedures with higher preset importance is less likely to be increased, while the preset time interval for monitoring pre-transaction procedures with lower preset importance is more likely to be increased. Therefore, it can reduce hardware resource consumption while promptly detecting faults in pre-transaction procedures for important transactions.

[0102] Optionally, based on any of the above embodiments, step 601 is also included.

[0103] Step 601: In response to the transaction failure rate being greater than or equal to the second preset threshold, the running state of the pre-transaction program is switched to the stopped running state; the second preset threshold is greater than the first preset threshold.

[0104] In this embodiment, the second preset threshold is greater than the first preset threshold. For example, the second preset threshold can be a number greater than 0.5, such as 0.9, 1, etc.

[0105] In this embodiment, if a transaction failure rate greater than or equal to a first preset threshold indicates that the transaction initiated by the user initiating the pre-transaction procedure may fail, then a transaction failure rate greater than or equal to a second preset threshold indicates that the transaction initiated by the user initiating the pre-transaction procedure is highly likely to fail. Therefore, to conserve the performance of the client device and prevent users from initiating transactions knowing that the transaction is highly likely to fail, the running state of the pre-transaction procedure can be controlled to switch to a stopped running state. Specifically, the electronic device can send a control command through a multi-bank routing server to the pre-transaction server where the pre-transaction procedure is located, instructing the pre-transaction server to switch the running state of the pre-transaction procedure to a stopped running state.

[0106] The monitoring method for the pre-processing transaction program provided in this embodiment controls the running state of the pre-processing transaction program to switch to a stopped running state in response to a transaction failure rate greater than or equal to a second preset threshold; the second preset threshold is greater than a first preset threshold. Since the running state of the pre-processing transaction program is switched to a stopped running state when the transaction failure rate is greater than or equal to the second preset threshold, it can prevent users from initiating transactions that cannot be successfully completed, save hardware resources of the client device, and improve the performance of the client device.

[0107] Example 2

[0108] The monitoring method for the pre-transaction program provided in this embodiment, based on Embodiment 1, further includes step 701 after step 202 "determine whether the pre-transaction program is running normally based on the running status information".

[0109] Step 701: In response to the failure of the pre-trading process to run normally, the cause of the failure is determined to be a failure of the pre-trading process.

[0110] In this embodiment, since the pre-transaction program is running normally, and users need to access the corresponding financial institution's server through the pre-transaction program to conduct transactions through the treasury management software, if the user cannot successfully conduct a transaction when the pre-transaction program is not running normally, the cause of the failure is determined to be a failure of the pre-transaction program.

[0111] The monitoring method for the pre-trading process provided in this embodiment determines the cause of the failure as a malfunction in the pre-trading process by responding to the pre-trading process not running normally. Since the cause of the failure is determined as a malfunction in the pre-trading process when it does not run normally, the reason for the inability to successfully complete a transaction can be quickly identified.

[0112] Figure 3 This is a flowchart illustrating the monitoring method for the pre-transaction procedure provided in Embodiment 2 of this application, as shown below. Figure 3 As shown, the monitoring method for the pre-transaction process provided in this embodiment, based on any of the above embodiments, further includes steps 801 to 803 after step 201.

[0113] Step 801: In response to the inability to obtain the running status information of the front-end transaction program, determine whether it is possible to communicate with the multi-bank routing server; the multi-bank routing server establishes a communication connection with the front-end server to which the front-end transaction program belongs.

[0114] In this embodiment, the electronic device communicates with the front-end server where the front-end transaction program resides through a communication interface with the multi-bank routing server, thereby obtaining the running status information of the front-end transaction program. Therefore, if the electronic device cannot obtain the running status information of the front-end transaction program, it can be determined whether the electronic device can communicate with the multi-bank routing server.

[0115] Step 802: In response to the ability to communicate with the multi-bank routing server, determine that the cause of the failure is a failure of the front-end server to which the front-end transaction program belongs.

[0116] In this embodiment, if the electronic device can communicate with the multi-bank routing server, the network connection failure between the electronic device and the multi-bank routing server can be ruled out. Therefore, the cause of the failure is determined to be a failure of the front-end server to which the front-end transaction program belongs.

[0117] Step 803: In response to the inability to communicate with the multi-bank routing server, the cause of the failure is determined to be a network connectivity failure.

[0118] In this embodiment, if the electronic device cannot communicate with the multi-bank routing server, the cause of the failure is determined to be a network connection failure.

[0119] The monitoring method for the pre-transaction process provided in this embodiment determines whether communication with a multi-bank routing server is possible in response to the inability to obtain the pre-transaction process's running status information; the multi-bank routing server establishes a communication connection with the pre-transaction process's associated server; if communication with the multi-bank routing server is possible, the cause of the fault is determined to be a failure of the pre-transaction process's associated server; if communication with the multi-bank routing server is not possible, the cause of the fault is determined to be a network connection failure. Since the cause of the fault is determined based on whether the electronic device can communicate with the multi-bank routing server when running status information is unavailable, the cause of the fault can be accurately determined to be either a network connection failure or a pre-transaction server failure.

[0120] Optionally, based on any of the above embodiments, step 901 is also included.

[0121] Step 901: In response to determining the cause of the fault, output alarm information; the alarm information includes the cause of the fault; the cause of the fault includes a fault in the server of the financial institution to which the front-end transaction program belongs, a fault in the front-end transaction program, a fault in the front-end server to which the front-end transaction program belongs, or a fault in the network connection.

[0122] In this embodiment, during the monitoring of the pre-transaction process, the cause of the fault can also be determined. Therefore, in response to the determination of the cause of the fault, an alarm message can be output. The alarm message includes the cause of the fault and is used to remind staff to verify, confirm, maintain, or report the cause of the fault.

[0123] In this embodiment, the cause of the failure includes at least one of the following: a server failure of the financial institution to which the pre-transaction procedure belongs, a failure of the pre-transaction procedure itself, a failure of the pre-transaction server to which the pre-transaction procedure belongs, or a network connection failure. Therefore, when a user is unable to successfully complete a transaction, the electronic device can output an alarm message to help the user quickly determine the cause of the failure.

[0124] The monitoring method for the pre-transaction process provided in this embodiment outputs alarm information in response to determining the cause of the failure. The alarm information includes the cause of the failure, which may include a failure of the server of the financial institution to which the pre-transaction process belongs, a failure of the pre-transaction process itself, a failure of the pre-transaction server to which the pre-transaction process belongs, or a network connection failure. Because the alarm information is output after the cause of the failure is determined, the cause of the failure can be quickly determined when a transaction cannot be successfully completed, without requiring the user to log in to each pre-transaction service sequentially to check the running status of each pre-transaction process.

[0125] Example 3

[0126] Figure 4 This is a schematic diagram of the monitoring device for the pre-transaction process provided in Embodiment 3 of this application. Figure 4 As shown, the monitoring device 40 for the pre-transaction process provided in this embodiment includes:

[0127] The first acquisition module 41 is used to acquire the running status information of the preceding transaction program according to a preset time interval;

[0128] The determination module 42 is used to determine whether the front-end transaction program is running normally based on the obtained running status information in response to the acquisition of the running status information.

[0129] The second acquisition module 43 is used to acquire transaction-related information corresponding to the front-end transaction program within a preset time interval in response to the normal operation of the front-end transaction program; the transaction-related information is transaction-related information generated by the user through the front-end transaction program on the financial institution's server;

[0130] Adjustment module 44 is used to adjust the preset time interval according to transaction-related information to obtain the adjusted time interval;

[0131] The monitoring module 45 is used to determine that the server of the financial institution to which the front-end transaction program belongs has failed in response to the adjusted time interval being greater than the preset time interval, and to continue to obtain the running status information of the front-end transaction program according to the adjusted time interval in order to continue to monitor the front-end transaction program.

[0132] Optionally, the running status information is either in a running state or in a stopped running state; when the running status information is in a running state, the running status information also includes running parameters; the determining module 42 is specifically used to: determine that the pre-transaction program is not running normally in response to the running status information being in a stopped running state; and determine whether the pre-transaction program is running normally based on the running parameters in response to the running status information being in a running state.

[0133] Optionally, the determining module 42 is further configured to: obtain the preset operating parameter conditions corresponding to the pre-trading program; determine that the pre-trading program is not running normally in response to the operating parameters not meeting the preset operating parameter conditions; and determine that the pre-trading program is running normally in response to the operating parameters meeting the preset operating parameter conditions.

[0134] Optionally, the operating parameters include CPU utilization and memory usage; the determination module 42 is further configured to: determine that the front-end trading program is not running normally in response to determining that the CPU utilization is greater than a preset CPU utilization and the memory usage is greater than a preset memory amount; and determine that the front-end trading program is running normally in response to determining that the CPU utilization is less than or equal to a preset CPU utilization and the memory usage is less than or equal to a preset memory amount.

[0135] Optionally, the transaction-related information includes the transaction failure rate; the adjustment module 44 is specifically used to: obtain the first preset threshold that has a mapping relationship with the pre-stored pre-existing transaction program from the mapping relationship between the pre-stored pre-existing transaction program and the first preset threshold; and increase the preset time interval in response to the transaction failure rate being greater than the corresponding first preset threshold.

[0136] Optionally, the monitoring device for the pre-trading program further includes a construction module, which is used to: construct a mapping relationship based on the preset importance of the transactions performed by the pre-trading program; the preset importance is positively correlated with a first preset threshold.

[0137] Optionally, the monitoring device for the pre-trading program further includes a control module, which is used to: switch the running state of the pre-trading program to a stopped running state in response to the transaction failure rate being greater than a second preset threshold; the second preset threshold being greater than a first preset threshold.

[0138] Optionally, the monitoring device for the front-end trading program further includes a second determining module, which is used to: determine the cause of the failure as a failure of the front-end trading program in response to the front-end trading program not operating normally.

[0139] Optionally, the monitoring device for the pre-transaction procedure further includes a third determining module, which is used to: determine whether communication with the multi-bank routing server is possible in response to the inability to obtain the running status information of the pre-transaction procedure; the multi-bank routing server communicates with the pre-transaction server to which the pre-transaction procedure belongs; determine that the cause of the failure is a failure of the pre-transaction server to which the pre-transaction procedure belongs in response to the ability to communicate with the multi-bank routing server; and determine that the cause of the failure is a network connection failure in response to the inability to communicate with the multi-bank routing server.

[0140] Optionally, the monitoring device for the front-end transaction program also includes an alarm module, which is used to: output alarm information in response to determining the cause of the fault; the alarm information includes the cause of the fault; the cause of the fault includes a fault in the server of the financial institution to which the front-end transaction program belongs, a fault in the front-end transaction program, a fault in the front-end server to which the front-end transaction program belongs, or a fault in the network connection.

[0141] The monitoring device for the pre-transaction process provided in this embodiment can execute the monitoring method for the pre-transaction process provided in any of the above embodiments. The specific implementation and principle are similar, and will not be repeated here.

[0142] Example 4

[0143] Figure 5 This is a schematic diagram of the structure of an electronic device according to Embodiment 4 of this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes: a processor 52, and a memory 51 communicatively connected to the processor 52;

[0144] Memory 51 stores instructions executed by the computer;

[0145] The processor 52 executes the computer execution instructions stored in the memory 51 to implement the monitoring method of the pre-transaction program provided in any of the above embodiments. The specific implementation method and principle are similar and will not be described again here.

[0146] Optionally, the electronic device 50 also includes a transceiver, which is communicatively connected to the memory and processing unit for sending and receiving data.

[0147] The memory 51, processor 52, and transceiver can communicate and interconnect via a bus. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be categorized into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0148] The memory 51 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk, etc.

[0149] In an exemplary embodiment, the electronic device 50 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0150] Embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions. When executed by a processor, these instructions are used to implement the monitoring method for the pre-transaction procedure provided in any of the above embodiments. Exemplarily, the computer-readable storage medium may be a read-only memory (ROM), random access memory (RAM), magnetic tape, floppy disk, or optical data storage device, etc.

[0151] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the monitoring method for the pre-transaction procedure as provided in any of the above embodiments.

[0152] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the module division in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple modules can be combined, or integrated into another system, or some features can be ignored or not executed.

[0153] Furthermore, unless otherwise specified, the functional modules in the various embodiments of this application can be integrated into one module, or each module can exist physically separately, or two or more modules can be integrated together. The integrated modules described above can be implemented in hardware or as software program modules.

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

[0155] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0156] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0157] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for monitoring a pre-transaction process, characterized in that, include: Obtain the running status information of the preceding transaction program at preset time intervals; In response to obtaining the running status information of the front-end transaction program, determine whether the front-end transaction program is running normally based on the running status information; In response to the normal operation of the pre-transaction procedure, the system acquires transaction-related information corresponding to the pre-transaction procedure within a preset time interval; the transaction-related information is transaction-related information generated by the user through the pre-transaction procedure on the financial institution's server. The preset time interval is adjusted based on the transaction-related information to obtain the adjusted time interval; If the adjusted time interval is greater than the preset time interval, the cause of the failure is determined to be a server failure of the financial institution to which the pre-transaction program belongs. The system continues to acquire the running status information of the pre-transaction program according to the adjusted time interval in order to continue to monitor the pre-transaction program. The transaction-related information includes the transaction failure rate; The step of adjusting the preset time interval based on the transaction-related information includes: Obtain the first preset threshold that has a mapping relationship with the previous transaction program from the pre-stored mapping relationship between the previous transaction program and the first preset threshold. In response to the transaction failure rate being greater than or equal to the corresponding first preset threshold, the preset time interval is increased.

2. The method according to claim 1, characterized in that, The running status information indicates whether the system is running or stopped; when the running status information indicates that the system is running, the running status information also includes running parameters. The step of determining whether the pre-transaction program is running normally based on the running status information includes: In response to the running status information indicating a stopped running state, it is determined that the pre-transaction procedure is not running normally; In response to the running status information indicating that the system is running, the system determines whether the pre-transaction program is running normally based on the running parameters.

3. The method according to claim 2, characterized in that, The step of determining whether the pre-transaction program is running normally based on the operating parameters includes: Obtain the preset operating parameters and conditions corresponding to the pre-processing transaction program; In response to the fact that the operating parameters do not meet the preset operating parameter conditions, it is determined that the pre-transaction program is not running normally; In response to the fact that the operating parameters meet the preset operating parameter conditions, it is determined that the pre-transaction program is operating normally.

4. The method according to claim 3, characterized in that, The operating parameters include CPU utilization and memory usage. The response to the operating parameters not meeting the preset operating parameter conditions, determining that the pre-transaction program is not running normally, includes: In response to determining that at least one of the CPU utilization rate is greater than the preset CPU utilization rate and the memory usage is greater than the preset memory usage, it is determined that the front-end transaction program is not running normally; The step of determining that the pre-processing transaction is running normally in response to the operating parameters meeting the preset operating parameter conditions includes: In response to determining that the CPU utilization rate is less than or equal to the preset CPU utilization rate and the memory usage is less than or equal to the preset memory usage, the pre-processing transaction program is confirmed to be running normally.

5. The method according to claim 1, characterized in that, Before obtaining the first preset threshold that has a mapping relationship with the previous transaction program from the pre-stored mapping relationship between the previous transaction program and the first preset threshold, the method further includes: The mapping relationship is constructed based on the preset importance of the transactions performed in the preceding transaction process; the preset importance is positively correlated with the first preset threshold.

6. The method according to claim 1, characterized in that, Also includes: In response to the transaction failure rate being greater than or equal to a second preset threshold, the running state of the pre-transaction program is switched to a stopped running state; The second preset threshold is greater than the first preset threshold.

7. The method according to claim 1, characterized in that, After determining whether the pre-transaction program is running normally based on the running status information, the process further includes: In response to the failure of the front-end trading process, the cause of the failure was determined to be a malfunction in the front-end trading process.

8. The method according to claim 7, characterized in that, After obtaining the running status information of the preceding transaction program at preset time intervals, the method further includes: In response to the inability to obtain the running status information of the front-end transaction program, it is determined whether communication with the multi-bank routing server is possible; the multi-bank routing server establishes a communication connection with the front-end server to which the front-end transaction program belongs. In response to the ability to communicate with multi-bank routing servers, the cause of the failure was determined to be a failure of the front-end server to which the front-end transaction program belonged; In response to the inability to communicate with the multi-bank routing server, the cause of the failure was determined to be a network connectivity problem.

9. The method according to claim 8, characterized in that, Also includes: In response to determining the cause of the fault, an alarm message is output; the alarm message includes the cause of the fault. The causes of the failure include a failure of the server of the financial institution to which the pre-transaction program belongs, a failure of the pre-transaction program itself, a failure of the pre-transaction server to which the pre-transaction program belongs, or a failure of the network connection.

10. A monitoring device for a pre-transaction process, characterized in that, include: The first acquisition module is used to acquire the running status information of the preceding transaction program at preset time intervals; The determination module is used to determine whether the front-end transaction program is running normally based on the obtained running status information in response to the acquisition of the running status information. The second acquisition module is used to acquire transaction-related information corresponding to the front-end transaction program within a preset time interval in response to the normal operation of the front-end transaction program; the transaction-related information is transaction-related information generated by the user through the front-end transaction program on the server of a financial institution. The adjustment module is used to adjust the preset time interval according to the transaction-related information to obtain the adjusted time interval; The monitoring module is used to determine that the server of the financial institution to which the front-end transaction program belongs has failed when the adjusted time interval is greater than the preset time interval, and to continue to obtain the running status information of the front-end transaction program according to the adjusted time interval, so as to continue to monitor the front-end transaction program. The transaction-related information includes the transaction failure rate; The adjustment module is specifically used to: obtain a first preset threshold that has a mapping relationship with the pre-stored pre-transaction program from the mapping relationship between the pre-stored pre-transaction program and the first preset threshold; and increase the preset time interval in response to the transaction failure rate being greater than or equal to the corresponding first preset threshold.

11. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-9.

13. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1-9.

Images