CN108255629B - Breakpoint data obtaining method and terminal equipment - Google Patents

Breakpoint data obtaining method and terminal equipment Download PDF

Info

Publication number
CN108255629B
CN108255629B CN201710865431.8A CN201710865431A CN108255629B CN 108255629 B CN108255629 B CN 108255629B CN 201710865431 A CN201710865431 A CN 201710865431A CN 108255629 B CN108255629 B CN 108255629B
Authority
CN
China
Prior art keywords
list
tracked
needing
data processing
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201710865431.8A
Other languages
Chinese (zh)
Other versions
CN108255629A (en
Inventor
田正伟
薛艳
张领
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ping An Technology Shenzhen Co Ltd
Original Assignee
Ping An Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ping An Technology Shenzhen Co Ltd filed Critical Ping An Technology Shenzhen Co Ltd
Priority to CN201710865431.8A priority Critical patent/CN108255629B/en
Priority to PCT/CN2018/082495 priority patent/WO2019056736A1/en
Publication of CN108255629A publication Critical patent/CN108255629A/en
Application granted granted Critical
Publication of CN108255629B publication Critical patent/CN108255629B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793Remedial or corrective actions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The invention is suitable for the technical field of data transmission and provides a breakpoint data acquisition method and terminal equipment. The method comprises the following steps: determining a mechanism list needing to be tracked; sending a data processing progress query request to the mechanisms in the list; receiving the returned data processing progress, and recording the data processing progress and the receiving time; generating a mechanism updating list needing to be tracked according to the data processing progress and the mechanism list needing to be tracked; after a first preset time interval, taking an updated mechanism list needing to be tracked as a new mechanism list needing to be tracked, and returning to execute the step of sending a data processing progress query request to the mechanisms in the list; when the system is abnormal, the mechanism update list which is closest to the abnormal time of the system and needs to be tracked is obtained, and the prompt that the system is abnormal and needs to reprocess data is sent to the mechanism in the list, so that breakpoint data can be quickly and simply obtained without rolling back all data, a large amount of time is saved, and the data processing accuracy is improved.

Description

Breakpoint data obtaining method and terminal equipment
Technical Field
The invention belongs to the technical field of data transmission, and particularly relates to a breakpoint data acquisition method and terminal equipment.
Background
At present, the system is abnormal, and more or less data loss exists, which directly causes that the system data is incomplete and the data needs to be rolled back. Rollback (Rollback) refers to the act of data processing error, restoring the data to the last correct state. Taking the example that the system pulls the report data, if the system is abnormal, all the data need to be rolled back, the workload is large, and errors are easy to occur.
Disclosure of Invention
The embodiment of the invention provides a method for acquiring breakpoint data and terminal equipment, and aims to solve the problems that all data need to be rolled back when an existing system is abnormal, the workload is large, and errors are easy to occur.
A first aspect of an embodiment of the present invention provides a method for acquiring breakpoint data, including:
determining a mechanism list needing to be tracked;
sending a data processing progress query request to the mechanisms in the mechanism list needing to be tracked;
receiving a data processing progress returned by a mechanism in a mechanism list needing to be tracked, and recording the data processing progress and a receiving moment;
generating a mechanism updating list needing to be tracked according to the data processing progress and the mechanism list needing to be tracked;
after a first preset time interval, taking the mechanism updating list needing to be tracked as a new mechanism list needing to be tracked, and returning to execute the step of sending a data processing progress query request to the mechanism in the mechanism list needing to be tracked;
when the system is abnormal, acquiring a mechanism update list needing to be tracked, which is nearest to the time when the system is abnormal, and sending a prompt that the system is abnormal and data needs to be reprocessed to a mechanism in the nearest mechanism update list needing to be tracked.
Optionally, generating an updated mechanism list to be tracked according to the data processing progress and the mechanism list to be tracked includes:
judging whether a mechanism for finishing data processing exists according to the data processing progress;
if the mechanism which completes the data processing is judged to be present, the mechanism which completes the data processing is deleted from the mechanism list which needs to be tracked, and a mechanism updating list which needs to be tracked is generated.
Optionally, the determining the mechanism list needing to be tracked includes:
sending a prompt whether data needs to be processed or not to the mechanisms in the prestored mechanism list;
receiving information returned by mechanisms in a pre-stored mechanism list, and determining the mechanism list needing to be tracked according to the information and the pre-stored mechanism list, wherein the information is information for confirming that data needs to be processed or information for confirming that data does not need to be processed.
Optionally, the method for acquiring breakpoint data further includes:
sending a prompt whether the list is correct or not to the mechanisms in the mechanism list needing to be tracked;
if receiving the information which is returned by the mechanism in the mechanism list needing to be tracked and confirms that the list is correct, executing the data processing progress query request sent to the mechanism in the mechanism list needing to be tracked;
if the information for confirming that the list is wrong returned by the first mechanism is received and the list change request sent by the first mechanism is received, whether the list change request accords with a preset list change rule or not is checked, if the list change request accords with the preset list change rule, the mechanism list needing to be tracked is changed according to the list change request, the changed mechanism list needing to be tracked is used as a new mechanism list needing to be tracked, the data processing progress query request is sent to the mechanism in the mechanism list needing to be tracked, and the first mechanism is any one mechanism in the mechanism list needing to be tracked.
Optionally, the method for acquiring breakpoint data further includes:
sending a prompt for returning receipt to the mechanism in the latest mechanism updating list needing to be tracked;
judging whether a receipt returned by a second mechanism is received or not after a second preset time interval, wherein the second mechanism is any one mechanism in the latest mechanism updating list needing to be tracked;
and if the receipt returned by the second mechanism is not received after the second preset time interval, sending a prompt that the data needs to be reprocessed due to system abnormity to the second mechanism again.
A second aspect of the embodiments of the present invention provides a breakpoint data acquisition terminal device, including a memory, a processor, and a computer program that is stored in the memory and is executable on the processor, where the processor implements the following steps when executing the computer program:
determining a mechanism list needing to be tracked;
sending a data processing progress query request to the mechanisms in the mechanism list needing to be tracked;
receiving a data processing progress returned by a mechanism in a mechanism list needing to be tracked, and recording the data processing progress and a receiving moment;
generating a mechanism updating list needing to be tracked according to the data processing progress and the mechanism list needing to be tracked;
after a first preset time interval, taking the mechanism updating list needing to be tracked as a new mechanism list needing to be tracked, and returning to execute the step of sending a data processing progress query request to the mechanism in the mechanism list needing to be tracked;
when the system is abnormal, acquiring a mechanism update list needing to be tracked, which is nearest to the time when the system is abnormal, and sending a prompt that the system is abnormal and data needs to be reprocessed to a mechanism in the nearest mechanism update list needing to be tracked.
Optionally, generating an updated mechanism list to be tracked according to the data processing progress and the mechanism list to be tracked includes:
judging whether a mechanism for finishing data processing exists according to the data processing progress;
if the mechanism which completes the data processing is judged to be present, the mechanism which completes the data processing is deleted from the mechanism list which needs to be tracked, and a mechanism updating list which needs to be tracked is generated.
Optionally, the determining the mechanism list needing to be tracked includes:
sending a prompt whether data needs to be processed or not to the mechanisms in the prestored mechanism list;
receiving information returned by mechanisms in a pre-stored mechanism list, and determining the mechanism list needing to be tracked according to the information and the pre-stored mechanism list, wherein the information is information for confirming that data needs to be processed or information for confirming that data does not need to be processed.
Optionally, the processor, when executing the computer program, further implements the following steps:
sending a prompt whether the list is correct or not to the mechanisms in the mechanism list needing to be tracked;
if receiving the information which is returned by the mechanism in the mechanism list needing to be tracked and confirms that the list is correct, executing the data processing progress query request sent to the mechanism in the mechanism list needing to be tracked;
if the information for confirming that the list is wrong returned by the first mechanism is received and the list change request sent by the first mechanism is received, whether the list change request accords with a preset list change rule or not is checked, if the list change request accords with the preset list change rule, the mechanism list needing to be tracked is changed according to the list change request, the changed mechanism list needing to be tracked is used as a new mechanism list needing to be tracked, the data processing progress query request is sent to the mechanism in the mechanism list needing to be tracked, and the first mechanism is any one mechanism in the mechanism list needing to be tracked.
A third aspect of the embodiments of the present invention provides a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, the computer program implements the steps of the above-mentioned breakpoint data acquisition method.
Compared with the prior art, the embodiment of the invention has the following beneficial effects: the method comprises the steps of determining a mechanism list needing to be tracked, sending a data processing progress query request to mechanisms in the mechanism list needing to be tracked, receiving the data processing progress returned by the mechanisms in the mechanism list needing to be tracked, recording the data processing progress and the receiving time, and generating a mechanism updating list needing to be tracked according to the data processing progress and the mechanism list needing to be tracked; after a first preset time interval, taking the mechanism updating list needing to be tracked as a new mechanism list needing to be tracked, and returning to execute the step of sending a data processing progress query request to the mechanism in the mechanism list needing to be tracked; when the system is abnormal, a mechanism updating list needing to be tracked, which is nearest to the system at the abnormal moment, is obtained, a prompt that the system is abnormal and data needs to be reprocessed is sent to a mechanism in the mechanism updating list needing to be tracked, the broken point data acquisition is quickly and simply completed, all data do not need to be rolled back, a large amount of time is saved, the data processing accuracy is improved, the problems that all data need to be rolled back when the existing system is abnormal, the workload is large and mistakes are easy to occur are solved, the user operation is reduced, the user experience is improved, and the actual application needs are met.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.
Fig. 1 is a schematic flow chart of a method for acquiring breakpoint data according to an embodiment of the present invention;
FIG. 2 is a schematic flow chart of a method for acquiring breakpoint data according to another embodiment of the present invention;
FIG. 3 is a schematic flow chart diagram of a method for fault data acquisition according to yet another embodiment of the present invention;
FIG. 4 is a schematic flow chart diagram of a method for acquiring breakpoint data according to another embodiment of the present invention;
FIG. 5 is a schematic flow chart diagram of a method for acquiring breakpoint data according to another embodiment of the present invention;
fig. 6 is a schematic block diagram of a breakpoint data acquisition terminal device according to an embodiment of the present invention;
fig. 7 is a schematic block diagram of a breakpoint data acquisition procedure provided in an embodiment of the present invention.
Detailed Description
In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail.
In order to explain the technical means of the present invention, the following description will be given by way of specific examples.
Referring to fig. 1, fig. 1 is a schematic flowchart of a method for acquiring breakpoint data according to an embodiment of the present invention, in this embodiment, an angle trigger of a terminal is taken as an example for description, where the terminal may be a mobile terminal such as a smart phone and a tablet computer. As shown in fig. 1, in this embodiment, the processing procedure of the terminal may include the following steps:
s101: a list of institutions that need to be tracked is determined.
Here, an identity obtaining request may be sent to the mechanism to be tracked, the identity of the mechanism to be tracked may be obtained, and a mechanism list to be tracked may be generated. The mechanism to be tracked can be one or more, and is determined according to actual conditions.
S102: and sending a data processing progress inquiry request to the organizations in the organization list needing to be tracked.
Specifically, a data processing progress query request may be sent to the organizations in the list of organizations to be tracked at a preset time, for example, eight am each day, so as to know the data processing progress of the organizations to be tracked in time. If there are a plurality of mechanisms to be tracked, a data processing progress query request can be sent to the mechanisms at the same time, or a data processing progress query request can be sent to the mechanisms in sequence according to the sequence of the mechanisms in the mechanism list to be tracked.
S103: and receiving the data processing progress returned by the mechanisms in the mechanism list needing to be tracked, and recording the data processing progress and the receiving time.
Here, taking the organization a as an example, the data processing progress returned by the organization a is recorded under the name of the organization a, and the time when the data processing progress is received is recorded. In order to ensure that the subsequent processing is normally performed, a processing progress check request may be sent to the institutions in the institution list that needs to be tracked, or, taking institution a as an example, a processing progress check request is sent to institution a, where the request carries the data processing progress of institution a, if information that the processing progress returned by each institution is correct is received, step S104 is executed, otherwise, step S102 is executed again.
S104: and generating a mechanism updating list needing to be tracked according to the data processing progress and the mechanism list needing to be tracked.
Specifically, the mechanism list to be tracked is adjusted according to the received data processing progress to obtain the mechanism update list to be tracked, the mechanism update list to be tracked can be sent to the mechanisms in the mechanism list to be tracked for auditing, when the auditing passing information returned by the mechanisms in the mechanism list to be tracked is received, step S105 is executed, otherwise, step S104 is executed again.
S105: and after a first preset time interval, taking the mechanism updating list needing to be tracked as a new mechanism list needing to be tracked, and returning to execute the step of sending a data processing progress inquiry request to the mechanisms in the mechanism list needing to be tracked.
Here, the first preset time interval is set according to an actual situation, a data processing progress query request is sent to the mechanism in the mechanism update list needing to be tracked through the first preset time interval, the data processing progress returned by the mechanism in the mechanism update list needing to be tracked is received, and the mechanism update list needing to be tracked is further updated according to the data processing progress.
S106: when the system is abnormal, acquiring a mechanism update list needing to be tracked, which is nearest to the time when the system is abnormal, and sending a prompt that the system is abnormal and data needs to be reprocessed to a mechanism in the nearest mechanism update list needing to be tracked.
Specifically, for example, if an abnormality occurs at 5 points in the system, and there is a mechanism update list needing to be tracked, which is generated at 4 points 50 closest to 5 points, and a prompt that the system is abnormal and data needs to be reprocessed is sent to the mechanism in the mechanism update list needing to be tracked, or taking the mechanism a as an example, if the mechanism a receives the prompt that the system is abnormal and data needs to be reprocessed, the mechanism a reprocesses the data according to the prompt to obtain breakpoint data.
From the above description, the method for acquiring the breakpoint data of the embodiment of the present invention completes acquisition of the breakpoint data quickly and simply, does not need to rollback all data, saves a large amount of time, improves data processing accuracy, solves the problems that all data need to be rolled back when an existing system is abnormal, has a large workload and is prone to errors, reduces user operations, improves user experience, and meets the requirements of practical applications.
Referring to fig. 2, fig. 2 is a schematic flow chart of a method for acquiring breakpoint data according to another embodiment of the present invention. The embodiment corresponding to fig. 1 differs in that: generating an organization update list requiring tracking according to the data processing progress and the organization list requiring tracking may include S204. S201 to S203 are the same as S101 to S103 in the previous embodiment, and S205 to S206 are the same as S105 to S106 in the previous embodiment, and reference is specifically made to the description of S101 to S103 and S105 to S106 in the previous embodiment, which is not repeated herein. Specifically, S204 may include S2041-S2042.
S2041: and judging whether a mechanism for finishing data processing exists according to the data processing progress.
S2042: if the mechanism which completes the data processing is judged to be present, the mechanism which completes the data processing is deleted from the mechanism list which needs to be tracked, and a mechanism updating list which needs to be tracked is generated.
Here, whether there is a mechanism that completes data processing is determined based on the data processing progress of each mechanism, if there is a mechanism that completes data processing, sending a data processing progress inquiry request to the mechanism that completes data processing is stopped, that is, tracing is stopped, the mechanism that completes data processing is deleted from the mechanism list that needs to be traced, a new mechanism list that needs to be traced, that is, a mechanism update list that needs to be traced is generated, and the data processing progress of the mechanism can be recorded in the mechanism update list that needs to be traced.
The mechanism list needing to be tracked is continuously updated according to the received data processing progress, so that the number of mechanisms needing to be tracked can be reduced, the follow-up tracking work is reduced, the resources are saved, and the method is suitable for application.
Referring to fig. 3, fig. 3 is a schematic flow chart of a method for acquiring breakpoint data according to still another embodiment of the present invention. The embodiment corresponding to fig. 1 differs in that: the determining of the list of institutions that need to be tracked may comprise S301. S302 to S306 are the same as S102 to S106 in the previous embodiment, and reference is specifically made to the description of S102 to S106 in the previous embodiment, which is not repeated herein. Specifically, S301 may include S3011 to S3012.
S3011: and sending a prompt whether the data needs to be processed or not to the institutions in the prestored institution list.
Specifically, a general organization list of each organization may be stored in advance, for example, a total of 10 organizations may be stored, and a prompt indicating whether data needs to be processed or not may be sent to each organization to determine which organization needs to process data.
S3012: receiving information returned by mechanisms in a pre-stored mechanism list, and determining the mechanism list needing to be tracked according to the information and the pre-stored mechanism list, wherein the information is information for confirming that data needs to be processed or information for confirming that data does not need to be processed.
Here, each mechanism receives the prompt of whether the data needs to be processed or not, returns corresponding information according to the self condition, returns information for confirming that the data needs to be processed if the data needs to be processed, and otherwise returns information for confirming that the data does not need to be processed.
Further, taking the mechanism a as an example, when receiving the information that the mechanism a returns that confirms that the data needs to be processed, the mechanism a is determined to be the mechanism that needs to be tracked, and when receiving the information that the mechanism a returns that the data does not need to be processed, the mechanism a is determined to be the mechanism that does not need to be tracked. And finally, obtaining a mechanism list needing to be tracked according to information returned by each mechanism, and subsequently, only carrying out data tracking on the mechanism needing to be tracked, and not carrying out data tracking on the mechanism needing to be tracked, so that the user operation is reduced, and the user experience is improved.
Referring to fig. 4, fig. 4 is a schematic flow chart of a method for acquiring breakpoint data according to still another embodiment of the present invention. The difference between the above embodiments of the present embodiment is S401 to S404, where S405 to S408 are the same as S103 to S106 in the previous embodiment, and please refer to the description related to S103 to S106 in the above embodiments, which is not repeated herein. The method for acquiring breakpoint data in this embodiment may further include:
s401: a list of institutions that need to be tracked is determined.
S402: an indication is sent to the authorities in the list of authorities that need to be tracked whether the list is correct.
Here, a prompt is sent to each organization in the list of organizations to be tracked, which prompt carries the list of organizations to be tracked.
S403: and if receiving the information which is returned by the mechanism in the mechanism list needing to be tracked and confirms that the list is correct, executing the data processing progress query request sent to the mechanism in the mechanism list needing to be tracked.
Specifically, after receiving the information returned by each mechanism to confirm the correctness of the list, a data processing progress query request is sent to the mechanism in the mechanism list to be tracked, so that the normal operation of subsequent processing is ensured.
S404: if the information for confirming that the list is wrong returned by the first mechanism is received and the list change request sent by the first mechanism is received, whether the list change request accords with a preset list change rule or not is checked, if the list change request accords with the preset list change rule, the mechanism list needing to be tracked is changed according to the list change request, the changed mechanism list needing to be tracked is used as a new mechanism list needing to be tracked, the data processing progress query request is sent to the mechanism in the mechanism list needing to be tracked, and the first mechanism is any one mechanism in the mechanism list needing to be tracked.
If the list change request sent by the first mechanism is received, the list change request is audited according to a preset list change rule, if the audit is passed, the mechanism list needing to be tracked is changed according to the list change request, a data processing progress inquiry request is sent to the mechanism in the changed mechanism list needing to be tracked, and if the audit is not passed, list change failure information is returned to the first mechanism, wherein the information carries the preset list change rule. Specifically, the preset list change rule may be set according to actual conditions.
After the mechanism list needing to be tracked is determined, the mechanism list needing to be tracked is sent to the corresponding mechanism for confirmation, and if the mechanism list needing to be tracked is wrong, the mechanism list needing to be tracked can be further changed, so that errors in acquiring subsequent breakpoint data are avoided.
Referring to fig. 5, fig. 5 is a schematic flow chart of a method for acquiring breakpoint data according to still another embodiment of the present invention. The difference between the above embodiments of the present embodiment is in S507 to S509, where S501 to S506 are the same as S101 to S106 in the previous embodiment, and please refer to the related description of S103 to S106 in the above embodiments, which is not repeated herein. The method for acquiring breakpoint data in this embodiment may further include:
s507: and sending a prompt for returning receipt to the mechanism in the latest mechanism updating list needing to be tracked.
S508: and judging whether a receipt returned by a second mechanism is received or not after a second preset time interval, wherein the second mechanism is any mechanism in the latest mechanism updating list needing to be tracked.
S509: and if the receipt returned by the second mechanism is not received after the second preset time interval, sending a prompt that the data needs to be reprocessed due to system abnormity to the second mechanism again.
Specifically, after a prompt that data needs to be reprocessed due to system anomaly is sent to the mechanisms in the latest mechanism update list needing to be tracked, a prompt for returning receipt can be sent to the mechanisms at the same time, if the mechanisms all return receipt at preset time intervals, it is indicated that the mechanisms all receive the prompt that data needs to be reprocessed due to system anomaly, if only part of the mechanisms return receipt at the preset time intervals, it is indicated that some mechanisms do not receive the prompt that data needs to be reprocessed due to system anomaly, and in order to notify the mechanisms to acquire breakpoint data as soon as possible, the prompt that data needs to be reprocessed due to system anomaly can be sent to the mechanisms which do not receive receipt again, so that the actual application needs are met. Here, the preset time interval is set as needed, and may be 5 seconds, 10 seconds, or the like.
It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.
Corresponding to the method for acquiring fault data described in the above embodiment, fig. 6 shows a schematic view of an operating environment of a fault data acquiring program provided in the embodiment of the present invention. For convenience of explanation, only the portions related to the present embodiment are shown.
In the present embodiment, the breakpoint data acquisition program 600 is installed and executed in the terminal device 60. The terminal device 60 may be a mobile terminal, a palm top computer, a server, etc. The terminal device 60 may include, but is not limited to, a memory 601, a processor 602, and a display 603. Fig. 6 only shows terminal device 60 with components 601 and 603, but it is to be understood that not all of the shown components are required and that more or fewer components may alternatively be implemented.
The storage 601 may in some embodiments be an internal storage unit of the terminal device 60, such as a hard disk or a memory of the terminal device 60. In other embodiments, the memory 601 may also be an external storage device of the terminal device 60, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), or the like, provided on the terminal device 60. Further, the memory 601 may also include both an internal storage unit and an external storage device of the terminal device 60. The memory 601 is used for storing application software installed in the terminal device 60 and various types of data, such as a program code of the breakpoint data obtaining program 600. The memory 601 may also be used to temporarily store data that has been output or is to be output.
The processor 602 may be a Central Processing Unit (CPU), a microprocessor or other data processing chip in some embodiments, and is used to execute the program code stored in the memory 601 or process data, such as executing the breakpoint data obtaining program 600.
The display 603 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode) touch panel, or the like in some embodiments. The display 603 is used for displaying information processed in the terminal device 60 and for displaying a visualized user interface, such as an application menu interface, an application icon interface, and the like. The components 601 and 603 of the terminal device 60 communicate with each other via a system bus.
Fig. 7 is a functional block diagram of a breakpoint data obtaining program 600 according to an embodiment of the present invention. In this embodiment, the breakpoint data obtaining program 600 may be divided into one or more modules, and the one or more modules are stored in the memory 601 and executed by one or more processors (in this embodiment, the processor 602) to complete the present invention. For example, in fig. 7, the breakpoint data acquisition program 600 may be divided into a list determination unit 701, a processing progress inquiry unit 702, a processing progress receiving unit 703, a list updating unit 704, and a system abnormality processing unit 705. The module referred to in the present invention refers to a series of computer program instruction segments capable of performing specific functions, and is more suitable than a program for describing the execution process of the breakpoint data acquisition program 600 in the terminal device 60. The following description will specifically describe the functions of the modules 701-705.
The list determining unit 701 is configured to determine a mechanism list that needs to be tracked. A processing progress inquiry unit 702, configured to send a data processing progress inquiry request to the organizations in the list of organizations to be tracked. A processing progress receiving unit 703, configured to receive a data processing progress returned by a mechanism in the mechanism list that needs to be tracked, and record the data processing progress and a receiving time. And a list updating unit 704, configured to generate an organization updating list needing to be tracked according to the data processing progress and the organization list needing to be tracked. The processing progress querying unit 702 is configured to, after a first preset time interval, use the updated mechanism list that needs to be tracked as a new mechanism list that needs to be tracked, and return to execute a step of sending a data processing progress querying request to a mechanism in the mechanism list that needs to be tracked. The system exception handling unit 705 is configured to, when a system is abnormal, obtain a mechanism update list that needs to be tracked and is closest to a time when the system is abnormal, and send a prompt that the system is abnormal and data needs to be reprocessed to a mechanism in the closest mechanism update list that needs to be tracked.
Alternatively, the list updating unit 704 may be divided into a processing progress determination unit 7041 and an update list generation unit 7042.
The processing progress determining unit 7041 is configured to determine whether there is a mechanism for completing data processing according to the data processing progress. Update list generation section 7042 is configured to, when it is determined that there is a mechanism that completes data processing, delete the mechanism that completes data processing from the mechanism list that needs to be tracked, and generate a mechanism update list that needs to be tracked.
Alternatively, list determining unit 701 may be divided into first prompt transmitting unit 7011 and information processing unit 7012.
The first prompt sending unit 7011 is configured to send a prompt to a pre-stored organization in the organization list to determine whether data processing is required. And an information processing unit 7012, configured to receive information returned by an organization in a pre-stored organization list, and determine an organization list that needs to be tracked according to the information and the pre-stored organization list, where the information is information for confirming that data needs to be processed or information for confirming that data does not need to be processed.
Optionally, the breakpoint data acquisition program 600 may be further divided into a second prompt sending unit 706 and a list changing unit 707.
Wherein, the second prompt sending unit 706 is configured to send a prompt indicating whether the list is correct to the institutions in the list of institutions that need to be tracked. A processing progress query unit 702, configured to execute sending a data processing progress query request to the mechanism in the mechanism list needing to be tracked if receiving information that confirms that the list is correct and is returned by the mechanism in the mechanism list needing to be tracked. A list changing unit 707, configured to, if information for confirming that the list is incorrect and a list changing request sent by the first mechanism is received, check whether the list changing request conforms to a preset list changing rule, and if the list changing request conforms to the preset list changing rule, change the mechanism list to be tracked according to the list changing request. A processing progress query unit 702, configured to use the modified mechanism list needing to be tracked as a new mechanism list needing to be tracked, and execute sending a data processing progress query request to a mechanism in the mechanism list needing to be tracked, where the first mechanism is any one mechanism in the mechanism list needing to be tracked.
Optionally, the breakpoint data obtaining program 600 may be further divided into a third prompt sending unit 708 and a receipt judging unit 709.
Wherein, the third prompt sending unit 708 is configured to send a prompt to return a receipt to the mechanism in the latest mechanism update list that needs to be tracked. A closing judgment unit 709, configured to judge whether a closing returned by a second mechanism is received after a second preset time interval, where the second mechanism is any mechanism in the latest mechanism update list that needs to be tracked. The system exception handling unit 705 is configured to, if it is determined that the receipt returned by the second mechanism is not received after the second preset time interval, send a prompt that the system exception requires data reprocessing to the second mechanism again.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
In the embodiments provided in the present invention, it should be understood that the disclosed apparatus/terminal device and method may be implemented in other ways. For example, the above-described embodiments of the apparatus/terminal device are merely illustrative, and for example, the division of the modules or units is only one logical division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated modules/units, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow of the method according to the embodiments of the present invention may also be implemented by a computer program, which may be stored in a computer-readable storage medium, and when the computer program is executed by a processor, the steps of the method embodiments may be implemented. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.
The above-mentioned embodiments are only used for illustrating the technical solutions of the present invention, and not for limiting the same; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present invention, and are intended to be included within the scope of the present invention.

Claims (10)

1. A method for acquiring breakpoint data is characterized by comprising the following steps:
determining a mechanism list needing to be tracked;
sending a data processing progress query request to the mechanisms in the mechanism list needing to be tracked;
receiving a data processing progress returned by a mechanism in a mechanism list needing to be tracked, and recording the data processing progress and a receiving moment;
adjusting a mechanism list to be tracked according to the data processing progress, and generating a mechanism updating list to be tracked;
after a first preset time interval, taking the mechanism updating list needing to be tracked as a new mechanism list needing to be tracked, and returning to execute the step of sending a data processing progress query request to the mechanism in the mechanism list needing to be tracked;
when the system is abnormal, acquiring a mechanism update list needing to be tracked, which is nearest to the time when the system is abnormal, and sending a prompt that the system is abnormal and data needs to be reprocessed to a mechanism in the nearest mechanism update list needing to be tracked.
2. The method for acquiring breakpoint data according to claim 1, wherein generating a mechanism update list to be tracked according to the data processing progress and the mechanism list to be tracked comprises:
judging whether a mechanism for finishing data processing exists according to the data processing progress;
if the mechanism which completes the data processing is judged to be present, the mechanism which completes the data processing is deleted from the mechanism list which needs to be tracked, and a mechanism updating list which needs to be tracked is generated.
3. The method of claim 1, wherein determining a list of institutions that need to be tracked comprises:
sending a prompt whether data needs to be processed or not to the mechanisms in the prestored mechanism list;
receiving information returned by mechanisms in a pre-stored mechanism list, and determining the mechanism list needing to be tracked according to the information and the pre-stored mechanism list, wherein the information is information for confirming that data needs to be processed or information for confirming that data does not need to be processed.
4. The method for acquiring breakpoint data according to claim 1, further comprising:
sending a prompt whether the list is correct or not to the mechanisms in the mechanism list needing to be tracked;
if receiving the information which is returned by the mechanism in the mechanism list needing to be tracked and confirms that the list is correct, executing the data processing progress query request sent to the mechanism in the mechanism list needing to be tracked;
if the information for confirming that the list is wrong returned by the first mechanism is received and the list change request sent by the first mechanism is received, whether the list change request accords with a preset list change rule or not is checked, if the list change request accords with the preset list change rule, the mechanism list needing to be tracked is changed according to the list change request, the changed mechanism list needing to be tracked is used as a new mechanism list needing to be tracked, the data processing progress query request is sent to the mechanism in the mechanism list needing to be tracked, and the first mechanism is any one mechanism in the mechanism list needing to be tracked.
5. The method for acquiring breakpoint data according to claim 1, further comprising:
sending a prompt for returning receipt to the mechanism in the latest mechanism updating list needing to be tracked;
judging whether a receipt returned by a second mechanism is received or not after a second preset time interval, wherein the second mechanism is any one mechanism in the latest mechanism updating list needing to be tracked;
and if the receipt returned by the second mechanism is not received after the second preset time interval, sending a prompt that the data needs to be reprocessed due to system abnormity to the second mechanism again.
6. A breakpoint data acquisition terminal device, comprising a memory, a processor, and a computer program stored in the memory and operable on the processor, wherein the processor implements the following steps when executing the computer program:
determining a mechanism list needing to be tracked;
sending a data processing progress query request to the mechanisms in the mechanism list needing to be tracked;
receiving a data processing progress returned by a mechanism in a mechanism list needing to be tracked, and recording the data processing progress and a receiving moment;
adjusting a mechanism list to be tracked according to the data processing progress, and generating a mechanism updating list to be tracked;
after a first preset time interval, taking the mechanism updating list needing to be tracked as a new mechanism list needing to be tracked, and returning to execute the step of sending a data processing progress query request to the mechanism in the mechanism list needing to be tracked;
when the system is abnormal, acquiring a mechanism update list needing to be tracked, which is nearest to the time when the system is abnormal, and sending a prompt that the system is abnormal and data needs to be reprocessed to a mechanism in the nearest mechanism update list needing to be tracked.
7. The breakpoint data acquisition terminal device according to claim 6, wherein generating the mechanism update list that needs to be tracked according to the data processing progress and the mechanism list that needs to be tracked includes:
judging whether a mechanism for finishing data processing exists according to the data processing progress;
if the mechanism which completes the data processing is judged to be present, the mechanism which completes the data processing is deleted from the mechanism list which needs to be tracked, and a mechanism updating list which needs to be tracked is generated.
8. The breakpoint data acquisition terminal device of claim 6, wherein the determining of the list of mechanisms that need to be tracked includes:
sending a prompt whether data needs to be processed or not to the mechanisms in the prestored mechanism list;
receiving information returned by mechanisms in a pre-stored mechanism list, and determining the mechanism list needing to be tracked according to the information and the pre-stored mechanism list, wherein the information is information for confirming that data needs to be processed or information for confirming that data does not need to be processed.
9. The breakpoint data acquisition terminal device of claim 6, wherein the processor, when executing the computer program, further implements the steps of:
sending a prompt whether the list is correct or not to the mechanisms in the mechanism list needing to be tracked;
if receiving the information which is returned by the mechanism in the mechanism list needing to be tracked and confirms that the list is correct, executing the data processing progress query request sent to the mechanism in the mechanism list needing to be tracked;
if the information for confirming that the list is wrong returned by the first mechanism is received and the list change request sent by the first mechanism is received, whether the list change request accords with a preset list change rule or not is checked, if the list change request accords with the preset list change rule, the mechanism list needing to be tracked is changed according to the list change request, the changed mechanism list needing to be tracked is used as a new mechanism list needing to be tracked, the data processing progress query request is sent to the mechanism in the mechanism list needing to be tracked, and the first mechanism is any one mechanism in the mechanism list needing to be tracked.
10. A computer-readable storage medium, in which a computer program is stored, which, when being executed by a processor, carries out the steps of the breakpoint data acquisition method according to any one of claims 1 to 5.
CN201710865431.8A 2017-09-22 2017-09-22 Breakpoint data obtaining method and terminal equipment Active CN108255629B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201710865431.8A CN108255629B (en) 2017-09-22 2017-09-22 Breakpoint data obtaining method and terminal equipment
PCT/CN2018/082495 WO2019056736A1 (en) 2017-09-22 2018-04-10 Breakpoint data acquisition method and apparatus, terminal device and medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710865431.8A CN108255629B (en) 2017-09-22 2017-09-22 Breakpoint data obtaining method and terminal equipment

Publications (2)

Publication Number Publication Date
CN108255629A CN108255629A (en) 2018-07-06
CN108255629B true CN108255629B (en) 2020-09-22

Family

ID=62721286

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710865431.8A Active CN108255629B (en) 2017-09-22 2017-09-22 Breakpoint data obtaining method and terminal equipment

Country Status (2)

Country Link
CN (1) CN108255629B (en)
WO (1) WO2019056736A1 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111478751B (en) * 2020-03-30 2023-03-24 百富计算机技术(深圳)有限公司 Data breakpoint continuous transmission method and device and terminal equipment

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW201013550A (en) * 2008-09-17 2010-04-01 Chunghwa Telecom Co Ltd Operating flow control and management system and the method thereof
CN104794138A (en) * 2014-01-22 2015-07-22 深圳市沃信科技有限公司 Method, device and system for determining database transaction result
CN106611364A (en) * 2015-10-22 2017-05-03 中国电信股份有限公司 Storage fragmentation arrangement method and device
CN106682017A (en) * 2015-11-09 2017-05-17 高德软件有限公司 Database update method and device

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101286127B (en) * 2008-05-08 2010-06-02 华中科技大学 Multi-fork diary memory continuous data protecting and restoration method
CN103198159B (en) * 2013-04-27 2016-01-06 国家计算机网络与信息安全管理中心 A kind of many copy consistency maintaining methods of isomeric group reformed based on affairs
CN104424162A (en) * 2013-08-21 2015-03-18 鸿合科技有限公司 Method and device for generating record of document used recently

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW201013550A (en) * 2008-09-17 2010-04-01 Chunghwa Telecom Co Ltd Operating flow control and management system and the method thereof
CN104794138A (en) * 2014-01-22 2015-07-22 深圳市沃信科技有限公司 Method, device and system for determining database transaction result
CN106611364A (en) * 2015-10-22 2017-05-03 中国电信股份有限公司 Storage fragmentation arrangement method and device
CN106682017A (en) * 2015-11-09 2017-05-17 高德软件有限公司 Database update method and device

Also Published As

Publication number Publication date
CN108255629A (en) 2018-07-06
WO2019056736A1 (en) 2019-03-28

Similar Documents

Publication Publication Date Title
CN108427705B (en) Electronic device, distributed system log query method and storage medium
CN110278143B (en) E-mail data processing method and device, computer equipment and storage medium
CN111211929A (en) Fault positioning method, fault positioning device, control equipment and intelligent equipment
CN108491304B (en) electronic device, business system risk control method and storage medium
CN110555150B (en) Data monitoring method, device, equipment and storage medium
CN112631911A (en) Automatic testing method and device, computer equipment and storage medium
CN109491733B (en) Interface display method based on visualization and related equipment
CN112631924A (en) Automatic testing method and device, computer equipment and storage medium
CN110659210A (en) Information acquisition method and device, electronic equipment and storage medium
CN111258832B (en) Interface parameter verification method, device, equipment and medium
CN111221727A (en) Test method, test device, electronic equipment and computer readable medium
CN108255629B (en) Breakpoint data obtaining method and terminal equipment
CN111741046B (en) Data reporting method, data acquisition method, device, equipment and medium
CN113722225A (en) Page testing method and device, computer equipment and storage medium
CN111078550A (en) Software testing method and device, computer device and storage medium
CN110955686A (en) Data multidimensional cross processing method and device, electronic equipment and storage medium
CN114281849B (en) Data query method and device
CN111026571B (en) Processor down-conversion processing method and device and electronic equipment
CN108241739B (en) POI data processing method, device, equipment and computer readable storage medium
CN108255904B (en) Table structure modeling method and server
CN115689561A (en) U shield testing method, device, equipment and medium
CN115758093A (en) Data processing method and device
CN117851265A (en) Test method, test device, electronic equipment and storage medium
CN112165512A (en) File publishing method and device, terminal equipment and storage medium
CN116627958A (en) Big data quality checking method, device, equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant