A full-link data linkage and idempotency control method for reviewing product modification

Abstract

The application discloses a full-link data linkage and idempotency control method for reviewing product modification, and relates to the technical field of reviewing data processing.The method comprises the following steps: S1, performing pre-checking on the reviewing product according to a modification request, and then generating an idempotency identifier and storing the idempotency identifier in an idempotency control table; S2, obtaining reviewing data, creating a product modification main record, generating a product modification identifier, and generating a modification process node based on a reviewing process node record; S3, receiving a modified file and a modification detail, performing legality and idempotency checking based on a modification detail temporary table, and then, after passing the checking, associating the modified file and the modification detail into a database and synchronously updating a reviewing detail data table; and S4, approving the product modification process node, associating signing information when signing, and updating a product modification main record, a reviewing main record and an idempotency control table state after the end of the signing.The application has the advantages of high safety, strong consistency, repeated modification adaptation, good compatibility and the like, and solves the problems of data fragmentation, repeated operation, version disorder and difficult traceability.

Description

Technical Field

[0001] This invention relates to the field of proofreading data processing technology, specifically to a method for end-to-end data linkage and idempotency control of proofreading product modification. Background Technology

[0002] In fields such as engineering design, technology research and development, and product manufacturing, finished documents such as CAD drawings and technical reports need to undergo a complete review process before being finalized. After the review is completed, if design defects, parameter errors, or changes in requirements are found, a finished product modification process needs to be initiated. In the existing technology, the review and modification process for finished products has the following technical pain points: I. Fragmented Data Storage Architecture and Lack of Cross-Module Data Consistency Guarantee Mechanism: Review process data such as review records, countersigning information, and process nodes, as well as finished product modification data such as modification details, version information, and file updates, belong to different data storage modules. Lacking a full-link linkage mechanism, modified finished product data cannot be synchronously updated to the review system, leading to inconsistencies between review records and actual finished product versions. This makes subsequent traceability difficult and may even result in the misuse of old versions or omission of modifications, leading to a "version management out of control" dilemma, increasing rework costs and project delay risks. For example, a similar patent, CN108564300A, proposes an online collaborative review method for DWG drawings based on a process engine. This method improves the efficiency and quality of the review process on the basis of a traditional process engine, enabling data flow and simple saving of drawing versions within the review process. However, it lacks a temporary data isolation mechanism and does not establish a two-way linkage relationship between review data and modification data, failing to solve the core problem of cross-module data inconsistency. Second, the lack of idempotency makes data anomalies prone to occur: During the modification of the finished product, there are scenarios such as repeated calls to interfaces and repeated data entry due to network timeout retries and accidental duplicate submissions. Existing methods do not effectively control idempotency, resulting in problems such as duplicate creation of modification records, redundant modification details, and disordered process nodes, which seriously affect data consistency and process standardization. At the same time, the lack of a unified idempotency verification mechanism makes it impossible to cope with repeated operations in multiple scenarios and makes it difficult to ensure system stability. 3. Lack of data association logic in version iteration and low efficiency in tracing historical data: After the finished product is modified, especially after multiple modifications, a complete version chain cannot be formed. There is no clear relationship between the original review version and the modified version, as well as the historical modified version. The modified content, modification time, and the person responsible for the modification cannot be accurately traced. This can easily lead to problems such as version jumps, conflicting modified content, and data gaps. When disputes arise, it is difficult to define responsibility and restore the basis for decision-making. IV. Insufficient Process and Data Collaboration: The initiation and advancement of the finished product modification process are disconnected from data updates. Changes in the status of process nodes cannot synchronously trigger data verification and updates, and abnormal modified data cannot be promptly reported to the process stage, resulting in process bottlenecks and the inability to correct data errors in a timely manner, affecting modification efficiency. Although existing technologies have corresponding control methods for process management during the review process, none of them are specifically designed for the "finished product modification after review" scenario. They fail to organically combine temporary data transfer, idempotent anti-duplicate measures, and chained version association to achieve full-link data linkage and idempotency control, thus failing to solve the above pain points and making it difficult to meet the needs for efficient, accurate, and standardized finished product modification. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method for end-to-end data linkage and idempotency control in the revision of finished products. This method enables end-to-end collaborative linkage of revision data, revision data, and process data, ensuring data consistency during the revision process. At the same time, through the idempotency control mechanism, it avoids problems such as duplicate operations and data redundancy, and achieves traceability of revised versions, controllability of processes, and verifiability of data, thereby improving the consistency of data updates and the reliability of anomaly handling during the revision process.

[0004] To achieve the above objectives, the present invention provides a method for end-to-end data linkage and idempotency control in the review and approval of finished product modifications, specifically including the following steps: S1, Receive modification request for the finished product, perform pre-verification on the finished product according to the modification request, perform idempotency initialization after the pre-verification is passed, obtain idempotency identifier, and store the idempotency identifier and its initial state as a record in the idempotency control table. S2, obtain the verification data of the finished product according to the modification request, and generate modification data based on the modification request. The verification data is extracted from the verification detail data table; create a finished product modification master record, associate the finished product modification master record with the idempotency control table, and generate a unique finished product modification identifier; generate a finished product modification process node based on the finished product modification identifier, associate the finished product modification process node with the finished product modification master record, and initialize the process state of the finished product modification process node; S3, receive the modified and reviewed finished document and the modification details of the modified and reviewed finished document, wherein the modification data of the modified and reviewed finished document carries the idempotency identifier generated in S1, and perform legality verification and idempotency verification on the modified and reviewed finished document; The legality verification includes writing the modification details into a temporary modification details table, and comparing the modification details with the original data in the review details data table based on the temporary modification details table; In response to successful verification, the modification details of the revised and approved finished product document are associated with the finished product modification identifier and stored in the finished product modification details data table. The modification details of the revised and approved finished product document are also verified. The file information in the modification details of the verified and approved finished product document is synchronously updated to the revised and approved details data table. S4. Advance the process of the modified and reviewed finished product according to the finished product modification process nodes; respond to the status change of the finished product modification process node, update the process node record table synchronously, and perform data verification to confirm whether to enter the next finished product modification process node; when the finished product modification process node requires countersigning, initiate a countersigning request, extract the countersigning information from the review and approval detail data table and synchronously associate it with the finished product modification detail data table. Once all finished product modification process nodes are completed, the status of the finished product modification master record is updated to "Completed", and the status of the review master record in the review detail data table is updated to "Modified" simultaneously. At the same time, the status of the idempotency control table is updated to "Execution Completed".

[0005] Preferably, S1 specifically includes the following steps: S11, Receive a modification request for the reviewed finished product. The modification request includes at least the reviewed finished product identifier, the modification applicant ID, the reason for modification, and the reviewed finished product file to be modified. If the reviewed finished product has undergone two or more modifications, the modification request also includes the effective version identifier of the previous modification, which is used to retrieve and associate the data from the previous round of modifications. S12, Perform preliminary verification on the final product, the preliminary verification including at least: Verify whether the final proofreading process has been completed. If the final proofreading process has not been completed, reject the modification request. Also verify the legality of the final proofreading document to be modified. If the document is invalid, return an error message and reject the modification request. If the final product has undergone two or more revisions, the pre-verification also includes the validity of the effective version identifier of the previous revision; S13, after the pre-verification is passed, the reviewed finished product is initialized with idempotency, a unique idempotency identifier is generated, and the data of the idempotency identifier, the reviewed finished product identifier, the applicant ID, the reason for modification, and the idempotency identifier status are associated and stored in the idempotency control table. At the same time, the idempotency validity period and unique index constraint are set. The unique index is established based on the idempotency identifier field. For idempotency identifiers modified a second or more times, the previous idempotency identifier is appended to the original concatenation content. After the idempotency identifier is stored in the idempotency control table, the initial status is marked as "not executed". The idempotency identifier is generated by sequentially concatenating the finished product identifier, the applicant ID for modification, and the timestamp.

[0006] Preferably, S2 specifically includes the following steps: S21, based on the finished product identifier in the modification request, extract the associated data of the finished product from the review and approval detail data table. The associated data includes at least review and approval data and process data. If the finished product is modified for the first time, the review and approval data includes the review and approval master record, review and approval detail record, and countersigning information. The process data includes the review and approval process node record. The review and approval process node record is a pre-configured static process template that defines the process steps, flow order, and approval roles. If it is modified for the second or more times, the associated data also includes the review and approval master record, review and approval detail record, countersigning information, review and approval process node record, and effective version information of the previous modification. The master review record is used to record the review task information of each review product. The master review record includes the review version ID, review time, department, and number of modifications. The review detail record is used to save the file information of the review version of the review product for each review task. The review details include the product name, file path, PDF file, version number, and version status. S22, perform the association between the review data and the modified data of the finished product: create a finished product modification master record, which is used to record modified data, associate the finished product modification master record with the data in the idempotency control table, generate a finished product modification identifier, and synchronize the data of the review master record to the finished product modification master record, and synchronize the data of the review detail record to the modification detail temporary table; the modification detail temporary table is a temporary data transfer table, which is only used for data comparison and version reference in this modification. The data is not persistently stored after the process ends, so as to realize the isolation between operation data and formal archived data; if it is a second or more modifications, the finished product modification master record is also associated with the finished product modification master record of the previous modification, and the effective version information of the previous modification is synchronized to the modification detail temporary table; S23, perform the association between the process data and modification data of the finished product for review: based on the initial review process node configuration or the previous modification process node configuration stored in the review process node record, fully reuse the original process steps, flow order, and approval roles, generate the finished product modification process node, associate the finished product modification process node with the finished product modification master record, and initialize the finished product modification process status.

[0007] Preferably, S3 includes the following: S31, Receive the modified and proofread finished product file uploaded by the user and the modification details of the modified finished product file; S32, perform legality verification on the modified final product document based on the temporary modification details table. The legality verification includes at least the integrity verification of the modified content and the consistency verification of the file format. The file format consistency means that the file suffix, encoding, and file type are consistent with the base version in the temporary modification details table. If it is a second or more modification, the compatibility between the current modification content and the previous modification content needs to be verified. The modification details of the final product document should include at least the product name, the path to the modified file, and the path to the modified PDF file. Idempotency verification is performed on the modified and reviewed finished document: When receiving the modified data of the modified and reviewed finished document, the modified data carries the idempotency flag generated by S1. The status of the idempotency flag in the idempotency control table is queried to confirm whether the idempotency flag is in the "executed" state. If the idempotency flag status shows "executed," the processing result is returned directly, and the modification operation is not repeated. If the idempotency flag status shows "processing," the repeated request for modification is rejected. If the idempotency flag status shows "not executed" and is within the idempotency validity period, the idempotency flag status is updated to "processing," and the modification operation continues. If the idempotency flag status shows "expired," a prompt to re-initiate the modification request is returned. If it is a second or more modifications, the idempotency flag status of the previous modification is further verified to determine that the idempotency flag status of the previous modification is in the "executed" state. S33. Associate the modification details of the revised and approved finished product document with the finished product modification identifier and store it in the finished product modification details data table. Set a unique verification rule. The unique verification rule is to generate the finished product modification identifier and product name in sequence. If there is an undeleted modification record with the same finished product modification identifier and the same product name, determine to perform the old version content update operation; if there is no undeleted modification record with the same finished product modification identifier and the same product name, perform the modification details addition operation; if it is a second or more modifications, further associate it with the finished product modification identifier of the previous modification. S34, synchronize the file information in the modification details of the revised and reviewed final document to the review details data table, link the modification data with the review data, and update the version status based on the modification details temporary table; specifically including: If this is the first modification, the version status of the original review detail record in the modification details temporary table will be marked as "historical version", denoted as Level=1. The version status of the newly modified review detail record will be set as "current effective version", denoted as Level=0. The version number will be updated, and all historical versions will be associated with the current version through the ParentId field. If it is a second or more modification, the current effective version Level=0 of the previous modification in the modification details temporary table will be downgraded to the historical version Level=1. A new review detail record after this modification will be added as the "current effective version", denoted as Level=0, with the version number = the previous version number + 1. The ParentId of all historical versions will be uniformly updated to the ID of the newly added review detail record. At the same time, the latest review version ID and modification count information in the review master record of the review detail data table will be updated synchronously.

[0008] Preferably, S4 includes the following: S41, according to the finished product modification process nodes, perform the approval operation of the modified and reviewed finished product documents in sequence. Each approval operation generates a process approval record and stores it in the process node record table. The status change of each finished product modification process node is synchronously updated to the process node record table and triggers data verification. If the approval of a finished product modification process node is not approved, the modification opinion is returned and the process rollback is triggered to re-execute step S3. If the approval of the finished product modification process node is approved, proceed to the next finished product modification process node. During the process of the second and more modifications, the process approval record of the previous modification is synchronously linked for comparison of the content of each modification. S42, the finished product modification process node requests a countersigning request. If it is the first modification, the countersigner list is extracted from the countersigning information in the review and approval details data table. If it is the second or subsequent modification, the countersigner list of the previous modification is reused, and countersigning information can be added synchronously according to the current modification requirements. The countersigning result of the countersigning request is updated to the finished product modification master record in real time, and the countersigning information is associated with the finished product modification details data table. The countersigning information adopts a unique verification rule, and only historical countersigning data is appended and stored. Existing countersigning records are not overwritten or modified. S43, after all finished product modification process nodes are completed, update the status of the finished product modification master record to "completed", and simultaneously update the status of the review master record in the review detail data table to "modified", and mark the modification completion time and the person responsible for the modification; at the same time, update the status of the idempotency control table to "executed and completed", completing this modification operation; if it is a second or more modification, simultaneously update the "subsequent modification identifier field" of the previous finished product modification master record. The subsequent modification identifier is used to chain the two modification master records before and after, build a complete modification link, and associate it with the current finished product modification master record.

[0009] Preferably, the method also includes S5, which performs version tracing and idempotency review on the proofread product, specifically including: Based on the proofreading finished product identifier or finished product modification identifier, query the complete proofreading finished product version chain, including the original proofreading finished product version, the modification content of each modification version, the modification time, the person responsible for the modification, the process approval record, and the countersigning information; for two or more modifications, you can quickly locate all the data of the last modified proofreading finished product through the association identifier of the previous and subsequent modification master records and the version chain ID.

[0010] Prior to this, expired records in the idempotency control table are periodically cleaned up, the number of idempotency checks triggered and the number of duplicate request interceptions are counted, the idempotency validity period parameter is dynamically adjusted based on the statistical data, and the idempotency identifier generation strategy is optimized to improve the adaptability of idempotency control and the efficiency of duplicate request interception.

[0011] Prior to this, if any network interruption or system failure occurs during the modification process, the status of the corresponding idempotency flag in the idempotency control table remains "processing". After the system recovers, the idempotency flag is checked to determine whether the modification operation needs to be re-executed. If the status remains "processing" for longer than the preset abnormal recovery time, and it is confirmed that there is no ongoing modification transaction, the modification process is restored or restarted based on the baseline data in the temporary modification details table, and the abnormal log is automatically retained for fault investigation. If it is a second or more modifications, the status of the previous modification is additionally checked.

[0012] This invention intercepts duplicate concurrent write requests at the database level by introducing idempotency identifiers and unique index constraints; it achieves physical isolation between modified verification data and formal archived data by constructing a temporary data isolation table; and it solves the inconsistency problem of cross-module data updates through foreign key linkage between master and slave tables and state machine synchronization. Compared with existing technologies, this invention has the following advantages: 1) This invention achieves full-link data linkage and solves the problem of data fragmentation. It establishes a two-way linkage mechanism for review data, modified data, and process data. Modified data can be synchronously updated to the review system. Process nodes and data updates are triggered bidirectionally to ensure data consistency and avoid version confusion and data disconnection.

[0013] 2) The multi-dimensional idempotency control of this invention ensures data security. It forms a complete control system through idempotency identification, unique index, and multi-level verification, effectively intercepting duplicate requests, avoiding duplicate data entry and process disorder, and improving system stability.

[0014] 3) The version chain of the present invention is complete and traceable throughout the process. With hierarchical version management, it can achieve accurate association between the original review version and each modified version. The modified content, responsible persons, and approval records can be queried based on the version chain, which makes it easy to restore the data status of each version and the corresponding process records.

[0015] 4) This invention is adaptable to multiple modifications, improving modification efficiency. Through chain linkage and process reuse, it supports unlimited iterative modifications without the need to repeatedly configure processes and basic data, reducing invalid operations, standardizing modification processes, and has strong versatility.

[0016] 5) The present invention has good compatibility and scalability. It can be directly adapted to the existing review process system and data architecture based on existing data tables. No large-scale modification is required. Only the addition of linkage and idempotency modules is needed for implementation. The rules can be flexibly adjusted according to different industries and scenarios. Attached Figure Description

[0017] Figure 1 This is a flowchart of the end-to-end data linkage and idempotency control method for modifying the proofreading product according to an embodiment of the present invention.

[0018] Figure 2 The flowchart below shows the specific steps of step S1 of the end-to-end data linkage and idempotency control method for the modification of the proofreading finished product according to an embodiment of the present invention.

[0019] Figure 3 The flowchart below shows the specific steps of step S2 in the method for full-link data linkage and idempotency control of the proofreading and reviewing finished product modification according to an embodiment of the present invention.

[0020] Figure 4 This is a flowchart of step S3 of the end-to-end data linkage and idempotency control method for modifying the proofreading product according to an embodiment of the present invention.

[0021] Figure 5 The flowchart below shows the specific steps of step S4 in the end-to-end data linkage and idempotency control method for the modification of the proofreading product according to an embodiment of the present invention.

[0022] Figure 6 This is a flowchart illustrating the process of updating the version of the end-to-end data linkage and idempotency control method for modifying the final product according to an embodiment of the present invention. Detailed Implementation

[0023] The present invention will be further described in detail below with reference to specific embodiments.

[0024] The specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of protection of this invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this invention should be included within the scope of protection of this invention.

[0025] This embodiment uses the scenario of modifying the finished product after CAD drawing review as an example to illustrate the specific implementation process of the present invention. The scope of protection of the present invention is not limited to this embodiment.

[0026] like Figures 1-2This invention provides a method for end-to-end data linkage and idempotency control in the review and approval of finished product modifications, specifically including the following steps: S1, Receive modification requests for the reviewed finished product, perform pre-verification on the reviewed finished product according to the modification requests, and after the pre-verification passes, perform idempotency initialization to obtain an idempotency identifier, and store the idempotency identifier and its initial state as a record in the idempotency control table. Specifically, this includes the following steps: S11, Receive a modification request for the reviewed finished product. The modification request includes at least the reviewed finished product identifier, the modification applicant ID, the reason for modification, and the reviewed finished product file to be modified. If the reviewed finished product has undergone two or more modifications, the modification request also includes the effective version identifier of the previous modification, which is used to retrieve and associate the data from the previous round of modifications.

[0027] In this embodiment, the designer initiates a modification request through the system, which includes: reviewing the finished product identifier ( :123456), Modify Applicant ID :789), Reason for modification (incorrect drawing dimensions, needs correction), Final file to be modified and reviewed (.dwg format CAD drawing). This example is the first modification and does not require an effective version identifier.

[0028] S12, Perform preliminary verification on the final product, the preliminary verification including at least: Verify whether the final proofreading process has been completed. If the final proofreading process has not been completed, reject the modification request. Also verify the legality of the final proofreading document to be modified. If the document is invalid, return an error message and reject the modification request. If the final product has undergone two or more revisions, the pre-verification also includes the validity of the effective version identifier of the previous revision.

[0029] In this embodiment, the system queries the main review record to confirm that the review result status is completed; verifies that the file to be modified is in .dwg format and that the content is complete and undamaged; the first modification does not require verification of the historical version identifier, and the pre-verification passes.

[0030] S13, after the pre-verification is passed, the reviewed finished product is initialized with idempotency, a unique idempotency identifier is generated, and the data of the idempotency identifier, the reviewed finished product identifier, the applicant ID, the reason for modification, and the idempotency identifier status are associated and stored in the idempotency control table. At the same time, the idempotency validity period and unique index constraint are set. The unique index is established based on the idempotency identifier field. For idempotency identifiers modified a second or more times, the previous idempotency identifier is appended to the original concatenation content. After the idempotency identifier is stored in the idempotency control table, the initial status is marked as "not executed". The idempotency identifier is generated by sequentially concatenating the finished product identifier, the applicant ID for modification, and the timestamp.

[0031] In this embodiment, a unique idempotency identifier is generated: 123456_789_20260301093000 (final product identifier + applicant ID + timestamp); the idempotency identifier, final product identifier, applicant ID, reason for modification, and idempotency identifier status (not executed) are stored in the idempotency control table; the idempotency validity period is set to 30 minutes, and a unique index is established for the idempotency identifier field. This invention, by generating a unique idempotency identifier and setting a unique index at the database level, ensures that even in high-concurrency or network retry scenarios, repeated operations on the same modification request will be identified and intercepted by the system, thereby guaranteeing data consistency and process uniqueness, effectively solving the problems of data redundancy and process disorder caused by repeated submissions in existing technologies.

[0032] like Figure 1 , Figure 3 S2, based on the modification request, obtain the verification data of the finished product, and generate modification data based on the modification request. The verification data is extracted from the verification detail data table. Create a finished product modification master record, associate the finished product modification master record with the idempotency control table, and generate a unique finished product modification identifier. Generate a finished product modification process node based on the finished product modification identifier, associate the finished product modification process node with the finished product modification master record, and initialize the process state of the finished product modification process node. Specifically, this includes the following steps: S21, based on the finished product identifier in the modification request, extract the associated data of the finished product from the review and approval detail data table. The associated data includes at least the review and approval data and the process data. If the finished product is modified for the first time, the review and approval data includes the review and approval master record, the review and approval detail record, and the countersigning information. The process data includes the review and approval process node record. The review and approval process node record is a pre-configured static process template that defines the process steps, the flow order, and the approval roles. If it is modified for the second or more times, the associated data also includes the review and approval master record, the review and approval detail record, the countersigning information, the review and approval process node record, and the effective version information of the previous modification.

[0033] The master review record is used to record the review task information of each review product. The master review record includes the review version ID, review time, department, and number of modifications. The review detail record is used to save the file information of the review version of the review product for each review task. The review details include the product name, file path, PDF file, version number, and version status.

[0034] In this embodiment, based on the finished product identifier 123456, the following review data is extracted: Review Master Record (Review Version) Proofreading date: 2026-03-01; Department: [Name of Department] :456, Number of revisions: 0); Proofreading details (Product Name CAD Drawing - Architectural Floor Plan, File Path, PDF Path, Version Number) Countersigning information (in the SCGL_SignDetails table) (The signatories); Process data: Review process node records (static process template, including process steps, flow order and approval roles).

[0035] S22, perform the association between the review data and the modified data of the finished product: create a finished product modification master record, which is used to record modified data, associate the finished product modification master record with the data in the idempotency control table, generate a finished product modification identifier, and synchronize the data of the review master record to the finished product modification master record, and synchronize the data of the review detail record to the modification detail temporary table; the modification detail temporary table is a temporary data transfer table, which is only used for data comparison and version reference in this modification. The data is not persistently stored after the process ends, so as to isolate the operation data from the formal archived data; if it is a second or more modifications, the finished product modification master record is also associated with the finished product modification master record of the previous modification, and the effective version information of the previous modification is synchronized to the modification detail temporary table.

[0036] In this embodiment, a finished product modification master record is created ( (654321); associate the finished product identifier, idempotency identifier, modification applicant ID, and modification reason to generate the finished product modification identifier 654321; synchronize the master record data of the review to the finished product modification master record, and synchronize the detailed record data of the review to the modification details temporary table.

[0037] All data comparison and verification operations in this process read the baseline data in the temporary modification details table. After the current modification process is completed, the data in the temporary modification details table is cleared to achieve physical isolation between the operation data and the formal archived data.

[0038] S23, perform the association between the process data and modification data of the finished product for review: based on the initial review process node configuration or the previous modification process node configuration stored in the review process node record, fully reuse the original process steps, flow order, and approval roles, generate the finished product modification process node, associate the finished product modification process node with the finished product modification master record, and initialize the finished product modification process status.

[0039] In this embodiment, based on the review and approval process node records (static process template), :789012), fully reuses the reviewers, approval nodes, and workflow sequence to generate finished product modification process nodes; associated with the finished product modification master record ( (654321), the initial process status is pending approval.

[0040] like Figure 1 , Figure 4 S3, receiving the modified and reviewed finished document and its modification details, wherein the modified data of the modified and reviewed finished document carries the idempotency identifier generated in S1, and performing legality and idempotency checks on the modified and reviewed finished document; the legality check includes writing the modification details into a temporary modification details table, and comparing the modification details with the original data in the review details data table based on the temporary modification details table; in response to passing the check, associating the modification details of the modified and reviewed finished document with the finished document modification identifier, storing it in the finished document modification details data table, and checking the modification details of the modified and reviewed finished document; synchronously updating the file information in the modified details of the checked and reviewed finished document to the review details data table. Includes the following: S31, Receive the modified and proofread finished product file uploaded by the user, as well as the modification details of the modified finished product file.

[0041] In this embodiment, the modified CAD drawing file and modification details are uploaded (product name CAD drawing - architectural floor plan, modified file path, modified PDF path).

[0042] S32. Based on the temporary modification details table, perform a legality check on the revised and reviewed final document. This legality check includes at least verifying the completeness of the modified content and the consistency of the file format. File format consistency refers to the file extension, encoding, and file type being consistent with the base version in the temporary modification details table. If there are two or more modifications, the compatibility between the current modification and the previous modification must be verified. Specifically, the current modification details are written to the temporary modification details table, and based on this table, the modification details are compared with the original data in the review details data table to confirm that the modified content is complete and without omissions, and that the file format is consistent with the original file format.

[0043] The modification details of the final product document should include at least the product name, the path to the modified file, and the path to the modified PDF file.

[0044] Idempotency verification is performed on the modified and reviewed finished document: When receiving modified data of the modified and reviewed finished document, the modified data carries the idempotency flag generated by S1. The status of the idempotency flag in the idempotency control table is queried to confirm whether the idempotency flag is in the "executed" state. If the idempotency flag status shows "executed," the processing result is returned directly, and the modification operation is not repeated. If the idempotency flag status shows "processing," the repeated request for modification is rejected. If the idempotency flag status shows "not executed" and is within the idempotency validity period, the idempotency flag status is updated to "processing," and the modification operation continues. If the idempotency flag status shows "expired," a prompt to re-initiate the modification request is returned. If it is a second or more modifications, the idempotency flag status of the previous modification is further verified to determine that the idempotency flag status of the previous modification is in the "executed" state.

[0045] In this embodiment, the modification details are written to a temporary modification details table and compared with the original data in the review details data table. The legality check passes (content is complete and file format is consistent). The idempotency identifier 123456_789_20260301093000 carried in the uploaded data is read, and the idempotency control table is queried. The current status is not executed and within the validity period. The system updates it to processing, allowing the modification process to continue, and there is no duplicate request blocking.

[0046] S33. Associate the modification details of the revised and approved finished product document with the finished product modification identifier and store it in the finished product modification details data table. Set a unique verification rule. The unique verification rule is to generate the finished product modification identifier and product name in sequence. If there is an undeleted modification record with the same finished product modification identifier and the same product name, determine to perform the old version content update operation; if there is no undeleted modification record with the same finished product modification identifier and the same product name, then perform the modification details addition operation; if it is a second or more modifications, then further associate it with the finished product modification identifier of the previous modification.

[0047] In this embodiment, the modification details are associated with the finished product modification identifier 654321 and stored in the finished product modification details data table; after verification by finished product modification identifier + product name, if there are no duplicate records, the modification details addition operation is performed.

[0048] like Figure 6 As shown in S34, the file information in the modification details of the revised and reviewed finished document is synchronously updated to the review details data table to link the modification data with the review data, and the version status is updated based on the modification details temporary table; specifically including: If this is the first modification, the version status of the original review details record in the temporary modification details table will be marked as "historical version". The version status of the newly added and modified proofreading details record is recorded as "Current Effective Version". It also updates the version number and associates all historical versions with the current version through the ParentId field; If it is a second or subsequent modification, the current effective version of the previous modification in the temporary modification details table will be modified. Downgraded to a historical version The revised proofreading details record has been added as the "current effective version" and is recorded as follows. The version number is equal to the previous version number plus 1. The ParentId of all historical versions is updated to the ID of the newly added review and approval detail record. At the same time, the latest review and approval version ID and modification count information in the review and approval master record of the review and approval detail data table are updated synchronously.

[0049] This embodiment represents the first modification, downgrading the review details record with the original version number 1 to a historical version. The revised proofreading details record has been added, with the version number updated to 2, and marked as the currently effective version. The ParentId field is used to associate historical versions with the detailed ID of the newly added version; the latest review version ID and modification count of the review master record are updated synchronously, and the modification count is updated from 0 to 1, realizing the full-link linkage update of modified data and original review data.

[0050] like Figure 1 , Figure 5 S4, proceed with the process of reviewing the modified finished product according to the finished product modification process nodes; respond to the status change of the finished product modification process node, synchronously update the process node record table, and perform data verification to confirm whether to enter the next finished product modification process node; when the finished product modification process node requires countersigning, initiate a countersigning request, extract the countersigning information from the review detail data table and synchronously associate it with the finished product modification detail data table; when all finished product modification process nodes are completed, update the status of the finished product modification master record to "completed", and synchronously update the status of the review master record in the review detail data table to "modified", and at the same time update the status of the idempotency control table to "execution completed". Specifically, this includes the following steps: S41, according to the finished product modification process nodes, perform the approval operation of the modified and reviewed finished product documents in sequence. Each approval operation generates a process approval record and stores it in the process node record table. The status change of each finished product modification process node is synchronously updated to the process node record table and triggers data verification. If the approval of a finished product modification process node is not approved, the modification opinion is returned and the process rollback is triggered to re-execute step S3. If the approval of the finished product modification process node is approved, proceed to the next finished product modification process node. During the process of the second and subsequent modifications, the process approval record of the previous modification is synchronously linked for comparison of the content of each modification.

[0051] In this embodiment, the system advances the approval process sequentially according to the preset finished product modification process nodes. After each node approval is completed, the node status is updated to the process node record table in real time and the data consistency verification is automatically completed. Since all node approvals are approved in this instance, the process proceeds downwards level by level without triggering a rollback.

[0052] S42, the finished product modification process node requests a countersigning agreement. If it is the first modification, the list of countersigners is extracted from the countersigning information in the review and approval details data table. If it is the second or subsequent modification, the list of countersigners from the previous modification is reused, and new countersigning information can be added synchronously according to the current modification requirements. The countersigning result of the countersigning request is updated to the finished product modification master record in real time, and the countersigning information is associated with the finished product modification details data table. The countersigning information adopts a unique verification rule, and only historical countersigning data is appended and stored. Existing countersigning records are not overwritten or modified.

[0053] This embodiment is the first modification. The system extracts the original list of countersigners from the review and approval details data table and initiates a countersigning request. After each countersigner completes the review, the countersigning result is written back to the finished product modification master record in real time, and the countersigning details are associated and stored in the finished product modification details data table. The countersigning data adopts the append storage rule, which does not overwrite or modify the existing countersigning records, ensuring that all countersigning records are traceable and not lost.

[0054] S43, after all finished product modification process nodes are completed, update the status of the finished product modification master record to "completed", and simultaneously update the status of the review master record in the review detail data table to "modified", and mark the modification completion time and the person responsible for the modification; at the same time, update the status of the idempotency control table to "executed and completed", completing this modification operation; if it is a second or more modification, simultaneously update the "subsequent modification identifier field" of the previous finished product modification master record. The subsequent modification identifier is used to chain the two modification master records before and after, build a complete modification link, and associate it with the current finished product modification master record.

[0055] This is the first modification. After all process nodes have been approved and countersigned, the system will update the status of the final product modification master record to "Completed" and the status of the review master record to "Modified," automatically marking the modification completion time as 2026-03-01 10:00:00 and the ID of the person responsible for the modification. Simultaneously, the status of the corresponding record in the idempotency control table is updated to "executed," marking the completion of the entire process for this final review and modification. The initial modification does not involve updating the subsequent modification identifier field of the previous modification.

[0056] S5 performs version tracing and idempotency review of the proofread and reviewed products: Based on the proofreading finished product identifier or finished product modification identifier, query the complete proofreading finished product version chain, including the original proofreading finished product version, the modification content of each modification version, the modification time, the person responsible for the modification, the process approval record, and the countersigning information; for two or more modifications, you can quickly locate all the data of the last modified proofreading finished product through the association identifier of the previous and subsequent modification master records and the version chain ID.

[0057] In this embodiment, the unique identifier of the final product can be used to fully trace the version chain: initial review version (version 1, historical versions) Version 2 is currently in effect. This allows for one-click retrieval of all modification details, operation time, responsible party, and the entire process of approval and countersigning, enabling full-chain traceability and review. This embodiment focuses on the initial modification and does not involve locating the previous modification through associated identifiers.

[0058] As a preferred embodiment, expired records in the idempotency control table are periodically cleaned up, the number of idempotency checks triggered and the number of duplicate request interceptions are counted, the idempotency validity period parameter is dynamically adjusted based on the statistical data, and the idempotency flag generation strategy is optimized to improve the adaptability of idempotency control and the efficiency of duplicate request interception.

[0059] In this embodiment, the system is set to automatically clean up expired idempotent records with a validity period of more than 30 minutes every day at midnight, and to count the number of idempotent verification triggers and duplicate request interceptions during the day, continuously optimizing the idempotent validity period parameters and the identifier generation strategy to improve system stability.

[0060] In a preferred embodiment, if any of the following occurs during the modification process: network interruption or system failure, the status of the corresponding idempotency identifier in the idempotency control table remains "processing". After the system recovers, the idempotency identifier is checked to determine whether the modification operation needs to be re-executed. If the status remains "processing" for longer than the preset anomaly recovery time, and it is confirmed that there is no ongoing modification transaction, the modification process is restored or restarted based on the baseline data in the modification details temporary table, and the anomaly log is automatically retained for troubleshooting. If it is a second or more modifications, the status of the previous modification is additionally checked.

[0061] In this embodiment, the system captures all anomalies during the modification process and records them in logs for easy investigation and review. After the system recovers, if the idempotency flag remains in the processing state for more than the preset anomaly recovery time, and it is confirmed that there are no ongoing modification transactions, the system reads the baseline data from the modification details temporary table to restore or restart the process, and records the anomaly time and anomaly type in the log.

[0062] The above embodiments merely illustrate several implementations of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention.

Claims

1. A method for end-to-end data linkage and idempotency control in the review and approval of finished product modifications, characterized in that, Specifically, the following steps are included: S1, Receive modification request for the finished product, perform pre-verification on the finished product according to the modification request, perform idempotency initialization after the pre-verification is passed, obtain idempotency identifier, and store the idempotency identifier and its initial state as a record in the idempotency control table. S2, obtain the verification data of the finished product according to the modification request, and generate modification data based on the modification request. The verification data is extracted from the verification detail data table; create a finished product modification master record, associate the finished product modification master record with the idempotency control table, and generate a unique finished product modification identifier; generate a finished product modification process node based on the finished product modification identifier, associate the finished product modification process node with the finished product modification master record, and initialize the process state of the finished product modification process node; S3, receive the modified and reviewed finished document and the modification details of the modified and reviewed finished document, wherein the modification data of the modified and reviewed finished document carries the idempotency identifier generated in step S1, and perform legality verification and idempotency verification on the modified and reviewed finished document; The legality verification includes writing the modification details into a temporary modification details table, and comparing the modification details with the original data in the review details data table based on the temporary modification details table; In response to successful verification, the modification details of the revised and reviewed finished product document are associated with the finished product modification identifier and stored in the finished product modification details data table. The modification details of the revised and reviewed finished product document are then verified. The file information in the modification details of the verified and reviewed finished document will be synchronously updated to the review details data table. S4, proceed with the process of reviewing and verifying the modified finished product according to the process nodes of the finished product modification process; In response to the status change of the finished product modification process node, the process node record table is updated synchronously, and data verification is performed to confirm whether to proceed to the next finished product modification process node; when the finished product modification process node requires countersigning, a countersigning request is initiated, the countersigning information in the review and approval detail data table is extracted and synchronously associated with the finished product modification detail data table. Once all finished product modification process nodes are completed, the status of the finished product modification master record is updated to "Completed", and the status of the review master record in the review detail data table is updated to "Modified" simultaneously. At the same time, the status of the idempotency control table is updated to "Execution Completed".

2. The method according to claim 1, characterized in that, S1 specifically includes the following steps: S11, Receive a modification request for the reviewed finished product. The modification request includes at least the reviewed finished product identifier, the modification applicant ID, the reason for modification, and the reviewed finished product file to be modified. If the reviewed finished product has undergone two or more modifications, the modification request also includes the effective version identifier of the previous modification, which is used to retrieve and associate the data from the previous round of modifications. S12, Perform preliminary verification on the final product, the preliminary verification including at least: Verify whether the final proofreading process has been completed. If the final proofreading process has not been completed, reject the modification request. Also verify the legality of the final proofreading document to be modified. If the document is invalid, return an error message and reject the modification request. If the final product has undergone two or more revisions, the pre-verification also includes the validity of the effective version identifier of the previous revision; S13, after the pre-verification is passed, the reviewed finished product is initialized with idempotency, a unique idempotency identifier is generated, and the data of the idempotency identifier, the reviewed finished product identifier, the applicant ID, the reason for modification, and the idempotency identifier status are associated and stored in the idempotency control table. At the same time, the idempotency validity period and unique index constraint are set; the unique index is established based on the idempotency identifier field; for idempotency identifiers modified a second or more times, the previous idempotency identifier is appended to the original concatenation content; after the idempotency identifier is stored in the idempotency control table, the initial status is marked as "not executed"; The idempotency identifier is generated by sequentially concatenating the finished product identifier, the applicant ID for modification, and the timestamp.

3. The method according to claim 2, characterized in that, S2 specifically includes the following steps: S21, based on the finished product identifier in the modification request, extract the associated data of the finished product from the review and approval detail data table. The associated data includes at least review and approval data and process data. If the finished product is modified for the first time, the review and approval data includes the review and approval master record, review and approval detail record, and countersigning information. The process data includes the review and approval process node record. The review and approval process node record is a pre-configured static process template that defines the process steps, flow order, and approval roles. If it is modified for the second or more times, the associated data also includes the review and approval master record, review and approval detail record, countersigning information, review and approval process node record, and effective version information of the previous modification. The master review record is used to record the review task information of each review product. The master review record includes the review version ID, review time, department, and number of modifications. The review detail record is used to save the file information of the review version of the review product for each review task. The review details include the product name, file path, PDF file, version number, and version status. S22, perform the association between the review data and the modified data of the finished product: create a finished product modification master record, which is used to record modified data, associate the finished product modification master record with the data in the idempotency control table, generate a finished product modification identifier, and synchronize the data of the review master record to the finished product modification master record, and synchronize the data of the review detail record to the modification detail temporary table; the modification detail temporary table is a temporary data transfer table, which is only used for data comparison and version reference in this modification. The data is not persistently stored after the process ends, so as to realize the isolation between operation data and formal archived data; if it is a second or more modifications, the finished product modification master record is also associated with the finished product modification master record of the previous modification, and the effective version information of the previous modification is synchronized to the modification detail temporary table; S23, perform the association between the process data and modification data of the finished product for review: based on the initial review process node configuration or the previous modification process node configuration stored in the review process node record, fully reuse the original process steps, flow order, and approval roles, generate the finished product modification process node, associate the finished product modification process node with the finished product modification master record, and initialize the finished product modification process status.

4. The method according to claim 3, characterized in that, S3 includes the following: S31, Receive the modified and proofread finished product file uploaded by the user and the modification details of the modified finished product file; S32, perform legality verification on the modified final product document based on the temporary modification details table. The legality verification includes at least the integrity verification of the modified content and the consistency verification of the file format. The file format consistency means that the file suffix, encoding, and file type are consistent with the base version in the temporary modification details table. If it is a second or more modification, the compatibility between the current modification content and the previous modification content needs to be verified. The modification details of the final product document should include at least the product name, the path to the modified file, and the path to the modified PDF file. Idempotency verification is performed on the modified and reviewed finished document: When receiving the modified data of the modified and reviewed finished document, the modified data carries the idempotency flag generated by S1. The status of the idempotency flag in the idempotency control table is queried to confirm whether the idempotency flag is in the "executed" state. If the idempotency flag status shows "executed," the processing result is returned directly, and the modification operation is not repeated. If the idempotency flag status shows "processing," the repeated request for modification is rejected. If the idempotency flag status shows "not executed" and is within the idempotency validity period, the idempotency flag status is updated to "processing," and the modification operation continues. If the idempotency flag status shows "expired," a prompt to re-initiate the modification request is returned. If it is a second or more modifications, the idempotency flag status of the previous modification is further verified to determine that the idempotency flag status of the previous modification is in the "executed" state. S33. Associate the modification details of the revised and approved finished product document with the finished product modification identifier and store it in the finished product modification details data table. Set a unique verification rule. The unique verification rule is to generate the finished product modification identifier and product name in sequence. If there is an undeleted modification record with the same finished product modification identifier and the same product name, determine to perform the old version content update operation; if there is no undeleted modification record with the same finished product modification identifier and the same product name, perform the modification details addition operation; if it is a second or more modifications, further associate it with the finished product modification identifier of the previous modification. S34, synchronize the file information in the modification details of the revised and reviewed final document to the review details data table, link the modification data with the review data, and update the version status based on the modification details temporary table; specifically including: If this is the first modification, mark the version status of the original review detail record in the modification details temporary table as "historical version", denoted as Level=1, and mark the version status of the newly modified review detail record as "current effective version", denoted as Level=0. Update the version number and associate all historical versions with the current version through the ParentId field. If it is a second or more modification, the current effective version Level=0 of the previous modification in the modification details temporary table will be downgraded to the historical version Level=1. A new review detail record after this modification will be added as the "current effective version", denoted as Level=0, with the version number = the previous version number + 1. The ParentId of all historical versions will be uniformly updated to the ID of the newly added review detail record. At the same time, the latest review version ID and modification count information in the review master record of the review detail data table will be updated synchronously.

5. The method according to claim 1, characterized in that, S4 includes the following: S41, according to the finished product modification process nodes, the approval operation of the modified and reviewed finished product documents is carried out in sequence. Each approval operation generates a process approval record and stores it in the process node record table. The status change of each finished product modification process node is synchronously updated to the process node record table and triggers data verification. If the approval of a certain process node for modifying a finished product is not approved, the modification comments will be returned and the process rollback will be triggered to re-execute step S3; If the approval of a finished product modification process node is approved, proceed to the next finished product modification process node; during the process of two or more modifications, the approval record of the previous modification process is synchronously linked for comparison of the content of each modification. S42, the finished product modification process node requests a countersigning request. If it is the first modification, the countersigner list is extracted from the countersigning information in the review and approval details data table. If it is the second or subsequent modification, the countersigner list of the previous modification is reused, and countersigning information can be added synchronously according to the current modification requirements. The countersigning result of the countersigning request is updated to the finished product modification master record in real time, and the countersigning information is associated with the finished product modification details data table. The countersigning information adopts a unique verification rule, and only historical countersigning data is appended and stored. Existing countersigning records are not overwritten or modified. S43, after all finished product modification process nodes are completed, the status of the finished product modification master record is updated to "completed", and the status of the review master record in the review detail data table is updated to "modified" simultaneously, and the modification completion time and the person responsible for the modification are marked; at the same time, the status of the idempotency control table is updated to "executed and completed", completing this modification operation; if it is a second or more modification, the "subsequent modification identifier field" of the previous finished product modification master record is updated simultaneously. The subsequent modification identifier is used to link the two modification master records in a chain, construct a complete modification link, and associate it with the current finished product modification master record.

6. The method according to claim 2, characterized in that, The method also includes S5, which performs version tracing and idempotency review on the proofread and reviewed product, specifically including: Based on the proofreading finished product identifier or finished product modification identifier, query the complete proofreading finished product version chain, including the original proofreading finished product version, the modification content of each modification version, the modification time, the person responsible for the modification, the process approval record, and the countersigning information; for two or more modifications, you can quickly locate all the data of the last modified proofreading finished product through the association identifier of the previous and subsequent modification master records and the version chain ID.

7. The method according to claim 2, characterized in that, The expired records in the idempotency control table are cleaned up periodically. The number of idempotency checks triggered and the number of duplicate requests blocked are counted. The idempotency validity period parameter is dynamically adjusted based on the statistical data, and the idempotency flag generation strategy is optimized to improve the adaptability of idempotency control and the efficiency of duplicate request blocking.

8. The method according to claim 2, characterized in that, If any network interruption or system failure occurs during the modification process, the status of the corresponding idempotency flag in the idempotency control table remains "processing". After the system recovers, the idempotency flag is checked to determine whether the modification operation needs to be re-executed. If the status remains "processing" for longer than the preset abnormal recovery time, and it is confirmed that there is no ongoing modification transaction, the modification process is restored or restarted based on the baseline data in the temporary modification details table, and the abnormal log is automatically retained for troubleshooting. If it is a second or more modifications, the status of the previous modification is additionally checked.

Images