A method and system for patrol task control based on effective time point matching and atomic snapshot freezing

Abstract

The application discloses a kind of based on effective time point matching and atomic snapshot freezing inspection task control method and system, comprising the following steps: establishing the check list version with version identification and effective time point for check object;With the expected start point of inspection task as matching time point, determine the target version no later than the matching time point and closest from the published version of the same check object;When new version is released or planned to change, only update the version snapshot of the task that meets the variable condition. When saving the inspection result, check whether the answer corresponding to the check item belongs to the target version;When submitting for approval, based on task identification, expected old snapshot and approval state, execute condition update, atomically write the target version snapshot and frozen state, and if condition update fails, terminate submission. Approval and result query read frozen snapshot and check item content snapshot. The application avoids mismatch between new list and old answer caused by concurrent version switching, and maintains consistency and traceability of cross-period inspection results.

Description

Technical Field

[0001] This invention relates to the field of computer data consistency control and inspection task management technology, specifically to an inspection task control method and system based on effective time point matching and atomic snapshot freezing. Background Technology

[0002] An information-based inspection system typically consists of checklist configuration, inspection plan, inspection tasks, on-site execution, result submission, and approval / archiving. Checklists may be revised due to changes in regulations, equipment standards, warehouse conditions, or material categories. To ensure new standards take effect on a specified date, the system also needs to allow for the approval of new versions before they become effective at a future date.

[0003] Existing systems often directly read the current version of the checklist when a task is opened or submitted, or only save the checklist identifier when the plan is created. After the current version changes, tasks that have not yet been executed, tasks that are being filled out, and tasks that have entered the approval process may simultaneously reference check items with different meanings. If a new version is released while the user is filling out answers on the old page, a combination of the new checklist and the old answers may appear upon submission; if the plan scope or time window changes and tasks are rebuilt uniformly, tasks that are being executed or approved may be deleted or overwritten.

[0004] Furthermore, updating the version snapshot only in the application before updating the approval status leaves concurrency gaps: two requests might both complete verification based on the same old version and repeatedly start the approval process, or one request might freeze the new version while the other still retains the old version's answer. These issues fall under the category of computer data consistency problems between task versions, checklist sets, and result data, leading to the inability to reproduce historical results, duplicate calculations of anomalies, and changes in approval criteria.

[0005] In summary, this invention presents a method and system for controlling inspection tasks based on effective time point matching and atomic snapshot freezing. Summary of the Invention

[0006] To address the version mismatch problem in existing technologies involving multiple version checklists under scenarios of future activation, plan adjustments, and concurrent submissions, the present invention aims to provide a method and system for controlling inspection tasks based on activation point matching and atomic snapshot freezing. This ensures that each inspection task obtains a specific version according to its expected execution time and that version snapshots, check item answers, and approval status remain consistent at the submission boundary.

[0007] To achieve the above objectives, the present invention provides a method for controlling inspection tasks based on effective time point matching and atomic snapshot freezing, comprising the following steps: S101: Establish a checklist version record: Each record includes the business key of the check object, version identifier, effective date, approval and release status, and set of check items; the version number is incremented based on the last released version of the same business key.

[0008] S102: Using the expected start time of the inspection task as the matching time, query the published versions with the same business key whose effective time is no later than the matching time, and select the target version in descending order of effective time and version number on the same day.

[0009] S103: When a new version is released or a change is planned, determine whether the task snapshot is mutable based on the expected start time, approval status, and whether there are already submission results; only update mutable tasks, and retain the original snapshots of tasks that are under approval, approved, or have already been executed.

[0010] S104: When saving the inspection results for an editable task, refresh the version snapshot according to the expected start time, generate a set of valid inspection items, and write the inspection standards, content, methods, types, and options into the result content snapshot.

[0011] S105: Before submitting for approval, compare the set of answered check items with the set of valid check items for the target version; if there are invalid check items or missing required items, terminate the submission to avoid binding old answers to the new version.

[0012] S106: After verification, the target version snapshot and frozen status are written in the same condition update, using the task identifier, expected old version snapshot and variable approval status as update conditions; if the number of affected rows is not one, rollback is performed and a refresh is prompted.

[0013] S107: Approval, anomaly query and historical result reproduction all use frozen version snapshots and inspection item content snapshots; after approval is returned, the version is rematched according to the expected start time and re-verified when resubmitted.

[0014] Preferably, the inspection object business key includes the inspection object type and the warehouse identifier or material category code corresponding to the inspection object type; the version identifier of the new inspection list version is generated incrementally based on the last released version identifier under the same inspection object business key, and does not change the version increment benchmark based on the future effective time point that has not yet arrived.

[0015] Selecting the target checklist version includes: filtering checklist versions whose effective date is later than the expected start date; sorting the remaining checklist versions in descending order of their effective date; when at least two checklist versions have the same effective date, sorting them in descending order of their version identifiers; and selecting the first checklist version after sorting as the target checklist version.

[0016] After the new checklist version is approved and released, the associated inspection plan and associated inspection task are found based on the business key of the inspection object. The associated inspection task is identified as a snapshot variable task only if the expected start time of the associated inspection task is not earlier than the effective time of the new checklist version and the approval status of the associated inspection task is empty, draft or returned. The associated inspection task that is under approval, approved or has already produced a submission result retains the original version snapshot.

[0017] Updating the snapshot version of a snapshot variable task includes: reselecting the corresponding target checklist version according to the expected start time of each snapshot variable task; replacing only the version identifier corresponding to the business key of the inspection object from the current version snapshot of the snapshot variable task, while retaining the version identifiers corresponding to other inspection objects.

[0018] When the scope of an inspection plan changes, update the scope snapshot of incomplete inspection tasks with variable snapshots; when the time window of an inspection plan changes, rebuild inspection tasks that have not yet started, and retain inspection tasks that are in progress, under approval, or approved, in order to avoid generating inspection tasks repeatedly in the same time slot.

[0019] The verification before submission for approval includes: generating a set of valid check item identifiers based on the target checklist version; extracting the set of answered check item identifiers from the saved inspection answers; determining whether the set of answered check item identifiers is a subset of the set of valid check item identifiers and determining whether the required check items of the target checklist version are complete; if any judgment is not satisfied, the submission is terminated and conflict information indicating that the checklist version has changed is returned.

[0020] Preferably, the update conditions for the condition update include at least the following: the inspection task identifier is equal to the inspection task identifier to be submitted, the current version snapshot is equal to the expected old version snapshot, and the current approval status belongs to the preset variable approval status; when the number of affected records is not one, the current submitted transaction is rolled back and the client is instructed to reread the inspection task.

[0021] When saving the inspection answer, the inspection criteria, inspection content, inspection method, inspection type and candidate options are also written into the inspection item content snapshot; after submission, the inspection item content snapshot is read when judging abnormal items and displaying historical results, instead of reading the current definition of the variable inspection list.

[0022] After an inspection task is rejected by the approval process, the target checklist version is re-matched based on the expected start time of the inspection task; before resubmitting, the verification of the set of answered check items and the set of valid check items is re-executed, and a new approval process instance is generated only if the verification passes.

[0023] An inspection task control system based on effective time point matching and atomic snapshot freezing includes: a checklist version management module for establishing checklist version records with inspection object business keys, version identifiers, effective times, and approval release status; an effective time point matching module for determining the closest target checklist version no later than the expected start time of the inspection task; a variable task snapshot synchronization module for updating the version snapshot only for inspection tasks that meet the expected start time and approval status conditions; a check item and answer verification module for verifying that the set of answered check items belongs to the valid check item set of the target checklist version before submitting for approval; an atomic snapshot freezing module for atomically writing the version snapshot and snapshot freezing status of the target checklist version based on the inspection task identifier, the expected old version snapshot, and the variable approval status execution conditions; and a frozen snapshot query module for reading the frozen version snapshot and check item content snapshot during approval and result query.

[0024] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described inspection task control method based on effective time-point matching and atomic snapshot freezing.

[0025] The present invention has the following beneficial effects: 1. The task version is determined by the expected execution time, rather than by the user opening the page or the current server time, which can reliably handle future versions and cross-time period plans.

[0026] 2. By using variability layering, only tasks that have not yet been frozen are synchronized, avoiding the overwriting of results that are being executed, approved, or archived by plan adjustments or new version releases.

[0027] 3. Pre-submission set validation prevents mismatches between new checklists and old answers, ensuring a verifiable consistency between checklists, answers, and version identifiers.

[0028] 4. By updating the conditions with the expected old snapshot and approval status, snapshot and frozen state writes are completed in a single atomic database operation, preventing concurrent duplicate submissions and old pages from overwriting new versions.

[0029] 5. By capturing snapshots of the results, the inspection criteria, methods, and options are preserved. Historical results can be reproduced without relying on variable master data, reducing redundant calculations and audit ambiguities. Attached Figure Description

[0030] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments; Figure 1 To develop a structural diagram of the inspection task control system; Figure 2 This is a schematic diagram showing the timing of the effective date of this invention; Figure 3 This is a flowchart of the inspection task control method of the present invention; Figure 4 This is a flowchart illustrating the task snapshot synchronization process after the release of a new version of this invention. Figure 5 This is a flowchart of the atomic snapshot freezing process at the time of submission of this invention; Figure 6 This is a diagram showing the variability transition between task state and snapshot in this invention. Detailed Implementation

[0032] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0033] Reference Figure 1-6 The specific implementation adopts the following technical solution: a patrol task control method based on effective time point matching and atomic snapshot freezing, including the following steps: S101: Establish a checklist version record: Each record includes the business key of the check object, version identifier, effective date, approval and release status, and set of check items; the version number is incremented based on the last released version of the same business key.

[0034] S102: Using the expected start time of the inspection task as the matching time, query the published versions with the same business key whose effective time is no later than the matching time, and select the target version in descending order of effective time and version number on the same day.

[0035] S103: When a new version is released or a change is planned, determine whether the task snapshot is mutable based on the expected start time, approval status, and whether there are already submission results; only update mutable tasks, and retain the original snapshots of tasks that are under approval, approved, or have already been executed.

[0036] S104: When saving the inspection results for an editable task, refresh the version snapshot according to the expected start time, generate a set of valid inspection items, and write the inspection standards, content, methods, types, and options into the result content snapshot.

[0037] S105: Before submitting for approval, compare the set of answered check items with the set of valid check items for the target version; if there are invalid check items or missing required items, terminate the submission to avoid binding old answers to the new version.

[0038] S106: After verification, the target version snapshot and frozen status are written in the same condition update, using the task identifier, expected old version snapshot and variable approval status as update conditions; if the number of affected rows is not one, rollback is performed and a refresh is prompted.

[0039] S107: The approval, abnormal item query and historical result reproduction all use the frozen version snapshot and the check item content snapshot; after the approval is rejected, the version is re-matched according to the estimated start time point, and re-verification is performed upon re-submission.

[0040] The terms and data structures in this specific embodiment are as follows: Checklist version Business key, version identifier, effective date, release status Constructing a temporal version sequence Inspection Plan Inspection scope, cycle, time window, version identifier list Generate tasks and save the planned scope Inspection task Expected start time, version snapshot, approval status Carrying matching results and frozen boundaries Inspection Item Results Checklist identifiers, answers, standards / content / methods / options snapshots References for reproduction and submission Approval Records Process examples, approval rounds, results and timelines Associate frozen tasks and retain audit trails Effective time point matching in this specific embodiment: Assume that the set of released versions of the same check object is V={V1, V2, ..., Vn}, the effective time point of version Vi is Ei, and the estimated start time point of the inspection task T is P. The candidate set is defined as C(T)={Vi|Ei≤P}. The system sorts C(T) in descending order of Ei; when Ei is the same, sorting is performed in descending order of comparable version numbers, and the first item in the sorted list is the target version V(T).

[0041] For example, versions V1, V2, and V3 take effect at E1, E2, and E3 respectively, and E1<E2<E3. If the estimated start time point P1 of task TA is between E1 and E2, V1 is matched; if P2 of task TB is between E2 and E3, V2 is matched; if P3 of task TC is no earlier than E3, V3 is matched. Even if V3 has been approved and released, as long as the estimated start time point of the task is earlier than E3, the task still retains V2 or an earlier valid version.

[0042] Snapshot synchronization after new version release in this specific embodiment: after the new version is approved, the system obtains the service key and effective time point of the check object of this version, and finds the inspection plan containing the old version of the same check object through the service key. For each plan, load the unfinished tasks and make judgments respectively: whether the estimated start time point of the task is no earlier than the effective time point of the new version; whether the approval status is empty, draft or rejected; whether a submission result that needs to be retained has been generated. Only tasks that meet the variable conditions enter the synchronization set.

[0043] During synchronization, the newly released version is not uniformly replaced, but the V(T) selection is re-executed based on the estimated start time point of each task itself. For a case where one plan contains multiple warehouses or material categories, only the version identifier corresponding to the current service key in the version snapshot is replaced, and the version identifiers of other objects remain unchanged. This can handle combined plans where multiple objects have different effective dates.

[0044] This specific implementation method protects tasks during plan changes: It checks that changes in scope do not alter existing task times; therefore, the system only updates the scope and version snapshot for incomplete and variable tasks. Changes in the time window affect task time slots; the system deletes and recreates tasks that have not yet started. Tasks that are in progress, under approval, approved, or have been returned but still retain execution results are not deleted; only their permissible scope information is synchronized. Before generating a new task, a unique key for the time slot is constructed using the plan identifier, expected start time, and execution sequence number to avoid duplication between retained and new tasks.

[0045] In this specific implementation, the saving result and pre-submission verification are as follows: When a user saves the result, the system first reads the current approval status of the task. Modifications are rejected if the task is in approval or approved; saving is allowed if it is a draft or returned task. For editable tasks, the system reselects the target version according to the expected start time and performs condition updates using the current version snapshot as the expected value. If the conditions are not met, it indicates that other requests have changed the task status or version, and the current save request is terminated.

[0046] The system loads the valid checklist set (IV) based on the target version and simultaneously saves snapshots of the check criteria, check content, check methods, check types, and candidate options for each answer. Before submission for approval, the saved checklist set (IA) of the answers is extracted, and it is verified that IA is a subset of IV and that the required fields are complete. If the target version changes while the user is filling out the form on the old page, IA will contain checklists that do not belong to IV, and the system will reject the submission accordingly, rather than silently binding the old answers to the new version.

[0047] In this specific implementation, atomic snapshot freezing works as follows: After verification, the system serializes the target version identifier list into a snapshot to be frozen, Snew, and retains the old snapshot, Sold, obtained when loading the task. Database updates satisfy the following conditions: task identifier equals T.id; current version snapshot equals Sold; current approval status is a preset state of empty, draft, or pending. The update content in the same statement includes version snapshot = Snew, approval status = pending, and freeze flag = frozen.

[0048] If one row is affected, the newly started approval process instance is bound; if zero rows are affected, it means the task was changed by another request between validation and freezing, the system throws a conflict and rolls back the transaction. Compared to the two-step approach of writing a snapshot first and then modifying the state, this conditional update eliminates observable intermediate states.

[0049] Approval rejection and historical recurrence of this specific implementation method: After approval is rejected, the task reverts to an editable state, but does not directly reuse potentially expired versions. When re-entering editing or resubmitting, the currently published and valid version is re-matched to the originally expected start time; if the version has changed, the user is required to re-enter the form based on the new checklist. Resubmissions undergo the same set of validations and atomic freeze process, and a new approval round is created.

[0050] During the approval process, once approved, and in historical queries, the system prioritizes reading the frozen version snapshot of the task; the text, standards, methods, and options for inspection items are read from the snapshot of the results content. Even if the master data of the checklist is subsequently revised, the system can still restore the complete inspection basis and answers at the time of submission. Results for anomalies are also fixed upon submission, preventing subsequent recalculation according to new standards from altering historical conclusions.

[0051] Example 1: Concurrent Example Request A and Request B simultaneously read Task T, both obtaining the same old snapshot S1 and draft status. Request A first completes the answer validation and updates the snapshot S2 and the approval status with the condition WHERE (id=T and snapshot=S1 and status=draft), affecting only one row. When Request B subsequently performs the same conditional update, since the current snapshot or status has changed, the number of affected rows is zero, and Request B rolls back without starting a second process. This ensures that there is only one frozen version of the same task in the same approval round.

[0052] Example 2: System Example like Figure 1As shown, the system includes a checklist version management module 110, a plan and task generation module 120, an effective time point matching module 130, a variable task snapshot synchronization module 140, a check item and answer verification module 150, an atomic snapshot freezing module 160, an approval status control module 170, and a frozen snapshot query module 180. These modules can be deployed on the same server or implemented collaboratively by multiple services; the modules exchange data through a version repository 410, a task snapshot repository 420, a result content snapshot repository 430, and an approval process and status storage unit 440. The configuration terminal 100 is sequentially connected to the checklist version management module 110 and the variable task snapshot synchronization module 140. The variable task snapshot synchronization module 140 and the check item and answer verification module 150 are both connected to the approval status control module 170. The variable task snapshot synchronization module 140 is also connected to the version repository 410. The inspection execution terminal 200, the plan and task generation module 120, and the check item and answer verification module 150 are sequentially connected. The approval status control module 170 is connected to the task snapshot repository 420. The task snapshot repository 420 is connected to the status storage unit 440. The approval terminal 300, the effective time point matching module 130, and the atomic snapshot freezing module 160 are sequentially connected. The atomic snapshot freezing module 160 is connected to the frozen snapshot query module 180, the version repository 410, and the task snapshot repository 420, respectively. The frozen snapshot query module 180 is connected to the result content snapshot repository 430.

[0053] The method of the present invention can be implemented by a processor executing a program stored in a computer-readable storage medium. The storage medium may be a disk, solid-state storage, or other non-transitory computer-readable medium.

[0054] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A method and system for controlling inspection tasks based on effective time point matching and atomic snapshot freezing, characterized in that, Includes the following steps: (S101) Establish a checklist version record: Each record includes the business key of the check object, version identifier, effective date, approval and release status, and set of check items; the version number is incremented based on the last released version of the same business key; (S102) Using the expected start time of the inspection task as the matching time, query the published versions with the same business key whose effective time is no later than the matching time, and select the target version in descending order of effective time and version number on the same day; (S103) When a new version is released or the plan is changed, determine whether the task snapshot is changeable based on the expected start time, approval status and whether there are already submission results. Only update variable tasks, and retain the original snapshots of tasks that are under approval, approved, or have already been executed; (S104) When the editable task saves the inspection results, refresh the version snapshot according to the expected start time, generate a set of valid inspection items, and write the inspection standards, contents, methods, types and options into the result content snapshot. (S105) Before submitting for approval, compare the set of answered check items with the set of valid check items in the target version; if there are invalid check items or missing required items, terminate the submission to avoid binding old answers to the new version. (S106) After the verification is passed, the target version snapshot and the frozen status are written in the same condition update, using the task identifier, the expected old version snapshot and the variable approval status as update conditions; if the number of affected rows is not one, rollback is performed and a refresh is prompted. (S107) Approval, anomaly query and historical result reproduction all use frozen version snapshot and inspection item content snapshot; after approval is returned, the version is rematched according to the expected start time and re-verified when resubmitted.

2. The inspection task control method based on effective time point matching and atomic snapshot freezing according to claim 1, characterized in that, The inspection object business key includes the inspection object type and the warehouse identifier or material category code corresponding to the inspection object type; the version identifier of the new inspection list version is generated incrementally based on the last released version identifier under the same inspection object business key, and does not change the version increment base based on the future effective time that has not yet arrived.

3. The inspection task control method based on effective time point matching and atomic snapshot freezing according to claim 1, characterized in that... Selecting the target checklist version includes: filtering checklist versions whose effective time is later than the expected start time; sorting the remaining checklist versions in descending order of their effective time; when at least two checklist versions have the same effective time, sorting them in descending order of their version identifiers; and selecting the first checklist version after sorting as the target checklist version.

4. The inspection task control method based on effective time point matching and atomic snapshot freezing according to claim 1, characterized in that, After the new checklist version is approved and released, the associated inspection plans and associated inspection tasks can be found based on the business key of the inspection object. A related inspection task will be designated as a snapshot variable task only if the expected start time of the related inspection task is not earlier than the effective date of the new checklist version, and the approval status of the related inspection task is empty, draft, or returned. Related inspection tasks that are under review, approved, or have already generated submission results should maintain the original version snapshot.

5. The inspection task control method based on effective time point matching and atomic snapshot freezing according to claim 1, characterized in that, Updating the snapshot version of a snapshot variable task includes: reselecting the corresponding target checklist version according to the expected start time of each snapshot variable task; replacing only the version identifier corresponding to the business key of the inspection object from the current version snapshot of the snapshot variable task, while retaining the version identifiers corresponding to other inspection objects.

6. The inspection task control method based on effective time point matching and atomic snapshot freezing according to claim 1, characterized in that, When the scope of an inspection plan changes, update the scope snapshot of incomplete inspection tasks with variable snapshots; when the time window of an inspection plan changes, rebuild inspection tasks that have not yet started, and retain inspection tasks that are in progress, under approval, or approved, in order to avoid generating inspection tasks repeatedly in the same time slot.

7. The inspection task control method based on effective time point matching and atomic snapshot freezing according to claim 1, characterized in that, The verification before submission for approval includes: generating a set of valid check item identifiers based on the target checklist version; extracting the set of answered check item identifiers from the saved inspection answers; determining whether the set of answered check item identifiers is a subset of the set of valid check item identifiers and determining whether the required check items of the target checklist version are complete; if any judgment is not satisfied, the submission is terminated and conflict information indicating that the checklist version has changed is returned.

8. The inspection task control method based on effective time point matching and atomic snapshot freezing according to claim 1, characterized in that, The update conditions for the conditional update include at least the following: the inspection task identifier is equal to the inspection task identifier to be submitted, the current version snapshot is equal to the expected old version snapshot, and the current approval status belongs to the preset variable approval status; when the number of affected records is not one, the current submitted transaction is rolled back and the client is instructed to reread the inspection task. When saving the inspection answer, the inspection standards, inspection content, inspection methods, inspection types and candidate options are also written into the inspection item content snapshot; after submission, when judging abnormal items and displaying historical results, the inspection item content snapshot is read, but the current definition of the variable inspection list is not read; After an inspection task is rejected by the approval process, the target checklist version is re-matched based on the expected start time of the inspection task; before resubmitting, the verification of the set of answered check items and the set of valid check items is re-executed, and a new approval process instance is generated only if the verification passes.

9. A patrol task control system based on effective time point matching and atomic snapshot freezing, characterized in that, include: The checklist version management module is used to establish checklist version records with the business key of the inspection object, version identifier, effective date, and approval release status; the effective date matching module is used to determine the closest target checklist version with the expected start date of the inspection task as the matching date; the variable task snapshot synchronization module is used to update the version snapshot only for inspection tasks that meet the expected start date and approval status conditions; and the check item and answer verification module is used to verify that the set of answered check items belongs to the valid set of check items of the target checklist version before submitting for approval. The atomic snapshot freeze module is used to atomically write the version snapshot and snapshot freeze status of the target checklist version based on the inspection task identifier, the expected old version snapshot and the variable approval status to perform condition updates. And a frozen snapshot query module, used to read frozen version snapshots and inspection item content snapshots during approval and result queries.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 10.

Images